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

[ZHIZHIKIN Andrey <andrey.zhizhikin@leica-geosystems.com>]

Hello Vanessa,

> -----Original Message-----
> From: Vanessa Maegima <vanessa.maegima@foundries.io>
> Sent: Tuesday, May 18, 2021 3:15 PM
> To: ZHIZHIKIN Andrey <andrey.zhizhikin@leica-geosystems.com>
> Cc: Ricardo Salveti <rsalveti@rsalveti.net>; Fabio Estevam
> <festevam@gmail.com>; Peng Fan (OSS) <peng.fan@oss.nxp.com>;
> sbabic at denx.de; u-boot at lists.denx.de; uboot-imx at nxp.com; Ye Li
> <ye.li@nxp.com>; igor.opaniuk at foundries.io
> Subject: Re: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board
> 
> 
> Hi Andrey,
> 
> On Sun, May 16, 2021 at 11:31 AM ZHIZHIKIN Andrey <andrey.zhizhikin@leica-
> geosystems.com> wrote:
> >
> > Hello Ricardo,
> >
> > > -----Original Message-----
> > > From: Ricardo Salveti <rsalveti@rsalveti.net>
> > > Sent: Friday, May 14, 2021 5:29 PM
> > > To: Fabio Estevam <festevam@gmail.com>
> > > Cc: ZHIZHIKIN Andrey <andrey.zhizhikin@leica-geosystems.com>; Peng
> > > Fan
> > > (OSS) <peng.fan@oss.nxp.com>; sbabic at denx.de; u-boot at lists.denx.de;
> > > uboot- imx at nxp.com; Ye Li <ye.li@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@gmail.com>
> wrote:
> > > >
> > > > Hi Andrey,
> > > >
> > > > On Wed, May 12, 2021 at 6:47 PM ZHIZHIKIN Andrey
> > > > <andrey.zhizhikin@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.

I've also found this implementation for Toradex Verdin CoM, but did not track
which commit brought it.

Thanks for pointing out the commit message - I would certainly have a look
at it further!

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

I was thinking that this would be done by NXP as well for the EVK they
distribute, but the statement was rather clear: No backward compatibility
is provided as the old EVK is not supported any longer.

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

-- andrey