Hi Otavio, On 10/10/2014 05:23 AM, Otavio Salvador wrote: > On Thu, Oct 9, 2014 at 10:45 PM, Eric Nelson > <[email protected]> wrote: >> Thanks for the feedback Otavio, >> >> On 10/09/2014 06:18 PM, Otavio Salvador wrote: >>> On Thu, Oct 9, 2014 at 9:00 PM, Eric Nelson >>> <[email protected]> wrote: >>>> The 3.10.31 kernel contains a nifty bit of code from Sascha Hauer >>>> that addresses the question of SD card numbering (device naming) >>>> quite well: >>>> >>>> >>>> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/drivers/mmc/card/block.c?h=imx_3.10.31_1.1.0_beta&id=5f9447e5d97060207c4742d5a06e5548de45972d >>>> >>>> https://www.mail-archive.com/[email protected]/msg26472.html >>>> >>>> Unfortunately, it also changes the requirements for the kernel >>>> command-line and breaks our boot scripts. >>> >>> Yes. >>> >>>> This is probably a good time to ask a related question about >>>> where we're keeping boot scripts. >>>> >>>> We have been compiling boot scripts out of our U-Boot tree >>>> from a Yocto-specific "6x_bootscript-yocto.txt" that implements >>>> the conventions of the Freescale Community BSP (kernel in >>>> the root of partition 1 and rootfs in partition 2). >>>> >>>> Since boot scripts have dependencies on a lot of things, it's >>>> not clear to me that they belong in the U-Boot source treet >>>> and that a Yocto-specific boot script really belongs directly >>>> in the Yocto tree somewhere. >>>> >>>> Since a Yocto build knows about the PREFERRED_VERSION of the >>>> kernel, it would be straightforward to have multiple versions >>>> of a boot script. >>>> >>>> Otherwise, we'd need to place a couple of versions in the >>>> U-Boot tree: >>>> 6x_bootscript-yocto.txt >>>> 6x_bootscript-yocto-after-3.10.17.txt >>>> and we'd also need some logic in u-boot-script-boundary.bb >>>> to choose between them. >>>> >>>> Before crafting a patch to do this, I'd like to get some feedback. >>> >>> It is harder than it seems to be. The providing system does not track >>> versions so you'd need to do some "uglyness" to make this work. >>> >> >> I haven't tried, but it seems generally useful to allow >> conditionals based on kernel versions in Yocto/OE and I'm >> surprised that there isn't a stock way of doing this. > > It would be indeed however there are some complexities as package feed > upgrade path and other details which makes this very complex. > > As I said, I think this is technically possible to be done but will > require some 'hacks'. > >>> Personally I think it is easier to address this on the bootscript >>> itself using the setexpr command in U-Boot and with the REGEX config >>> enabled. So you could try to match the kernel version on it somehow. >>> >>> Not sure if we have a command to 'ask' for the kernel version loaded >>> though... >>> >> >> Not currently. >> >> Using a root=PARTUUID=blah would also be nice and might allow the same >> command-line on multiple kernel versions. >> >> Unfortunately, this doesn't seem to work: >> >> https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_3.10.31_1.1.0_beta/init/do_mounts.c#L213 > > The problem with the UUID is because we need to inject it during > rootfs generation and it'd not be in the initial environment, so an > 'env default -f -a' would make the system not bootable. In your case, > as you use the script in a partition it is more doable but it'd not be > an generic solution. >
If the kernel could accept a PARTUUID parameter, the boot script could potentially produce it, but that doesn't seem to be an immediate option. Regards, Eric -- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
