[U-Boot-Users] My first embedded project

[U-Boot-Users] My first embedded project

[Benjamin D Boicourt]

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

[U-Boot-Users] My first embedded project

[Wolfgang Denk]

In message <OF148F35BA.97D68C7A-ON07256FA4.007D54A4@mck.us.ray.com> you wrote:
> 
> 1. 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.


> 2. 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.

> 3. 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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Business is like a wheelbarrow. Nothing ever happens until you  start
pushing.

[U-Boot-Users] My first embedded project

[Roger Larsson]

On Friday 11 February 2005 00.11, Wolfgang Denk wrote:
> In message <OF148F35BA.97D68C7A-ON07256FA4.007D54A4@mck.us.ray.com> you 
wrote:
> > 1. 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

[U-Boot-Users] My first embedded project

[Wolfgang Denk]

In message <200502111457.39393.roger.larsson@norran.net> you wrote:
> 
> 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

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Save yourself!  Reboot in 5 seconds!

[U-Boot-Users] My first embedded project

[Grant Likely]

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.
> 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
> 
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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>

[U-Boot-Users] My first embedded project

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In C we had to code our own bugs, in C++ we can inherit them.

[U-Boot-Users] My first embedded project

[Grant Likely]

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.