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

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

According my HW guy, he said the ML403 reference design, the flash is
accesible only by 16-bit fetch.  I thought that this alone would make
XIP not feasible out of that flash region.

As of today, I just had the bit file made enabling Xilinx flash
side-by-side data access (two 16-bit fetch from a single chip into a
32-bit data read)...

Will give it a shot again then.

Steve


Peter Ryser wrote:
> 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
>>
>>
>>  
>>
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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
> 


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GAT d- s++: !a C+++ UL++++ P+++ L+++ E W+++ N+ o++ K+++ w--
O- M+ V- PS PE++ Y+ PGP++ t++ 5++ X++ R tv- b++ DI+ D+
G++ e* h++ r+++ z
------END GEEK CODE BLOCK------
GPG Public Key: http://www.egbert.net/pgp