On 28 dec 2011, at 14:36, "Frans Meulenbroeks" <fransmeulenbro...@gmail.com<mailto:fransmeulenbro...@gmail.com>> wrote:
2011/12/28 Anders Darander <and...@chargestorm.se<mailto:and...@chargestorm.se>> On 27 dec 2011, at 21:35, "Frans Meulenbroeks" <fransmeulenbro...@gmail.com<mailto:fransmeulenbro...@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 > <fransmeulenbro...@gmail.com<mailto:fransmeulenbro...@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. > ++ > ++#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. I'm personally fine with either, as I'm often using config-files, or otherwise there's likely more customization anyway. Though, I'd probably argue that if we are to change the defaults in this case compared to upstream, it should be due to a either that most/a lage number of boards are using that scheme, or that the new seem is at least used by reference boards for OE-Core and yocto (although, I don't know which reference boards uses nandflash, and how they are configured). > + #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. If the numbers quoted above are the same/similar if you only look at boards with 128k pages, then we should keep your patch. 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. Yes, I agree that that's the most important part of the patch. And a welcomed patch. (I've a local patch doing something similar, that I've never got around to submit). Cheers, Anders 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.
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
