From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13541 invoked by alias); 4 Dec 2012 08:51:05 -0000 Received: (qmail 13506 invoked by uid 22791); 4 Dec 2012 08:51:04 -0000 X-SWARE-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from tirion.supremecenter202.com (HELO tirion.supremecenter202.com) (209.25.195.243) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 04 Dec 2012 08:50:48 +0000 Received: from [94.234.170.178] (port=38543 helo=[192.168.0.244]) by tirion.supremecenter202.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TfoDH-0005G0-83; Tue, 04 Dec 2012 08:50:47 +0000 Message-ID: <50BDB965.3040802@siva.com.mk> Date: Tue, 04 Dec 2012 08:51:00 -0000 From: Ilija Kocho User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Michael Jones CC: eCos Discussion References: <88A5F92E-1AE1-4246-B566-3EFE5DEA360B@linear.com> <50BB299F.5070404@siva.com.mk> <50BCF9AD.7030309@siva.com.mk> <7E4912AF-4819-49DA-95C3-225AF53F0A42@linear.com> <50BDB773.7040208@siva.com.mk> In-Reply-To: <50BDB773.7040208@siva.com.mk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00017.txt.bz2 On 04.12.2012 09:42, Ilija Kocho wrote: > On 04.12.2012 06:32, Michael Jones wrote: >> IIija, >> >> I have some questions: >> >> - Is the Kinetis rev 1/2 silicon rev or Tower rev? I have part number PK60n512vmd100. 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 for me? > It's silicon revision, ref: > http://cache.freescale.com/files/32bit/doc/app_note/AN4445.pdf?fpsp=1&WT_TYPE=Application%20Notes&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation > >> - 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. Nothing is creating. I was attempting to see if it fixed the problem. Is there a log somewhere to look at for clues? > There's no linker script for non-unified SRAM in the (ad hoc) RAM > startup patch. > >> - I would like to verify that you don't add the RedBoot package to the application to work with the monitor. I assume that enabling Working with a ROM monitor is all that is needed. Just being paranoid :-) > Sure. And /Work with ROM monitor/ should enable by default when RAM > startup is selected. > >> - On the virtual vector table that is shared by the Rom monitor and applicaiton, I dug up the linker settings. >> >> The Rom Monitor has this: >> >> hal_vsr_table = (0x20000000 - CYGHWR_HAL_KINETIS_SRAM_BANK_SIZE); >> hal_virtual_vector_table = hal_vsr_table + 128*4; >> hal_startup_stack = 0x20000000 + CYGHWR_HAL_KINETIS_SRAM_BANK_SIZE; >> >> The application using RAM has this: >> >> hal_vsr_table = (0x20000000 - CYGHWR_HAL_KINETIS_SRAM_BANK_SIZE); >> hal_virtual_vector_table = hal_vsr_table + 128*4; >> hal_startup_stack = 0x20000000 + CYGHWR_HAL_KINETIS_SRAM_BANK_SIZE; >> >> I am not sure which of these are to be shared. I think the virtual vector table are shared so that the monitor will work. I would think the startup stack would not be shared. And the hal_vsr_table might be shared, but I am not sure. > You are right for both. However, effectively there isn't collision over > VSR table because RAM startup (exclusively) omits VSR table > initialization (arch/current/src/hal_misc.c). > >> Does the RAM setup need to have these changed? > No need to change but /SECTION_rom_vectors/ base may need. In the patch > it is 0xe000. Check the RedBoot memory report (printed during boot). To precise, 0xe000 is not base but offset from RedBoot's base. > >> >> Mike >> >> >> >> >> On Dec 3, 2012, at 12:12 PM, Ilija Kocho wrote: >> >>> Mike >>> >>> I need insight in your RedBoot configuration. It would help if you send >>> me the ECM file (File->Export...) >>> >>> 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. >>> >>> FYI you can also initialize RedBoot configuration (fconfig -i) so you >>> won't need to enter tftp host every time. >>> >>> I hope this will work for you. >>> >>> Ilija >>> >>> >>> On 03.12.2012 01:01, Michael Jones wrote: >>>> IIila, >>>> >>>> I implemented what you sent, and ended up with an infinite loop of SIGTRAPs. So I am stuck, but at least I have Insight/gdb running and can see what the code is doing. But, I don't know enough about the memory usage to know what is wrong. >>>> >>>> DETAILS >>>> ------------ >>>> >>>> I made some progress. I updated the files, and then did the following: >>>> >>>> 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 >>>> >>>> The command line then becomes unresponsive, and nothing prints. >>>> >>>> I then change printf to diag_printf, just in case that is the problem. Same results. >>>> >>>> So then I compile up Insight so I have a debugger and then: >>>> >>>> A) Connect to RedBoot with Insight >>>> B) Load image >>>> >>>> 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 >>>> >>>> I see a break point at the first line in main: >>>> >>>> int main(void) >>>> { >>>> *** diag_printf("Hello 1, eCos world!\n"); >>>> diag_printf("Hello 2, eCos world!\n"); >>>> return 0; >>>> } >>>> >>>> >>>> C) Tell image to continue via Control | Continue >>>> >>>> The debugger then stops in file vectors.S at line 101: >>>> >>>> 86 //========================================================================== >>>> 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 >>>> 94 .align 2 >>>> 95 .global reset_vector >>>> 96 .thumb >>>> 97 .thumb_func >>>> 98 .type reset_vector, %function >>>> 99 reset_vector: >>>> 100 >>>> - 101 ldr sp,=hal_startup_stack >>>> - 102 b hal_reset_vsr >>>> 103 >>>> 104 .pool >>>> >>>> >>>> Any time I do a continue, I stop at this line 101 and the gdb console says: >>>> >>>> Program received signal SIGTRAP, Trace/breakpoint trap. >>>> reset_vector () at /opt/ecos/ecos-3.0/packages/hal/cortexm/arch/current/src/vectors.S:101 >>>> >>>> My intuition is that "b" means branch, and the hal_reset_vsr either is pointing to reset_vector, or something else causes the SIGTRAP, leading back here. >>>> >>>> At this point I have to admit ignorance of how traps work. But moving forward, 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. >>>> >>>> A little research says that SIGTRAP is the processor noting an instruction was hit, and then GDB should handle the breakpoint. >>>> >>>> My interpretation of the GDB console is that the target trapped at vectors.S:101, but I used the debugger to put a break point at the first instruction in main. I suppose it is possible this is where it thinks the trap goes... >>>> >>>> but I am guessing something is in the wrong place, like loading the program image stepped on part of RedBoot's SRAM code or tables. >>>> >>>> Any insights? >>>> >>>> Mike >>>> >>>> >>>> On Dec 2, 2012, at 3:12 AM, Ilija Kocho wrote: >>>> >>>>> Hi Mike >>>>> >>>>> On 01.12.2012 22:07, Michael Jones wrote: >>>>>> BACKGROUND >>>>>> ---------------------- >>>>>> >>>>>> I am having a little bit of trouble trying to get my first hello world app on a K60 Tower Board. >>>>>> >>>>>> I have RedBoot running from ROM and I can ping the ethernet port, so presumably I will eventually get GDB to talk to it. >>>>>> >>>>>> 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 obvious way to run and debug. >>>>>> >>>>>> PROBLEM >>>>>> -------------- >>>>>> >>>>>> I am getting a conflict I don't know how to resolve. I have set CYG_HAL_STARTUP_VAR = SRAM. This results in CYG_HAL_STARTUP = SRAM by calculation. >>>>>> >>>>>> But I get a conflict from CYGSEM_HAL_USE_ROM_MONITOR that wants CYG_HAL_STARTUP == 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... >>>>> >>>>> SRAM startup is kind of "stand-alone" in a way it does not depend on >>>>> RedBoot (but depends on JTAG debugger) >>>>> >>>>>> QUESTIONS >>>>>> ----------------- >>>>>> >>>>>> 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. >>>>> >>>>> 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? >>>>> >>>>>> 3) Has anyone succeeded to use RedBoot on the K60 and can you supply an 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=1001623 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 :) >>>>> >>>>> I hope this helps and I would appreciate feedback. >>>>> >>>>> Regards >>>>> Ilija >>>>> -- >>>>> 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 > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss