[U-Boot-Users] RFC: U-Boot Environment support in SystemAce Compact FLASH
Wolfgang Denk
wd at denx.de
Tue Aug 23 22:46:00 CEST 2005
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?
More information about the U-Boot
mailing list