Hi Andrey,
On Sun, May 16, 2021 at 11:31 AM ZHIZHIKIN Andrey
<[email protected]> wrote:
>
> Hello Ricardo,
>
> > -----Original Message-----
> > From: Ricardo Salveti <[email protected]>
> > Sent: Friday, May 14, 2021 5:29 PM
> > To: Fabio Estevam <[email protected]>
> > Cc: ZHIZHIKIN Andrey <[email protected]>; Peng Fan
> > (OSS) <[email protected]>; [email protected]; [email protected]; uboot-
> > [email protected]; Ye Li <[email protected]>; [email protected];
> > [email protected]
> > 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 <[email protected]> wrote:
> > >
> > > Hi Andrey,
> > >
> > > On Wed, May 12, 2021 at 6:47 PM ZHIZHIKIN Andrey
> > > <[email protected]> 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
