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

[ZHIZHIKIN Andrey]

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.

> 
> 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