On Fri, Feb 13, 2015 at 12:16 AM, Robin Gong <b38...@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 <b38...@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@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@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
