yaffs_utils-20060418-mkyaffs2image.patchDescription: Text Data
|
| From: | Peter Barada |
| Subject: | Re: [Ltib] Adding YAFFS2 deployment to LTIB (as well as elf file generation of result) |
| Date: | Fri, 06 Nov 2009 14:43:09 -0500 |
Hi Peter, If you can send me a new patch that would help. A flag in .ltibrc to indicate times are local would be fine, the default (no entry at all) should be to GMT (UTC).
Attached.
# If %use_localtime is set, and non-zero, then timestamps are in localtime, not GMT %use_localtime 1
Regards, Stuart
Peter Barada wrote:
> On Fri, 2009-11-06 at 16:07 +0000, Stuart Hughes wrote:
>> Hi Peter,
>>
>> I understand your reluctance to use UTC (GMT), but I still think in the
>> log run that will cause less confusion. If you just want a timestamp,
>> who about using the 'time' seconds since the epoch? Anyhow I can
>> foresee many issues if you use localtime, so although there's no
>> right/wrong wrt it would please me to go with something based on UTC.
> I understand the implications of using localtime, especially if
> development is spread out across timezones. Seconds since epoch would
> certainly work, but is quite cumbersome for users I distribute images to
> that don't understand how to convert back-n-forth from localtime.
>
> In my case the granularity is only to a day, and isolated to the stamp
> on the file so I wouldn't expect much problem with it.
>
> As a compromise, would a patch that adds/uses a flag to .ltibrc to
> specify whether timestamps are in localtime or GMT be acceptable? Then
> the default can be GMT and users can choose which time refernce they
> want to use.....
>
>> For now I'll apply your proposed change to add $top to relative paths,
>> lets see if there is any fallout (regressions) and if so deal with it then.
> As I'm the only one (apparently) who needs this, lemme look at fixing
> the symbolic link creation in rpm/SOURCES instead. I'll get you
> something over the weekend.
>
>> I will re-factor deployment.lkc as discussed (as time permits).
>
> If you want, I can re-factor and resubmit the change....
>
>> Regards, Stuart
>>
>> Peter Barada wrote:
>> > 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> <mailto:address@hidden>>
>> >> > Logic Product Development, Inc.
>> >> >
>> > --
>> > 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.
>
|
-- Peter Barada <address@hidden> Logic Product Development, Inc. |
yaffs_utils-20060418-mkyaffs2image.patch
Description: Text Data
yaffs_utils-20060418-mkyaffs2image.patch.md5
Description: Text document
ltib-add-yaffs2.patch
Description: Text Data
| [Prev in Thread] | Current Thread | [Next in Thread] |