This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Kinetis CYG_HAL_STARTUP_VAR conflict


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).

>     
> Mike
>
>
>
>
> On Dec 3, 2012, at 12:12 PM, Ilija Kocho <ilijak@siva.com.mk> 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 <ilijak@siva.com.mk> 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
>>>> <kinetis_var_ram-startup_cdl_121202.diff><kinetis_var_ram-startup_mlt_121202.diff>-- 
>>>> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>>>> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>> <rb_k60.ecm>-- 
>> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]