All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Looijmans <mike.looijmans@topic.nl>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: Going beyond MACHINE?
Date: Mon, 20 Oct 2014 14:40:22 +0200	[thread overview]
Message-ID: <544502B6.5040808@topic.nl> (raw)
In-Reply-To: <1413806657.17752.154.camel@ted>

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?




Met vriendelijke groet / kind regards,

Mike Looijmans

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/



  reply	other threads:[~2014-10-20 12:40 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 [this message]
2014-10-20 13:36     ` Otavio Salvador
2014-11-04 15:05       ` Mike Looijmans
2014-10-20 15:23     ` Richard Purdie

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=544502B6.5040808@topic.nl \
    --to=mike.looijmans@topic.nl \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.