* nitrogen6x machine config and imxpxp problems
@ 2020-04-24 6:59 Carlos Rafael Giani
2020-04-24 7:29 ` [meta-freescale] " Gary Bisson
0 siblings, 1 reply; 4+ messages in thread
From: Carlos Rafael Giani @ 2020-04-24 6:59 UTC (permalink / raw)
To: meta-freescale
The nitrogen6x machine config also supports other machines according to
the comment block inside the .conf file:
> # Note that this machine configuration also supports the SABRE Lite
> # reference design and the Nitrogen6X-SOM.
> #
> # By default, this machine will build for the standard Quad-Core, 1GB
> # option.
> #
> # To build U-Boot for other CPU or memory combinations, you can set
> # the UBOOT_MACHINE variable in your local.conf according to the
> # following table:
> #
> # Processor Memory Configuration
> # -------------- ------ --------------------
> # i.MX6Quad/Dual 1GB nitrogen6q_config
> # i.MX6Quad/Dual 2GB nitrogen6q2g_config
> # i.MX6Quad/Dual 4GB nitrogen6_max_config
> # i.MX6Dual-Lite 1GB nitrogen6dl_config
> # i.MX6Dual-Lite 2GB nitrogen6dl2g_config
> # i.MX6Solo 512MB nitrogen6s_config
> # i.MX6Solo 1GB nitrogen6s1g_config
This is the reason for this line in the config:
MACHINEOVERRIDES =. "mx6:mx6dl:mx6q:"
This is a problem, since the features between the different i.MX6 SoC
variants to differ. In particular, imxpxp is enabled because of this,
even though my nitrogen6x - which has an i.MX6 Quad - has no PxP
support. As a result, software whose recipes test for imxpxp presence
incorrectly have their PxP features enabled. This is especially bad if
it affects ptest packages, which then fail.
I now wonder what to do here. Split nitrogen6x.conf into multiple
individual recipes? Or selectively remove machineoverrides somehow?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [meta-freescale] nitrogen6x machine config and imxpxp problems
2020-04-24 6:59 nitrogen6x machine config and imxpxp problems Carlos Rafael Giani
@ 2020-04-24 7:29 ` Gary Bisson
2020-04-24 7:41 ` Carlos Rafael Giani
0 siblings, 1 reply; 4+ messages in thread
From: Gary Bisson @ 2020-04-24 7:29 UTC (permalink / raw)
To: Carlos Rafael Giani; +Cc: meta-freescale
Hi Carlos,
On Fri, Apr 24, 2020 at 08:59:34AM +0200, Carlos Rafael Giani wrote:
> The nitrogen6x machine config also supports other machines according to the
> comment block inside the .conf file:
>
> > # Note that this machine configuration also supports the SABRE Lite
> > # reference design and the Nitrogen6X-SOM.
> > #
> > # By default, this machine will build for the standard Quad-Core, 1GB
> > # option.
> > #
> > # To build U-Boot for other CPU or memory combinations, you can set
> > # the UBOOT_MACHINE variable in your local.conf according to the
> > # following table:
> > #
> > # Processor Memory Configuration
> > # -------------- ------ --------------------
> > # i.MX6Quad/Dual 1GB nitrogen6q_config
> > # i.MX6Quad/Dual 2GB nitrogen6q2g_config
> > # i.MX6Quad/Dual 4GB nitrogen6_max_config
> > # i.MX6Dual-Lite 1GB nitrogen6dl_config
> > # i.MX6Dual-Lite 2GB nitrogen6dl2g_config
> > # i.MX6Solo 512MB nitrogen6s_config
> > # i.MX6Solo 1GB nitrogen6s1g_config
>
> This is the reason for this line in the config:
>
> MACHINEOVERRIDES =. "mx6:mx6dl:mx6q:"
>
> This is a problem, since the features between the different i.MX6 SoC
> variants to differ. In particular, imxpxp is enabled because of this, even
> though my nitrogen6x - which has an i.MX6 Quad - has no PxP support. As a
> result, software whose recipes test for imxpxp presence incorrectly have
> their PxP features enabled. This is especially bad if it affects ptest
> packages, which then fail.
Well the board itself (Nitrogen6x) is the same, only the CPU populated
changed (pin-to-pin compatible) so it made sense not to separate the
machine.
Then as the commit from Eric explained [1], the main reason was for the
firmware-imx vpu files, without "mx6dl" it wouldn't install the matching
firmware.
This isn't ideal but has worked for the past 6 years, so I'm not sure
what is the ptest packages error, can you copy it here?
> I now wonder what to do here. Split nitrogen6x.conf into multiple individual
> recipes? Or selectively remove machineoverrides somehow?
At this stage of the product (entering legacy) we do not plan on
splitting its machine.
Also want to point out that even NXP SABRE SD machine does the same
thing [2] so I doubt the solution is splitting it or removing an
override.
Regards,
Gary
[1] https://github.com/Freescale/meta-freescale-3rdparty/commit/9d34fea1
[2] https://github.com/Freescale/meta-freescale/blob/zeus/conf/machine/imx6qdlsabresd.conf
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [meta-freescale] nitrogen6x machine config and imxpxp problems
2020-04-24 7:29 ` [meta-freescale] " Gary Bisson
@ 2020-04-24 7:41 ` Carlos Rafael Giani
2020-04-24 7:54 ` Gary Bisson
0 siblings, 1 reply; 4+ messages in thread
From: Carlos Rafael Giani @ 2020-04-24 7:41 UTC (permalink / raw)
To: Gary Bisson; +Cc: meta-freescale
Two problems actually.
First, gstreamer1.0-plugins-imx has its PxP plugin enabled.
Second, libimxdmabuffer's PxP allocator is enabled. This allocator is
then tested for in the test-alloc program. This program is what's used
by libimxdmabuffer's ptest. test-alloc then detects a failure while
trying to use the PxP allocator (of course, since PxP is not actually
present), causing test-alloc to report a failure.
I could change libimxdmabuffer's test-alloc to report success if at
least one tested allocator works, but I'm not sure if this is really the
right way to go. This would pave the way for run-time checks that
enable/disable features. From what I know, this kind of thing isn't
considered good practice in Yocto, since it tends to make builds less
deterministic.
Carlos
On 24.04.20 09:29, Gary Bisson wrote:
> Hi Carlos,
>
> On Fri, Apr 24, 2020 at 08:59:34AM +0200, Carlos Rafael Giani wrote:
>> The nitrogen6x machine config also supports other machines according to the
>> comment block inside the .conf file:
>>
>>> # Note that this machine configuration also supports the SABRE Lite
>>> # reference design and the Nitrogen6X-SOM.
>>> #
>>> # By default, this machine will build for the standard Quad-Core, 1GB
>>> # option.
>>> #
>>> # To build U-Boot for other CPU or memory combinations, you can set
>>> # the UBOOT_MACHINE variable in your local.conf according to the
>>> # following table:
>>> #
>>> # Processor Memory Configuration
>>> # -------------- ------ --------------------
>>> # i.MX6Quad/Dual 1GB nitrogen6q_config
>>> # i.MX6Quad/Dual 2GB nitrogen6q2g_config
>>> # i.MX6Quad/Dual 4GB nitrogen6_max_config
>>> # i.MX6Dual-Lite 1GB nitrogen6dl_config
>>> # i.MX6Dual-Lite 2GB nitrogen6dl2g_config
>>> # i.MX6Solo 512MB nitrogen6s_config
>>> # i.MX6Solo 1GB nitrogen6s1g_config
>> This is the reason for this line in the config:
>>
>> MACHINEOVERRIDES =. "mx6:mx6dl:mx6q:"
>>
>> This is a problem, since the features between the different i.MX6 SoC
>> variants to differ. In particular, imxpxp is enabled because of this, even
>> though my nitrogen6x - which has an i.MX6 Quad - has no PxP support. As a
>> result, software whose recipes test for imxpxp presence incorrectly have
>> their PxP features enabled. This is especially bad if it affects ptest
>> packages, which then fail.
> Well the board itself (Nitrogen6x) is the same, only the CPU populated
> changed (pin-to-pin compatible) so it made sense not to separate the
> machine.
>
> Then as the commit from Eric explained [1], the main reason was for the
> firmware-imx vpu files, without "mx6dl" it wouldn't install the matching
> firmware.
>
> This isn't ideal but has worked for the past 6 years, so I'm not sure
> what is the ptest packages error, can you copy it here?
>
>> I now wonder what to do here. Split nitrogen6x.conf into multiple individual
>> recipes? Or selectively remove machineoverrides somehow?
> At this stage of the product (entering legacy) we do not plan on
> splitting its machine.
>
> Also want to point out that even NXP SABRE SD machine does the same
> thing [2] so I doubt the solution is splitting it or removing an
> override.
>
> Regards,
> Gary
>
> [1] https://github.com/Freescale/meta-freescale-3rdparty/commit/9d34fea1
> [2] https://github.com/Freescale/meta-freescale/blob/zeus/conf/machine/imx6qdlsabresd.conf
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [meta-freescale] nitrogen6x machine config and imxpxp problems
2020-04-24 7:41 ` Carlos Rafael Giani
@ 2020-04-24 7:54 ` Gary Bisson
0 siblings, 0 replies; 4+ messages in thread
From: Gary Bisson @ 2020-04-24 7:54 UTC (permalink / raw)
To: Carlos Rafael Giani; +Cc: meta-freescale
Hi Carlos,
On Fri, Apr 24, 2020 at 09:41:26AM +0200, Carlos Rafael Giani wrote:
> Two problems actually.
>
> First, gstreamer1.0-plugins-imx has its PxP plugin enabled.
Sure, that has been acceptable to us as as most customer don't use PxP
on i.MX6 but prefer GPU2D/3D features.
> Second, libimxdmabuffer's PxP allocator is enabled. This allocator is then
> tested for in the test-alloc program. This program is what's used by
> libimxdmabuffer's ptest. test-alloc then detects a failure while trying to
> use the PxP allocator (of course, since PxP is not actually present),
> causing test-alloc to report a failure.
How did that work on GStreamer-imx before? Because this issue has been
there all along.
Was there a runtime check to enable/disable features? (I don't recall)
> I could change libimxdmabuffer's test-alloc to report success if at least
> one tested allocator works, but I'm not sure if this is really the right way
> to go. This would pave the way for run-time checks that enable/disable
> features. From what I know, this kind of thing isn't considered good
> practice in Yocto, since it tends to make builds less deterministic.
I know the "build" has to be deterministic but is there "runtime"
recommendations from Yocto?
Regards,
Gary
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-04-24 7:54 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-24 6:59 nitrogen6x machine config and imxpxp problems Carlos Rafael Giani
2020-04-24 7:29 ` [meta-freescale] " Gary Bisson
2020-04-24 7:41 ` Carlos Rafael Giani
2020-04-24 7:54 ` Gary Bisson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).