On Fri, 2009-11-06 at 09:13 +0000, Stuart Hughes wrote:
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.
In my timezone (GMT+5), its quite aggravating to do a build a 6:59pm and
get one date, but then a build at 7:01pm produces tomorrows date. The
date is only used in the ELF image name to stamp it.
The reason for the date is so ELF images I create are anchored by date
which makes it much easier to track when bugs pop up (by bisecting tests
using all images to date(thanks to really cheap disc space!)) as well as
easily have developers/users "keep up" with feature additions.
The only place gm_yyyymmdd() is used is in Ltibrelease.pm::release_main.
The same functionality (i.e. calling gmtime) is replicated in multiple
places (autobuild, listpkginfo, mk_pkg_results).
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).
In my %ldirs I have:
/var/ltmp/pkgs
/opt/freescale/pkgs
my-package-pool
and if I have the yaffs_utils-20060418-mkyaffs2image.patch patch in
my-package-pool, and w/o the change to prefix the relative path, adding
a print of $getcwd() and $path right before the "if (-f $path) {"
statement in get_file(), then I see the following output:
address@hidden:~/work/logic/svn/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102$
./ltib -p yaffs-utils.spec -m prep
Processing: yaffs-utils
=========================
Build path taken because: build key set, no prebuilt rpm,
pwd: /home/peter/work/logic/svn/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102 path: /opt/ltib/pkgs/yaffs_utils-20060418-mkyaffs2image.patch
pwd:
/home/peter/work/logic/svn/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102
path: /var/tmp/pkgs/yaffs_utils-20060418-mkyaffs2image.patch
pwd:
/home/peter/work/logic/svn/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102
path: /opt/freescale/pkgs/yaffs_utils-20060418-mkyaffs2image.patch
pwd:
/home/peter/work/logic/svn/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102
path: my-package-pool/yaffs_utils-20060418-mkyaffs2image.patch
Testing network connectivity
OK GPP:
Try yaffs_utils-20060418-mkyaffs2image.patch.md5 from the GPP
http://bitshrine.org/gpp/yaffs_utils-20060418-mkyaffs2image.patch.md5:
10:23:48 ERROR 404: Not Found.
WARN: skipping md5sum check for
lpd-IP-package-pool/yaffs_utils-20060418-mkyaffs2image.patch, md5 file was not
found
rpmbuild --dbpath
/home/peter/work/logic/svn/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102/rootfs//var/lib/rpm
--target arm --define '_unpackaged_files_terminate_build 0' --define
'_target_cpu arm' --define '__strip strip' --define '_topdir
/home/peter/work/logic/svn/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102/rpm'
--define '_prefix /usr' --define '_tmppath
/home/peter/work/logic/svn/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102/tmp'
--define '_rpmdir
/home/peter/work/logic/svn/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102/rpm/RPMS'
--define '_mandir /usr/share/man' --define '_sysconfdir /etc' --define
'_localstatedir /var' -bp
/home/peter/work/logic/svn/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102/dist/lfs-5.1/yaffs-utils/yaffs-utils.spec
Building target platforms: arm
Building for target arm
error: File
/home/peter/work/logic/svn/eps_svn/software/products/linux/LTIB/trunk/ltib-20091102/rpm/SOURCES/yaffs_utils-20060418-mkyaffs2image.patch:
No such file or directory
Build time for yaffs-utils: 0 seconds
Failed building yaffs-utils
f_prep() returned an error, exiting
traceback:
main:561
Exiting on error or interrupt
so get_file works fine w/o the change. The failure is because
rpm/SOURCES/yaffs_utils-20060418-mkyaffs2image.patch is a symbolic link
to "my-package-pool/yaffs_utils-20060418-mkyaffs2image.patch" using a
relative path, which causes rpm to fail as the symbolic link is valid
IFF the cwd (when accessing that file) is the top-level LTIB directory.
I think rpm changes its working directory to "rpm/BUILD" which would
cause accessing that file to fail....
I'll look at prefixing $top in the symbolic link creation, not in
get_file itself and see what happens in my LTIB usage....
---+ 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.
Yes, on my platform I want to optionally build the ELF file as well as
the rootfs, and in the case of a ramdisk, combine it into the ELF file
(as the other rootfs images would reside on non-volatile storage).
Your refactoring makes perfect sense to me.
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> <mailto:address@hidden>>
> Logic Product Development, Inc.
>
--
Peter Barada <address@hidden <mailto:address@hidden>>
Logic Product Development, Inc.