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

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

[S. Egbert]

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

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

[Wolfgang Denk]

In message <43D9E2AB.5020108@sbcglobal.net> you wrote:
>
> 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

On PowerPC the kernel starts always at physical address 0x0000 in RAM ==> lowest address.

> dual-stage vmlinux.initrd or single-stage vmlinux is used or not?

With U-Boot you use neither vmlinux.initrd nor  vmlinux  but  uImage,
eventually  with  a  separate ramdisk image, or eventually a combined
"multi-file image".

> 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.

U-Boot installs it's own exception vectors.

> Despite this RAM-to-RAM relocation, this "mtest" clobbering of the
> 0000_10C0 region caused Machine Exception error whenever I attempt to

Yes, of course. What else do you expect when you overwrite active code?

> perform memory test over this supposedly former exception vector region.

Former and current in your case.

>  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).

I cannot parse this. Pleasee see the README  for  the  U-Boot  memory
layout. It's all written there. Just RTFM.

> 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?

I really don't understand the question, nor your concerns.  The  code
is working find on many, many boards. No tweaking isnecessary.

> 2. And lastly, do I go high or low for Linux OS?

I tend to keep my feet on the ground; no idea what you do.

What exactly is the question? "go high"??? Can't parse that.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Human beings were created by water to transport it uphill.

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

[Peter Ryser]

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
>
>
>  
>

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

[S. Egbert]

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

[U-Boot-Users] XUARTLITE/PPC405/Linux after UBOOT.

[S. Egbert]

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@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

[U-Boot-Users] Xilinx ML403/PPC U-Boot support

[bbosch at iphase.com]

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

Wolfgang,

Were the Xilinx patches (2005-09-28 thru 2005-10-02) rejected or lost,
or are they still in your queue?

Peter,

Do you happen to have a design for the ML403 that boots directly from
the linear flash?  Perhaps with devices mapped as in
board/xilinx/ml403/xparameters.h?  It would be easier to start with a
design known to work with U-Boot.

Thanks,

--Brad

[U-Boot-Users] Re: Xilinx ML403/PPC U-Boot support

[Peter Ryser]

Brad,

I've uploaded a zip file that contains FPGA designs for ML300, ML310, 
ML403 and ML410 as well as an U-Boot snapshot with all "Xilinx" patches 
included to
ftp://customer:xilinx at ftp.xilinx.com/upload/xapp542.zip (12 MB)

The design for the ML403 maps the Flash at the reset vector. I have 
several ML403s that completely boot from linear flash - bitstream, 
U-Boot, Linux kernel. I've enabled MTD support in the Linux kernel. With 
that I can upgrade bitstream and Linux image from within Linux.

As you can see from the name the uploaded zip file is part of a project 
to update the current Xilinx application note XAPP542 with a newer 
version. I'm kind of been waiting for the September patches to be 
applied in the U-Boot CVS but figured Wolfgang must be busy with other 
stuff as I was myself.

- Peter


bbosch at iphase.com wrote:

>Peter Ryser writes:
> > 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
>
>Wolfgang,
>
>Were the Xilinx patches (2005-09-28 thru 2005-10-02) rejected or lost,
>or are they still in your queue?
>
>Peter,
>
>Do you happen to have a design for the ML403 that boots directly from
>the linear flash?  Perhaps with devices mapped as in
>board/xilinx/ml403/xparameters.h?  It would be easier to start with a
>design known to work with U-Boot.
>
>Thanks,
>
>--Brad
>
>
>  
>

[U-Boot-Users] Re: Xilinx ML403/PPC U-Boot support

[bbosch at iphase.com]

Peter Ryser writes:
 > Brad,
 > 
 > I've uploaded a zip file that contains FPGA designs for ML300, ML310, 
 > ML403 and ML410 as well as an U-Boot snapshot with all "Xilinx" patches 
 > included to
 > ftp://customer:xilinx at ftp.xilinx.com/upload/xapp542.zip (12 MB)

Peter,

Thanks very much for the new sample designs.  It made getting u-boot
going without using the platform flash or System ACE fairly easy.

--Brad

[U-Boot-Users] Xilinx ML403/PPC U-Boot support

[Paula S]

Hi!

I'm using the ml403 as well, trying to boot from Flash, without SysACE. But
when I load u-boot, I get the message: 
### No HW ID - assuming ML403
DRAM:  64 MB
FLASH: ## Unknown FLASH on Bank 0 - Size = 0x00000000 = 0 MB
*** failed ***
### ERROR ### Please RESET the board ###

The flash address is ok in hw design.

Any help would be appreciated.
Thanks!
Paula

--
View this message in context: http://www.nabble.com/Sequence-of-Xilinx-ML403-PPC-t1009012.html#a3278946
Sent from the Uboot - Users forum at Nabble.com.

[U-Boot-Users] Re: Xilinx ML403/PPC U-Boot support

[Filippo Capurso - DAVE srl]

Hi Peter,

I have a Xilinx ML403 board and I'm trying to make u-boot start directly 
from linear flash.
I compiled U-Boot with your patches for ML403 and I tried to syntesize 
an EDK project starting with the reference desing and remapping the 
linear flash at the end of the memory space. By the way, when I 
configure the Virtex-4 with the generated bitstream the 'Error 1' led 
(the red one) turns on, so I've certainly made some mistake.
I found the following message in list and I try to download the linked 
.zip file, but the link seems to be broken.
Can I have the XPS files with the correct memory map and system 
configuration in order to run u-boot from flash?
There are other important things that I should know for make it working?
Than you

Filippo Capurso

Peter Ryser ha scritto:
> Brad,
> 
> I've uploaded a zip file that contains FPGA designs for ML300, ML310, 
> ML403 and ML410 as well as an U-Boot snapshot with all "Xilinx" patches 
> included to
> ftp://customer:xilinx at ftp.xilinx.com/upload/xapp542.zip (12 MB)
> 
> The design for the ML403 maps the Flash at the reset vector. I have 
> several ML403s that completely boot from linear flash - bitstream, 
> U-Boot, Linux kernel. I've enabled MTD support in the Linux kernel. With 
> that I can upgrade bitstream and Linux image from within Linux.
> 
> As you can see from the name the uploaded zip file is part of a project 
> to update the current Xilinx application note XAPP542 with a newer 
> version. I'm kind of been waiting for the September patches to be 
> applied in the U-Boot CVS but figured Wolfgang must be busy with other 
> stuff as I was myself.
> 
> - Peter
> 
> 
> bbosch at iphase.com wrote:
> 
>> Peter Ryser writes:
>> > 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
>>
>> Wolfgang,
>>
>> Were the Xilinx patches (2005-09-28 thru 2005-10-02) rejected or lost,
>> or are they still in your queue?
>>
>> Peter,
>>
>> Do you happen to have a design for the ML403 that boots directly from
>> the linear flash?  Perhaps with devices mapped as in
>> board/xilinx/ml403/xparameters.h?  It would be easier to start with a
>> design known to work with U-Boot.
>>
>> Thanks,
>>
>> --Brad
>>
>>
>>  
>>
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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
> 
> 

-- 

DAVE Srl - Electronics System House
via Forniz 2/1
33080 Porcia (PN) - Italy
Telephone: +39.0434.921215
Telefax: +39.0434.1994030
Freefax: +39.02.700520062
web: www.dave-tech.it
e-mail: filippo.capurso at dave-tech.it
how to reach us: http://mail.map24.com/dave

[U-Boot-Users] Xilinx ML403/PPC U-Boot support

[S. Egbert]

bbosch at iphase.com wrote:
> Peter Ryser writes:
>  > 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
> 
> Wolfgang,
> 
> Were the Xilinx patches (2005-09-28 thru 2005-10-02) rejected or lost,
> or are they still in your queue?
> 

I'm also interested whether Xilinx EMAC or TEMAC ethernet driver is
supported in this...(after reviewing the Xilinx zip file, it doesn't...
sigh).

However, I do DO have an Ethernet driver for Xilinx EMAC and TEMAC for
U-boot and it works...   Unfortunately, it uses Xilinx copyrighted
codes...  Somehow, I doubt this is what you wanted.

Is Xilinx copyright ok with you?


> Peter,
> 
> Do you happen to have a design for the ML403 that boots directly from
> the linear flash?  Perhaps with devices mapped as in
> board/xilinx/ml403/xparameters.h?  It would be easier to start with a
> design known to work with U-Boot.
> 

Careful.  ML403 reference design (as-is) is not using the Xilinx option
of using side-by-side data access (32-bit fetch out of a single 16-bit
flash), so XIP (execution in place) is evidently NOT supported in ML403.
 However, I had a new bit file built with side-by-side data access
enabled, but haven't yet execute out of flash (no need because ML403 has
a big memory.)  But it correctly fetches 32-bit now.  Ping me in a week
on my progress with XIP and flash.

S. Egbert

[U-Boot-Users] Xilinx ML403/PPC U-Boot support

[Peter Ryser]

>Careful.  ML403 reference design (as-is) is not using the Xilinx option
>of using side-by-side data access (32-bit fetch out of a single 16-bit
>flash), so XIP (execution in place) is evidently NOT supported in ML403.
> However, I had a new bit file built with side-by-side data access
>enabled, but haven't yet execute out of flash (no need because ML403 has
>a big memory.)  But it correctly fetches 32-bit now.  Ping me in a week
>on my progress with XIP and flash.
>
Hmm, why do you need that? The ML403 has two flash chips and with that 
allows 32 bit wide accesses. That allows you to access the whole flash 
space and should give you much better performance than executing out of 
a 16 bit wide flash.

- Peter

[U-Boot-Users] Xilinx ML403/PPC U-Boot support

[S. Egbert]

Peter Ryser wrote:
> 
>> Careful.  ML403 reference design (as-is) is not using the Xilinx option
>> of using side-by-side data access (32-bit fetch out of a single 16-bit
>> flash), so XIP (execution in place) is evidently NOT supported in ML403.
>> However, I had a new bit file built with side-by-side data access
>> enabled, but haven't yet execute out of flash (no need because ML403 has
>> a big memory.)  But it correctly fetches 32-bit now.  Ping me in a week
>> on my progress with XIP and flash.
>>
> Hmm, why do you need that? The ML403 has two flash chips and with that
> allows 32 bit wide accesses. That allows you to access the whole flash
> space and should give you much better performance than executing out of
> a 16 bit wide flash.
> 

Brain fart.   My ML403-derived board dropped only one flash chip down to
one....

Please disregard note of side-by-side data fetch and ML403.  This is not
applicable toward ML403 reference design.  XIP SHOULD BE possible out of
linear flash, however, time is saved in the long run if you preload it
into DDR SDRAM firstly.

True on the better execution performance using two flash chips BUT no
need for XIP here on my part.


S. Egbert

[U-Boot-Users] Xilinx ML403/PPC U-Boot support

[yogir]

Hi Egbert, 

I would like to have access to u-boot with TEMAC for Xilinx ML403 board, 
please let me have the location of it.

thanks 
Yogi

S Egbert wrote:
> 
> bbosch at iphase.com wrote:
>> Peter Ryser writes:
>>  > 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
>> 
>> Wolfgang,
>> 
>> Were the Xilinx patches (2005-09-28 thru 2005-10-02) rejected or lost,
>> or are they still in your queue?
>> 
> 
> I'm also interested whether Xilinx EMAC or TEMAC ethernet driver is
> supported in this...(after reviewing the Xilinx zip file, it doesn't...
> sigh).
> 
> However, I do DO have an Ethernet driver for Xilinx EMAC and TEMAC for
> U-boot and it works...   Unfortunately, it uses Xilinx copyrighted
> codes...  Somehow, I doubt this is what you wanted.
> 
> Is Xilinx copyright ok with you?
> 
> 
>> Peter,
>> 
>> Do you happen to have a design for the ML403 that boots directly from
>> the linear flash?  Perhaps with devices mapped as in
>> board/xilinx/ml403/xparameters.h?  It would be easier to start with a
>> design known to work with U-Boot.
>> 
> 
> Careful.  ML403 reference design (as-is) is not using the Xilinx option
> of using side-by-side data access (32-bit fetch out of a single 16-bit
> flash), so XIP (execution in place) is evidently NOT supported in ML403.
>  However, I had a new bit file built with side-by-side data access
> enabled, but haven't yet execute out of flash (no need because ML403 has
> a big memory.)  But it correctly fetches 32-bit now.  Ping me in a week
> on my progress with XIP and flash.
> 
> 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
> 
> 

-- 
View this message in context: http://www.nabble.com/Sequence-of-Xilinx-ML403-PPC-tf1009012.html#a8072383
Sent from the Uboot - Users mailing list archive at Nabble.com.