[PATCH 2/5] u-boot REV C - Additional build to ignore ENV settings
Khasim Syed Mohammed
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.
---
diff --git a/Makefile b/Makefile
index 787c5f2..d65079e 100644
--- a/Makefile
+++ b/Makefile
@@ -151,8 +151,12 @@ ifeq ($(ARCH),ppc)
CROSS_COMPILE = ppc_8xx-
endif
ifeq ($(ARCH),arm)
+ifeq ($(CPU),arm_cortexa8)
+CROSS_COMPILE = arm-none-linux-gnueabi-
+else
CROSS_COMPILE = arm-linux-
endif
+endif
ifeq ($(ARCH),i386)
CROSS_COMPILE = i386-linux-
endif
@@ -2935,6 +2939,14 @@ omap3_pandora_config : unconfig
omap3_zoom1_config : unconfig
@$(MKCONFIG) $(@:_config=) arm arm_cortexa8 zoom1 omap3 omap3
+beagle : unconfig
+ @$(MKCONFIG) omap3_beagle arm arm_cortexa8 beagle omap3 omap3
+ $(MAKE) || exit 1
+ mv u-boot.bin u-boot-f.bin
+ echo "#define CONFIG_OVERRIDE_BOOTENV 1" >>$(obj)include/config.h
+ $(MAKE) || exit 1
+ ./mkbootscr
+
#########################################################################
## XScale Systems
#########################################################################
diff --git a/common/env_common.c b/common/env_common.c
index 6be3bb0..6f39f10 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -251,8 +251,12 @@ void env_relocate (void)
DEBUGF ("%s[%d] malloced ENV at %p\n", __FUNCTION__,__LINE__,env_ptr);
#endif
+#ifdef CONFIG_OVERRIDE_BOOTENV
+ gd->env_valid = 0;
+#endif
if (gd->env_valid == 0) {
-#if defined(CONFIG_GTH) || defined(CONFIG_ENV_IS_NOWHERE) /*
Environment not changable */
+#if defined(CONFIG_GTH) || defined(CONFIG_ENV_IS_NOWHERE) \
+ || defined(CONFIG_OVERRIDE_BOOTENV) /* Environment not changable */
puts ("Using default environment\n\n");
#else
puts ("*** Warning - bad CRC, using default environment\n\n");
diff --git a/doc/README.omap3 b/doc/README.omap3
index 1ba307f..03fc53e 100644
--- a/doc/README.omap3
+++ b/doc/README.omap3
@@ -31,8 +31,7 @@ Build
* BeagleBoard:
-make omap3_beagle_config
-make
+make beagle
* Gumstix Overo:
diff --git a/mkbootscr b/mkbootscr
new file mode 100755
index 0000000..d175c25
--- /dev/null
+++ b/mkbootscr
@@ -0,0 +1,53 @@
+#!/bin/sh
+cat <<EOF > normal.cmd
+if fatload mmc 0 80200000 uImage.bin
+then
+ echo ***** Kernel: /dev/mmcblk0p1/uImage.bin *****
+else
+ echo ***** Kernel: /dev/mtd3 *****
+ nand read 80200000 280000 400000
+fi
+if fatload mmc 0 81600000 ramdisk.gz
+then
+ echo ***** RootFS: /dev/mmcblk0p1/ramdisk.gz *****
+ setenv bootargs 'console=ttyS2,115200n8 console=tty0 root=/dev/ram0
rw ramdisk_size=32768 initrd=0x81600000,32M'
+else
+ echo ***** RootFS: /dev/mmcblk0p2 *****
+ setenv bootargs 'console=ttyS2,115200n8 console=tty0
root=/dev/mmcblk0p2 rw rootwait'
+fi
+bootm 80200000
+EOF
+
+mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n 'Execute
uImage.bin' -d normal.cmd normal.scr
+
+cat <<EOF_FLASH > reset.cmd
+if fatload mmc 0 80200000 x-load.bin.ift
+then
+ echo ***** Replacing x-load *****
+ nand unlock
+ nandecc hw
+ nand erase 0 80000
+ nand write 80200000 0 20000
+ nand write 80200000 20000 20000
+ nand write 80200000 40000 20000
+ nand write 80200000 60000 20000
+fi
+if fatload mmc 0 80200000 u-boot-f.bin
+then
+ echo ***** Replacing u-boot *****
+ nand unlock
+ nandecc sw
+ nand erase 80000 160000
+ nand write 80200000 80000 160000
+fi
+echo ***** Erasing environment settings *****
+nand unlock
+nand erase 160000 20000
+if fatload mmc 0 80200000 normal.scr
+then
+ echo ***** Executing normal.scr *****
+ autoscr 80200000
+fi
+EOF_FLASH
+
+mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n 'Reset flash'
-d reset.cmd reset.scr
Søren Steen Christensen
> 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 :-) Avoiding one extra would be beneficial, I
think...
Best regards
Søren
Nishanth Menon
> 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...
>
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
Koen Kooi
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
Søren Steen Christensen
>> 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 :-)
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
Koen Kooi
Op 20 feb 2009, om 12:07 heeft Søren Steen Christensen het volgende
geschreven:
>
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 :)
regards,
Koen
Søren Steen Christensen
> > 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 :)
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 :-) - Right?...
Best regards and thanks
Søren
Syed Mohammed, Khasim
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 :)
Regards,
Khasim
Steve Sakoman
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 :-)
Steve
PS: Koen, I know your response is "use OE" :-) But it often takes
newbies a long frustrating journey to get to that simple (and
effective) advice.
Koen Kooi
Op 20 feb 2009, om 16:48 heeft Steve Sakoman het volgende geschreven:
>
> PS: Koen, I know your response is "use OE" :-) 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 :)
regards,
Koen
Søren Steen Christensen
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
Steve Sakoman
<sorensch...@stofanet.dk> wrote:
> 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
Jason Kridner
On Feb 20, 12:27 pm, Steve Sakoman <sako...@gmail.com> wrote:
> On Fri, Feb 20, 2009 at 9:09 AM, Søren Steen Christensen
>
*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.
Jason Kridner
On Feb 21, 2:54 am, Jason Kridner <jkrid...@beagleboard.org> wrote:
> On Feb 20, 12:27 pm, Steve Sakoman <sako...@gmail.com> wrote:
>
>
>
> > On Fri, Feb 20, 2009 at 9:09 AM, Søren Steen Christensen
>
> > <sorenschristen...@stofanet.dk> wrote:
> > > 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!
>
> > > 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
> > 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
> as we can build that step in, I think we can aligned on a single u-
> boot binary.
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?
John (USP)
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.
sanju More
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
Søren Steen Christensen
> 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