[OE-core] [PATCH 2/2] u-boot: added generating the env utils (fixes bug 1800)

Frans Meulenbroeks fransmeulenbroeks at gmail.com
Wed Dec 28 13:36:26 UTC 2011


2011/12/28 Anders Darander <anders at chargestorm.se>

>
> On 27 dec 2011, at 21:35, "Frans Meulenbroeks" <
> fransmeulenbroeks at gmail.com> wrote:
>
> > This adds building the u-boot tools for target.
> > (fw_printenv, fw_setenv).
> > They are put into a separate package
> > With these files it becomes possible to modify
> > the u-boot environment when linux is booted
> >
> > The #ifdef's in fw_env.h were needed to avoid compilation issues
> > The constants have been changed to more meaningful defaults
> > (as 128k flash pages are much more common than 4k pages)
> > but can be overridden using a configuration file.
> >
> > This resolves bug 1800
> >
> > Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks at gmail.com>
> >
> > ---
> > Note: development and testing was done under openembedded classic.
> > I've tested it there quite heavily (for mpc8313 if that matters).
> > I was requested to provide a patch for oe-core too (to resolve bug 1800)
> > so here it is, although at the moment I am unable to test the patch for
> oe-core.
> > I suggest that this is carefully reviewed and tested before being merged.
>
>
> > create mode 100644 meta/recipes-bsp/u-boot/files/tools_fwenv.patch
> >
> > diff --git a/meta/recipes-bsp/u-boot/files/tools_fwenv.patch
> b/meta/recipes-bsp/u-boot/files/tools_fwenv.patch
> > new file mode 100644
> > index 0000000..8e87800
> > --- /dev/null
> > +++ b/meta/recipes-bsp/u-boot/files/tools_fwenv.patch
> > @@ -0,0 +1,48 @@
> > +Index: u-boot-2011.03/tools/env/fw_env.h
> > +===================================================================
> > +--- u-boot-2011.03.orig/tools/env/fw_env.h    2011-03-31
> 23:45:36.000000000 +0200++++ u-boot-2011.03/tools/env/fw_env.h
>  2011-12-02 13:55:24.667278362 +0100
> > +@@ -27,25 +27,35 @@
> > +  * See included "fw_env.config" sample file (TRAB board)
> > +  * for notes on configuration.
> > +  */
> > +-#define CONFIG_FILE     "/etc/fw_env.config"
> > ++//#define CONFIG_FILE     "/etc/fw_env.config"
>
> Why do you remove the default for CONFIG_FILE?
> I haven't the u-boot code here, but isn't there a check for the
> configuration file in the code? Thus, you would still get compiled in
> defaults if no config file is found?
>

Good catch.
This was based on work I did for a project a while ago.
Didn't have time to submit a patch then and decided the Xmas holiday was a
good point in time to upstream this, but apparently I overlooked this local
change.

I peeked into the code (tools/env/fw_env.c). If config file is used it does
uses the values in it, otherwise it fails. It does not use the built-in
values in that case (which imho would be preferable)
Anyway, for this specific project it was decided to use hardcoded values,
and that crept in.
I'll see if I can come up with a patch to use the default values if the
config file cannot be opened.


>
> > ++
> > ++#include "config.h"
> > +
> > + #define HAVE_REDUND /* For systems with 2 env sectors */
> > +-#define DEVICE1_NAME      "/dev/mtd1"
> > +-#define DEVICE2_NAME      "/dev/mtd2"
> > ++#define DEVICE1_NAME      "/dev/mtd0"
> > ++#define DEVICE2_NAME      "/dev/mtd0"
>
> Would this really be a more comman case than he original defines?
> (Personally, I'm usually using the config file, so this doesn't really
> matter. But I'd still question changing these to mtd0...)
>
I can live with either value. This was what was used in our project.
Personally I'm somewhat inclined to keep the # of partitions small, so I am
less inclined to make two partitions for the env.

>
> > + #define DEVICE1_OFFSET    0x0000
> > +-#define ENV1_SIZE         0x4000
> > +-#define DEVICE1_ESIZE     0x4000
> > +-#define DEVICE2_OFFSET    0x0000
> > +-#define ENV2_SIZE         0x4000
> > +-#define DEVICE2_ESIZE     0x4000
> > ++#define ENV1_SIZE         0x2000
> > ++#define DEVICE1_ESIZE     0x20000
> > ++#define DEVICE1_ENVSECTORS     1
> > ++#define DEVICE2_OFFSET    0x20000
> > ++#define ENV2_SIZE         0x2000
> > ++#define DEVICE2_ESIZE     0x20000
> > ++#define DEVICE2_ENVSECTORS     1
>
> Ok, I can agree with you that 128k pages are more common, thus that could
> be a sensible default.
>
> I can also see a few reasons for changing the size of the environments,
> ENV1_SIZE and ENV2_SIZE, but there is no reason given in the commit log.
>
> Again probably a personal preference that crept in.
I did a quick grep: in u-boot/include/configs 146 boards have a size of
0x2000, and 78 have a size of 0x4000, so it seems 0x2000 is more used.
THen again perhaps the code should be modified to make use of whatever
config/include says.

I'll see if I can come up with an update.
But actually the most important part of this patch is to add the code in
.inc and .bb to compile the tools.

Best regards, Frans

PS: it could also be decided to make a separate u-boot-env recipe.
PPS: if interested in why fw_prntenv is compiled with HOSTCC: see this
thread:
http://old.nabble.com/-U-Boot---PATCH-1-4--tools%3A-enable-img2srec-for-%22all%22-target-td29440508.html#a29440510
discussion starts somewhere halfway the thread.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20111228/f84da12f/attachment-0002.html>


More information about the Openembedded-core mailing list