Flash programmer via ethernet

Hi 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&#39;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&#39;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&#39;s simple ;-) so it won&#39;t automagically update the config file for you (or warn you) when your config

file doesn&#39;t match your actual hardware.

> If I understand the trampoline, it is only using during relocation, and it should&#39;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&#39;s not, it copies the trampoline to

CFG_EXCEPTION_ADDR. The trampoline code does nothing more than jump to u-boot&#39;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&#39;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&#39;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&#39;ll do my best to help you get there :-) Once things are stable, I think you&#39;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 &#39;make distclean&#39; prior to copying the source tree -- it should remove any absolute

path references. In the new tree you&#39;ll have to make xxx_config again though.