Re: nitrogen6x machine config and imxpxp problems


Gary Bisson
 

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

Join {meta-freescale@lists.yoctoproject.org to automatically receive all group messages.