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

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

[Keith J Outwater]

Hello all - 
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.
As it stands now, there is DOS FAT read support in U-Boot but no write 
support, so that would have to be added if the environment was to be 
stored as a DOS file on the CF card.  Another option might be to partition 
the CF card so as to leave a few sectors unused and use low-level sector 
read/write routines to store the environment directly to the CF card. This 
solution seems straightforward, but seems somehow inelegant.
I am leaning toward the approach of adding DOS FAT write support and 
adjusting the initial U-Boot environment to provide sufficient stack space 
to run the DOS filesystem code during initial boot.  Does this seem 
reasonable?  Does anyone know where the original DOS filesystem code came 
from? 

Keith

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

[Wolfgang Denk]

In message <OF8ADB0661.25EF292C-ON07257065.00568E7A-07257065.00576B05@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.

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

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

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

[Andrew Dyer]

On 8/22/05, Wolfgang Denk <wd@denx.de> wrote:
> In message <OF8ADB0661.25EF292C-ON07257065.00568E7A-07257065.00576B05@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.
> 
> > 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.
> 

Does a system ace CF card have a partition table?  Maybe you could make a
special partition on the CF for this type of info.  You would need a sector read
routine and code to parse the partition table to index into the
environment sectors.
You would probably need some ram available (or at least a bunch of registers)
to pull this off.

Another option might be to store the environment stuff as data to be loaded into
an accessible block ram on fpga power-up.  I haven't looked at how system ace
handles this sort of thing.  Are the block ram contents stored in
separate files on
the CF?

-- 
Hardware, n.:
        The parts of a computer system that can be kicked.

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

[Keith J Outwater]

u-boot-users-admin at lists.sourceforge.net wrote on 08/22/2005 04:43:15 PM:

> On 8/22/05, Wolfgang Denk <wd@denx.de> wrote:
> > 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.
> > 
> > > 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.
> > 
> 
> Does a system ace CF card have a partition table?  Maybe you could make 
a
> special partition on the CF for this type of info.  You would need a
> sector read
> routine and code to parse the partition table to index into the
> environment sectors.
> You would probably need some ram available (or at least a bunch of 
registers)
> to pull this off.

RAM is not a problem.  VirtexII FPGA based processor systems have plenty 
of RAM for this type of thing.
I like this idea a lot better than just trying to access raw sectors on 
the CF card.  I'll take a look at that.

> 
> Another option might be to store the environment stuff as data to be
> loaded into
> an accessible block ram on FPGA power-up.  I haven't looked at how 
system ace
> handles this sort of thing.  Are the block ram contents stored in
> separate files on
> the CF?

Not as a separate file, but (optionally) as part of the FPGA configuration 
bitstream.
The problem with using block RAM for storing the environment is that it is 
volatile.

[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

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

[Wolfgang Denk]

In message <OF59D7AF38.9E936776-ON07257066.0059D1CC-07257066.005B8D56@mck.us.ray.com> you wrote:
> 
> 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?

Many other parts are not yet initialized and/or working,  and  trying
to change the init sequence to make it work will most probably result
in  a  mess.  You  don't  even  have  a  serial  console port yet for
debugging. This also means that your have to remove  each  and  every
printf() or puts() from all code you need to call, and recursively.

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

I am definitely aware  of  this.  However,  the  design  decision  to
provide  a  serial  console  port  very early also results in certain
restrictions - like not being  able  to  load  the  environment  from
arbitrary storage devices.

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

The U-Boot design is definitely *not* optimized for such a system.

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

All you get rid of is the file system problems.

You still have lots of other problems.  I  mentioned  that  you  must
"clean" all code you are going to call, and recursively all functions
that are referenced by this code, from any printf() or puts(). Either
you give up here, or you will have a mess of code. or you will try to
delay access to the real environment and fake one, at which point the
whole approach should be put into question.

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
If ignorance is bliss, why aren't there more happy people?