Hello Vanessa, > -----Original Message----- > From: Vanessa Maegima <[email protected]> > Sent: Tuesday, May 18, 2021 3:15 PM > To: ZHIZHIKIN Andrey <[email protected]> > Cc: Ricardo Salveti <[email protected]>; Fabio Estevam > <[email protected]>; Peng Fan (OSS) <[email protected]>; > [email protected]; [email protected]; [email protected]; Ye Li > <[email protected]>; [email protected] > 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 <[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.
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
