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@denx.de; u-boot@lists.denx.de; uboot-imx@nxp.com; Ye Li ye.li@nxp.com; igor.opaniuk@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@denx.de; u-boot@lists.denx.de; uboot- imx@nxp.com; Ye Li ye.li@nxp.com; vanessa.maegima@foundries.io; igor.opaniuk@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