Simultaneous support of CONFIG_MX6UL and CONFIG_MX6ULL

Simultaneous support of CONFIG_MX6UL and CONFIG_MX6ULL

[Matthias Schiffer]

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

Re: Simultaneous support of CONFIG_MX6UL and CONFIG_MX6ULL

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]

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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Simultaneous support of CONFIG_MX6UL and CONFIG_MX6ULL

[Fabio Estevam]

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