[meta-freescale] Operating points mismatch on imx6sx SabreSD DTS?

Mauro Salvini mauro.salvini at smigroup.net
Thu Jan 19 00:52:33 PST 2017


Hi,
I'm here again about this issue: investigating further on it, I found
that into NXP u-boot and kernel trees LDO bypass is managed.

In these trees, u-boot actually puts LDOs into bypass mode (reading
"fsl,ldo-bypass" property from board dts), so Linux properly works on
PFuze usign dts operating points with LDOs bypassed. But this introduces
a (ugly) dependency between u-boot and Linux.

In Freescale community trees, u-boot does not integrate code to bypass
LDO (because mainline u-boot does not include the above dependency, see
[1] discussion), so the resulting situation is that Linux uses operating
points into dts like the NXP one, but actually LDOs are not bypassed by
u-boot (rather they are set to a fixed voltage as said), resulting into
a chip working out-of-specs.

In message [2] from above mentioned discussion Tim Harvey said that some
work was made into Gateworks kernel tree (on Linux 3.10) to fix the
dependency in the right way (furthermore seems to me that this fix lacks
support for CPUs with 1.2GHz clock when run at 1.2GHz, that needs LDOs
enabled also when there is an external regulator).
In message [3] that some work was starting to upstream the fix, but I
haven't found nothing about this into Linux git trees 
Is there a fix somewhere or it has never been upstreamed?

Thanks again, regards
Mauro

[1] http://lists.denx.de/pipermail/u-boot/2015-February/204513.html
[2] http://lists.denx.de/pipermail/u-boot/2015-February/204542.html
[3] http://lists.denx.de/pipermail/u-boot/2015-February/204544.html


On Fri, 2016-12-16 at 10:52 +0100, Mauro Salvini wrote:
> Hi,
> I'm using krogoth branch of meta-fsl-arm and I'm doing some
> modifications on imx6sx-sdb.dts to tailor it on my custom board based on
> SabreSD rev. B.
> I'm facing with a thing that seems a mismatch between u-boot and linux
> domains, I try to explain it.
> 
> On cpu0 section of imx6sx.dtsi file I can find these operating points:
> 
> operating-points = <
>    /* kHz uV */
>    996000 1250000
>    792000 1175000
>    396000 1075000
>    198000 975000
> >;
> fsl,soc-operating-points = <
>    /* ARM kHz SOC uV */
>    996000 1175000
>    792000 1175000
>    396000 1175000
>    198000 1175000
> >;
> 
> arm-supply = <&reg_arm>;
> soc-supply = <&reg_soc>;
> 
> These settings seems to come from table 10 in IMX6SXCEC.pdf, the imx6sx
> datasheet.
> 
> In imx6sx-sdb.dts file these settings are overwritten with these ones:
>  
> operating-points = <
>    /* kHz uV */
>     996000 1250000
>     792000 1175000
>     396000 1175000
>     198000 1175000
> >;
> fsl,soc-operating-points = <
>    /* ARM kHz SOC uV */
>     996000 1250000
>     792000 1175000
>     396000 1175000
>     198000 1175000
> >;
> arm-supply = <&sw1a_reg>;
> soc-supply = <&sw1a_reg>;
> fsl,arm-soc-shared = <1>;
> 
> to use sw1a_reg (SW1AB regulator into PFuze200 that is on SabreSD
> board). Furthermore, enables "fsl,ldo-bypass" property to bypass
> internal LDOs as we have a pfuze.
> 
> These values seems derived from above mentioned table 10 from datasheet,
> LDO-disabled section: I can understand that the two tables have same
> values because PFuze power source is shared between ARM domain and SOC
> domain, and values are the best trade-off to both SOC_IN and ARM_IN
> rails.
> 
> But here the mismatch: ARM and SOC LDOs are programmed to 1.150V and
> 1.175V respectively (I read 0x020c8140 register that has 0x004c0012
> value, see PMU_REG_CORE into imx6sx reference manual; 1.175V set by
> u-boot), so operating points into imx6sx-sdb.dts does not respect
> assertion into LDO enabled section from datasheet: 
> 
> "VDDARM_IN must be 125mV higher than the LDO Output Set Point
> (VDD_ARM_CAP) for correct supply voltage regulation."
> 
> I read source code to get an answer, and I found these items:
> - u-boot sets SOC LDO only to 1.175V (board_postclk_init() call into
> arch/arm/cpu/armv7/mx6/soc.c)
> - linux has this comment into arch/arm/mach-imx/gpc.c, when
> "fsl,ldo-bypass" property was read:
> /* We only bypass pu since arm and soc has been set in u-boot */
> in facts, this piece of code bypasses only "pu" regulator (anyway not
> present on sabresd), leaving ARM and SOC LDOs untouched
> - in imx6sx-sdb-ldo.dts (that disables LDO-bypass and re-enables
> internal LDOs), original operating point and regulators are set, and set
> to 0 "fsl,ldo-bypass", with comment "use ldo-enable, u-boot will check
> it and configure"
> 
> It seems that kernel expects that u-boot reads from dtb to find if
> internal LDOs must be bypassed or not, but this never happens, instead
> u-boot sets SOC LDO to 1.175V and leave ARM LDO untouched (1.150V), so
> when linux starts and uses operating points on pfuze it works with
> out-of-specs voltages-frequencies applied on ARM and SOC LDOs due to
> settings done by u-boot.
> 
> Or simply I have miss some point?
> 
> Sorry if it is not the right point to post this, but since meta-fsl-arm
> layer brings up u-boot and linux into an image, I think it could be the
> right one.
> 
> Thanks in advance, regards
> Mauro



More information about the meta-freescale mailing list