[PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board

[Vanessa Maegima]

Hi Andrey,

On Sun, May 16, 2021 at 11:31 AM ZHIZHIKIN Andrey
<andrey.zhizhikin at leica-geosystems.com> wrote:
>
> Hello Ricardo,
>
> > -----Original Message-----
> > From: Ricardo Salveti <rsalveti at rsalveti.net>
> > Sent: Friday, May 14, 2021 5:29 PM
> > To: Fabio Estevam <festevam at gmail.com>
> > Cc: ZHIZHIKIN Andrey <andrey.zhizhikin at leica-geosystems.com>; Peng Fan
> > (OSS) <peng.fan at oss.nxp.com>; sbabic at denx.de; u-boot at lists.denx.de; uboot-
> > imx at nxp.com; Ye Li <ye.li at nxp.com>; vanessa.maegima at foundries.io;
> > igor.opaniuk at foundries.io
> > Subject: Re: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board
> >
> >
> > Hi Fabio,
> >
> > On Fri, May 14, 2021 at 9:30 AM Fabio Estevam <festevam at gmail.com> wrote:
> > >
> > > Hi Andrey,
> > >
> > > On Wed, May 12, 2021 at 6:47 PM ZHIZHIKIN Andrey
> > > <andrey.zhizhikin at leica-geosystems.com> wrote:
> > >
> > > > > Update PMIC to use PCA9540, the legacy board not supported by NXP
> > > >
> > > > This commit seems rather a "nuclear" to me, as de-facto it drops the
> > initialization of ROMH PMIC in
> > > > favor of PCA one, leaving all the previous board revisions not to be properly
> > sourced.
> > > >
> > > > I know that there might be no intention to provide a support for earlier
> > revisions of i.MX8M Mini
> > > > EVKs from NXP, but providing no backward compatibility to those boards
> > which are still in use by
> > > > a lot of people for development purposes is highly undesirable either.
> > > >
> > > > TBH, I've tested this patch on the old EVK where ROMH PMIC is present, and
> > apart from having some
> > > > error messages in SPL regarding the register writes - it does boots. What
> > worries me the most though
> > > > is that DTS changes some voltage settings, which I'm not sure how the SOC
> > would react on.
> > > >
> > > > To my opinion, this patch should either be complemented with the
> > mechanism to provide a
> > > > level of backward compatibility (where the PMIC can be dynamically
> > identified and instantiated),
> > > > or the separate implementation should be presented which would make the
> > old board type not to
> > > > be bootable at all if it is considered not to be supported any longer. Or this
> > patch should be reverted
> > > > in an effort to come up with a solution which covers new revision without
> > "damaging" the currently
> > > > integrated one.
> > > >
> > > > Fabio / Stefano,
> > > > Do you have any thoughts here on how this should be handled further,
> > considering the fact that the
> > > > backward compatibility of 2021.07 release is not kept for this board type
> > across multiple revisions?
> > > >
> > > > I'd really like to get your opinion here as I do have those boards in
> > development and would need to
> > > > come up with the idea on what to do with them.
> > > >
> > > > Also, this should be taken care of in the Yocto, since there is only one
> > definition of the i.MX8MM EVK
> > > > machine which does not make any distinction regarding the revision.
> > >
> > > You bring a good point.
> > >
> > > What about adding a new defconfig to support the old imx8mm-evk with
> > > the Rohm PMIC?
> > >
> > > Then we could have imx8mm_evk_defconfig for the new version and
> > > imx8mm_evk_rohm_defconfig for the old one.
> > >
> > > What do you think?
> >
> > Maybe a dynamic way to identify if BD71837 or PCA9450 (by probing i2c)
> > would work better?
>
> This might be solution given that there is an implementation in SPL which
> can be used to query I2C to determine the PMIC type and get it dynamically.
>
> I'm not aware if this functionality exist, I would need to search for the reference
> in the U-Boot tree for this.
>
> But still, as I previously replied to Fabio, it would still need to have 2 separate
> entries in DTS for both PMICs, and SPL power_init_board(void) code should be
> extended to request the PMIC based on the type detected.
>
> I guess this can be done in 2 steps: first make the PMIC selection based on the
> config option in SPL, and then - replace it with dynamic query (if possible).
>
> >
> > Different configs would imply different builds and binaries, which is
> > a problem when trying to support a single build for both the old EVK
> > and EVKB (and the main difference is the PMIC, nothing really major).
>
> This is especially true for Yocto builds, but there would be a way to define
> separate U-Boot config based on the type, so having 2 separate config files
> would not be technically impossible to achieve.
>
> However, I totally agree with you - one build for both revisions would be the
> best solution here.

Just as a reference, Toradex has worked around this issue for their
imx8mmevk-based design by implementing the dynamic board rev selection in their
tree ("verdin-imx8mm: implement hardware version detection"). With this patch,
they use the same Uboot defconfig with two different dtbs being selected
at runtime in board.c.

We have implemented a similar logic in our tree and it worked for both EVK and
EVKB versions.

>
> >
> > I also share Andrey's concerns, as we do have several EVKs in hands,
> > and having one single build would facilitate quite a bit.
> >
> > Cheers,
> > --
> > Ricardo Salveti de Araujo
>
> -- andrey

Regards,
Vanessa