[meta-freescale] [meta-fsl-arm-extra][PATCH 1/3] u-boot-toradex: add U-Boot recipe for Toradex i.MX 6 based modules

[Stefan Agner]

On 2015-12-03 10:49, Otavio Salvador wrote:
> On Thu, Dec 3, 2015 at 4:43 PM, Stefan Agner <stefan at agner.ch> wrote:
>> On 2015-12-03 10:28, Otavio Salvador wrote:
>>> On Thu, Dec 3, 2015 at 4:24 PM, Stefan Agner <stefan at agner.ch> wrote:
>>>> On 2015-12-03 10:17, Otavio Salvador wrote:
>>>>> I prefer SoC family as it makes easier for end customers to customized
>>>>> it without need to override the compatibility set in a bbappend. As
>>>>> this provides a SoM it is common it ends being used in a custom
>>>>> carrier board and eventually a new machine file in a customer layer
>>>>> can reuse the recipe.
>>>>
>>>> This is a good point, so e.g. if somebody would need to alter the
>>>> machine and would create a machine like apalis-imx6-mycarrier. We
>>>> actually would need another inheritance like SoC, for boards/carrier
>>>> boards...
>>>
>>> Yes but this can be add on the machine itself. The compatibile would
>>> demand a bbappend usually.
>>
>> How can this be added? By using the module name "apalis-imx6" as
>> SOC_FAMILY?
>>
>> In that case, a COMPATIBLE on module level would be good enough (e.g. as
>> it is now, just apalis/colibri-imx6 would be the module level).
> 
> Yes; so it is added to the MACHINEOVERRIDES and ends being used as
> fallback. This is done for Wandboard in the past and I think is still
> used for OLinuxIno boards.
> 

I see.

>> However, so far customization needs on machine level hasn't really come
>> up so far. Customers typically use our default machines, and customize
>> the image by other means...
> 
> Yes but I see no problem in making it easier for end-users, do you?

It would be a big change, since all machines are now called according to
the module name. I guess you can't use the same name of a SOC level and
a machine... Hence we would have to rename all machines... taking care
of Documentation, etc...

I guess we need to discuss this internally and look at things a little
closer to understand the implications. Maybe we can postpone such a
change?

--
Stefan