[U-Boot-Users] Sequence of Xilinx ML403/PPC

[S. Egbert <s.egbert@sbcglobal.net>]

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