Simultaneous support of CONFIG_MX6UL and CONFIG_MX6ULL

Hi everyone,
for the submission of support for our TQMa6UL/TQMa6ULL SoM family I've been wondering if it would be desirable to allow U-Boot configs that support both i.MX6UL and i.MX6ULL. This would allow us to reduce the number of required defconfig variants for our SoMs significantly.
I had a look at the differences between these configurations, and most of the code already treats both SoCs the same (lots of "#if defined(CONFIG_MX6UL) || defined(CONFIG_MX6ULL)"). The differences are sufficiently small that it seems easy to change them to use runtime detection for the SoC variant (and maybe not even leave CONFIG_MX6UL and CONFIG_MX6ULL as separate config symbols):
- MX6UL selects HAS_CAAM. Runtime detection should already work (will double-check) - Fuse support: Easy to switch to runtime detection - mx6ul_pins.h vs. mx6ull_pins.h: Mostly identical. Only definitions for GPIO5 differ (and none of the differing definitions are used at all)
I can propose patches for these changes if you think that it is a good idea.
Kind regards, Matthias

On Mon, Nov 08, 2021 at 03:30:06PM +0100, Matthias Schiffer wrote:
Hi everyone,
for the submission of support for our TQMa6UL/TQMa6ULL SoM family I've been wondering if it would be desirable to allow U-Boot configs that support both i.MX6UL and i.MX6ULL. This would allow us to reduce the number of required defconfig variants for our SoMs significantly.
I had a look at the differences between these configurations, and most of the code already treats both SoCs the same (lots of "#if defined(CONFIG_MX6UL) || defined(CONFIG_MX6ULL)"). The differences are sufficiently small that it seems easy to change them to use runtime detection for the SoC variant (and maybe not even leave CONFIG_MX6UL and CONFIG_MX6ULL as separate config symbols):
- MX6UL selects HAS_CAAM. Runtime detection should already work (will
double-check)
- Fuse support: Easy to switch to runtime detection
- mx6ul_pins.h vs. mx6ull_pins.h: Mostly identical. Only definitions
for GPIO5 differ (and none of the differing definitions are used at all)
I can propose patches for these changes if you think that it is a good idea.
Generally this sounds good, yes. We might need to keep the separate symbols in order to avoid size growth on platforms that only support one rather than both SoCs however.

Hi Matthias,
On Mon, Nov 8, 2021 at 11:30 AM Matthias Schiffer matthias.schiffer@ew.tq-group.com wrote:
Hi everyone,
for the submission of support for our TQMa6UL/TQMa6ULL SoM family I've been wondering if it would be desirable to allow U-Boot configs that support both i.MX6UL and i.MX6ULL. This would allow us to reduce the number of required defconfig variants for our SoMs significantly.
I had a look at the differences between these configurations, and most of the code already treats both SoCs the same (lots of "#if defined(CONFIG_MX6UL) || defined(CONFIG_MX6ULL)"). The differences are sufficiently small that it seems easy to change them to use runtime detection for the SoC variant (and maybe not even leave CONFIG_MX6UL and CONFIG_MX6ULL as separate config symbols):
- MX6UL selects HAS_CAAM. Runtime detection should already work (will
double-check)
- Fuse support: Easy to switch to runtime detection
- mx6ul_pins.h vs. mx6ull_pins.h: Mostly identical. Only definitions
for GPIO5 differ (and none of the differing definitions are used at all)
I can propose patches for these changes if you think that it is a good idea.
Yes, that would be helpful. Please go ahead.
Thanks
participants (3)
-
Fabio Estevam
-
Matthias Schiffer
-
Tom Rini