* Going beyond MACHINE? @ 2014-10-20 11:55 Mike Looijmans 2014-10-20 12:04 ` Richard Purdie 0 siblings, 1 reply; 6+ messages in thread From: Mike Looijmans @ 2014-10-20 11:55 UTC (permalink / raw) To: openembedded-core 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... 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Going beyond MACHINE? 2014-10-20 11:55 Going beyond MACHINE? Mike Looijmans @ 2014-10-20 12:04 ` Richard Purdie 2014-10-20 12:40 ` Mike Looijmans 0 siblings, 1 reply; 6+ messages in thread From: Richard Purdie @ 2014-10-20 12:04 UTC (permalink / raw) To: Mike Looijmans; +Cc: openembedded-core 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. Cheers, Richard ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Going beyond MACHINE? 2014-10-20 12:04 ` Richard Purdie @ 2014-10-20 12:40 ` Mike Looijmans 2014-10-20 13:36 ` Otavio Salvador 2014-10-20 15:23 ` Richard Purdie 0 siblings, 2 replies; 6+ messages in thread From: Mike Looijmans @ 2014-10-20 12:40 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-core 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Going beyond MACHINE? 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 1 sibling, 1 reply; 6+ messages in thread From: Otavio Salvador @ 2014-10-20 13:36 UTC (permalink / raw) To: Mike Looijmans; +Cc: Patches and discussions about the oe-core layer 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. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Going beyond MACHINE? 2014-10-20 13:36 ` Otavio Salvador @ 2014-11-04 15:05 ` Mike Looijmans 0 siblings, 0 replies; 6+ messages in thread From: Mike Looijmans @ 2014-11-04 15:05 UTC (permalink / raw) To: Otavio Salvador; +Cc: Patches and discussions about the oe-core layer 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Going beyond MACHINE? 2014-10-20 12:40 ` Mike Looijmans 2014-10-20 13:36 ` Otavio Salvador @ 2014-10-20 15:23 ` Richard Purdie 1 sibling, 0 replies; 6+ messages in thread From: Richard Purdie @ 2014-10-20 15:23 UTC (permalink / raw) To: Mike Looijmans; +Cc: openembedded-core 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-11-04 15:05 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox