XUARTLITE/PPC405/Linux after UBOOT.
S. Egbert <s.egbert <at> sbcglobal.net>
2006-02-01 06:36:54 GMT
I'm using XUARTLITE with PPC405 and special core. U-Boot hasn't
leverage this combo before (AFAICT, U-Boot XUARTLITE is used only with
MicroBlaze CPU).
So, I took a Oct. 10 2005 snapshot and integrated the XUARTLITE into
U-Boot. That works so far when Xilinx bootloader (via ISOCM/DSOCM)
loads the Linux 2.4.20 SREC-formatted file directly from flash into DDR
and jumps to 0x100. So, it has been established that a working Linux
XUARTLITE output has been had by Xilinx-booting directly from
flash-based Linux.SREC. (that was my earlier announcement).
But flashing 8MB Linux.SREC, every time I tweak things, isn't my cup of
tea. It is not reasonable to wait 45 minutes for a serial download to
finish. So, I thought, why not U-Boot it.
My next step is to put a uImage (Linux XUARTLITE) into flash using
=> tftpboot 30000000 uImage
=> bootm 30000000
bootm confirms that the uImage checksum is good and jumps to 0x100.
The calling sequence within Linux in question is:
+ _start (linux/arch/ppc/kernel/head_4xx.S)
+ initial_mmu (also in head_4xx.S)
+ start_here (head_4xx.S)
+ machine_init (
+ MMU_init (arch/ppc/mm/init.c)
--> XUARLITE register goes phantom here <--
+ start_kernel (init/main.c)
Via linux/arch/ppc/mm/init.c ppc_md.progress() debug output, I see that
outputs various "MMU:" debug lines and then it falls silent (no further
output).
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
so, it finished mmu_init() and platform_init() just fine.
Using Xilinx XDM, one can repeatedly poke the XUARTLITE transmit
register and evoke character outputs just fine while in Linux IDLE
(scheduler) mode. So, the XUARTLITE hardware is still working at this
point. HW works still.
I noticed that in Linux PPC, to get 'early debug output' using
CONFIG_SERIAL_TEXT_DEBUG option, PPC4xx TLB Slot 0 is dedicated to
mapping serial hardware registers/memory region. Somehow that TLB
remapping fails.
At the moment, I'm about to re-review the TLB slot 0 and figure out why
poking the XUARTLITE transmit register isn't working from memory-mapped
mode.
Any insight is greatly appreciated, particularly on how to read PPC405
TLB registers.
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
>
and
--
--
-----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
-------------------------------------------------------
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
RSS Feed