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

[Wolfgang Denk]

In message <OF59D7AF38.9E936776-ON07257066.0059D1CC-07257066.005B8D56 at 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?