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

Tim Harvey tharvey at gateworks.com
Tue Feb 24 16:56:44 CET 2015


On Fri, Feb 13, 2015 at 12:16 AM, Robin Gong <b38343 at freescale.com> wrote:
> On Wed, Feb 11, 2015 at 07:47:57AM -0800, Tim Harvey 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.
>>
> pinmux is not enough. WDT bit of WDOGx_WCR need to be taken care of if you want
> to enable WDOG_B pin reset function. But unfortunately the current wdog driver
> of kernel not touch this write-once bit. To limit the impact from kernel, set
> this bit in u-boot.

Hi Robin,

'To limit the impact from kernel, set this bit in u-boot' indicates
that you are trying to create a u-boot and kernel dependence on each
other which is a bad idea. The kernel should take care of everything
it needs without making assumptions on what the bootloader did.

You are correct in that the current imx2_wdt.c does not 'set' the
write-once WCR bit to enable the external reset but it does seem funny
to me that Freescale decided to patch system.c's mxc_restart
(http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/arch/arm/mach-imx/system.c?h=imx_3.10.53_1.1.0_ga&id=ee07b144e1adff13d262e7f353f5804e3c2d3e06)
to try to deal with the machine_restart case but did not patch
imx2_wdt.c to deal with the watchdog timeout case.

Wouldn't these boards also hang when reset from a watchdog timeout
when using ldo-enabled and CPU at 397Mhz. It seems to me that you should
also be patching imx2_wdt.c to set WCR for that case.

>> 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.
>>
> As you saw in another mail, bootloader is too late. It'll hang in ROM code.
>>
<snip>
>>
> Can you please share me the patch link? Thanks.

The link was further up in the thread in response to Peng:

Instead of touching U-Boot, in my 'Freescale' kernel I look for the
fsl,ldo-bypass node in the kernel init and enable it just like their
bootloader would have:

https://github.com/Gateworks/linux-imx6/commit/a1af6ac6f00b4da7c8a5656e8ff093d4ab5cadee

It is still not good to rely on the fsl,ldo-bypass property to be set
(which will never make it into mainline) because this does not
garuntee that ldo-bypass is setup and functioning correctly at all (ie
user could have PMIC driver disabled, or not configured in device-tree
properly as source for arm/soc rails) but I haven't figured out the
best solution upstream yet and haven't had time to get back to it. Its
still a much lesser evil than requiring that ldo-bypass be configured
in the bootloader. This patch removes the dependence upon the
bootloader (I will never use Freescales hacked up U-Boot - I think its
still based on a 2009 branch).

I have given up on getting patches into Freescale's kernel - perhaps
being an employee you will have better luck :) I'm still hoping that
someday mainline linux will have all the IPU/VPU/GPU support for IMX6
that is missing (but getting very close!) which is what is forcing me
to use Freescale's kernel for some of our BSP's.

Tim


More information about the U-Boot mailing list