RE: [U-Boot-Users] u-boot on top of another bootloader

Can u-boot run on top of another bootloader? The board I'm working on has a proprietary boot loader. I cannot totally abandon this bootloader because the vendor is unwilling to disclose some critical details of the board. So I'm thinking of putting u-boot on top of it. Is this idea feasible?
reminds me something ;) (see post a few weeks ago...)
The original boot loader is at 0xFFF00000. One thing I need to do is to move the u-boot location to somewhere else. AFAIK u-boot usually locates at 0xFFF00000. What feature of a board decides the address of the first instruction?
I did the following: The manufacturer provided a srec version of its bootloader and a flash utility. Using a debugger, I made sure I could put back the original bootloader if anything went wrong with u-boot. After this I gathered as much information about the board as I could by: - using the debugger and writing down the values of initialized registers (done by the original bootloader) - using some "utilities" provided by the original bootloader Then I decided where to flash u-boot. On a ppc cpu, the processor first jumps at address 0xfffffffc. At this very address there is a branch instruction to a bootloader. For example, with the original bootloader this could be 0xfff00000. You could replace this value and the position of u-boot in flash by using the config.mk file in the board/$BOARD directory. This will place the .text section at the defined position and replace the branch address from the reset vector to the correct one.
hope this helps,
regards
François-Xavier SEINGIER

Dear François-Xavier,
in message DA5CB450F843D611823E0002A5D4DB3C01FFD0B8@renexch1.rennes.thmulti.com you wrote:
Then I decided where to flash u-boot. On a ppc cpu, the processor first jumps at address 0xfffffffc. At this very address there is a branch instruction to a bootloader. For example, with the original bootloader > this
Please don't make such statements. They may be correct on your system (which obviously uses a IBM 4xx processor), but they are wrong on most other systems. For example, no Motorola PowerPC processor that I know of uses 0xFFFFFFFC as reset entry point. Nor does any ARM or MIPS based system.
Also, checking the register initialization may have worked in your case, but it does not help in the general case like when unknown board hardware (like a FPGA) needs to be initialized or set to a certain state. In such a case you are LOST without adequate documentation from the manufacturer.
On the other hand, there are usually other, better documented hardware solutions around :-)
Best regards,
Wolfgang Denk
participants (2)
-
Seingier François-Xavier
-
Wolfgang Denk