[U-Boot-Users] RFC: U-Boot Environment support in SystemAce Compact FLASH
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
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
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?
u-boot-users-admin@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@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.
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
In message OF59D7AF38.9E936776-ON07257066.0059D1CC-07257066.005B8D56@mck.us.ray.com you wrote:
As I understand it, these are the issues:
- Small stack
- BSS is uninitialized
- 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
participants (4)
-
Andrew Dyer -
Keith J Outwater -
Keith J Outwater
-
Wolfgang Denk