**** BEGIN LOGGING AT Fri Dec 16 02:59:56 2011
Dec 16 09:07:34 <bluelightning> morning all
Dec 16 11:58:23 <s0undt3ch> hello ppl
Dec 16 11:58:58 <s0undt3ch> how I can I tell my yocto build system that my machine target is a S3C2416 with a ARM926EJ-S?
Dec 16 11:59:36 <s0undt3ch> specifying arm926ejs as the machine tells me that it's an invalid machine
Dec 16 16:05:28 <otavio> dvhart: around?
Dec 16 16:05:39 <dvhart> hey otavio
Dec 16 16:05:47 <otavio> dvhart: I'd like to talk to you about generalizing bootimg to support uboot devices too
Dec 16 16:05:58 <dvhart> ok
Dec 16 16:06:13 <otavio> dvhart: have time now?
Dec 16 16:06:36 <dvhart> otavio, sure we can start here, but lets finish with you sending a proposal summary to the list?
Dec 16 16:06:39 <otavio> dvhart: in fact i am involved in meta-ti and meta-fsl since i have projects with both
Dec 16 16:06:42 <dvhart> make sure it all gets captured
Dec 16 16:06:45 <dvhart> and others can comment
Dec 16 16:08:07 <otavio> dvhart: https://github.com/OSSystems/meta-ti/blob/master/classes/sdcard_image.bbclass
Dec 16 16:08:26 <otavio> dvhart: this is the class i rewrote to avoid using loopback devices
Dec 16 16:08:50 <dvhart> reading
Dec 16 16:10:28 <dvhart> so it looks like half of this (all the image population) can be moved to a uboot.bbclass or similar in meta/classes along the lines of syslinux.bbclass and grub-efi.bbclass
Dec 16 16:10:40 <dvhart> the partitioning bit I'm not sure about
Dec 16 16:10:58 <dvhart> we are discussing moving the bootimg over to a unified iso image that works on usb keys and CDs
Dec 16 16:11:13 <dvhart> and supports more x86 bios
Dec 16 16:11:18 <otavio> ishybrid?
Dec 16 16:11:18 <dvhart> bioses
Dec 16 16:11:33 <dvhart> perhaps, I forget... there is a bug... looking
Dec 16 16:11:54 <dvhart> http://bugzilla.yoctoproject.org/show_bug.cgi?id=1763
Dec 16 16:14:40 <dvhart> so that method would also introduce a partition table
Dec 16 16:14:54 <otavio> dvhart: seems to be using isohybrid that has been integrated onto syslinux by hpa
Dec 16 16:17:01 <dvhart> so the one difference with your sdcard image really is the second partition
Dec 16 16:17:19 <dvhart> we have 3 options:
Dec 16 16:17:38 <dvhart> 1) have you use /dev/ram0 from an initramfs like we do now
Dec 16 16:18:14 <dvhart> 2) abstract the partitioning as I did the populate and install steps
Dec 16 16:18:25 <dvhart> 3) Continue to use separate images
Dec 16 16:19:17 <otavio>  I prefer 2
Dec 16 16:19:47 <dvhart> OK, my concern there is if in the end things are just a lot more complex
Dec 16 16:19:55 <otavio> both imx53 and beagle are mostly compatible with this layout
Dec 16 16:20:22 <dvhart> hrm
Dec 16 16:20:33 <dvhart> actually wait
Dec 16 16:20:49 <dvhart> we have the make_hddimg and mak_isoimg, you just need a make_somethingelseimg
Dec 16 16:21:00 * dvhart takes another look at bootimg.bbclass
Dec 16 16:21:58 <dvhart> otavio, actually, I'm not seeing the advantage here
Dec 16 16:22:21 <dvhart> you would have to add the same code to buildimg that you would to a separate recipe
Dec 16 16:22:40 <dvhart> and the "plugins" to buildimg (syslinux and grub_efi) wouldn't be relevant to you at all
Dec 16 16:22:49 <dvhart> you're really trying to build a different kind of image
Dec 16 16:22:53 <dvhart> bootimg builds live images
Dec 16 16:23:25 <dvhart> you're looking to do directdisk images (which were dropped from oe-core several months ago b/c the implementation was buggy)
Dec 16 16:24:24 <dvhart> have a look at bootimg.bbclass
Dec 16 16:24:40 <dvhart> we would basically add a build_sdcardimg (new name though)
Dec 16 16:24:41 <otavio> dvhart: in this case we could bring directdisk back and work from it?
Dec 16 16:24:58 <dvhart> possibly
Dec 16 16:25:19 <dvhart> the required arguments to sdcardimg would be different than those to iso and hddimg
Dec 16 16:25:43 <dvhart> ie, you need the ext3 image rather than the ROOTFS image
Dec 16 16:26:22 <dvhart> hrm, although if you specified the ext3 image as the ROOTFS... perhaps it would work.... hrm
Dec 16 16:26:56 <dvhart> you would need some additional switches to do_bootimg() to have it build only the image you want
Dec 16 16:28:30 <dvhart> otavio, I'm not sure now, I can see advantages to integration and to keeping it apart.... pondering
Dec 16 16:29:55 <dvhart> otavio, I think in the end, it would make sense to keep it separate, and possibly rename bootimg to liveimg
Dec 16 16:30:13 <otavio> dvhart: right
Dec 16 16:30:16 <dvhart> then we could have liveimg.bbclass and hddimg.bbclass or something like that
Dec 16 16:30:35 <otavio> dvhart: that would be nice
Dec 16 16:31:29 <dvhart> I guess the motivation to not use the /dev/ram0 approach is lack of memory on some uboot targets?
Dec 16 16:32:05 <otavio> sure
Dec 16 16:32:10 <otavio> and speed
Dec 16 16:33:54 <dvhart> ok, well it would be nice to have an image builder for the beagleboard - I do that with an external script now
Dec 16 16:35:05 <otavio> Ok
Dec 16 16:35:21 <otavio> this class can be the base of what we have now as sdcard_image
Dec 16 16:35:32 <otavio> our should we bring directdisk back?
Dec 16 16:36:31 <dvhart> otavio, have a look at directdisk and see what you think, but I'm guessing sdcard_image is probably the route to take
Dec 16 16:37:15 <dvhart> directdisk images had some issues with the way they used dd and stomped over parts of the image - that was the bad part, there may or may not be some genuinely great parts in there as well , I just don't recall
Dec 16 16:42:50 <otavio> dvhart: in fact it does most of stuff
Dec 16 16:43:02 <otavio> dvhart: but needs to be generic
Dec 16 16:45:18 <otavio>  dvhart the point is that I don't want to have sdcard_image duplicated on meta-fsl
Dec 16 16:45:26 <otavio> dvhart: and it does need the same thing
Dec 16 16:51:28 <otavio> dvhart: many code can be shared
Dec 16 16:51:32 <otavio> dvhart: for example
Dec 16 16:51:55 <otavio> dvhart: the pcibios and efi code ought to be in  a common class
Dec 16 16:58:42 <dvhart> otavio, how do you mean?
Dec 16 16:59:19 <otavio> like a boot-method-choose.bbclass
Dec 16 16:59:30 <otavio> so it checks for efi, pcbios and uboot
Dec 16 17:00:05 <dvhart> it's complicated by the fact that you can also use more than one at a time
Dec 16 17:00:14 <dvhart> I currently build EFI + PCBIOS images
Dec 16 17:00:14 <otavio> right
Dec 16 17:00:27 <otavio> but it could export the vars as you do
Dec 16 17:00:31 <dvhart> I also want the option to have multiple providers of each
Dec 16 17:00:58 <dvhart> I guess I like the abstraction of having each implementation in its own bbclass
Dec 16 17:01:09 <otavio> no no
Dec 16 17:01:11 <otavio> right
Dec 16 17:01:13 <dvhart> as I will also be adding syslinux-efi.bbclass when it becomes available
Dec 16 17:01:19 <otavio> i mean the initial part of bootimg
Dec 16 17:02:10 <otavio> http://paste.debian.net/149415/
Dec 16 17:03:42 <dvhart> alright, but only if the results are really usable outside of bootimg.bbclass
Dec 16 17:03:55 <dvhart> right now the interface to those selected classes are rather specific to bootimg
Dec 16 17:04:08 <otavio> they ought to be used on boot-directdisk
Dec 16 17:06:13 <dvhart> right, I think they would work there as is actually
Dec 16 17:06:33 <otavio> yes
Dec 16 17:06:42 <otavio> so ...
Dec 16 17:06:54 <otavio> are you able to help me and doing it?
Dec 16 17:07:04 <otavio> I will be starting an uboot.bbclass for now
Dec 16 17:07:43 <dvhart> I suggest you include a patch that abstracts out the selection into a separate class as part of your series to add the new image type
Dec 16 17:07:56 <dvhart> I'll be happy to review, test, etc.
Dec 16 17:08:11 <dvhart> I only have a few days left before I'm out for vacation this year
Dec 16 17:08:29 <dvhart> and I have a lot I need to complete that is already pretty behind
Dec 16 17:09:09 <dvhart> I'll be looking at bootimg again in January, and can help with refactoring then if you'd still like help with it.
Dec 16 17:10:28 <otavio> yes
Dec 16 17:11:02 <otavio> I will start working on that and then I ask things from time to time to you
Dec 16 17:11:30 <dvhart> great
Dec 16 17:57:34 <kavacha> please forgive my ignorance,  I would like to build for an Arm cortex-A9 chip and was wondering if the armv5 toolchain that is installed as part of adt_installer is generic enough for this task
Dec 16 18:04:24 <zenlinux> in a _git recipe, do I need to update PR when I change SRCREV?
Dec 16 19:31:13 <sgw> zeddii: Hi There, any ideas why we might be keeping udev-145 around? Does this still need to exist?
Dec 16 19:36:01 <zeddii> sgw. no reason that I know of now. there are bindings between kernel versions and udevs (sort of compatibilty points), but we don't have anything that I know of that would require that particular version.
Dec 16 19:38:18 <sgw> Ok, I will send an email to see if any layers require it.
Dec 16 19:38:23 <sgw> zeddii: thanks
Dec 16 19:57:53 <otavio> rcw: it seems opkg has broken something ..
Dec 16 19:58:00 <otavio> |  * pkg_get_installed_files: Error extracting file list from /tmp/opkg-pXoWGk/ccid_1.4.4-r0_i586.ipk.
Dec 16 19:58:04 <otavio> rcw: sorry
Dec 16 19:58:11 <otavio> RP__: ^
Dec 16 20:16:48 <otavio> RP__: indeed it broke the install of some binaries
Dec 16 21:13:13 <otavio> RP__: I'm rebuilding without the opkg patch to see if it is the cause
Dec 16 22:13:11 <otavio> RP__: yes; last opkg change has broken my rootfs generation. Some ipk fails to extract the files
Dec 16 22:13:27 <otavio> bluelightning: when you have qt 4.8 for test, send me
Dec 16 22:13:38 <bluelightning> otavio: one sec
Dec 16 22:14:05 <bluelightning> otavio: http://cgit.openembedded.org/openembedded-core-contrib/log/?h=paule/qt-4.8.0-test
Dec 16 22:14:23 <bluelightning> there's still a problem with shared library linking which I haven't figured out yet
Dec 16 22:14:54 <bluelightning> (the libraries are linking to the non-versioned .so symlinks)
**** ENDING LOGGING AT Sat Dec 17 02:59:57 2011