From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21290 invoked by alias); 4 Dec 2012 05:32:46 -0000 Received: (qmail 21263 invoked by uid 22791); 4 Dec 2012 05:32:45 -0000 X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from p02c11o147.mxlogic.net (HELO p02c11o147.mxlogic.net) (208.65.144.80) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 04 Dec 2012 05:32:38 +0000 Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c11o147.mxlogic.net(mxl_mta-6.16.0-0) with ESMTP id 4fa8db05.0.176196.00-2291.387856.p02c11o147.mxlogic.net (envelope-from ); Mon, 03 Dec 2012 22:32:37 -0700 (MST) X-MXL-Hash: 50bd8af527993a11-73caa52af325278a38160688c4e7d120aecec094 Received: from smtpauth1.linear.com (localhost [127.0.0.1]) by smtpauth1.linear.com (Postfix) with ESMTP id CE0D0740A5; Mon, 3 Dec 2012 21:32:35 -0800 (PST) Received: from [192.168.0.119] (75-163-186-131.clsp.qwest.net [75.163.186.131]) by smtpauth1.linear.com (Postfix) with ESMTPSA id 5D337740A2; Mon, 3 Dec 2012 21:32:35 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Michael Jones In-Reply-To: <50BCF9AD.7030309@siva.com.mk> Date: Tue, 04 Dec 2012 05:32:00 -0000 Cc: eCos Discussion Content-Transfer-Encoding: quoted-printable Message-Id: <7E4912AF-4819-49DA-95C3-225AF53F0A42@linear.com> References: <88A5F92E-1AE1-4246-B566-3EFE5DEA360B@linear.com> <50BB299F.5070404@siva.com.mk> <50BCF9AD.7030309@siva.com.mk> To: Ilija Kocho X-AnalysisOut: [v=2.0 cv=X+vl3hve c=1 sm=1 a=glloKNylpeYNumXQcclYyA==:17 a] X-AnalysisOut: [=gTASQVg5WCMA:10 a=D2_GN2MmYMYA:10 a=BLceEmwcHowA:10 a=8nJ] X-AnalysisOut: [EP1OIZ-IA:10 a=MqDINYqSAAAA:8 a=l9cmVeDug7kA:10 a=O8eIFpr9] X-AnalysisOut: [AAAA:8 a=CCpqsmhAAAAA:8 a=zPWV44wpYwG8DDA7Pk8A:9 a=wPNLvfG] X-AnalysisOut: [TeEIA:10 a=FaqvLmL-nz4ZJtJ5:21 a=cZ6hsclZxrvaPwB-:21] X-MAIL-FROM: X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Kinetis CYG_HAL_STARTUP_VAR conflict X-SW-Source: 2012-12/txt/msg00015.txt.bz2 IIija, I have some questions: - Is the Kinetis rev 1/2 silicon rev or Tower rev? I have part number PK60n= 512vmd100. Best I can tell the silicon rev is 1, because there is no number= between 512 and V. The Tower board is Rev A. Can you disambiguate things f= or me? - If I turn off unified Ram, the configuration does not build. Any idea why= ? I verified this by deleting the build and install dirs, the building. Not= hing is creating. I was attempting to see if it fixed the problem. Is there= a log somewhere to look at for clues? - I would like to verify that you don't add the RedBoot package to the appl= ication to work with the monitor. I assume that enabling Working with a ROM= monitor is all that is needed. Just being paranoid :-) - On the virtual vector table that is shared by the Rom monitor and applica= iton, I dug up the linker settings. The Rom Monitor has this: hal_vsr_table =3D (0x20000000 - CYGHWR_HAL_KINETIS_SRAM_BANK_SIZE); hal_virtual_vector_table =3D hal_vsr_table + 128*4; hal_startup_stack =3D 0x20000000 + CYGHWR_HAL_KINETIS_SRAM_BANK_SIZE; The application using RAM has this: hal_vsr_table =3D (0x20000000 - CYGHWR_HAL_KINETIS_SRAM_BANK_SIZE); hal_virtual_vector_table =3D hal_vsr_table + 128*4; hal_startup_stack =3D 0x20000000 + CYGHWR_HAL_KINETIS_SRAM_BANK_SIZE; I am not sure which of these are to be shared. I think the virtual vector t= able are shared so that the monitor will work. I would think the startup st= ack would not be shared. And the hal_vsr_table might be shared, but I am no= t sure. Does the RAM setup need to have these changed? =20=20=20=20 Mike On Dec 3, 2012, at 12:12 PM, Ilija Kocho wrote: > Mike >=20 > I need insight in your RedBoot configuration. It would help if you send > me the ECM file (File->Export...) >=20 > I also attach the ECM file of my RedBoot that works for small "Hello > world" app. > Importing it in a _fresh_ RedBoot configuration should give you same > configuration as mine (provided that you have patched the latest SVN > version). > I tested it for loading from RedBoot prompt but not for GDB since at > present I am away from my lab. > Load works for both SREC and ELF files. >=20 > FYI you can also initialize RedBoot configuration (fconfig -i) so you > won't need to enter tftp host every time. >=20 > I hope this will work for you. >=20 > Ilija >=20 >=20 > On 03.12.2012 01:01, Michael Jones wrote: >> IIila, >>=20 >> I implemented what you sent, and ended up with an infinite loop of SIGTR= APs. So I am stuck, but at least I have Insight/gdb running and can see wha= t the code is doing. But, I don't know enough about the memory usage to kno= w what is wrong. >>=20 >> DETAILS >> ------------ >>=20 >> I made some progress. I updated the files, and then did the following: >>=20 >> 1) Put memory checking back into the RedBoot image >> 2) In the application config, changed to RAM. Built the app, etc. >> 3) telnet into RedBoot >> 4) Load with >> load -v -h x.x.x.x hello.srec >> 5) go >>=20 >> The command line then becomes unresponsive, and nothing prints. >>=20 >> I then change printf to diag_printf, just in case that is the problem. S= ame results. >>=20 >> So then I compile up Insight so I have a debugger and then: >>=20 >> A) Connect to RedBoot with Insight >> B) Load image >>=20 >> Loading section .rom_vectors, size 0x8 lma 0x1fffe400 >> Loading section .ARM.exidx, size 0x10 lma 0x1fffe408 >> Loading section .text, size 0x6930 lma 0x1fffe418 >> Loading section .rodata, size 0x2004 lma 0x20004d48 >> Loading section .data, size 0x1b0 lma 0x20006d58 >> Start address 0x1fffe419, load size 35580 >>=20 >> I see a break point at the first line in main: >>=20 >> int main(void) >> { >> *** diag_printf("Hello 1, eCos world!\n"); >> diag_printf("Hello 2, eCos world!\n"); >> return 0; >> } >>=20 >>=20 >> C) Tell image to continue via Control | Continue >>=20 >> The debugger then stops in file vectors.S at line 101: >>=20 >> 86 //=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >> 87 // Fake entry point. >> 88 // >> 89 // The ELF file entry point points here. When loading an executable >> 90 // via RedBoot/Stubs or via JTAG the PC will be set to this address. >> 91 // The code here sets up the SP and branches to the reset VSR in >> 92 // emulation of the hardware reset behaviour. >> 93=09 >> 94 .align 2 >> 95 .global reset_vector >> 96 .thumb >> 97 .thumb_func >> 98 .type reset_vector, %function >> 99 reset_vector: >> 100=09 >> - 101 ldr sp,=3Dhal_startup_stack >> - 102 b hal_reset_vsr >> 103=09 >> 104 .pool >>=20 >>=20 >> Any time I do a continue, I stop at this line 101 and the gdb console sa= ys: >>=20 >> Program received signal SIGTRAP, Trace/breakpoint trap. >> reset_vector () at /opt/ecos/ecos-3.0/packages/hal/cortexm/arch/current/= src/vectors.S:101 >>=20 >> My intuition is that "b" means branch, and the hal_reset_vsr either is p= ointing to reset_vector, or something else causes the SIGTRAP, leading back= here. >>=20 >> At this point I have to admit ignorance of how traps work. But moving fo= rward, I did a step next line in the debugger. This resulted in an infinite= wait for a response that never came. So I closed Insight and stopped. >>=20 >> A little research says that SIGTRAP is the processor noting an instructi= on was hit, and then GDB should handle the breakpoint. >>=20 >> My interpretation of the GDB console is that the target trapped at vecto= rs.S:101, but I used the debugger to put a break point at the first instruc= tion in main. I suppose it is possible this is where it thinks the trap goe= s... >>=20 >> but I am guessing something is in the wrong place, like loading the prog= ram image stepped on part of RedBoot's SRAM code or tables. >>=20 >> Any insights? >>=20 >> Mike >>=20 >>=20 >> On Dec 2, 2012, at 3:12 AM, Ilija Kocho wrote: >>=20 >>> Hi Mike >>>=20 >>> On 01.12.2012 22:07, Michael Jones wrote: >>>> BACKGROUND >>>> ---------------------- >>>>=20 >>>> I am having a little bit of trouble trying to get my first hello world= app on a K60 Tower Board. >>>>=20 >>>> I have RedBoot running from ROM and I can ping the ethernet port, so p= resumably I will eventually get GDB to talk to it. >>>>=20 >>>> I am having trouble building an initial app that uses the ROM monitor.= Following the example in the eCos book, I went hunting for CYGSEM_HAL_USE_= ROM_MONITOR, enabled it and then set startup to SRAM. This seems the obviou= s way to run and debug. >>>>=20 >>>> PROBLEM >>>> -------------- >>>>=20 >>>> I am getting a conflict I don't know how to resolve. I have set CYG_HA= L_STARTUP_VAR =3D SRAM. This results in CYG_HAL_STARTUP =3D SRAM by calcula= tion. >>>>=20 >>>> But I get a conflict from CYGSEM_HAL_USE_ROM_MONITOR that wants CYG_HA= L_STARTUP =3D=3D RAM >>> SRAM and RAM startups are not the same. RAM startup is intended for >>> using under control of RedBoot and has some special properties: RAM, >>> unlike other startup types uses RedBoot's vectors, etc... >>>=20 >>> SRAM startup is kind of "stand-alone" in a way it does not depend on >>> RedBoot (but depends on JTAG debugger) >>>=20 >>>> QUESTIONS >>>> ----------------- >>>>=20 >>>> 1) Can I ignore this conflict and get the monitor and app to work? >>> I'm afraid not because, SRAM startup collides with RedBoot. >>>> 2) Is there a better approach? >>> The right approach is to create RAM startup. It could live on variant >>> level and be available to all Kinetis platforms (though some may have >>> too little memory to utilize it). >>> The attached patches should produce proper variant-level RAM startup. >>>=20 >>> I did not add it from beginning since I consider internal SRAM too >>> little for practical work, seems that other people have different view. >>> You are not the first to look for. >>> This being said, I am considering to add this startup to the main >>> repository. Would you open a Bug on Bugzilla? >>>=20 >>>> 3) Has anyone succeeded to use RedBoot on the K60 and can you supply a= n example config project that works that I can look at? >>> You may want to try this: >>> http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001623 but beware, it >>> is experimental, and at present it may be broken as it's not synced with >>> recent Kinetis patches. >>> Take care not to lock your Kinetis flash - You have been warned :) >>>=20 >>> I hope this helps and I would appreciate feedback. >>>=20 >>> Regards >>> Ilija >>> --=20 >>> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos >>> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss >>=20 >=20 > --=20 > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss