Honored Contributor
Honored ContributorHi tns1,
> When I do a mw.b for the memory from 0x800000 to 0x9D0000, u-boot crashes (locks) > apparently because I am writing over some parts it is actively using. Yes, you're overwriting the stack and the heap. > First, I see three long words at 0x800020 that I verified with objdump are the trampoline > instructions you mentioned, but writing over them causes u-boot to either reset, lockup or > stop working correctly (depends on which one I write over). If this is the case, your exception address is probably 0x800020. When the timer interrupt fires and the exception is taken, the core executes corrupted code. > Also my <myboard>.h file I created defines CFG_EXCEPTION_ADDR to be x900020. Isn't this > where the trampoline should be? There are two critical macros that must be correct in your config file: CFG_RESET_ADDR and CFG_EXCEPTION_ADDR. These _must_ match your hardware configuration (cpu settings in SOPC builder). The u-boot build process is not very sophisticated -- this is good and bad. The good part is that it's simple -- you only need a shell and the cross-development tools to build it -- no interactions with an IDE, etc -- you can edit & control the whole process with a text editor. The bad part is, well ... it's simple ;-) so it won't automagically update the config file for you (or warn you) when your config file doesn't match your actual hardware. > If I understand the trampoline, it is only using during relocation, and it should't matter what > happens to that memory afterwards. Correct. The trampoline gets copied to CFG_EXCEPTION_ADDR when u-boot relocates itself. This allows u-boot to stored at the reset address (e.g. flash) or any other arbitrary address. When u-boot begins execution, it copies itself to TEXT_BASE (ram) and jumps to the relocated u-boot image. After a few more initializations (e.g. clearing bss, etc), u-boot checks to see if the trampoline is at the proper exception address. If it's not, it copies the trampoline to CFG_EXCEPTION_ADDR. The trampoline code does nothing more than jump to u-boot's exception handler. NOTE: In some cases, the trampoline does not need to be copied. This would be the case when TEXT_BASE is set to the exception address minus 0x0020 -- since the trampoline code is conveniently located at the start address + 0x0020 it's already where it needs to be. > If I change the first three to 0x900000, 0x800000, 0x800020 I get more consistent behavior, Yes, this makes sense. This would indicate that your actual hardware configuration has the exception address set to 0x80_0020. BTW: the "irqinfo" command shows the timer interrupt count. The count should be incrementing if everything is operating ok. > but I still cant use the lower memory. I had a similar problem since I mapped the low-end of SDRAM into a PCI window. When the host cleared the memory, my core would basically lock up once the timer interrupt fired. (It would simply execute jmp 0). The solution was to define a small section of on-chip RAM (0x40 bytes) and set the exception address to offset 0x20 in this memory. This kept SOPC builder happy, and prevented the host from trashing my interrupts ;-) > I have been unable to use u-boot to download an image of itself for flashing because this > step crashes. I believe this is all related -- the downloaded image is probably corrupting the trampoline, the heap, or the stack. Based on your ealier comments, you're probably downloading to 0x80_0000 for subsequent copy into flash. This overwrites the trampoline and causes a crash once the timer interrupt fires. > My HW has already been fully tested under uCos, and I thought the bootloader functions > would be a nice addition. Absolutely ... and I'll do my best to help you get there :-) Once things are stable, I think you'll really enjoy the more "interesting" features like cramfs/jffs2 support and scripting. Try the following: 1. Add some on-chip memory and set the exception address to offset 0x20 in the memory. 2. Update you config file with the actual reset/exception addresses from SOPC builder. 3. Rebuild u-boot and strip the elf. 4. Determine the actual u-boot size using objdump and set TEXT_BASE appropriately. 5. Rebuild. Hope this helps, --Scott PS: > I discovered that once you have built, you cannot copy the source tree to another > folder and rebuild. use 'make distclean' prior to copying the source tree -- it should remove any absolute path references. In the new tree you'll have to make xxx_config again though.
