Re: About customizing the image_types_fsl class

[Daiane Angolini <daiane.angolini@freescale.com>]

On 20-01-2014 08:12, Carlos Rafael Giani wrote:
> Hello,
>
> I am working on revised hummingboard and cubox-i patches.
>
> One issue that has come up is its u-boot support.
> There is a new forked u-boot version for these machines, with SPL
> support. The way it is supposed to be built differs from the regular
> u-boot.imx generation.
> Building produces two files, u-boot.img and SPL. The SPL has to be
> flashed first, the u-boot.img right after.
>
> The details are here:
> http://imx.solid-run.com/wiki/index.php?title=Building_the_kernel_and_u-boot_for_the_CuBox-i_and_the_HummingBoard
>
> Excerpt:
>     Flashing SPL -  sudo dd if=SPL of=/dev/sdX bs=512 seek=2
>     Flashing u-boot.img as raw to the micro SD -  sudo dd if=u-boot.img
> of=/dev/sdX bs=1K seek=42
>
>
> I have been thinking about how to adapt this for meta-fsl-arm-extra. I
> essentially have to derive my own class from image_types_fsl and provide
> a new SDcard generation function. And to do that, I would have to copy &
> paste large parts of the existing mx6 sdcard generation command. This is
> not exactly clean.

I think the question here is how "standard" will SPL be for imx. How 
many boards has already SPL support *now*?

I think it's something we need to start including, because it's the next 
standard, however, we must make both working in parallel (spl and non-spl).

And, I would say, it's better to include the additional source code for 
SPL support directly to image_types_fsl instead of derivative it only on 
meta-fsl-arm-extra

>
> One other detail, which is less important but still present, is that
> these machines do _not_ expect the uImage to be outside of the
> partitions. They just load the uImage from the first partition by default.
>
> I know mainline u-boot got hummingboard and cubox-i support, but first I
> want to use something that has been tested by the machine vendors.
> (Plus, I am not sure how stable the current git mainline of u-boot is,
> and OE still uses 2013.10).

Overall I choose u-boot mainline always. It is our default bootloader, 
at least in general lines.

The u-boot mainline hummingboard stability can be known with simple 
test. And any additional support may be included. It's only a matter of 
planing.

2014.01 is about to be released, and u-boot-fslc is about to be update 
to that version. And we may thing about backport any accepted patch to 
2014.01 if it's planned only to 2014.04.

Conclusion: I think the best is u-boot mainline, even if it need some 
rework, it's the best long-term option, in my point of view.


>
> Suggestions? Comments?

Let's wait for more suggestions.


>
> cheers,
>    Carlos
>
>
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>

Regards,
-- 
Daiane