Hi Andreas, thanks a lot for your detailed write-up. Indeed these register settings are confusing. > What concerns me more is the CPU core clock reduction: > // CCM_ANALOG_PLL_ARM0 : PLL setup => PLL locked, PLL on, > // bypass off, 396MHz > // reset default: 0x00013042 => PLL not locked, PLL off, bypass on, > // bypass 24MHz osc as src, pll divider > // for 792MHz > // 0x80002021 => PLL locked, PLL on, bypass off, pll divider for > // 396MHz ; Attn.: PLL locked is w/o ; divider for > // 396MHz is below valid range > wm 32 0x020c8000 0x80002021 > Comments again added by me. > > Two things here look questionable to me: > 1.) Datasheet says valid divider values are 54-108, so the > default 0x42=66 is in range, whereas the 0x21=33 is not. > 2.) Even if the divider value is legit, the change flow might be not. > A PLL normally takes some time to lock. We have tracked down the origin of this DCD entry internally. It originated from a PMIC workaround for the phyFLEX-i.MX6 in an older barebox version which isn't mainline. It had a comment attached to it, but that was dropped while bringing the phyFLEX-i.MX6 mainline. We will take a closer look to that issue next week, whether the fix is still needed or can be resolved differently. Mit freundlichen Grüßen / Kind regards, Stefan Christ On Fri, Feb 19, 2016 at 08:28:25PM +0100, Andreas Pretzsch wrote: > While looking into a maybe boarderline RAM setup on one specific piece > of hardware, I took a closer look at the i.MX6 DDR setup of the Phytec > i.MX6 modules in barebox. > And came across two things that look ... somewhat questionable, maybe > worth a look. > > In the very first setup (the DCD) in > arch/arm/boards/phytec-som-imx6/flash-header-phytec-pfla02.h > there is a block > wm 32 0x020e0010 0xf00000ff > wm 32 0x020e0018 0x007F007F > wm 32 0x020e001c 0x007F007F > wm 32 0x020c8000 0x80002021 > at the end. > > > The first three (comments about complete register meanings added by me) > // IOMUX_GPR4 : VDOA, PCIe, VPU, IPU cache setup ; stop acknowledge > wm 32 0x020e0010 0xf00000ff > // IOMUX_GPR6 : IPU1 QoS setup > wm 32 0x020e0018 0x007F007F > // IOMUX_GPR7 : IPU2 QoS setup > wm 32 0x020e001c 0x007F007F > do setup some cache attributes of VDOA, IPU, VPU (some of the video > cores) and IPU QoS. Beside accessing two reserved bits in GPR4, they > maybe do not harm, and can be found also in various other board files. > Might be some case of copy-from-copy, no idea. > Not sure if these really should be part of lowest-level memory setup... > Maybe - if at all - in some board-specific setup, given barebox drives a > display. > Also, a quick google search shows the possible origin, and that it has > been removed in some U-Boot branch, leaving it to the Linux kernel: > https://github.com/linksprite/u-boot-acadia1.0-beta/blob/master/u-boot-acadia1.0-beta/patches/0546-ENGR00215515-MX6-Move-IPU-QoS-and-VDOA-IPU-VPU-AXI-C.patch > So maybe more of a cleanup issue. > Not only in the Phytec DCDs, but maybe also the other ones. > > > What concerns me more is the CPU core clock reduction: > // CCM_ANALOG_PLL_ARM0 : PLL setup => PLL locked, PLL on, > // bypass off, 396MHz > // reset default: 0x00013042 => PLL not locked, PLL off, bypass on, > // bypass 24MHz osc as src, pll divider > // for 792MHz > // 0x80002021 => PLL locked, PLL on, bypass off, pll divider for > // 396MHz ; Attn.: PLL locked is w/o ; divider for > // 396MHz is below valid range > wm 32 0x020c8000 0x80002021 > Comments again added by me. > > Two things here look questionable to me: > 1.) Datasheet says valid divider values are 54-108, so the > default 0x42=66 is in range, whereas the 0x21=33 is not. > 2.) Even if the divider value is legit, the change flow might be not. > A PLL normally takes some time to lock. > > Now, I have not looked yet at the PLL setup and/or scaling code of the > kernel, both wrt PLL change flow as well as dividers. So this might be > ok, and even if only implicitly (like due to some implicit delay after > DCD got parsed). > And obviously it works. "Only" misses a comment whats it does. And only > present in some of the Phytec DCDs, as far as I can see. > > But what I like to understand is why ? > I mean, scaling down the i.MX6 to its minimum frequency (half of > default) in the bootloader, to get a maximum stable state, ok. Even if > it extends the bootup time. > > But why after all the IOMUX, MMDC and DDR setup is through ? > Probably too late if it is about some PMIC-reset-voltage-scaling issue. > Or some thermal precaution ? > > By the way, the above setups goes back through long history, as in > a540c30 boards: Add phytec-som-imx6 > c5b4f09 ARM:phyFLEX-iMX6 New Ram Timings for Q/DL > 30f29e3 ARM: Add Phytec phyFLEX-i.MX6 board support > and applies to other Phytec i.MX6 boards as well, beside the DL ones. > > > Any comments on this, maybe also from Phytec ? > > Best regards, > Andreas Pretzsch > > -- > > carpe noctem engineering > Ingenieurbuero fuer Hard- & Software-Entwicklung Andreas Pretzsch > Dipl.-Ing. (FH) Andreas Pretzsch Tel. +49-(0)7307-936088-1 > Lange Strasse 28a Fax: +49-(0)7307-936088-9 > 89250 Senden, Germany email: apr@xxxxxxxxx > _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
