[PATCH v2] omap3_beagle: enable the use of a plain text file named uEnv.txt instead of boot.scr
Jason Kridner
Using the new env import command it is possible to use plain text files instead
of script-images. Plain text files are much easier to handle.
E.g. If your boot.scr contains the following:
-----------------------------------
setenv dvimode 1024x768-16@60
run loaduimage
run mmcboot
-----------------------------------
you could create a file named uEnv.txt and use that instead of boot.scr:
-----------------------------------
dvimode=1024x768-16@60
uenvcmd=run loaduimage; run mmcboot
-----------------------------------
The variable uenvcmd (if existent) will be executed (using run) after uEnv.txt
was loaded. If uenvcmd doesn't exist the default boot sequence will be started,
therefore you could just use
-----------------------------------
dvimode=1024x768-16@60
-----------------------------------
as uEnv.txt because loaduimage and mmcboot is part of the default boot sequence.
For backwards compatibility the use of boot.scr is still supported.
---
Changes for v2:
- Eliminated else redundant clause that would be ignored if boot
succeeds.
Signed-off-by: Jason Kridner <jkri...@beagleboard.org>
Cc: Alexander Holler <hol...@ahsoftware.de>
---
include/configs/omap3_beagle.h | 26 ++++++++++++++++++--------
1 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index f151e98..b7f5480 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -229,6 +229,9 @@
"loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
"bootscript=echo Running bootscript from mmc ...; " \
"source ${loadaddr}\0" \
+ "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
+ "importbootenv=echo Importing environment from mmc ...; " \
+ "env import -t $loadaddr $filesize\0" \
"loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
"mmcboot=echo Booting from mmc ...; " \
"run mmcargs; " \
@@ -240,15 +243,22 @@
#define CONFIG_BOOTCOMMAND \
"if mmc rescan ${mmcdev}; then " \
+ "echo SD/MMC found on device ${mmcdev};" \
+ "if run loadbootenv; then " \
+ "run importbootenv;" \
+ "fi;" \
+ "if test -n $uenvcmd; then " \
+ "echo Running uenvcmd ...;" \
+ "run uenvcmd;" \
+ "fi;" \
"if run loadbootscript; then " \
- "run bootscript; " \
- "else " \
- "if run loaduimage; then " \
- "run mmcboot; " \
- "else run nandboot; " \
- "fi; " \
- "fi; " \
- "else run nandboot; fi"
+ "run bootscript;" \
+ "fi;" \
+ "if run loaduimage; then " \
+ "run mmcboot;" \
+ "fi;" \
+ "fi;" \
+ "run nandboot;" \
#define CONFIG_AUTO_COMPLETE 1
/*
--
1.5.6.4
Alexander Holler
If I interpret your change correctly, your v2 would use uEnv.txt and
boot.scr if both are existent. I think this would only lead to confusion.
My target was to get rid of boot.scr and to therefor boot.scr would be
ignored if uEnv.txt exists. I don't see any reason why boot.scr should
be still used when uEnv.txt exists.
Regards,
Alexander
Jason Kridner
if uenvcmd results in a successful boot, then boot.scr would never get executed.
Again, my concern is that this default logic gets overly complex. A
policy of applying linear attempt-then-fall-through will make patches
to this logic apply cleanly as new boot sources are added,
specifically if we ever get the USER button support upstream.
I understand the goal of only using uEnv.txt and not using ucmdenv
such that the u-boot default variables can be used to perform the
boot. I think this goal can easily be achieved by deleting boot.scr.
If boot.scr exists, I don't follow that it would be any less confusing
to the user if it were to *not* be executed following uEnv.txt.
Alexander Holler
But that requires that uenvcmd is set/used which makes uEnv.txt
unnecessarily complex and will not be possible to define/change e.g.
only the (u-boot) environment variable dvimode.
> Again, my concern is that this default logic gets overly complex. A
> policy of applying linear attempt-then-fall-through will make patches
> to this logic apply cleanly as new boot sources are added,
> specifically if we ever get the USER button support upstream.
We could just delete the logic for boot.scr. Another approach would be
to print a warning like "The usage of boot.scr is deprecated and will be
removed with the next release!" if boot.scr will be used and delete the
stuff for boot.scr with the next release.
> I understand the goal of only using uEnv.txt and not using ucmdenv
> such that the u-boot default variables can be used to perform the
> boot. I think this goal can easily be achieved by deleting boot.scr.
> If boot.scr exists, I don't follow that it would be any less confusing
> to the user if it were to *not* be executed following uEnv.txt.
Again, I think such an approach will only confuse people because stuff
from two files might be used. And what is used will depend on what
u-boot is used. There might be people with an u-boot in NAND, for which
a boot.scr on an SD-card still is required. But if you want to serve
people with an new u-boot too, you'll need an uEnv.txt too. And with
your logic that has to use an uencmd, which makes uEnv.txt more
complicate than needed.
And most people never see the bootcmd, but they see uEnv.txt and/or
boot.scr because they have to define the resolution for their monitor there.
So I still would prefer to leave bootcmd currently a bit more
complicated, with the advantage that only a simple uEnv.txt is possible
which just contains e.g. "dvimode=1024x768-16@60".
Alexander Holler
just a last word. I don't have to decide which patch is used and I don't
have any problem if v2 is used. I'm able to modify bootcmd like I wish
and can live with any version.
I've justed wanted to make clear why I haven't used a simpler approach.
Anyway, if v2 will be used, please just remove my name as author, I
don't want to be responsible for the possible arising confusion.
Everyone can still use as much from that patch as he wishes, please just
don't use my name as author for a modified patch with a changed logic. ;)
Regards,
Alexander
Jason Kridner
Changes for v3:
- Removed boot.scr per discussion with Alexander.
Signed-off-by: Jason Kridner <jkri...@beagleboard.org>
---
include/configs/omap3_beagle.h | 28 ++++++++++++++++------------
1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index 8b580ef..c85537c 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -213,9 +213,9 @@
"omapdss.def_disp=${defaultdisplay} " \
"root=${nandroot} " \
"rootfstype=${nandrootfstype}\0" \
- "loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
- "bootscript=echo Running bootscript from mmc ...; " \
- "source ${loadaddr}\0" \
+ "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
+ "importbootenv=echo Importing environment from mmc ...; " \
+ "env import -t $loadaddr $filesize\0" \
"loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
"mmcboot=echo Booting from mmc ...; " \
"run mmcargs; " \
@@ -227,15 +227,19 @@
#define CONFIG_BOOTCOMMAND \
"if mmc rescan ${mmcdev}; then " \
- "if run loadbootscript; then " \
- "run bootscript; " \
- "else " \
- "if run loaduimage; then " \
- "run mmcboot; " \
- "else run nandboot; " \
- "fi; " \
- "fi; " \
- "else run nandboot; fi"
+ "echo SD/MMC found on device ${mmcdev};" \
+ "if run loadbootenv; then " \
+ "run importbootenv;" \
+ "fi;" \
+ "if test -n $uenvcmd; then " \
+ "echo Running uenvcmd ...;" \
+ "run uenvcmd;" \
+ "fi;" \
Alexander Holler
Am 02.03.2011 21:26, schrieb Jason Kridner:
> For backwards compatibility the use of boot.scr is still supported.
>
Sorry, but I think that line in the description should get removed too.
Regards,
Alexander
Robert Nelson
So, just a thought.. Are you guys planning to push this same boot
method to all the other "omap" devices that just finally got boot.scr
boot support by default in u-boot? It also seems's like it'll end up
be the FAQ of the month for the beagleboard group.. ;)
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
Jason Kridner
> On Wed, Mar 2, 2011 at 5:41 PM, Alexander Holler <hol...@ahsoftware.de> wrote:
>> Hello Jason,
>>
>> Am 02.03.2011 21:26, schrieb Jason Kridner:
>>>
>>> For backwards compatibility the use of boot.scr is still supported.
>>>
>>
>> Sorry, but I think that line in the description should get removed too.
I'll submit a v4.
>>
>
> So, just a thought.. Are you guys planning to push this same boot
> method to all the other "omap" devices that just finally got boot.scr
> boot support by default in u-boot? It also seems's like it'll end up
> be the FAQ of the month for the beagleboard group.. ;)
Indeed it is likely to be FAQ of the month, especially if it lands in
the next software update that gets shipped with the board. It is a
case, however, in which I like the answer--no more need to run
mkimage. The conversion process of a boot.scr script (commands) to a
uEnv.txt file (variable setting) won't be exactly trivial, so that has
me a tiny bit concerned. Still, most cases will be solved by a *much*
simpler uEnv.txt script and an overall simpler process.
I still see a need to use the USER button to go into some sort of
fall-back state to ignore this file and boot some sort of recovery
image. Since that code isn't upstream yet, there is still going to be
some delta between upstream and what ships on the board--unless I can
somehow figure out an easy way to get a command added for the generic
gpio framework.
Jason Kridner
Using the new env import command it is possible to use plain text files instead
of script-images. Plain text files are much easier to handle.
E.g. If your boot.scr contains the following:
-----------------------------------
setenv dvimode 1024x768-16@60
run loaduimage
run mmcboot
-----------------------------------
you could create a file named uEnv.txt and use that instead of boot.scr:
-----------------------------------
dvimode=1024x768-16@60
uenvcmd=run loaduimage; run mmcboot
-----------------------------------
The variable uenvcmd (if existent) will be executed (using run) after uEnv.txt
was loaded. If uenvcmd doesn't exist the default boot sequence will be started,
therefore you could just use
-----------------------------------
dvimode=1024x768-16@60
-----------------------------------
as uEnv.txt because loaduimage and mmcboot is part of the default boot sequence.
---
Changes for v2:
- Eliminated else redundant clause that would be ignored if boot
succeeds.
Changes for v3:
- Removed boot.scr
Changes for v4:
- Removed comment about boot.scr being supported.
Signed-off-by: Jason Kridner <jkri...@beagleboard.org>
Cc: Sandeep Paulraj <s-pa...@ti.com>
Alexander Holler
Am 03.03.2011 16:04, schrieb Jason Kridner:
> On Wed, Mar 2, 2011 at 6:48 PM, Robert Nelson<robert...@gmail.com> wrote:
>> On Wed, Mar 2, 2011 at 5:41 PM, Alexander Holler<hol...@ahsoftware.de> wrote:
>>> Hello Jason,
>>>
>>> Am 02.03.2011 21:26, schrieb Jason Kridner:
>>>>
>>>> For backwards compatibility the use of boot.scr is still supported.
>>>>
>>>
>>> Sorry, but I think that line in the description should get removed too.
>
> I'll submit a v4.
>
>>>
>>
>> So, just a thought.. Are you guys planning to push this same boot
>> method to all the other "omap" devices that just finally got boot.scr
>> boot support by default in u-boot? It also seems's like it'll end up
>> be the FAQ of the month for the beagleboard group.. ;)
>
> Indeed it is likely to be FAQ of the month, especially if it lands in
> the next software update that gets shipped with the board. It is a
> case, however, in which I like the answer--no more need to run
> mkimage. The conversion process of a boot.scr script (commands) to a
> uEnv.txt file (variable setting) won't be exactly trivial, so that has
> me a tiny bit concerned. Still, most cases will be solved by a *much*
> simpler uEnv.txt script and an overall simpler process.
Hmm, if someone will write such an FAQ-entry, be sure to mention that
people shouldn't use a windows-editor. I haven't tried it, but I don't
believe env import likes carriage returns.
Regards,
Alexander
Alexander Holler
I would say that should be decided by every board-maintainer, just like
the change from ttyS2 to ttyO2. E.g. I don't think the devkit8000-sdk
will change as soon as the stuff the for the beagleboard.
Regards,
Alexander
Robert Nelson
Oh, we will work around it over the transition, so it's not a big deal..
It was just kinda nice, (if we assume all boards have xlo/u-boot in
nand) that most boards would boot on one boot.scr/kernel/rootfs
combination. Since the mainline kernel can boot on all omap2/3/4
boards (in mainline) at this point..
But since both the xM/Panda don't have nand, my point's kinda moot as
they'll need a different xlo/u-boot...
Alexander Holler
I've just seen a patch which makes env import optional, so you might
consider adding CONFIG_CMD_IMPORTENV to omap3_beagle.h to be prepared
when env import will get optional.
Regards,
Alexander Holler
Alexander Holler
> Hello Jason,
>
> I've just seen a patch which makes env import optional, so you might
> consider adding CONFIG_CMD_IMPORTENV to omap3_beagle.h to be prepared
> when env import will get optional.
Sorry for the noise, the patch which makes it optional enables it by
default, so no action is necessary. Haven't seen that at first.
> Regards,
>
> Alexander Holler
Wolfgang Denk
In message <4D722D1F...@ahsoftware.de> you wrote:
>
> I've just seen a patch which makes env import optional, so you might
> consider adding CONFIG_CMD_IMPORTENV to omap3_beagle.h to be prepared
> when env import will get optional.
I disagree. CONFIG_CMD_IMPORTENV shall be enabled by default.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Reader, suppose you were an idiot. And suppose you were a member of
Congress. But I repeat myself. - Mark Twain
Paulraj, Sandeep
Pushed to u-boot-ti after making changes to the patch header
Paulraj, Sandeep
>
> Dear "Paulraj, Sandeep",
>
> In message <0554BEF07D437848AF01...@dlee01.ent.ti.com>
> I think you might have missed Jason Kridner's Signed-off-by ?
>
> Best regards,
>
> Wolfgang Denk
Thanks,
I have fixed this.
I had to edit the patch headers of quite a few patches and missed this one.
Regards,
Sandeep
Wolfgang Denk
In message <0554BEF07D437848AF01...@dlee01.ent.ti.com> you wrote:
>
I think you might have missed Jason Kridner's Signed-off-by ?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Documentation is like sex: when it is good, it is very, very good;
and when it is bad, it is better than nothing. - Dick Brandon