Re: [Ltib] Adding YAFFS2 deployment to LTIB (as well as elf file generation of result)

[Stuart Hughes]

Hi Peter,

Thanks for the patches.  I need to take a closer look (maybe over the 
w/e) but here's some initial comments/questions for you:
---+ bin/Ltibutils.pm

I don't like the idea of using localtime as timestamps when making ELF 
images.  The reason is this will confuse people as it's inconsistent 
with all other timestamps used in LTIB and also without a timezone it 
can't be given an absolute reference.  I'd advise switching to gm_yyyymmdd.
I think prefixing relative paths with $top in parse_config is probably 
okay, but I'm surprised it is needed as ltib is always run from the top 
directory?  Even if it doesn't do any harm, I'm a bit worried that this 
could break other configs if they run from a different directory and 
assume that current working directory.  (I can't remember if anything 
else uses this function).
---+ config/userspace/deployment.lkc

I can see what you're doing with the logic for primary deployment style 
+ elf.  If I understand correctly if your platform has an elf capability 
then you want to build that as well as your primary choice.  If so then 
I think it would be better to re-factor this.  Put it back as was, add 
yaffs2 to the 'root filesystem image type' choice-list and add a new 
independent section below it like this:
if CAP_DEPLOYMENT_ELF && (DEPLOYMENT_JFFS2
       || DEPLOYMENT_YAFFS2
       || DEPLOYMENT_RAMDIS)
config DEPLOYMENT_ELF
       bool "build an combined elf image"
endif

If you agree I can make that change.

Aside from that it looks okay so far.

Regards, Stuart


Peter Barada wrote:
> Stuart,
>
> The attached patch adds YAFFS2 as a deployment method to the current 
> LTIB (actually LTIB as checked out 20091102), as well as patches to 
> yaffs-utils-20060418 to allow for mkfsyaffs2image to be built and take 
> args that allow a device table.
> I've purposely left the original mkyaffsimage code alone (and did not 
> add a YAFFS deployment method) as I don't have a target with small-block 
> NAND to test that functionality with, but it should be failry simple to add.
> The patch to deployment.lkc and bin/Ltibutils.pm also adds in ELF 
> support, as in have LTIB create an ELF file of the resultant 
> u-boot/kernel or u-boot/kernel/ramdisk using a Makefile in 
> config/platform/__platform__/elf-image, and the ELF creation capability 
> is enabled if the platform's main.lkc contains:
> # Can deploy an ELF image.
> config CAP_DEPLOYMENT_ELF
>     bool
>     default y
>
>
> If this capability is not present then the code should act as it does 
> now (with the addition of creation of a YAFFS2 rootfs image).  My target 
> has LoLo as its boot loader, so to boot linux I need to load 
> u-boot/kernel and exec u-boot (which then uses bootm witht he address of 
> where the kernel was loaded as part of the ELF file) so I need the ELF 
> deployment method.  I can provide the Makefile/utilities for my target 
> to link together u-boot/kernel/rootfs into a single ELF file if anyone 
> is interested.
> I've been thinking about the sector/spare/erase size configuration for 
> YAFFS (and the erase size for JFFS2), and I'm starting to convince 
> myself that these variables should be in a platform's main.lkc as 
> constants.  The patch to yaffs-utils doesn't have any sector/page/block 
> size information in it, I'll generate that later and have mkyaffs2image 
> take advantage of it.
> Hopefully people will find this useful.
>
> --
> Peter Barada <address@hidden <mailto:address@hidden>>
> Logic Product Development, Inc.