Re: Simultaneous support of CONFIG_MX6UL and CONFIG_MX6ULL
Hi Matthias, On Mon, Nov 8, 2021 at 11:30 AM 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. Yes, that would be helpful. Please go ahead. Thanks
Re: Simultaneous support of CONFIG_MX6UL and CONFIG_MX6ULL
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 signature.asc Description: PGP signature
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
