Hi, On Mon, Nov 16, 2015 at 4:50 AM, Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote: > On Sat, 14 Nov 2015 04:36:16 +0800 > Vishnu Patekar <vishnupatekar0...@gmail.com> wrote: > >> Hello, >> >> On Fri, Nov 13, 2015 at 7:52 PM, Siarhei Siamashka < >> siarhei.siamas...@gmail.com> wrote: >> >> > On Fri, 13 Nov 2015 11:06:01 +0200 >> > Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote: >> > >> > > On Fri, 13 Nov 2015 01:12:43 +0800 >> > > Vishnu Patekar <vishnupatekar0...@gmail.com> wrote: >> > > >> > > > Hello, >> > > > >> > > > On Thu, Nov 12, 2015 at 7:03 PM, Julian Calaby < >> > julian.cal...@gmail.com> >> > > > wrote: >> > > > >> > > > > Hi Stefan, >> > > > > >> > > > > On Thu, Nov 12, 2015 at 12:20 AM, Stefan Monnier >> > > > > <monn...@iro.umontreal.ca> wrote: >> > > > > >> When the CPU clock speed is set to 480 MHz by the U-Boot SPL, >> > > > > > ^^^ >> > > > > > You mean MBUS? >> > > > > > >> > > > > >> the performance improvement for 'sunxi-fel write' transfers >> > > > > >> to DRAM is ~95 KB/s -> ~510 KB/s. >> > > > > > >> > > > > >> When the CPU clock speed is set to 1008 MHz by the U-Boot SPL, >> > > > > >> the performance improvement for 'sunxi-fel write' transfers >> > > > > >> to DRAM is ~180 KB/s -> ~510 KB/s. >> > > > > > >> > > > > > I don't understand the relation between the above 2 improvements. >> > > > > > What change causes the speed to go from 95KB/s to 180KB/s? >> > > > > >> > > > > My interpretation of this was that before this change, the transfer >> > > > > speed was somehow limited by the clock speed. With the MMU enabled, >> > it >> > > > > appears that the clock speed is no-longer the limiting factor. >> > > > > >> > > > > (I'm _guessing_ that the transfer has to bounce through the CPU and >> > > > > this was slow without the MMU for some reason. I'm also guessing that >> > > > > enabling the MMU has moved the bottleneck elsewhere - possibly the >> > USB >> > > > > hardware.) >> > > > > >> > > > >> > > > On A83T board, after enabling MMU, sunxi-fel write speed is similar >> > 510KB/s >> > > > (peripheral clock is at 600MHz). >> > > > >> > > > If I increase the PLL6(peripheral clock), performance is improving. >> > > > >> > > > after changing the PLL6 to 1200MHz, transfer speed to DDR3 is : 920.2 >> > KB/s >> > > > >> > > > Though, it is mentioned in datasheet that it's value should be 600. >> > > > However, allwinner u-boot code make it to 1200MHz. >> > > >> > > Thanks! That's an interesting discovery. Basically, by tweaking the >> > > PLL6 clock frequency you bring the FEL transfer speed to the A20 level: >> > > >> > > https://linux-sunxi.org/FEL/USBBoot#SoC_support_status >> > > >> > > It was always a bit strange why A20 is almost twice faster than >> > > everything else. Especially compared to A10/A13, which are sharing >> > > the same clock setup code with A20: >> > > >> > > >> > https://github.com/u-boot/u-boot/blob/v2015.10/arch/arm/cpu/armv7/sunxi/clock_sun4i.c >> > > >> > > Maybe after doing some experiments, we can pick better USB related >> > > clock settings in U-Boot for all SoC variants :-) >> > > >> > > >> > > Regarding the A83T SoC. The A82T user manual has quite a nice clock >> > > tree diagrams, which show that USB OTG is using the AHB1 BUS. So it's >> > > probably not just the PLL6 clock speed, but more like the AHB1 divisor >> > > that is responsible for the USB FEL transfer speed increase. >> > > >> > > By looking at your recent A83T clock support patches for U-Boot >> > > >> > > https://patchwork.ozlabs.org/patch/543587/ >> > > >> > > we can find >> > > >> > > #define PLL6_CFG_DEFAULT 0x80041800 /* 576 MHz */ >> > > #define AHB1_ABP1_DIV_DEFAULT 0x00002190 >> > > >> > > And AHB1_ABP1_DIV_DEFAULT can be decoded as: >> > > >> > > AHB1_CLK_DIV_RATIO: 01: /2 >> > > AHB1_PRE_DIV: 10: /3 >> > > APB1_CLK_RATIO: 01: /2 >> > > AHB1_CLK_SRC_SEL: 1X: PLL_PERIPH/ AHB1_PRE_DIV. >> > > >> > > Do I understand it correctly that you are currently setting AHB1 >> > > clock speed to 576 /2 /3 = 96 MHz ? >> > > >> > > The "7.2.5.2. SPI Module Clock Source and Frequency" section of the >> > > A83T manual says that "The SPI_SCLK can in the range from 3Khz to 100 >> > > MHZ" and also says that there is a requirement "AHB_CLK >= 2xSPI_SCLK". >> > > Does this effectively mean that we are supposed to clock AHB1 with at >> > > least 200MHz ? >> > >> > I can confirm that doubling the AHB1 clock speed by adjusting divisors >> > on Allwinner H3 can also increase the FEL transfer speed to ~900 KB/s. >> > >> > Now we just need to know what is the safe AHB clock speed limit for >> > all the SoC variants, then increase it in U-Boot and profit? >> > >> > We are still very far from the DFU transfers speeds. But there is >> > one more trick that still can be tried. We can copy the BROM code >> > to DRAM and then use MMU to map this copy to the 0xFFF00000 virtual >> > address, thus substituting the BROM. This code in DRAM can be patched >> > if necessary. Of course, this only makes sense if the patch is really >> > small (for example, just replacing something like a memcpy function >> > with a possibly better implementation). >> > >> >> Yes, I've also verified that xfer speed can go upto ~910KB/s after doubling >> the AHB1 clock. >> below are the results on A83T and A33. >> >> ============A33=================== >> 1. CPU Speed 480MHz, MMU Disbaled speed: 85.3 KB/s >> 2. CPU Speed 480MHz, MMU Enabled speed: 511.7 KB/s >> 3. CPU speed 1003MHz, MMU Disabled speed: 184.5 KB/s >> 4. CPU Speed 1003MHz, MMU enabled speed: 511.9 KB/s >> 5. CPU speed 1003MHz, MMU enabled, >> AHB1 freq doubled speed: 971.7 KB/s >> >> >> ============A83t=================== >> 1. CPU Speed 480MHz, MMU Disbaled : 112.4 KB/s >> 2. CPU Speed 480MHz, MMU Enabled : 510.7 KB/s >> 3. CPU speed 1003MHz, MMU Disabled : 112.6 KB/s >> 4. CPU Speed 1003MHz, MMU enabled : 510.8 KB/s >> 5. CPU speed 1003MHz, MMU enabled, >> AHB1 freq doubled : 907.7 KB/s > > Hello, > > Thanks for running these performance tests. They indeed look very > promising. With such transfer speeds, the FEL boot time becomes > less than 5 seconds for the typical size of the mainline kernel. > > It is very clear that we probably want to have the highest valid AHB > clock speed configured by U-Boot. It does affect FEL transfer speeds > and maybe also could affect the performance of the other hardware > blocks connected to the AHB bus (for example, the crypto accelerator > can be benchmarked too).
On the A10s/A13/A20/A31/A31s we have AHB clocked from PLL6, at 150 MHz. This is done in the dts file. For the A31, this is out of necessity, as the DMA engine has this weird requirement. For the other chips, we wanted the HSTIMER to be stable even if cpufreq changes the cpu speed. On the A23/A33 we haven't done so due to some issues with the clock driver. The default pre-divider is too low, which results in the AHB clock rate going up to 300 MHz and hanging. The safest top speed is around 200 ~ 250 MHz. IIRC one of the older manuals actually has the operating range for the various bus clocks. In any case, I'm for adding these settings to U-boot. Regards ChenYu > But this should be really discussed in the U-Boot mailing list. As > for the sunxi-tools patch in question, I will just amend the commit > messaage to mention that the AHB clock speed becomes the next > bottleneck. > > -- > Best regards, > Siarhei Siamashka > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
