[U-Boot-Users] RFC: U-Boot Environment support in SystemAce Compact FLASH

[Keith J Outwater]

wd at denx.de wrote on 08/22/2005 01:56:23 PM:

> In message <OF8ADB0661.25EF292C-ON07257065.00568E7A-07257065.
> 00576B05 at mck.us.ray.com> you wrote:
> >
> > I have completed the initial port of U-Boot to a custom 
PPC405/VirtexII 
> > Pro FPGA board and I am starting to look at ways to store the U-Boot 
> > environment in the CF card used for FPGA configuration by the Xilinx 
> > SystemAce.
> 
> Please re-read the archives why this is not as trivial as it may seem.

As I understand it, these are the issues:
1. Small stack
2. BSS is uninitialized
3. Global data is not writeable

Am I missing something from this list?

> 
> > I am leaning toward the approach of adding DOS FAT write support and 
> > adjusting the initial U-Boot environment to provide sufficient stack 
space 
> 
> This won't help you much. In the first step, you would have to modify
> the whole CF and DOS FAT code such that it works while  running  from
> flash.  This is a non-trivial task, and I don't intend to accept such
> modifications for inclusion in the publich tree.

OK, that pretty much kills that idea.

That being said, please realize that some board architectures have *much 
more* resources available at boot than some of the powerQUICC systems that 
ppcboot/U-Boot grew up on.

For example, the PPC405 systems that can be built using a VirtexII PRO 
FPGA have main memory (SDRAM, DDR SDRAM, etc) available *immediately* upon 
processor release.  These FPGAs provide lots of flexible, internal static 
RAM (block RAM), which for a 2VP50 device is something like 400 kbytes. In 
fact, my current design has no FLASH at all - a large chunk of block RAM 
is initialized with the U-Boot image along with the rest of the FPGA 
logic.  U-Boot is running from RAM from the start.

I think it's reasonable to assume that the kinds of resources I mentioned 
are going to be available for any system using the SystemACE given that 
the SystemACE approach to FPGA configuration is a high-end solution and it 
would typically be used in systems with big FPGAs and lots of memory.  I 
would not expect someone to use a Xilinx FPGA specific device like this 
simply to provide a CF card interface.

So that's why I was looking at simply throwing resources at issues 1-3 
above - I have a lot of resources available in this system, and any 
similar system would have them as well.

As to additional issues involved in running the FAT code from "flash", I'd 
like to learn more.  Maybe not to solve this problem (as I am considering 
this approach killed), but to broaden my knowledge.

There was a suggestion to use a dedicated partition on the CF card to hold 
the environment and manually parse the partition map.  Is this an approach 
you could support?

Keith

> 
> 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
> Men of peace usually are [brave].
>    -- Spock, "The Savage Curtain", stardate 5906.5