[U-Boot] [linux-sunxi] Re: [PATCH] sunxi: Fix gmac not working reliable on the Bananapi
Siarhei Siamashka
siarhei.siamashka at gmail.com
Mon Sep 29 23:37:53 CEST 2014
On Mon, 29 Sep 2014 20:16:35 +0200
Karsten Merker <merker at debian.org> wrote:
> On Mon, Sep 29, 2014 at 09:13:37AM +0300, Siarhei Siamashka wrote:
>
> > On Sun, 28 Sep 2014 20:13:21 +0200
> > Hans de Goede <hdegoede at redhat.com> wrote:
> >
> > > In order for the gmac nic to work reliable on the Bananapi, we need to poke
> > > these 2 undocumented bits in the gmac clk register. Since these are
> > > undocumented, this commit only sets these bits on the Bananapi for now.
> > >
> > > I'll contact Allwinner to try and get these bits documented, once they
> > > are documented we can hopefully replace this hack with a better patch.
> >
> > Could you please provide a bit more details in the commit message?
> > What are the symptoms of the problem?
>
> Without the patch, u-boot on the BananaPi shows massive packet loss
> on every network activity. The packet loss is so extreme that it is
> actually impossible to boot a kernel by tftp because u-boot gives up.
> The mainline kernel has (once booted) shown similar problems on the
> BananaPi.
>
> > How did you come to the idea to poke these bits?
>
> The linux 3.4 kernel from https://github.com/LeMaker/linux-bananapi
> (which is a patched linux-sunxi.org 3.4 kernel) does not show this
> problem, so we started looking into what is different there, and the
> relevant change that was found was setting these particular
> undocumented bits.
Thanks for the detailed explanations. They would look really great in
the commit message.
> > Does the GMAC driver in the linux kernel need a similar
> > fix/workaround?
>
> Not as far as I can see - once u-boot has set these two bits during
> system initialization, the mainline kernel works fine without
> any changes.
OK. I just wonder if it is a good idea for the kernel to rely on
these bits being set appropriately by the bootloader. Not that it
has anything to do with u-boot.
> > Also as mentioned in another e-mail
> > http://lists.denx.de/pipermail/u-boot/2014-September/190096.html
> > u-boot configures the "912MHz @1.4V" CPU clock frequency/voltage
> > setup for sun7i hardware. And according to the information from Tony
> > Zhang, this is supposed to be unreliable for the Banana Pi. So what
> > happens to this GMAC bug if you just increase the dcdc2 voltage in
> > u-boot (or reduce the CPU clock frequency)?
>
> I can test that if you could tell me what would have to be changed
> in u-boot to do that.
The dcdc2 voltage is set here (under the CONFIG_AXP209_POWER ifdef):
http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/board.c;h=2179e234e21d67b0fec064de792fca175db90ca5;hb=be9f643ae6aa9044c60fe80e3a2c10be8371c692#l140
Right now it is set to 1400, which means 1.4V (and the voltage can
be changed in 0.025V steps).
The CPU clock frequency for sun7i is set here:
http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/sun7i.h;h=a902b845744707e64fb5a064c6039bc93b0150d9;hb=be9f643ae6aa9044c60fe80e3a2c10be8371c692#l16
Right now it is set to 912MHz
This CPU clock frequency/voltage pair is then just used unmodified by
the mainline kernel (until we get proper cpufreq support later). So it
makes a lot of sense to be sure that it is sufficiently reliable on
every Allwinner A20 device. You can try to increase the dcdc2 voltage
or reduce the CPU clock frequency and check if the Banana Pi reliability
problems disappear.
By the way, the dcdc2 voltage is already set to the maximum, which is
specified in the datasheet. You can have a look at VDD-CPU limits in
https://github.com/allwinner-zh/documents/blob/master/A20/A20%20Datasheet%20V1.4%2020131230.pdf
And VDD-CPU is provided from dcdc2, as can be seen, for example, in the
A20-OLINUXINO-MICRO schematics (the Banana Pi does not seem to have its
schematics document in public access, but all A20 devices have it
designed in the same way):
https://github.com/OLIMEX/OLINUXINO/blob/master/HARDWARE/A10-OLinuXino-MICRO/A20-OLINUXINO-MICRO_4GB_Rev_F1.pdf
--
Best regards,
Siarhei Siamashka
More information about the U-Boot
mailing list