wd@denx.de wrote on 08/22/2005 01:56:23 PM:
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.
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@denx.de Men of peace usually are [brave]. -- Spock, "The Savage Curtain", stardate 5906.5