| Message ID | 20210319075718.14181-4-peng.fan@oss.nxp.com |
|---|---|
| State | Accepted |
| Commit | 48ddafd9a42284457ac22d42572b88dbdb136fdd |
| Delegated to: | Stefano Babic |
| Headers | show |
| Series | imx: update for i.MX8M | expand |
Hello Peng, > -----Original Message----- > From: U-Boot <u-boot-bounces@lists.denx.de> On Behalf Of Peng Fan (OSS) > Sent: Friday, March 19, 2021 8:57 AM > To: sbabic@denx.de; festevam@gmail.com > Cc: u-boot@lists.denx.de; uboot-imx@nxp.com; Ye Li <ye.li@nxp.com> > Subject: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board > > From: Ye Li <ye.li@nxp.com> > > 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. Thanks a lot! > > Signed-off-by: Ye Li <ye.li@nxp.com> > --- > arch/arm/dts/imx8mm-evk-u-boot.dtsi | 4 +- > arch/arm/dts/imx8mm-evk.dtsi | 127 +++++++++++++++------------- > board/freescale/imx8mm_evk/spl.c | 33 ++++---- > configs/imx8mm_evk_defconfig | 2 +- > 4 files changed, 86 insertions(+), 80 deletions(-) > > diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi b/arch/arm/dts/imx8mm-evk- > u-boot.dtsi > index e843a5648e..7f48912b49 100644 > --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi > +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi > @@ -114,11 +114,11 @@ > u-boot,dm-spl; > }; > > -&{/soc@0/bus@30800000/i2c@30a20000/pmic@4b} { > +&{/soc@0/bus@30800000/i2c@30a20000/pca9450@25} { > u-boot,dm-spl; > }; > > -&{/soc@0/bus@30800000/i2c@30a20000/pmic@4b/regulators} { > +&{/soc@0/bus@30800000/i2c@30a20000/pca9450@25/regulators} { > u-boot,dm-spl; > }; > > diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi > index 6518f088b2..60179e006d 100644 > --- a/arch/arm/dts/imx8mm-evk.dtsi > +++ b/arch/arm/dts/imx8mm-evk.dtsi > @@ -126,115 +126,120 @@ > pinctrl-0 = <&pinctrl_i2c1>; > status = "okay"; > > - pmic@4b { > - compatible = "rohm,bd71847"; > - reg = <0x4b>; > - pinctrl-names = "default"; > + pmic: pca9450@25 { > + reg = <0x25>; > + compatible = "nxp,pca9450a"; > + /* PMIC PCA9450 PMIC_nINT GPIO1_IO3 */ > pinctrl-0 = <&pinctrl_pmic>; > - interrupt-parent = <&gpio1>; > - interrupts = <3 IRQ_TYPE_LEVEL_LOW>; > - rohm,reset-snvs-powered; > - > - #clock-cells = <0>; > - clocks = <&osc_32k 0>; > - clock-output-names = "clk-32k-out"; > + gpio_intr = <&gpio1 3 GPIO_ACTIVE_LOW>; > > regulators { > - buck1_reg: BUCK1 { > - regulator-name = "buck1"; > - regulator-min-microvolt = <700000>; > - regulator-max-microvolt = <1300000>; > + #address-cells = <1>; > + #size-cells = <0>; > + > + pca9450,pmic-buck2-uses-i2c-dvs; > + /* Run/Standby voltage */ > + pca9450,pmic-buck2-dvs-voltage = <950000>, > + <850000>; > + > + buck1_reg: regulator@0 { > + reg = <0>; > + regulator-compatible = "buck1"; > + regulator-min-microvolt = <600000>; > + regulator-max-microvolt = <2187500>; > regulator-boot-on; > regulator-always-on; > - regulator-ramp-delay = <1250>; > + regulator-ramp-delay = <3125>; > }; > > - buck2_reg: BUCK2 { > - regulator-name = "buck2"; > - regulator-min-microvolt = <700000>; > - regulator-max-microvolt = <1300000>; > + buck2_reg: regulator@1 { > + reg = <1>; > + regulator-compatible = "buck2"; > + regulator-min-microvolt = <600000>; > + regulator-max-microvolt = <2187500>; > regulator-boot-on; > regulator-always-on; > - regulator-ramp-delay = <1250>; > - rohm,dvs-run-voltage = <1000000>; > - rohm,dvs-idle-voltage = <900000>; > + regulator-ramp-delay = <3125>; > }; > > - buck3_reg: BUCK3 { > - // BUCK5 in datasheet > - regulator-name = "buck3"; > - regulator-min-microvolt = <700000>; > - regulator-max-microvolt = <1350000>; > + buck3_reg: regulator@2 { > + reg = <2>; > + regulator-compatible = "buck3"; > + regulator-min-microvolt = <600000>; > + regulator-max-microvolt = <2187500>; > regulator-boot-on; > regulator-always-on; > }; > > - buck4_reg: BUCK4 { > - // BUCK6 in datasheet > - regulator-name = "buck4"; > - regulator-min-microvolt = <3000000>; > - regulator-max-microvolt = <3300000>; > + buck4_reg: regulator@3 { > + reg = <3>; > + regulator-compatible = "buck4"; > + regulator-min-microvolt = <600000>; > + regulator-max-microvolt = <3400000>; > regulator-boot-on; > regulator-always-on; > }; > > - buck5_reg: BUCK5 { > - // BUCK7 in datasheet > - regulator-name = "buck5"; > - regulator-min-microvolt = <1605000>; > - regulator-max-microvolt = <1995000>; > + buck5_reg: regulator@4 { > + reg = <4>; > + regulator-compatible = "buck5"; > + regulator-min-microvolt = <600000>; > + regulator-max-microvolt = <3400000>; > regulator-boot-on; > regulator-always-on; > }; > > - buck6_reg: BUCK6 { > - // BUCK8 in datasheet > - regulator-name = "buck6"; > - regulator-min-microvolt = <800000>; > - regulator-max-microvolt = <1400000>; > + buck6_reg: regulator@5 { > + reg = <5>; > + regulator-compatible = "buck6"; > + regulator-min-microvolt = <600000>; > + regulator-max-microvolt = <3400000>; > regulator-boot-on; > regulator-always-on; > }; > > - ldo1_reg: LDO1 { > - regulator-name = "ldo1"; > + ldo1_reg: regulator@6 { > + reg = <6>; > + regulator-compatible = "ldo1"; > regulator-min-microvolt = <1600000>; > regulator-max-microvolt = <3300000>; > regulator-boot-on; > regulator-always-on; > }; > > - ldo2_reg: LDO2 { > - regulator-name = "ldo2"; > + ldo2_reg: regulator@7 { > + reg = <7>; > + regulator-compatible = "ldo2"; > regulator-min-microvolt = <800000>; > - regulator-max-microvolt = <900000>; > + regulator-max-microvolt = <1150000>; > regulator-boot-on; > regulator-always-on; > }; > > - ldo3_reg: LDO3 { > - regulator-name = "ldo3"; > - regulator-min-microvolt = <1800000>; > + ldo3_reg: regulator@8 { > + reg = <8>; > + regulator-compatible = "ldo3"; > + regulator-min-microvolt = <800000>; > regulator-max-microvolt = <3300000>; > regulator-boot-on; > regulator-always-on; > }; > > - ldo4_reg: LDO4 { > - regulator-name = "ldo4"; > - regulator-min-microvolt = <900000>; > - regulator-max-microvolt = <1800000>; > + ldo4_reg: regulator@9 { > + reg = <9>; > + regulator-compatible = "ldo4"; > + regulator-min-microvolt = <800000>; > + regulator-max-microvolt = <3300000>; > regulator-boot-on; > regulator-always-on; > }; > > - ldo6_reg: LDO6 { > - regulator-name = "ldo6"; > - regulator-min-microvolt = <900000>; > - regulator-max-microvolt = <1800000>; > - regulator-boot-on; > - regulator-always-on; > + ldo5_reg: regulator@10 { > + reg = <10>; > + regulator-compatible = "ldo5"; > + regulator-min-microvolt = <1800000>; > + regulator-max-microvolt = <3300000>; > }; > + > }; > }; > }; > diff --git a/board/freescale/imx8mm_evk/spl.c > b/board/freescale/imx8mm_evk/spl.c > index 64bc60651d..4ef7f6f180 100644 > --- a/board/freescale/imx8mm_evk/spl.c > +++ b/board/freescale/imx8mm_evk/spl.c > @@ -26,7 +26,7 @@ > #include <dm/device-internal.h> > > #include <power/pmic.h> > -#include <power/bd71837.h> > +#include <power/pca9450.h> > > DECLARE_GLOBAL_DATA_PTR; > > @@ -94,7 +94,7 @@ static int power_init_board(void) > struct udevice *dev; > int ret; > > - ret = pmic_get("pmic@4b", &dev); > + ret = pmic_get("pca9450@25", &dev); > if (ret == -ENODEV) { > puts("No pmic\n"); > return 0; > @@ -102,25 +102,26 @@ static int power_init_board(void) > if (ret != 0) > return ret; > > - /* decrease RESET key long push time from the default 10s to 10ms */ > - pmic_reg_write(dev, BD718XX_PWRONCONFIG1, 0x0); > + /* BUCKxOUT_DVS0/1 control BUCK123 output */ > + pmic_reg_write(dev, PCA9450_BUCK123_DVS, 0x29); > > - /* unlock the PMIC regs */ > - pmic_reg_write(dev, BD718XX_REGLOCK, 0x1); > + /* Buck 1 DVS control through PMIC_STBY_REQ */ > + pmic_reg_write(dev, PCA9450_BUCK1CTRL, 0x59); > > - /* increase VDD_SOC to typical value 0.85v before first DRAM access */ > - pmic_reg_write(dev, BD718XX_BUCK1_VOLT_RUN, 0x0f); > + /* Set DVS1 to 0.8v for suspend */ > + pmic_reg_write(dev, PCA9450_BUCK1OUT_DVS1, 0x10); > > - /* increase VDD_DRAM to 0.975v for 3Ghz DDR */ > - pmic_reg_write(dev, BD718XX_1ST_NODVS_BUCK_VOLT, 0x83); > + /* increase VDD_DRAM to 0.95v for 3Ghz DDR */ > + pmic_reg_write(dev, PCA9450_BUCK3OUT_DVS0, 0x1C); > > -#ifndef CONFIG_IMX8M_LPDDR4 > - /* increase NVCC_DRAM_1V2 to 1.2v for DDR4 */ > - pmic_reg_write(dev, BD718XX_4TH_NODVS_BUCK_VOLT, 0x28); > -#endif > + /* VDD_DRAM needs off in suspend, set B1_ENMODE=10 (ON by > PMIC_ON_REQ = H && PMIC_STBY_REQ = L) */ > + pmic_reg_write(dev, PCA9450_BUCK3CTRL, 0x4a); > + > + /* set VDD_SNVS_0V8 from default 0.85V */ > + pmic_reg_write(dev, PCA9450_LDO2CTRL, 0xC0); > > - /* lock the PMIC regs */ > - pmic_reg_write(dev, BD718XX_REGLOCK, 0x11); > + /* set WDOG_B_CFG to cold reset */ > + pmic_reg_write(dev, PCA9450_RESET_CTRL, 0xA1); > > return 0; > } > diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig > index e22b7de56f..ae9e0626dd 100644 > --- a/configs/imx8mm_evk_defconfig > +++ b/configs/imx8mm_evk_defconfig > @@ -83,7 +83,7 @@ CONFIG_PINCTRL=y > CONFIG_SPL_PINCTRL=y > CONFIG_PINCTRL_IMX8M=y > CONFIG_DM_PMIC=y > -CONFIG_SPL_DM_PMIC_BD71837=y > +CONFIG_SPL_DM_PMIC_PCA9450=y > CONFIG_DM_REGULATOR=y > CONFIG_DM_REGULATOR_FIXED=y > CONFIG_DM_REGULATOR_GPIO=y > -- > 2.30.0 -- andrey
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? Thanks
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? 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). 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,
Hi Ricardo, On Fri, May 14, 2021 at 12:29 PM Ricardo Salveti <rsalveti@rsalveti.net> wrote: > Maybe a dynamic way to identify if BD71837 or PCA9450 (by probing i2c) > would work better? Yes, agreed. On imx53-qsb we support both Dialog and NXP PMICs in the same defconfig. > 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). > > I also share Andrey's concerns, as we do have several EVKs in hands, > and having one single build would facilitate quite a bit. Agreed. Thanks
Hello Fabio, > -----Original Message----- > From: Fabio Estevam <festevam@gmail.com> > Sent: Friday, May 14, 2021 2:31 PM > To: ZHIZHIKIN Andrey <andrey.zhizhikin@leica-geosystems.com> > Cc: 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> > Subject: Re: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board > > > 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? This would not be the only change that is necessary to provide support for both ROMH and PCA PMIC ICs. From the commit, it seems that also the "duplication" should be done in DTS and SPL PMIC code in power_init_board(void) should also be adapted to get PMIC based on the config option. I'm not saying it is not feasible - it is perfectly doable, but would require some verification afterwards. I can try to come up with the patch set for this but cannot commit to test the change since I do not own a updated EVK board. I guess an ideal situation would be that NXP can step in here to provide the better version of this patch where both revisions are supported, and they can verify the change on both EVK revisions. > > Then we could have imx8mm_evk_defconfig for the new version and > imx8mm_evk_rohm_defconfig for the old one. Yes, ultimately this would be possible provided that both DTS and SPL code are made in a way to provide implementation for both PMIC types. > > What do you think? > > Thanks -- andrey
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. > > 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
On 2021/5/13 5:47, ZHIZHIKIN Andrey wrote: > Hello Peng, > >> -----Original Message----- >> From: U-Boot <u-boot-bounces@lists.denx.de> On Behalf Of Peng Fan (OSS) >> Sent: Friday, March 19, 2021 8:57 AM >> To: sbabic@denx.de; festevam@gmail.com >> Cc: u-boot@lists.denx.de; uboot-imx@nxp.com; Ye Li <ye.li@nxp.com> >> Subject: [PATCH 03/26] imx8mm_evk: Switch to new imx8mm evk board >> >> From: Ye Li <ye.li@nxp.com> >> >> 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. The old evk board was no longer supported by NXP, all new boards using new PMIC. No damage, just some default voltage settings different. It is ok to add back the old pmic, but it finally will retire and no one will use it in production I think. Regards, Peng. > > 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. > > Thanks a lot! > >> >> Signed-off-by: Ye Li <ye.li@nxp.com> >> --- >> arch/arm/dts/imx8mm-evk-u-boot.dtsi | 4 +- >> arch/arm/dts/imx8mm-evk.dtsi | 127 +++++++++++++++------------- >> board/freescale/imx8mm_evk/spl.c | 33 ++++---- >> configs/imx8mm_evk_defconfig | 2 +- >> 4 files changed, 86 insertions(+), 80 deletions(-) >> >> diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi b/arch/arm/dts/imx8mm-evk- >> u-boot.dtsi >> index e843a5648e..7f48912b49 100644 >> --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi >> +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi >> @@ -114,11 +114,11 @@ >> u-boot,dm-spl; >> }; >> >> -&{/soc@0/bus@30800000/i2c@30a20000/pmic@4b} { >> +&{/soc@0/bus@30800000/i2c@30a20000/pca9450@25} { >> u-boot,dm-spl; >> }; >> >> -&{/soc@0/bus@30800000/i2c@30a20000/pmic@4b/regulators} { >> +&{/soc@0/bus@30800000/i2c@30a20000/pca9450@25/regulators} { >> u-boot,dm-spl; >> }; >> >> diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi >> index 6518f088b2..60179e006d 100644 >> --- a/arch/arm/dts/imx8mm-evk.dtsi >> +++ b/arch/arm/dts/imx8mm-evk.dtsi >> @@ -126,115 +126,120 @@ >> pinctrl-0 = <&pinctrl_i2c1>; >> status = "okay"; >> >> - pmic@4b { >> - compatible = "rohm,bd71847"; >> - reg = <0x4b>; >> - pinctrl-names = "default"; >> + pmic: pca9450@25 { >> + reg = <0x25>; >> + compatible = "nxp,pca9450a"; >> + /* PMIC PCA9450 PMIC_nINT GPIO1_IO3 */ >> pinctrl-0 = <&pinctrl_pmic>; >> - interrupt-parent = <&gpio1>; >> - interrupts = <3 IRQ_TYPE_LEVEL_LOW>; >> - rohm,reset-snvs-powered; >> - >> - #clock-cells = <0>; >> - clocks = <&osc_32k 0>; >> - clock-output-names = "clk-32k-out"; >> + gpio_intr = <&gpio1 3 GPIO_ACTIVE_LOW>; >> >> regulators { >> - buck1_reg: BUCK1 { >> - regulator-name = "buck1"; >> - regulator-min-microvolt = <700000>; >> - regulator-max-microvolt = <1300000>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + pca9450,pmic-buck2-uses-i2c-dvs; >> + /* Run/Standby voltage */ >> + pca9450,pmic-buck2-dvs-voltage = <950000>, >> + <850000>; >> + >> + buck1_reg: regulator@0 { >> + reg = <0>; >> + regulator-compatible = "buck1"; >> + regulator-min-microvolt = <600000>; >> + regulator-max-microvolt = <2187500>; >> regulator-boot-on; >> regulator-always-on; >> - regulator-ramp-delay = <1250>; >> + regulator-ramp-delay = <3125>; >> }; >> >> - buck2_reg: BUCK2 { >> - regulator-name = "buck2"; >> - regulator-min-microvolt = <700000>; >> - regulator-max-microvolt = <1300000>; >> + buck2_reg: regulator@1 { >> + reg = <1>; >> + regulator-compatible = "buck2"; >> + regulator-min-microvolt = <600000>; >> + regulator-max-microvolt = <2187500>; >> regulator-boot-on; >> regulator-always-on; >> - regulator-ramp-delay = <1250>; >> - rohm,dvs-run-voltage = <1000000>; >> - rohm,dvs-idle-voltage = <900000>; >> + regulator-ramp-delay = <3125>; >> }; >> >> - buck3_reg: BUCK3 { >> - // BUCK5 in datasheet >> - regulator-name = "buck3"; >> - regulator-min-microvolt = <700000>; >> - regulator-max-microvolt = <1350000>; >> + buck3_reg: regulator@2 { >> + reg = <2>; >> + regulator-compatible = "buck3"; >> + regulator-min-microvolt = <600000>; >> + regulator-max-microvolt = <2187500>; >> regulator-boot-on; >> regulator-always-on; >> }; >> >> - buck4_reg: BUCK4 { >> - // BUCK6 in datasheet >> - regulator-name = "buck4"; >> - regulator-min-microvolt = <3000000>; >> - regulator-max-microvolt = <3300000>; >> + buck4_reg: regulator@3 { >> + reg = <3>; >> + regulator-compatible = "buck4"; >> + regulator-min-microvolt = <600000>; >> + regulator-max-microvolt = <3400000>; >> regulator-boot-on; >> regulator-always-on; >> }; >> >> - buck5_reg: BUCK5 { >> - // BUCK7 in datasheet >> - regulator-name = "buck5"; >> - regulator-min-microvolt = <1605000>; >> - regulator-max-microvolt = <1995000>; >> + buck5_reg: regulator@4 { >> + reg = <4>; >> + regulator-compatible = "buck5"; >> + regulator-min-microvolt = <600000>; >> + regulator-max-microvolt = <3400000>; >> regulator-boot-on; >> regulator-always-on; >> }; >> >> - buck6_reg: BUCK6 { >> - // BUCK8 in datasheet >> - regulator-name = "buck6"; >> - regulator-min-microvolt = <800000>; >> - regulator-max-microvolt = <1400000>; >> + buck6_reg: regulator@5 { >> + reg = <5>; >> + regulator-compatible = "buck6"; >> + regulator-min-microvolt = <600000>; >> + regulator-max-microvolt = <3400000>; >> regulator-boot-on; >> regulator-always-on; >> }; >> >> - ldo1_reg: LDO1 { >> - regulator-name = "ldo1"; >> + ldo1_reg: regulator@6 { >> + reg = <6>; >> + regulator-compatible = "ldo1"; >> regulator-min-microvolt = <1600000>; >> regulator-max-microvolt = <3300000>; >> regulator-boot-on; >> regulator-always-on; >> }; >> >> - ldo2_reg: LDO2 { >> - regulator-name = "ldo2"; >> + ldo2_reg: regulator@7 { >> + reg = <7>; >> + regulator-compatible = "ldo2"; >> regulator-min-microvolt = <800000>; >> - regulator-max-microvolt = <900000>; >> + regulator-max-microvolt = <1150000>; >> regulator-boot-on; >> regulator-always-on; >> }; >> >> - ldo3_reg: LDO3 { >> - regulator-name = "ldo3"; >> - regulator-min-microvolt = <1800000>; >> + ldo3_reg: regulator@8 { >> + reg = <8>; >> + regulator-compatible = "ldo3"; >> + regulator-min-microvolt = <800000>; >> regulator-max-microvolt = <3300000>; >> regulator-boot-on; >> regulator-always-on; >> }; >> >> - ldo4_reg: LDO4 { >> - regulator-name = "ldo4"; >> - regulator-min-microvolt = <900000>; >> - regulator-max-microvolt = <1800000>; >> + ldo4_reg: regulator@9 { >> + reg = <9>; >> + regulator-compatible = "ldo4"; >> + regulator-min-microvolt = <800000>; >> + regulator-max-microvolt = <3300000>; >> regulator-boot-on; >> regulator-always-on; >> }; >> >> - ldo6_reg: LDO6 { >> - regulator-name = "ldo6"; >> - regulator-min-microvolt = <900000>; >> - regulator-max-microvolt = <1800000>; >> - regulator-boot-on; >> - regulator-always-on; >> + ldo5_reg: regulator@10 { >> + reg = <10>; >> + regulator-compatible = "ldo5"; >> + regulator-min-microvolt = <1800000>; >> + regulator-max-microvolt = <3300000>; >> }; >> + >> }; >> }; >> }; >> diff --git a/board/freescale/imx8mm_evk/spl.c >> b/board/freescale/imx8mm_evk/spl.c >> index 64bc60651d..4ef7f6f180 100644 >> --- a/board/freescale/imx8mm_evk/spl.c >> +++ b/board/freescale/imx8mm_evk/spl.c >> @@ -26,7 +26,7 @@ >> #include <dm/device-internal.h> >> >> #include <power/pmic.h> >> -#include <power/bd71837.h> >> +#include <power/pca9450.h> >> >> DECLARE_GLOBAL_DATA_PTR; >> >> @@ -94,7 +94,7 @@ static int power_init_board(void) >> struct udevice *dev; >> int ret; >> >> - ret = pmic_get("pmic@4b", &dev); >> + ret = pmic_get("pca9450@25", &dev); >> if (ret == -ENODEV) { >> puts("No pmic\n"); >> return 0; >> @@ -102,25 +102,26 @@ static int power_init_board(void) >> if (ret != 0) >> return ret; >> >> - /* decrease RESET key long push time from the default 10s to 10ms */ >> - pmic_reg_write(dev, BD718XX_PWRONCONFIG1, 0x0); >> + /* BUCKxOUT_DVS0/1 control BUCK123 output */ >> + pmic_reg_write(dev, PCA9450_BUCK123_DVS, 0x29); >> >> - /* unlock the PMIC regs */ >> - pmic_reg_write(dev, BD718XX_REGLOCK, 0x1); >> + /* Buck 1 DVS control through PMIC_STBY_REQ */ >> + pmic_reg_write(dev, PCA9450_BUCK1CTRL, 0x59); >> >> - /* increase VDD_SOC to typical value 0.85v before first DRAM access */ >> - pmic_reg_write(dev, BD718XX_BUCK1_VOLT_RUN, 0x0f); >> + /* Set DVS1 to 0.8v for suspend */ >> + pmic_reg_write(dev, PCA9450_BUCK1OUT_DVS1, 0x10); >> >> - /* increase VDD_DRAM to 0.975v for 3Ghz DDR */ >> - pmic_reg_write(dev, BD718XX_1ST_NODVS_BUCK_VOLT, 0x83); >> + /* increase VDD_DRAM to 0.95v for 3Ghz DDR */ >> + pmic_reg_write(dev, PCA9450_BUCK3OUT_DVS0, 0x1C); >> >> -#ifndef CONFIG_IMX8M_LPDDR4 >> - /* increase NVCC_DRAM_1V2 to 1.2v for DDR4 */ >> - pmic_reg_write(dev, BD718XX_4TH_NODVS_BUCK_VOLT, 0x28); >> -#endif >> + /* VDD_DRAM needs off in suspend, set B1_ENMODE=10 (ON by >> PMIC_ON_REQ = H && PMIC_STBY_REQ = L) */ >> + pmic_reg_write(dev, PCA9450_BUCK3CTRL, 0x4a); >> + >> + /* set VDD_SNVS_0V8 from default 0.85V */ >> + pmic_reg_write(dev, PCA9450_LDO2CTRL, 0xC0); >> >> - /* lock the PMIC regs */ >> - pmic_reg_write(dev, BD718XX_REGLOCK, 0x11); >> + /* set WDOG_B_CFG to cold reset */ >> + pmic_reg_write(dev, PCA9450_RESET_CTRL, 0xA1); >> >> return 0; >> } >> diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig >> index e22b7de56f..ae9e0626dd 100644 >> --- a/configs/imx8mm_evk_defconfig >> +++ b/configs/imx8mm_evk_defconfig >> @@ -83,7 +83,7 @@ CONFIG_PINCTRL=y >> CONFIG_SPL_PINCTRL=y >> CONFIG_PINCTRL_IMX8M=y >> CONFIG_DM_PMIC=y >> -CONFIG_SPL_DM_PMIC_BD71837=y >> +CONFIG_SPL_DM_PMIC_PCA9450=y >> CONFIG_DM_REGULATOR=y >> CONFIG_DM_REGULATOR_FIXED=y >> CONFIG_DM_REGULATOR_GPIO=y >> -- >> 2.30.0 > > -- andrey >
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. 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
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
diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi b/arch/arm/dts/imx8mm-evk-u-boot.dtsi index e843a5648e..7f48912b49 100644 --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi @@ -114,11 +114,11 @@ u-boot,dm-spl; }; -&{/soc@0/bus@30800000/i2c@30a20000/pmic@4b} { +&{/soc@0/bus@30800000/i2c@30a20000/pca9450@25} { u-boot,dm-spl; }; -&{/soc@0/bus@30800000/i2c@30a20000/pmic@4b/regulators} { +&{/soc@0/bus@30800000/i2c@30a20000/pca9450@25/regulators} { u-boot,dm-spl; }; diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi index 6518f088b2..60179e006d 100644 --- a/arch/arm/dts/imx8mm-evk.dtsi +++ b/arch/arm/dts/imx8mm-evk.dtsi @@ -126,115 +126,120 @@ pinctrl-0 = <&pinctrl_i2c1>; status = "okay"; - pmic@4b { - compatible = "rohm,bd71847"; - reg = <0x4b>; - pinctrl-names = "default"; + pmic: pca9450@25 { + reg = <0x25>; + compatible = "nxp,pca9450a"; + /* PMIC PCA9450 PMIC_nINT GPIO1_IO3 */ pinctrl-0 = <&pinctrl_pmic>; - interrupt-parent = <&gpio1>; - interrupts = <3 IRQ_TYPE_LEVEL_LOW>; - rohm,reset-snvs-powered; - - #clock-cells = <0>; - clocks = <&osc_32k 0>; - clock-output-names = "clk-32k-out"; + gpio_intr = <&gpio1 3 GPIO_ACTIVE_LOW>; regulators { - buck1_reg: BUCK1 { - regulator-name = "buck1"; - regulator-min-microvolt = <700000>; - regulator-max-microvolt = <1300000>; + #address-cells = <1>; + #size-cells = <0>; + + pca9450,pmic-buck2-uses-i2c-dvs; + /* Run/Standby voltage */ + pca9450,pmic-buck2-dvs-voltage = <950000>, <850000>; + + buck1_reg: regulator@0 { + reg = <0>; + regulator-compatible = "buck1"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <2187500>; regulator-boot-on; regulator-always-on; - regulator-ramp-delay = <1250>; + regulator-ramp-delay = <3125>; }; - buck2_reg: BUCK2 { - regulator-name = "buck2"; - regulator-min-microvolt = <700000>; - regulator-max-microvolt = <1300000>; + buck2_reg: regulator@1 { + reg = <1>; + regulator-compatible = "buck2"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <2187500>; regulator-boot-on; regulator-always-on; - regulator-ramp-delay = <1250>; - rohm,dvs-run-voltage = <1000000>; - rohm,dvs-idle-voltage = <900000>; + regulator-ramp-delay = <3125>; }; - buck3_reg: BUCK3 { - // BUCK5 in datasheet - regulator-name = "buck3"; - regulator-min-microvolt = <700000>; - regulator-max-microvolt = <1350000>; + buck3_reg: regulator@2 { + reg = <2>; + regulator-compatible = "buck3"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <2187500>; regulator-boot-on; regulator-always-on; }; - buck4_reg: BUCK4 { - // BUCK6 in datasheet - regulator-name = "buck4"; - regulator-min-microvolt = <3000000>; - regulator-max-microvolt = <3300000>; + buck4_reg: regulator@3 { + reg = <3>; + regulator-compatible = "buck4"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <3400000>; regulator-boot-on; regulator-always-on; }; - buck5_reg: BUCK5 { - // BUCK7 in datasheet - regulator-name = "buck5"; - regulator-min-microvolt = <1605000>; - regulator-max-microvolt = <1995000>; + buck5_reg: regulator@4 { + reg = <4>; + regulator-compatible = "buck5"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <3400000>; regulator-boot-on; regulator-always-on; }; - buck6_reg: BUCK6 { - // BUCK8 in datasheet - regulator-name = "buck6"; - regulator-min-microvolt = <800000>; - regulator-max-microvolt = <1400000>; + buck6_reg: regulator@5 { + reg = <5>; + regulator-compatible = "buck6"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <3400000>; regulator-boot-on; regulator-always-on; }; - ldo1_reg: LDO1 { - regulator-name = "ldo1"; + ldo1_reg: regulator@6 { + reg = <6>; + regulator-compatible = "ldo1"; regulator-min-microvolt = <1600000>; regulator-max-microvolt = <3300000>; regulator-boot-on; regulator-always-on; }; - ldo2_reg: LDO2 { - regulator-name = "ldo2"; + ldo2_reg: regulator@7 { + reg = <7>; + regulator-compatible = "ldo2"; regulator-min-microvolt = <800000>; - regulator-max-microvolt = <900000>; + regulator-max-microvolt = <1150000>; regulator-boot-on; regulator-always-on; }; - ldo3_reg: LDO3 { - regulator-name = "ldo3"; - regulator-min-microvolt = <1800000>; + ldo3_reg: regulator@8 { + reg = <8>; + regulator-compatible = "ldo3"; + regulator-min-microvolt = <800000>; regulator-max-microvolt = <3300000>; regulator-boot-on; regulator-always-on; }; - ldo4_reg: LDO4 { - regulator-name = "ldo4"; - regulator-min-microvolt = <900000>; - regulator-max-microvolt = <1800000>; + ldo4_reg: regulator@9 { + reg = <9>; + regulator-compatible = "ldo4"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <3300000>; regulator-boot-on; regulator-always-on; }; - ldo6_reg: LDO6 { - regulator-name = "ldo6"; - regulator-min-microvolt = <900000>; - regulator-max-microvolt = <1800000>; - regulator-boot-on; - regulator-always-on; + ldo5_reg: regulator@10 { + reg = <10>; + regulator-compatible = "ldo5"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; }; + }; }; }; diff --git a/board/freescale/imx8mm_evk/spl.c b/board/freescale/imx8mm_evk/spl.c index 64bc60651d..4ef7f6f180 100644 --- a/board/freescale/imx8mm_evk/spl.c +++ b/board/freescale/imx8mm_evk/spl.c @@ -26,7 +26,7 @@ #include <dm/device-internal.h> #include <power/pmic.h> -#include <power/bd71837.h> +#include <power/pca9450.h> DECLARE_GLOBAL_DATA_PTR; @@ -94,7 +94,7 @@ static int power_init_board(void) struct udevice *dev; int ret; - ret = pmic_get("pmic@4b", &dev); + ret = pmic_get("pca9450@25", &dev); if (ret == -ENODEV) { puts("No pmic\n"); return 0; @@ -102,25 +102,26 @@ static int power_init_board(void) if (ret != 0) return ret; - /* decrease RESET key long push time from the default 10s to 10ms */ - pmic_reg_write(dev, BD718XX_PWRONCONFIG1, 0x0); + /* BUCKxOUT_DVS0/1 control BUCK123 output */ + pmic_reg_write(dev, PCA9450_BUCK123_DVS, 0x29); - /* unlock the PMIC regs */ - pmic_reg_write(dev, BD718XX_REGLOCK, 0x1); + /* Buck 1 DVS control through PMIC_STBY_REQ */ + pmic_reg_write(dev, PCA9450_BUCK1CTRL, 0x59); - /* increase VDD_SOC to typical value 0.85v before first DRAM access */ - pmic_reg_write(dev, BD718XX_BUCK1_VOLT_RUN, 0x0f); + /* Set DVS1 to 0.8v for suspend */ + pmic_reg_write(dev, PCA9450_BUCK1OUT_DVS1, 0x10); - /* increase VDD_DRAM to 0.975v for 3Ghz DDR */ - pmic_reg_write(dev, BD718XX_1ST_NODVS_BUCK_VOLT, 0x83); + /* increase VDD_DRAM to 0.95v for 3Ghz DDR */ + pmic_reg_write(dev, PCA9450_BUCK3OUT_DVS0, 0x1C); -#ifndef CONFIG_IMX8M_LPDDR4 - /* increase NVCC_DRAM_1V2 to 1.2v for DDR4 */ - pmic_reg_write(dev, BD718XX_4TH_NODVS_BUCK_VOLT, 0x28); -#endif + /* VDD_DRAM needs off in suspend, set B1_ENMODE=10 (ON by PMIC_ON_REQ = H && PMIC_STBY_REQ = L) */ + pmic_reg_write(dev, PCA9450_BUCK3CTRL, 0x4a); + + /* set VDD_SNVS_0V8 from default 0.85V */ + pmic_reg_write(dev, PCA9450_LDO2CTRL, 0xC0); - /* lock the PMIC regs */ - pmic_reg_write(dev, BD718XX_REGLOCK, 0x11); + /* set WDOG_B_CFG to cold reset */ + pmic_reg_write(dev, PCA9450_RESET_CTRL, 0xA1); return 0; } diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig index e22b7de56f..ae9e0626dd 100644 --- a/configs/imx8mm_evk_defconfig +++ b/configs/imx8mm_evk_defconfig @@ -83,7 +83,7 @@ CONFIG_PINCTRL=y CONFIG_SPL_PINCTRL=y CONFIG_PINCTRL_IMX8M=y CONFIG_DM_PMIC=y -CONFIG_SPL_DM_PMIC_BD71837=y +CONFIG_SPL_DM_PMIC_PCA9450=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y