About customizing the image_types_fsl class

About customizing the image_types_fsl class

[Carlos Rafael Giani]

[-- Attachment #1: Type: text/plain, Size: 1546 bytes --]

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.

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).

Suggestions? Comments?

cheers,
   Carlos

[-- Attachment #2: Type: text/html, Size: 2300 bytes --]

Re: About customizing the image_types_fsl class

[Daiane Angolini]

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

Re: About customizing the image_types_fsl class

[Carlos Rafael Giani]

On 2014-01-20 15:12, Daiane Angolini wrote:
> 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

True. If more boards start using SPL, then it should become part of the 
image_types_fsl class. Also, a flag to disable writing the uImage 
outside of the partitions would also be useful (but not essential).

>
> 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.

This means I should wait until 2014.01 is released and added to oe-core 
before I submit my cubox-i patches for meta-fsl-arm-extra ?

Re: About customizing the image_types_fsl class

[Daiane Angolini]

On 20-01-2014 12:41, Carlos Rafael Giani wrote:
> On 2014-01-20 15:12, Daiane Angolini wrote:
>> 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
>
> True. If more boards start using SPL, then it should become part of the
> image_types_fsl class. Also, a flag to disable writing the uImage
> outside of the partitions would also be useful (but not essential).
>
>>
>> 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.
>
> This means I should wait until 2014.01 is released and added to oe-core
> before I submit my cubox-i patches for meta-fsl-arm-extra ?
>

As I know it's supposed to be released today/tomorrow




-- 
Daiane

Re: About customizing the image_types_fsl class

[Carlos Rafael Giani]

On 2014-01-20 16:00, Daiane Angolini wrote:
>
> As I know it's supposed to be released today/tomorrow
>

Just had a discussion with developers working on Cubox-I support. They 
tried to push MXC SPL support for the CuBox-i upstream, didn't work out 
so far. Otavio suggested to use mainline without SPL for now, but I am 
skeptical about it. SPL is a very nice feature, it allows me to use the 
exact same installation for several Cubox-i machines.

The way I see it, there are two options for me:
1) Use the u-boot fork with MXC SPL support for now, until mainline 
supports MXC SPL. Then immediately switch to mainline by applying a 
patch to meta-fsl-arm-extra.
2) Use mainline without SPL, and live with the fact that I need a build 
for every single CuBox-i machine.

I personally favor (1), especially since it is already fully working for 
me. I could send the patches to the mailing list after a little cleanup. 
You seem to favor (2), since mainline is usually a better choice than 
some odd fork (I agree on this in principle, but in this case, I favor 
the fork).

Re: About customizing the image_types_fsl class

[Fabio Estevam]

On Mon, Jan 20, 2014 at 3:40 PM, Carlos Rafael Giani
<dv@pseudoterminal.org> wrote:
> On 2014-01-20 16:00, Daiane Angolini wrote:
>>
>>
>> As I know it's supposed to be released today/tomorrow
>>
>
> Just had a discussion with developers working on Cubox-I support. They tried
> to push MXC SPL support for the CuBox-i upstream, didn't work out so far.

Have they sent their patch to the U-boot list? If so, care to point me
where these patches are in the list?

I do not recall seeing any patches from them in the U-boot mailing list.

> Otavio suggested to use mainline without SPL for now, but I am skeptical
> about it. SPL is a very nice feature, it allows me to use the exact same
> installation for several Cubox-i machines.
>
> The way I see it, there are two options for me:
> 1) Use the u-boot fork with MXC SPL support for now, until mainline supports
> MXC SPL. Then immediately switch to mainline by applying a patch to
> meta-fsl-arm-extra.
> 2) Use mainline without SPL, and live with the fact that I need a build for
> every single CuBox-i machine.

Or even better:

3) Work on upstreaming mx6 spl support into mainline U-boot

Regards,

Fabio Estevam

Re: About customizing the image_types_fsl class

[Carlos Rafael Giani]

On 2014-01-20 20:48, Fabio Estevam wrote:
> On Mon, Jan 20, 2014 at 3:40 PM, Carlos Rafael Giani
> <dv@pseudoterminal.org> wrote:
>> On 2014-01-20 16:00, Daiane Angolini wrote:
>>>
>>> As I know it's supposed to be released today/tomorrow
>>>
>> Just had a discussion with developers working on Cubox-I support. 
>> They tried
>> to push MXC SPL support for the CuBox-i upstream, didn't work out so 
>> far.
> Have they sent their patch to the U-boot list? If so, care to point me
> where these patches are in the list?
>
> I do not recall seeing any patches from them in the U-boot mailing list.

The patches were made by Jon Nettleton. According to him, this 
discussion happened offline. Hence no mailing list patches.

>
>> Otavio suggested to use mainline without SPL for now, but I am skeptical
>> about it. SPL is a very nice feature, it allows me to use the exact same
>> installation for several Cubox-i machines.
>>
>> The way I see it, there are two options for me:
>> 1) Use the u-boot fork with MXC SPL support for now, until mainline 
>> supports
>> MXC SPL. Then immediately switch to mainline by applying a patch to
>> meta-fsl-arm-extra.
>> 2) Use mainline without SPL, and live with the fact that I need a 
>> build for
>> every single CuBox-i machine.
> Or even better:
>
> 3) Work on upstreaming mx6 spl support into mainline U-boot
>

He tried just that, and ran into a wall. When he has time, he may be 
able to drop in and explain what happened in his own words.
Also, we just discovered that barebox has CuBox-i and HummingBoard 
support already. Its design seems to be much nicer and easier to manage. 
Has barebox ever been considered a u-boot alternative for meta-fsl-arm ?

Re: About customizing the image_types_fsl class

[Fabio Estevam]

On Tue, Jan 21, 2014 at 11:04 AM, Carlos Rafael Giani
<dv@pseudoterminal.org> wrote:

> He tried just that, and ran into a wall. When he has time, he may be able to
> drop in and explain what happened in his own words.
> Also, we just discovered that barebox has CuBox-i and HummingBoard support
> already. Its design seems to be much nicer and easier to manage. Has barebox
> ever been considered a u-boot alternative for meta-fsl-arm ?

There are already barebox users in meta-fsl-arm.

Regards,

Fabio Estevam

Re: About customizing the image_types_fsl class

[Daiane.Angolini]

> -----Original Message-----
> From: Carlos Rafael Giani [mailto:dv@pseudoterminal.org]
> Sent: Tuesday, January 21, 2014 11:05 AM
> To: Fabio Estevam
> Cc: Angolini Daiane-B19406; meta-freescale@yoctoproject.org
> Subject: Re: [meta-freescale] About customizing the image_types_fsl class
> 
> On 2014-01-20 20:48, Fabio Estevam wrote:
> > On Mon, Jan 20, 2014 at 3:40 PM, Carlos Rafael Giani
> > <dv@pseudoterminal.org> wrote:
> >> On 2014-01-20 16:00, Daiane Angolini wrote:
> >>>
> >>> As I know it's supposed to be released today/tomorrow
> >>>
> >> Just had a discussion with developers working on Cubox-I support.
> >> They tried
> >> to push MXC SPL support for the CuBox-i upstream, didn't work out so
> >> far.
> > Have they sent their patch to the U-boot list? If so, care to point me
> > where these patches are in the list?
> >
> > I do not recall seeing any patches from them in the U-boot mailing list.
> 
> The patches were made by Jon Nettleton. According to him, this discussion
> happened offline. Hence no mailing list patches.
> 
> >
> >> Otavio suggested to use mainline without SPL for now, but I am
> >> skeptical about it. SPL is a very nice feature, it allows me to use
> >> the exact same installation for several Cubox-i machines.
> >>
> >> The way I see it, there are two options for me:
> >> 1) Use the u-boot fork with MXC SPL support for now, until mainline
> >> supports MXC SPL. Then immediately switch to mainline by applying a
> >> patch to meta-fsl-arm-extra.
> >> 2) Use mainline without SPL, and live with the fact that I need a
> >> build for every single CuBox-i machine.
> > Or even better:
> >
> > 3) Work on upstreaming mx6 spl support into mainline U-boot
> >
> 
> He tried just that, and ran into a wall. When he has time, he may be able
> to drop in and explain what happened in his own words.
> Also, we just discovered that barebox has CuBox-i and HummingBoard support
> already. Its design seems to be much nicer and easier to manage.
> Has barebox ever been considered a u-boot alternative for meta-fsl-arm ?

http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-bsp/barebox


Daiane 

Re: About customizing the image_types_fsl class

[John Weber]

On 1/20/14 11:40 AM, Carlos Rafael Giani wrote:
> On 2014-01-20 16:00, Daiane Angolini wrote:
>>
>> As I know it's supposed to be released today/tomorrow
>>
>
> Just had a discussion with developers working on Cubox-I support. They tried 
> to push MXC SPL support for the CuBox-i upstream, didn't work out so far. 
> Otavio suggested to use mainline without SPL for now, but I am skeptical about 
> it. SPL is a very nice feature, it allows me to use the exact same 
> installation for several Cubox-i machines.
>
> The way I see it, there are two options for me:
> 1) Use the u-boot fork with MXC SPL support for now, until mainline supports 
> MXC SPL. Then immediately switch to mainline by applying a patch to 
> meta-fsl-arm-extra.
> 2) Use mainline without SPL, and live with the fact that I need a build for 
> every single CuBox-i machine.
>
> I personally favor (1), especially since it is already fully working for me. I 
> could send the patches to the mailing list after a little cleanup. You seem to 
> favor (2), since mainline is usually a better choice than some odd fork (I 
> agree on this in principle, but in this case, I favor the fork).
>
Other boards are making use of this.  The guys at Wandboard worked on it so that 
they could release a single image for all variants.

Why not add it to the default sdcard creation script and then make it 
enabled/disabled either at the machine level or cause it to be automatically 
selected by the SPL recipe?

Re: About customizing the image_types_fsl class

[Otavio Salvador]

On Mon, Jan 20, 2014 at 5:54 PM, John Weber <rjohnweber@gmail.com> wrote:
>
> On 1/20/14 11:40 AM, Carlos Rafael Giani wrote:
>>
>> On 2014-01-20 16:00, Daiane Angolini wrote:
>>>
>>>
>>> As I know it's supposed to be released today/tomorrow
>>>
>>
>> Just had a discussion with developers working on Cubox-I support. They
>> tried to push MXC SPL support for the CuBox-i upstream, didn't work out so
>> far. Otavio suggested to use mainline without SPL for now, but I am
>> skeptical about it. SPL is a very nice feature, it allows me to use the
>> exact same installation for several Cubox-i machines.
>>
>> The way I see it, there are two options for me:
>> 1) Use the u-boot fork with MXC SPL support for now, until mainline
>> supports MXC SPL. Then immediately switch to mainline by applying a patch to
>> meta-fsl-arm-extra.
>> 2) Use mainline without SPL, and live with the fact that I need a build
>> for every single CuBox-i machine.
>>
>> I personally favor (1), especially since it is already fully working for
>> me. I could send the patches to the mailing list after a little cleanup. You
>> seem to favor (2), since mainline is usually a better choice than some odd
>> fork (I agree on this in principle, but in this case, I favor the fork).
>>
> Other boards are making use of this.  The guys at Wandboard worked on it so
> that they could release a single image for all variants.
>
> Why not add it to the default sdcard creation script and then make it
> enabled/disabled either at the machine level or cause it to be automatically
> selected by the SPL recipe?

We can do it as soon U-Boot mailing list is consulted and we decide
how the final layout will be. Will it be two binaries or a single one?

We shouldn't add something here and just drop later; We need to bear
on mind we will have people depending on it.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750