Re: Going beyond MACHINE?

[Mike Looijmans <mike.looijmans@topic.nl>]

On 10/20/2014 03:36 PM, Otavio Salvador wrote:
> On Mon, Oct 20, 2014 at 10:40 AM, Mike Looijmans
> <mike.looijmans@topic.nl> wrote:
>> On 10/20/2014 02:04 PM, Richard Purdie wrote:
>>>
>>> On Mon, 2014-10-20 at 13:55 +0200, Mike Looijmans wrote:
>>>>
>>>> The short version of my question: Can I define a "level" that goes
>>>> beyond MACHINE?
>>>>
>>>> My problem in detail (and I suspect there are more systems with similar
>>>> problems):
>>>>
>>>> I have an SOC called "topic-miami". There are currently two variants: The
>>>> 7015
>>>> and 7030. They are identical but for one component: They have a different
>>>> FPGA
>>>> part (the 7030 is bigger and faster).
>>>> Both run exactly the same kernel and bootloader, and all other software
>>>> and
>>>> libraries are exactly the same.
>>>>
>>>> Currently I have MACHINE="topic-miami-7015" and then
>>>> SOC_FAMILY="topic-miami"
>>>> so I can use "topic-miami" as override word for all packages.
>>>>
>>>> However, this means I get two kernels, two bootloaders, etc. even though
>>>> they
>>>> are exactly the same.
>>>>
>>>> The only package that currently differs is the one that delivers the
>>>> bitstream(s) for the FPGA. These are big, too big to fit bitstreams for
>>>> both
>>>> models into flash and leave room for applications, so just installing
>>>> both
>>>> into the rootfs and pick the correct one at boot time is not really an
>>>> option.
>>>>
>>>> Maybe I could define some extra PACKAGE_ARCH for the bitstreams (which
>>>> make
>>>> sense, as this is sort of firmware for a different platform). But how
>>>> would a
>>>> user then pick the right value for this variable, since MACHINE seems to
>>>> be
>>>> the only thing he can really choose?
>>>>
>>>> Any thoughts and ideas are welcome...
>>>
>>>
>>> One possible solution would be to inject another PACKAGE_ARCH (as the
>>> intel gmgd graphics does for example), then mark the MACHINE specific
>>> packages as being that package architecture. They'd then only get built
>>> once per package architecture yet your bitstreams would still be machine
>>> specific. You could probably do the "remarking" using anonymous python
>>> injected at the machine level.
>>
>>
>> Sounds doable, but I can't find anything about "intel gmgd" in any layer.
>> Which machine are you referring to here?
>
> We did something similar in meta-fsl-arm, check:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/classes/fsl-dynamic-packagearch.bbclass
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/conf/machine/include/imx-base.inc#n41
>
> This should be easy to adapt for your specific case.

I experimented with both suggestions. The fsl method works well to prevent 
multiple kernels being built for the same machine, but I have to "whitelist" 
packages that I want to change. Since there's only one type of package that 
depends on the last four digits of the machine name, I'm thinking about going 
in a different direction.

I set MACHINE to a pattern like "<SOM>-<CARRIER>-<FPGA>"

Then I split this into MACHINE_ARCH="<SOM>_<CARRIER>", SOM_FAMILY="<SOM>" and 
introduce FPGA_FAMILY="<FPGA>" in the machine.conf file.

Thus, for a topic-miami SOM featuring a 7015 on a florida carrier board, this 
would result in:

MACHINE = "topic-miami-florida-7015"

MACHINE_BOARD = "${@'-'.join(d.getVar('MACHINE', True).split('-')[:-1])}"
MACHINE_ARCH = "${@'_'.join(d.getVar('MACHINE', True).split('-')[:-1])}"
SOM_FAMILY = "${@'-'.join(d.getVar('MACHINE', True).split('-')[:-2])}"
FPGA_FAMILY = "${@d.getVar('MACHINE', True).split('-')[-1:]}"

Then add these to the MACHINEOVERRIDES and EXTRA_ARCHS:

MACHINEOVERRIDES .= "${SOM_FAMILY}:${MACHINE_BOARD}:{FPGA_FAMILY}:"

PACKAGE_EXTRA_ARCHS_append = " ${FPGA_FAMILY}"

That should build machine specific packages by default at the "board" level, 
while the FPGA recipes would specify PACKAGE_ARCH="${FPGA_FAMILY}" and hence 
get selected based on FPGA type only.

What do you think, should this work (in particular, setting MACHINE_ARCH might 
have unforeseen consequences), or will this leave no survivors?


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijmans@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/