<br><br><div class="gmail_quote">2011/12/28 Anders Darander <span dir="ltr"><<a href="mailto:anders@chargestorm.se" target="_blank">anders@chargestorm.se</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
On 27 dec 2011, at 21:35, "Frans Meulenbroeks" <<a href="mailto:fransmeulenbroeks@gmail.com" target="_blank">fransmeulenbroeks@gmail.com</a>> wrote:<br>
<br>
> This adds building the u-boot tools for target.<br>
> (fw_printenv, fw_setenv).<br>
> They are put into a separate package<br>
> With these files it becomes possible to modify<br>
> the u-boot environment when linux is booted<br>
><br>
> The #ifdef's in fw_env.h were needed to avoid compilation issues<br>
> The constants have been changed to more meaningful defaults<br>
> (as 128k flash pages are much more common than 4k pages)<br>
> but can be overridden using a configuration file.<br>
><br>
> This resolves bug 1800<br>
><br>
> Signed-off-by: Frans Meulenbroeks <<a href="mailto:fransmeulenbroeks@gmail.com" target="_blank">fransmeulenbroeks@gmail.com</a>><br>
><br>
> ---<br>
> Note: development and testing was done under openembedded classic.<br>
> I've tested it there quite heavily (for mpc8313 if that matters).<br>
> I was requested to provide a patch for oe-core too (to resolve bug 1800)<br>
> so here it is, although at the moment I am unable to test the patch for oe-core.<br>
> I suggest that this is carefully reviewed and tested before being merged.<br>
<br>
<br>
</div><div>> create mode 100644 meta/recipes-bsp/u-boot/files/tools_fwenv.patch<br>
><br>
> diff --git a/meta/recipes-bsp/u-boot/files/tools_fwenv.patch b/meta/recipes-bsp/u-boot/files/tools_fwenv.patch<br>
> new file mode 100644<br>
> index 0000000..8e87800<br>
> --- /dev/null<br>
> +++ b/meta/recipes-bsp/u-boot/files/tools_fwenv.patch<br>
> @@ -0,0 +1,48 @@<br>
> +Index: u-boot-2011.03/tools/env/fw_env.h<br>
> +===================================================================<br>
</div>> +--- 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<br>
<div>> +@@ -27,25 +27,35 @@<br>
> + * See included "fw_env.config" sample file (TRAB board)<br>
> + * for notes on configuration.<br>
> + */<br>
> +-#define CONFIG_FILE "/etc/fw_env.config"<br>
> ++//#define CONFIG_FILE "/etc/fw_env.config"<br>
<br>
</div>Why do you remove the default for CONFIG_FILE?<br>
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?<br></blockquote><div><br>Good catch.<br>This was based on work I did for a project a while ago.<br>
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.<br><br>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)<br>
Anyway, for this specific project it was decided to use hardcoded values, and that crept in.<br>I'll see if I can come up with a patch to use the default values if the config file cannot be opened.<br> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><br>
> ++<br>
> ++#include "config.h"<br>
> +<br>
> + #define HAVE_REDUND /* For systems with 2 env sectors */<br>
> +-#define DEVICE1_NAME "/dev/mtd1"<br>
> +-#define DEVICE2_NAME "/dev/mtd2"<br>
> ++#define DEVICE1_NAME "/dev/mtd0"<br>
> ++#define DEVICE2_NAME "/dev/mtd0"<br>
<br>
</div>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...)<br></blockquote>
<div>I can live with either value. This was what was used in our project. <br>Personally I'm somewhat inclined to keep the # of partitions small, so I am less inclined to make two partitions for the env.<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><br>
> + #define DEVICE1_OFFSET 0x0000<br>
> +-#define ENV1_SIZE 0x4000<br>
> +-#define DEVICE1_ESIZE 0x4000<br>
> +-#define DEVICE2_OFFSET 0x0000<br>
> +-#define ENV2_SIZE 0x4000<br>
> +-#define DEVICE2_ESIZE 0x4000<br>
> ++#define ENV1_SIZE 0x2000<br>
> ++#define DEVICE1_ESIZE 0x20000<br>
> ++#define DEVICE1_ENVSECTORS 1<br>
> ++#define DEVICE2_OFFSET 0x20000<br>
> ++#define ENV2_SIZE 0x2000<br>
> ++#define DEVICE2_ESIZE 0x20000<br>
> ++#define DEVICE2_ENVSECTORS 1<br>
<br>
</div>Ok, I can agree with you that 128k pages are more common, thus that could be a sensible default.<br>
<br>
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.<br>
<br></blockquote><div>Again probably a personal preference that crept in. <br>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.<br>
THen again perhaps the code should be modified to make use of whatever config/include says.<br></div></div><br>I'll see if I can come up with an update.<br>But actually the most important part of this patch is to add the code in .inc and .bb to compile the tools.<br>
<br>Best regards, Frans<br><br>PS: it could also be decided to make a separate u-boot-env recipe.<br>PPS: if interested in why fw_prntenv is compiled with HOSTCC: see this thread: <a href="http://old.nabble.com/-U-Boot---PATCH-1-4--tools%3A-enable-img2srec-for-%22all%22-target-td29440508.html#a29440510">http://old.nabble.com/-U-Boot---PATCH-1-4--tools%3A-enable-img2srec-for-%22all%22-target-td29440508.html#a29440510</a><br>
discussion starts somewhere halfway the thread.<br><br>