[U-Boot-Users] My first embedded project

Hi, I'm new to the world of embedded linux and have a few questions.
First some back ground on my current project. I am the software guy on an embedded firmware project. We are using a Virtex II Pro P50 with one PowerPC 405 core. We will have 512MB Compactflash and 64MB SRAM. We want to use U-boot and the latest kernel of linux as our bootlaoder and OS. The firmware package that will be running on the OS will be C/C++ programs.
1. Is there a way to use U-boot without an EEPROM. Can we use U-boot with its environmental variables on the Compactflash card?
2. Is there a doc that details the boot processes of the boot loader and the linux kernel?
3. Is there a doc detailing the process of downloading, configuring and porting an open source kernel to the VII Pro?
I greatly appreciate any help. Thank you very much, Ben

In message OF148F35BA.97D68C7A-ON07256FA4.007D54A4@mck.us.ray.com you wrote:
- Is there a way to use U-boot without an EEPROM. Can we use U-b oot with
U-Boot does not need any EEPROM at all.
Ummm... maybe you meant flash memory when you wrote EEPROM?
Even then, U-Boot does not need any flash at all, either. [Although it makes some things much easier.]
its environmental variables on the Compactflash card?
Short answer: no, this is not possible.
In the current code there is no support for storing the environment in CF; adding this feature is non trivial and not possible withouit major reorganization of the U-Boot code.
Remember that the environment must be accessable very early, even before the system RAM has been initialized, i. e. in a very restricted environment with just a minimal stack, no writable data segment, etc. Compact Flash (or more generally: IDE) support is enabled much, much later in the boot sequence.
- Is there a doc that details the boot processes of the boot loader and
the linux kernel?
You mean additionally to the README and the manual and the sources? No.
- Is there a doc detailing the process of downloading, configuring and
porting an open source kernel to the VII Pro?
Dunno.
Best regards,
Wolfgang Denk

On Friday 11 February 2005 00.11, Wolfgang Denk wrote:
In message OF148F35BA.97D68C7A-ON07256FA4.007D54A4@mck.us.ray.com you
wrote:
- Is there a way to use U-boot without an EEPROM. Can we use U-b oot
with
U-Boot does not need any EEPROM at all.
Ummm... maybe you meant flash memory when you wrote EEPROM?
Even then, U-Boot does not need any flash at all, either. [Although it makes some things much easier.]
its environmental variables on the Compactflash card?
Short answer: no, this is not possible.
In the current code there is no support for storing the environment in CF; adding this feature is non trivial and not possible withouit major reorganization of the U-Boot code.
Remember that the environment must be accessable very early, even before the system RAM has been initialized, i. e. in a very restricted environment with just a minimal stack, no writable data segment, etc. Compact Flash (or more generally: IDE) support is enabled much, much later in the boot sequence.
Shouldn't it be possible to do this in two stages. 1) Have environment variables in flash/EEPROM so you can mount the CF disk 2) Run an autoscript(?) from that disk to change the variables (do not save) 3) Boot
/RogerL

In message 200502111457.39393.roger.larsson@norran.net you wrote:
Shouldn't it be possible to do this in two stages.
- Have environment variables in flash/EEPROM so you can mount the CF disk
- Run an autoscript(?) from that disk to change the variables (do not save)
- Boot
If you have 1) then why would you need or want 2)? [Of course this can be done, but it means that the master representation of the environment as used for booting is in on-voard flash.]
Best regards,
Wolfgang Denk

On Fri, 11 Feb 2005 14:57:39 +0100, Roger Larsson roger.larsson@norran.net wrote:
Shouldn't it be possible to do this in two stages.
- Have environment variables in flash/EEPROM so you can mount the CF disk
- Run an autoscript(?) from that disk to change the variables (do not save)
- Boot
Would it be safe to assume that you're using a VIIPro w/ a SystemACE boot device? If so, is it also safe to assume that you want to do this because your don't have a FLASH device? Are you booting off of BRAM that is loaded as part of the FPGA image?
If all of the above is true, another way to go about it is to use a two stage boot loader system. Create a very small boot loader that lives in BRAM who's sole purpose in life is to load a more feature rich bootloader off of the CF card from a predefined filename. The second stage boot loader can then also read boot parameters from CF and provide a boot console.
If you wish to use u-boot, you could get a simple 1st stage to load u-boot and it's environment image from CF into SDRAM. u-boot then becomes your second stage.
Wolfgang, regardless of the fact that the FAQ says that u-boot must run out of FLASH, in this scenario it will be running out of SDRAM. Now, from what I know, I cannot see this being a problem because with the VIIPro+SystemACE there is no SDRAM initialization that the bootloader is responsible for. Plus there is absolutely no FLASH device available anyway. Do you see this as a problem? If so, what are the likely issues that Roger may see?
Note; BRAM may be expensive so it is desirable to keep it as small as possible; especially considering that the SystemACE loads the VIIPro via JTAG. Big Image=Slow Boot. I would make the first stage loader as dumb as possible.
At the risk of peeing in this particular pool; if there is still a problem with running out of SDRAM then you may want to consider RedBoot as your second stage. Word of warning though; RedBoot/eCos has a steep learning curve associated with it.
Cheers, g.
/RogerL
SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

Dear Grant,
in message 528646bc050212001475fc6c92@mail.gmail.com you wrote:
Wolfgang, regardless of the fact that the FAQ says that u-boot must run out of FLASH, in this scenario it will be running out of SDRAM.
This is not quite correct. The FAQ says that it *is* possible, but you'd better understand what you are doing. There are situations (like flash- and ROM-less systems) where this is perfectly legal - or even the only way to run any software at all. For example, consider a PCI card where U-Boot gets loaded into pre-initialized RAM by software running on the host computer.
The FAQ entry is intended to stop people with standard systems (i. e. such booting from on-board flash) to use such an approach thinking it would save them time or effort.
Now, from what I know, I cannot see this being a problem because with the VIIPro+SystemACE there is no SDRAM initialization that the bootloader is responsible for. Plus there is absolutely no FLASH device available anyway. Do you see this as a problem? If so, what are the likely issues that Roger may see?
I don't see any inherent problems.
Note; BRAM may be expensive so it is desirable to keep it as small as possible; especially considering that the SystemACE loads the VIIPro via JTAG. Big Image=Slow Boot. I would make the first stage loader as dumb as possible.
Especially in such a situation it might make sense to include zlib functionality into the first stage loader - a compressed U-Boot image will load faster (assuming your processor is fast enough).
Best regards,
Wolfgang Denk

On Sat, 12 Feb 2005 21:15:31 +0100, Wolfgang Denk wd@denx.de wrote:
Dear Grant,
in message 528646bc050212001475fc6c92@mail.gmail.com you wrote:
Wolfgang, regardless of the fact that the FAQ says that u-boot must run out of FLASH, in this scenario it will be running out of SDRAM.
This is not quite correct. The FAQ says that it *is* possible, but you'd better understand what you are doing. There are situations (like flash- and ROM-less systems) where this is perfectly legal - or even the only way to run any software at all. For example, consider a PCI card where U-Boot gets loaded into pre-initialized RAM by software running on the host computer.
The FAQ entry is intended to stop people with standard systems (i. e. such booting from on-board flash) to use such an approach thinking it would save them time or effort.
Right; understood.
Note; BRAM may be expensive so it is desirable to keep it as small as possible; especially considering that the SystemACE loads the VIIPro via JTAG. Big Image=Slow Boot. I would make the first stage loader as dumb as possible.
Especially in such a situation it might make sense to include zlib functionality into the first stage loader - a compressed U-Boot image will load faster (assuming your processor is fast enough).
Good idea. Fortunatly once the first stage is loaded the processor is started and JTAG is no longer used. Loading the second stage should be quite quick.
Cheers, g.
participants (4)
-
Benjamin D Boicourt
-
Grant Likely
-
Roger Larsson
-
Wolfgang Denk