From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vanessa Maegima Date: Tue, 18 May 2021 10:14:57 -0300 Subject: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board In-Reply-To: References: <20210319075718.14181-1-peng.fan@oss.nxp.com> <20210319075718.14181-4-peng.fan@oss.nxp.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Andrey, On Sun, May 16, 2021 at 11:31 AM ZHIZHIKIN Andrey wrote: > > Hello Ricardo, > > > -----Original Message----- > > From: Ricardo Salveti > > Sent: Friday, May 14, 2021 5:29 PM > > To: Fabio Estevam > > Cc: ZHIZHIKIN Andrey ; Peng Fan > > (OSS) ; sbabic at denx.de; u-boot at lists.denx.de; uboot- > > imx at nxp.com; Ye Li ; 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 wrote: > > > > > > Hi Andrey, > > > > > > On Wed, May 12, 2021 at 6:47 PM ZHIZHIKIN Andrey > > > 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