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

Hello:
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 flash.
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: 7C6B1B78 MSR: 00001000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 00028000 01F7F708 01AB0000 01F7F718 0000000A 00000000 00000000 0A972F76 GPR08: 01FCA404 0A7C5AC5 00000004 00000001 00000000 00000080 01FE5300 02700000 GPR16: 00000000 00000000 00000000 00000001 00001000 01F7F708 00000000 01FC219C GPR24: 01FC2F84 01FC0000 01F7F88C 01F7F8FA 01FEA68C 01F7F860 01FE5384 00000006 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. :)

In message C7FFFEA58B43D311920D0004ACE5333F10E4F513@amer25.avnet.com you wrote:
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
You can use the "old" copy of U-Boot to store the image to SRAM, then switch the jumper, the reset the board.
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.
You would need to change so many things that a working "debugging version" gives no indication if a "real" version would run.
IMHO you are wasting your time.
Use the things as they are intended to be used: see above, or buy a BDI.
Best regards,
Wolfgang Denk
participants (2)
-
Kerl, John
-
Wolfgang Denk