[U-Boot-Users] Running U-Boot as a standalone application

Kerl, John John.Kerl at Avnet.com
Wed Jan 14 22:46:02 CET 2004


Another newbie question, I'm afraid ...

What I am trying to do is run another copy of U-Boot from SRAM, i.e.
treating U-Boot #2 as a standalone application to be loaded by U-Boot
#1.  This way I don't have to overwrite the boot code stored in the

Now, U-Boot is power-on-reset code as well as C code, and the CPU has
already *been* initialized, so not all of the code needs to be
re-run.  I am wondering what is the most straightforward way to
modify the early code for running from SRAM.

The board I'm using (PPChameleonEVB) has 1 MB SRAM at 0xff800000.
I've modified the .lds file and the flash base in include/configs so
that "flash" is now taken to be the SRAM.  (I know this is quick and
dirty, not elegant.  Also I know that the PPChameleonEVB has a jumper
which swaps CS0# [flash] and CS1# [SRAM], but I don't have a BDI so
I'm not able to load the SRAM.) Then I make an image file with
mkimage file, address 0xff800000 and entry point 0xff800100, TFTP it
to the board and execute it.  I obtain:

[board.c, 767] Calling env_relocate ...
env_relocate[203] offset = 0x2700000
env_relocate[221] malloced ENV at 01f7f908
U-Boot relocated to 01fc0000
[board.c, 907] Calling interrupt_init ...
Bus Fault @ 0x01fc2f84, fixup 0x00000000
Machine check in kernel mode.
Caused by (from msr): regs 01f7f618 Machine check signal - probably due to
mm ft
with mmu off
NIP: 01FC2F84 XER: 00000000 LR: 01FC219C REGS: 01f7f618 TRAP: 0200 DAR:
MSR: 00001000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00

GPR00: 00028000 01F7F708 01AB0000 01F7F718 0000000A 00000000 00000000
GPR08: 01FCA404 0A7C5AC5 00000004 00000001 00000000 00000080 01FE5300
GPR16: 00000000 00000000 00000000 00000001 00001000 01F7F708 00000000
GPR24: 01FC2F84 01FC0000 01F7F88C 01F7F8FA 01FEA68C 01F7F860 01FE5384
Call backtrace:
machine check

which is a machine check in PITException.  I can and will debug this
further, but I wonder if some things are already known.  Namely:

*	What I'm doing is re-running all the init code.
	This is overkill, since the CPU has already been initialized,
	but it is easiest to code, since I just need to modify the
	.lds et al.

*	The other extreme would be to re-run none of the init code
	(except installing handlers, etc.), which I don't mind
	doing except that it sounds like a several-day project.

*	Is there a happy medium?

*	There is a __DEBUG_START_FROM_SRAM__ macro which I see in
	the code, but it doesn't appear to be used very many places.

*	I think someone else out there must have tried something
	similar before ... however, if there's something in the
	U-Boot manual on this topic, I've missed it.

Thanks for any and all info, and for your patience. :)

More information about the U-Boot mailing list