From mboxrd@z Thu Jan  1 00:00:00 1970
From: Peter Ryser <peter.ryser@xilinx.com>
Date: Mon, 30 Jan 2006 22:10:17 -0800
Subject: [U-Boot-Users] Sequence of Xilinx ML403/PPC
In-Reply-To: <43D9E2AB.5020108@sbcglobal.net>
References: <43D9E2AB.5020108@sbcglobal.net>
Message-ID: <43DEFF49.9090909@xilinx.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Is there any reason why you don't start U-Boot directly out of Flash 
instead of using the initial SREC bootloader?

BTW: you can find a snapshot of U-Boot with board support for ML300, 
ML310, ML403 and ML410 at
http://www.xilinx.com/ml410-p/designs/u-boot.zip
The snapshot contains the patches that have been submitted to this 
mailing list back in September of last year. For ML403 just use
$ make ml403_config
$ make
to build U-Boot.

- Peter


S. Egbert wrote:

>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
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>_______________________________________________
>U-Boot-Users mailing list
>U-Boot-Users at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
>
>  
>