From mboxrd@z Thu Jan 1 00:00:00 1970 From: S. Egbert Date: Tue, 31 Jan 2006 17:15:47 -0800 Subject: [U-Boot-Users] Sequence of Xilinx ML403/PPC In-Reply-To: <43DEFF49.9090909@xilinx.com> References: <43D9E2AB.5020108@sbcglobal.net> <43DEFF49.9090909@xilinx.com> Message-ID: <43E00BC3.7020509@sbcglobal.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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