On Thu, 2011-07-14 at 16:56 -0400, Bruce Ashfield wrote: > On 07/14/11 12:34, Kumar Gala wrote: > > > > On Jul 14, 2011, at 11:24 AM, Bruce Ashfield wrote: > > > >> On 07/14/11 12:21, Koen Kooi wrote: > >>> > >>> Op 14 jul 2011, om 18:20 heeft Kumar Gala het volgende geschreven: > >>> > >>>> > >>>> On Jul 14, 2011, at 8:56 AM, Bruce Ashfield wrote: > >>>> > >>>>> On 07/14/11 09:40, Koen Kooi wrote: > >>>>>> > >>>>>> Op 14 jul 2011, om 15:13 heeft Bruce Ashfield het volgende geschreven: > >>>>>> > >>>>>>> On 07/14/11 09:05, Kumar Gala wrote: > >>>>>>>> Is there a list of which IMAGE_FSTYPES are supported. I didn't see > >>>>>>>> anything in the docs. Looking to see if a u-boot 'mkimage' wrapped > >>>>>>>> set of images is supported or not. > >>>>>>> > >>>>>>> I'm not 100% where the list is, but I can confirm that > >>>>>>> uImages are supported and work nicely. Assuming that > >>>>>>> you are talking about the common use case, and not something > >>>>>>> more exotic :) > >>>>>> > >>>>>> > >>>>>> I think he means partitioned uimages where you have a kernel + initrd > >>>>>> in a single uimage. We don't support that *yet*, but all the needed > >>>>>> blocks are there. And we finally get a usecase for having the > >>>>>> loadadresses in the machine.conf files :) > >>>>> > >>>>> Yah, that's what I wondered as well. I've done this locally, > >>>>> but nothing out of the box .. so I had nagging doubts! > >>>>> > >>>>> Cheers, > >>>>> > >>>>> Bruce > >>>>> > >>>> > >>>> What's the IMAGE_FSTYPE for a normal uImage ? > >>> > >>> None, it's built by the kernel class, not the rootfs class. > >> > >> and to expand a bit, the machine conf would have: > >> > >> KERNEL_IMAGETYPE = "uImage" > >> > >> So the kernel class will build and produce a uImage for deployment. > > > > Ah, so there isnt support for getting a ramdisk wrapped via mkimage. > > Correct, or at least not that I've used out of the box, and > this is what Koen was commenting on.
I think we have all the pieces there but someone would have to connect them up... Cheers, Richard _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto