On 10/20/2014 03:36 PM, Otavio Salvador wrote:
On Mon, Oct 20, 2014 at 10:40 AM, Mike Looijmans
<[email protected]> 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: [email protected]
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/
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
