[U-Boot] [PATCH 07/12] imx:mx6 Support LDO bypass

Tim Harvey tharvey at gateworks.com
Fri Feb 13 01:08:51 CET 2015


On Wed, Feb 11, 2015 at 7:47 AM, Tim Harvey <tharvey at gateworks.com> wrote:
> On Wed, Feb 11, 2015 at 2:49 AM, Robin Gong <b38343 at freescale.com> wrote:
> <snip>
>>>
>>> This is very board dependent. Here you are referring to a board that
>>> has a reset input to the PMIC's from the IMX6's watchdog output. In
>>> this case, this reset routing/pinmux would be needed regardless of
>>> using ldo-bypass mode or not and that should just be a pinmux of the
>>> pin your using for WDOG_B.
>>>
>> There are two types of reboot in our chip by watchdog : SRS/warm reset
>> (Software Reset Signal) and WDOG_B(reset signal output to external pmic
>> to trigger next power cycle). In fact, warm reset can work most cases except
>> ldo-bypass mode and this is why we connect WDOG_B reset and ldo-bypass here:
>> kernel may trigger warm reset at the lowest cpu freq setpoint, for example
>> VDDARM 0.975v at 396Mhz ldo-bypass mode. i.mx6q will reboot with ldo-enable mode
>> @792Mhz and the VDDARM_IN 0.975v can't support system boot.Thus, we need use
>> WDOG_B pin to reset external pmic if using ldo-byapss mode.
>
> Hi Robin,
>
> I understand that configuring WDOG_B external reset must be used when
> LDO bypass is used. This should be done in the kernel but you can also
> set this pinmux up in uboot in the board-specific init.
>
> If your kernel is providing the PMIC driver and cpufreq driver that
> alter the cpu core frequencies it must also be configuring pinmux so
> that WDOG_B gets routed to the pin that connects to the PMIC so any
> reset based on that wdog (SRS or timeout) issues a hard reset to the
> PMIC. Failure to do so is a kernel bug. I believe this is done
> properly in the Freescale kernel for the reference boards.
>
> If you are trying to take care of an issue caused by a watchdog reset
> (SRS or timeout) not properly resetting a PMIC (ie perhaps a PCB
> errata where signal doesn't go to the PMIC) then you should probably
> simply set the PMIC rails where they need to be for the 800MHz
> operation in the bootloader and not muck with the CPU frequency.
> Honestly, if your PMIC rails are too low for 800MHz on powerup your
> bootloader may not be stable anyway right? Note that the operating
> setpoints have the same SOC voltage for both 792MHz and 396MHz, its
> only the ARM voltage that is lower for 396 vs 792 and chances are your
> not going to have an issue just in the bootloader at that point.
>

Robin,

The issue your describing was interesting to me and I ran some tests
and found that on a board with no reset to the PMIC, an IMX6Q CPU,
ldo-bypass enabled, and the CPU freq set to 400MHz (such that VDD_ARM
rail set to 0.960V for 400MHz operation) the chip does not even come
out of reset (ie when SRS is set in the watchdog controller). So I
don't really see any ability to work around this in bootloader
software since you won't get there in this case.

Possible solutions I can think of for boards without a PMIC reset is
to either blow the eFUSE so the chip comes up in 400MHz or in the
kernel never allow the VDD_ARM or VDD_SOC rail to go below where they
need to be for CPU startup (the only one that does is VDD_ARM) or
before soft-reboot make sure the cpufreq is at 800MHz or above (which
must be done at higher levels before single-cpu mode in
machine_restart). This also does not deal with the case of a watchdog
reset and/or a crash handler.

Are you findings different?

Tim


More information about the U-Boot mailing list