Awesome... Got U-boot 1.1.4 working on a Xilinx ML403 (PPC 405) evaluation board with our custom core.
Next for this planning stage, I'm trying to juggle 'leap-frogging' memory mapping between the first-loader (Xilinx SREC bootloader in firmware), second loader (U-boot 1.1.4) and Linux 2.4 OS.
Firstly, we started with Xilinx's SREC (bootloader.c) bootloader (I know, I know, SREC is space consuming) and plan to replace this first bootloader with an ELF or pseudo-binary version later after everything-else is checked out.
Planning-wise, I envisioned that such a bring-up memory overlaying sequence would be something like this:
1. Xilinx bootloader.c reads SREC from 16-bit flash and decode/verify/copies to lowest RAM (0000_0000). Then transfers control to 0000_0100.
2. U-boot starts up and relocate itself to MONITOR region which is in the highest RAM region of 01F0_0000.
3. U-boot Scripting occurs which copies Linux OS from flash into where? Next highest or lowest portion of RAM? Is it dependent on whether dual-stage vmlinux.initrd or single-stage vmlinux is used or not?
At power-up, with U-Boot 1.1.4 being unusually low-RAM-based before starting up (instead of executing straight out of ROM), I noticed that despite being relocated to MONITOR (higher RAM) region, the PIT exception vector appears to be active in 0000_10c0-ish.
Despite this RAM-to-RAM relocation, this "mtest" clobbering of the 0000_10C0 region caused Machine Exception error whenever I attempt to perform memory test over this supposedly former exception vector region. I thought that the objective during U-boot relocation was to ensure a completely discontinued RAM region (formerly occupied by U-boot ROM-based session).
A hard and easy questions to the esteemed and avid readers of u-boot-users mailing list...
1. Where do I go from there with regard to the 0000_1000 (PIT_EXCEPTION). Isn't the PIT specific to Motorola 8xx-series (this here is a PPC 405). What exception did the lib_ppc/start.S/trap_init() exactly skipped? Skipped an exception mentioned vaguely in this source code vaguely. Do I need to tweak the trap_init() some more to relocate these untransfered exception vectors into the high MONITOR region?
2. And lastly, do I go high or low for Linux OS?
Thank you,
S. Egbert