[PATCH 2/5] u-boot REV C - Additional build to ignore ENV settings

X-Git-Tag: validation-revc-20090203d~2
X-Git-Url: http://www.beagleboard.org/gitweb/?p=u-boot-arm.git;a=commitdiff_plain;h=6b31b0e7d881b741e020d799f4d5bc1165241797

OMAP3: BeagleBoard: Additional build to ignore environment variables

Builds now performed as 'make beagle' and they will generate
two versions of u-boot. u-boot.bin is meant to be placed on
SD cards and will always ignore the environment variables that
are stored on flash and execute the default environment. The
u-boot-f.bin is meant to be stored on the flash and will work
normally, reading the environment off of the flash.

0002-Additional-build-to-ignore-env-variables (4.11 KB)

From: Jason Kridner <jkridner@beagleboard.org>
Date: Wed, 4 Feb 2009 01:34:34 +0000 (-0600)
Subject: OMAP3: BeagleBoard: Additional build to ignore environment
variables
X-Git-Tag: validation-revc-20090203d~2
X-Git-Url: http://www.beagleboard.org/gitweb/?p=u-boot-
arm.git;a=commitdiff_plain;h=6b31b0e7d881b741e020d799f4d5bc1165241797

OMAP3: BeagleBoard: Additional build to ignore environment variables

Builds now performed as 'make beagle' and they will generate two
versions of u-boot. u-boot.bin is meant to be placed on SD cards and
will always ignore the environment variables that are stored on flash
and execute the default environment. The u-boot-f.bin is meant to be
stored on the flash and will work normally, reading the environment off
of the flash.

Hi Khasim,

Instead of creating two different binaries (one for NAND and one for MMC), I
would recommend checking the ROM code trace word to detect if we are booting
from MMC or NAND, and then distinguish runtime instead. More information on
this can be found in the TRM chapter 25.4.9...

Sorry for not catching this preciously, but I really think it can avoid a
lot of confusion in the future only having one u-boot binary compared to
two. People are already more than enough confused about: xloader (MLO after
signing - Header adding :-)), u-boot, uImage and FileSystem images, and
which versions fits together :slight_smile: Avoiding one extra would be beneficial, I
think...

Best regards
  Søren

Søren Steen Christensen said the following on 02/20/2009 12:03 PM:

Instead of creating two different binaries (one for NAND and one for MMC), I
would recommend checking the ROM code trace word to detect if we are booting
from MMC or NAND, and then distinguish runtime instead. More information on
this can be found in the TRM chapter 25.4.9...
  

This probably needs to be done in the x-loader.. not u-boot rt? I dont
see how we need 2 u-boot binaries anyway.. once loaded to sdram, u-boot
probably does not care for anything else -> environment variables will
anyways be on nand.. the only case i can think of u-boot being aware of
mmc vs nand boot is if we have a way to read/write environment variables
in sd/mmc card with u-boot(I have'nt yet heard of anyone doing it..
kinda sounds cool thing though)..

Regards,
Nishanth Menon

Op 20 feb 2009, om 11:03 heeft Søren Steen Christensen het volgende geschreven:

Instead of creating two different binaries (one for NAND and one for MMC), I
would recommend checking the ROM code trace word to detect if we are booting
from MMC or NAND, and then distinguish runtime instead.

Please no! What Khasim tries to accomplish is the following:

* u-boot in nand with bootargs in nand env
* filesystem on SD needs specific bootargs (e.g. hardcoding g_ether address, setting videomode, etc)
* no serial or usb console

Think of handing out 30 beagles to a class room and having a set of SD cards that need a specific environment to run properly. With the env-ignoring uboot on SD you can garantee that.

What you DON'T want is that the single blessed u-boot binary will *always* ignore the uboot env if it's booting from SD, since those beagles won't always be used in the classroom.

regards,

Koen

Instead of creating two different binaries (one for NAND and one for
MMC), I
would recommend checking the ROM code trace word to detect if we are
booting
from MMC or NAND, and then distinguish runtime instead.

Please no! What Khasim tries to accomplish is the following:

* u-boot in nand with bootargs in nand env
* filesystem on SD needs specific bootargs (e.g. hardcoding g_ether
address, setting videomode, etc)
* no serial or usb console

Think of handing out 30 beagles to a class room and having a set of SD
cards that need a specific environment to run properly. With the env-
ignoring uboot on SD you can garantee that.

What you DON'T want is that the single blessed u-boot binary will
*always* ignore the uboot env if it's booting from SD, since those
beagles won't always be used in the classroom.

Apologizes for being a bit slow on this, but I don't get you point - You
might be right, but I just don't follow you - Yet :slight_smile:

1) In the classroom setup you want the SD U-boot to ignore the environment
variables and run with the standard set in order to ensure, that everything
works just nice.

2) Next you want the same U-boot (still on SD) to give the possibility to
change the variables when not used in a classroom setup in order to be
flexible?

Right? - How is this possible?
  Søren

Op 20 feb 2009, om 12:07 heeft Søren Steen Christensen het volgende geschreven:

Instead of creating two different binaries (one for NAND and one for
MMC), I
would recommend checking the ROM code trace word to detect if we are
booting
from MMC or NAND, and then distinguish runtime instead.

Please no! What Khasim tries to accomplish is the following:

* u-boot in nand with bootargs in nand env
* filesystem on SD needs specific bootargs (e.g. hardcoding g_ether
address, setting videomode, etc)
* no serial or usb console

Think of handing out 30 beagles to a class room and having a set of SD
cards that need a specific environment to run properly. With the env-
ignoring uboot on SD you can garantee that.

What you DON'T want is that the single blessed u-boot binary will
*always* ignore the uboot env if it's booting from SD, since those
beagles won't always be used in the classroom.

Apologizes for being a bit slow on this, but I don't get you point - You
might be right, but I just don't follow you - Yet :slight_smile:

1) In the classroom setup you want the SD U-boot to ignore the environment
variables and run with the standard set in order to ensure, that everything
works just nice.

Right

2) Next you want the same U-boot (still on SD) to give the possibility to
change the variables when not used in a classroom setup in order to be
flexible?

No, not the same uboot, a 'regular' uboot on SD. Your proposal would mean that people running of SD are screwed if they want to save their env.

Right? - How is this possible?

It isn't, which was my whole point :slight_smile:

regards,

Koen

> 1) In the classroom setup you want the SD U-boot to ignore the
> environment variables and run with the standard set in order
> to ensure, that everything works just nice.
Right

> 2) Next you want the same U-boot (still on SD) to give the
> possibility to change the variables when not used in a classroom
> setup in order to be flexible?
No, not the same uboot, a 'regular' uboot on SD. Your proposal would
mean that people running of SD are screwed if they want to save their
env.

> Right? - How is this possible?
It isn't, which was my whole point :slight_smile:

OK - Now I got the point. What confused me what the initial comment from
Khasim (copied below), which mainly distinguished between running from NAND
or MMC, and not running with fixed or changeable environment.

Khasim: "u-boot.bin is meant to be placed on SD cards and will always ignore
the environment variables that are stored on flash and execute the default
environment. The u-boot-f.bin is meant to be stored on the flash and will
work normally, reading the environment off of the flash."

With your explanation, I think the comment ought to be rewritten to reflect
this instead of the NAND/MMC distinguishing, since in your world the
u-boot-f.bin could as well go in the MMC, which makes the name a bit
misleading :slight_smile: - Right?...

Best regards and thanks
  Søren

The other requirement for second u-boot is to bring the board back to
Factory default settings even after one has messed up with bootargs
etc.

Koen, Thanks for answers :slight_smile:

Regards,
Khasim

I absolutely hate having multiple u-boots with different behaviors!

The Beagle world has enough confusion with two types of serial adapter
cables, two flavors of x-load/MLO, uImage vs uImage.bin, validation
u-boots vs community u-boots, TI kernel vs l-o kernel, no "standard"
distro, etc. I hate seeing people struggle with the same issues month
after month. We really should not make things worse!

The classroom type situation was one of the reasons I added the
boot.scr feature to the stock u-boot. If you want everyone in the
classroom to have a default u-boot environment, you just add a
boot.scr which sets up the desired env to the sd FAT partition and you
are good to go.

OK, enough ranting, back to work :slight_smile:

Steve

PS: Koen, I know your response is "use OE" :slight_smile: But it often takes
newbies a long frustrating journey to get to that simple (and
effective) advice.

I've seen people waste 3 weeks where they accomplished nothing to avoid the initial 3 hour build. Which is nice if you get payed by the hour, but I'm not :slight_smile:

regards,

Koen

>> Instead of creating two different binaries (one for NAND and one for
MMC),
>> I
>> would recommend checking the ROM code trace word to detect if we are
>> booting
>> from MMC or NAND, and then distinguish runtime instead.
>
> Please no! What Khasim tries to accomplish is the following:
>
> * u-boot in nand with bootargs in nand env
> * filesystem on SD needs specific bootargs (e.g. hardcoding g_ether
address,
> setting videomode, etc)
> * no serial or usb console
>
> Think of handing out 30 beagles to a class room and having a set of
SD cards
> that need a specific environment to run properly. With the env-
ignoring
> uboot on SD you can garantee that.
>
> What you DON'T want is that the single blessed u-boot binary will
*always*
> ignore the uboot env if it's booting from SD, since those beagles
won't
> always be used in the classroom.

I absolutely hate having multiple u-boots with different behaviors!

The Beagle world has enough confusion with two types of serial adapter
cables, two flavors of x-load/MLO, uImage vs uImage.bin, validation
u-boots vs community u-boots, TI kernel vs l-o kernel, no "standard"
distro, etc. I hate seeing people struggle with the same issues month
after month. We really should not make things worse!

The classroom type situation was one of the reasons I added the
boot.scr feature to the stock u-boot. If you want everyone in the
classroom to have a default u-boot environment, you just add a
boot.scr which sets up the desired env to the sd FAT partition and you
are good to go.

OK - But before getting back to work - How to go from here?

In case the needed functionality is already available in U-boot (using the
boot.scr-file) I would really still recommend only having one U-boot version
available. I can't see any benefit - but a lot of possible confusion - from
having several "nearly identical" u-boot binaries...

If you have to exchange the u-boot binary or add a boot.scr file to the SD
card for the classroom situation - I can't see the difference. I will
therefore tend to support the already integrated method since it gives the
biggest flexibility - I.e. you can change/overwrite the default set of
variables without doing a rebuild of u-boot, by just changing the boot.scr
file - Although it's still pretty fixed and you avoid the problem of exact
typing ...

@Sakoman: Is this right understood?

Best regards
  Søren

OK - But before getting back to work - How to go from here?

Well, it is really up to TI. They are the ones who decide what goes
into flash at the factory and what they use in training classes.

In case the needed functionality is already available in U-boot (using the
boot.scr-file) I would really still recommend only having one U-boot version
available. I can't see any benefit - but a lot of possible confusion - from
having several "nearly identical" u-boot binaries...

I agree totally!

If you have to exchange the u-boot binary or add a boot.scr file to the SD
card for the classroom situation - I can't see the difference. I will
therefore tend to support the already integrated method since it gives the
biggest flexibility - I.e. you can change/overwrite the default set of
variables without doing a rebuild of u-boot, by just changing the boot.scr
file - Although it's still pretty fixed and you avoid the problem of exact
typing ...

@Sakoman: Is this right understood?

Yes, you understand correctly.

At one level, there really isn't much difference between requiring a
special u-boot or a special boot.scr in a classroom environment. But
that neglects the effort in maintaining two versions of u-boot, and
also the potential confusion for newbies. I like having a single
version with a simple way to override defaults in special
circumstances.

Steve

The solution that I believe would be most elegant is for u-boot to
*always* probe for boot.scr on the SD card, even if the environment
variables on the NAND flash don't have that in the bootargs. As long
as we can build that step in, I think we can aligned on a single u-
boot binary.

To make this a clean experience, I'd also want the ability to delete
files from within u-boot. Also, the mkimage format isn't really
appropriate for this context and a plain text file would be far more
welcome.

In the meantime, I think we are stuck with two u-boot binaries as I
need to have a method for generating known-good boot conditions for
recovery and classroom situations, including situations where there is
no access to the serial port.

> > OK - But before getting back to work - How to go from here?

> Well, it is really up to TI. They are the ones who decide what goes
> into flash at the factory and what they use in training classes.

> > In case the needed functionality is already available in U-boot (using the
> >boot.scr-file) I would really still recommend only having one U-boot version
> > available. I can't see any benefit - but a lot of possible confusion - from
> > having several "nearly identical" u-boot binaries...

> I agree totally!

> > If you have to exchange the u-boot binary or add aboot.scrfile to the SD
> > card for the classroom situation - I can't see the difference. I will
> > therefore tend to support the already integrated method since it gives the
> > biggest flexibility - I.e. you can change/overwrite the default set of
> > variables without doing a rebuild of u-boot, by just changing theboot.scr
> > file - Although it's still pretty fixed and you avoid the problem of exact
> > typing ...

> > @Sakoman: Is this right understood?

> Yes, you understand correctly.

> At one level, there really isn't much difference between requiring a
> special u-boot or a specialboot.scrin a classroom environment. But
> that neglects the effort in maintaining two versions of u-boot, and
> also the potential confusion for newbies. I like having a single
> version with a simple way to override defaults in special
> circumstances.

The solution that I believe would be most elegant is for u-boot to
*always* probe forboot.scron the SD card, even if the environment
variables on the NAND flash don't have that in the bootargs. As long
as we can build that step in, I think we can aligned on a single u-
boot binary.

Can I get some ACKs on this approach? I seem to be getting a query
every couple days on the IRC now about my stupid decision to build a u-
boot that ignores the NAND environment variables. If boot.scr is
always read and executed, does that work for everyone? Does anyone
have a reasonable idea how to implement that?

From: beagleboard@googlegroups.com
[mailto:beagleboard@googlegroups.com] On Behalf Of Jason Kridner
Sent: Monday, March 09, 2009 8:55 PM
To: Beagle Board
Subject: [beagleboard] Re: u-boot REV C - Additional build to ignore ENV

settings

>
>
>
> > > OK - But before getting back to work - How to go from here?
>
> > Well, it is really up to TI. They are the ones who decide what goes
> > into flash at the factory and what they use in training classes.
>
> > > In case the needed functionality is already available in U-boot

(using the

> > >boot.scr-file) I would really still recommend only having one U-boot

version

> > > available. I can't see any benefit - but a lot of possible confusion

- from

> > > having several "nearly identical" u-boot binaries...
>
> > I agree totally!
>
> > > If you have to exchange the u-boot binary or add aboot.scrfile to

the SD

> > > card for the classroom situation - I can't see the difference. I

will

> > > therefore tend to support the already integrated method since it

gives the

> > > biggest flexibility - I.e. you can change/overwrite the default set

of

> > > variables without doing a rebuild of u-boot, by just changing

theboot.scr

> > > file - Although it's still pretty fixed and you avoid the problem of

exact

> > > typing ...
>
> > > @Sakoman: Is this right understood?
>
> > Yes, you understand correctly.
>
> > At one level, there really isn't much difference between requiring a
> > special u-boot or a specialboot.scrin a classroom environment. But
> > that neglects the effort in maintaining two versions of u-boot, and
> > also the potential confusion for newbies. I like having a single
> > version with a simple way to override defaults in special
> > circumstances.
>
> The solution that I believe would be most elegant is for u-boot to
> *always* probe forboot.scron the SD card, even if the environment
> variables on the NAND flash don't have that in the bootargs. As long
> as we can build that step in, I think we can aligned on a single u-
> boot binary.

Can I get some ACKs on this approach? I seem to be getting a query
every couple days on the IRC now about my stupid decision to build a u-
boot that ignores the NAND environment variables. If boot.scr is
always read and executed, does that work for everyone? Does anyone
have a reasonable idea how to implement that?

Here are my thoughts on this topic. The more complicated you make this, the
more support will be needed. I think the boot.scr file should be in plain
text format. If the boot.scr does not exist, use the NAND environment
variables. If you want to use the default environment variables, press the
user button during power up. This way, the board startup the way you last
configured the board. If you want to restore factory defaults, that should
be the exception and hence the need to press the user button. Just my two
cents worth.

Hi,

I am booting beagle board fro sd card, and it is failing at reading boot sector

Texas Instruments X-Loader 1.41
Starting on with MMC
Reading boot sector
Error: reading boot sector

How to overcome this error?

Sanjeev

I am booting beagle board fro sd card, and it is failing at reading
boot sector

Texas Instruments X-Loader 1.41
Starting on with MMC
Reading boot sector
Error: reading boot sector

Is the first partition on the SD card FAT-formatted?
Have you tried another SD Card?

/ Søren