From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Mike Looijmans <mike.looijmans@topic.nl>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: Going beyond MACHINE?
Date: Mon, 20 Oct 2014 16:23:55 +0100 [thread overview]
Message-ID: <1413818635.17752.159.camel@ted> (raw)
In-Reply-To: <544502B6.5040808@topic.nl>
On Mon, 2014-10-20 at 14:40 +0200, Mike Looijmans 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?
Sorry, emgd:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/classes/emgd-gl.bbclass?h=daisy
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/conf/machine/include/meta-intel-emgd.inc?h=daisy
I have actually sent Scott some text for the manual about this but its
not been edited yet.
Cheers,
Richard
prev parent reply other threads:[~2014-10-20 15:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-20 11:55 Going beyond MACHINE? Mike Looijmans
2014-10-20 12:04 ` Richard Purdie
2014-10-20 12:40 ` Mike Looijmans
2014-10-20 13:36 ` Otavio Salvador
2014-11-04 15:05 ` Mike Looijmans
2014-10-20 15:23 ` Richard Purdie [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1413818635.17752.159.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=mike.looijmans@topic.nl \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox