Project

General

Profile

Bug #2945

[uboot4extlinux-a20-olinuxino-lime2]: does not support newer 'MICREL' wired ethernet LAN chips

infinite_recursion - about 1 month ago - . Updated 20 days ago.

Status:
info needed
Priority:
bug
Assignee:
% Done:

0%


Description

Current revisions of olinuxino lime2 have different ethernet PHYs compared to the earlier ones as shown at link below

https://linux-sunxi.org/Olimex_A20-OLinuXino-Lime2

Due to this, lan port does not work. Guided by

https://regrow.earth/openbsd-on-olinuxino-lime2/

and top link, making changes of following to configs/A20-OLinuXino-Lime2_defconfig work

-CONFIG_PHY_REALTEK=y
+CONFIG_PHY_MICREL=y
+CONFIG_PHY_MICREL_KSZ9031=y
+CONFIG_GMAC_TX_DELAY=4

History

#1

Updated by infinite_recursion about 1 month ago

Meanwhile, people can use u-boot (2020.10) at

https://notabug.org/sagaracharya/parabola_openrc_olinuxino_lime2

if they want to.

#2

Updated by bill-auger about 1 month ago

what is the bug, as it relates to parabola?
which package would it be in - the kernel?
or is this related to the wiki documentation?

#3

Updated by bill-auger about 1 month ago

  • Assignee set to GNUtoo
#4

Updated by bill-auger about 1 month ago

GNUtoo -
could you look into this?

#5

Updated by infinite_recursion about 1 month ago

bill-auger wrote:

what is the bug, as it relates to parabola?

It's in 2 packages: uboot4extlinux-a20-olinuxino-lime2 and uboot4extlinux-a20-olinuxino-lime2-emmc.

Lime2 had REALTEK chip earlier versions and now (latest revision) it has the one with MICREL (details in the link above), and the uboot config files haven't been updated. I checked even the latest 2021.01rc3, same thing there. No updates in config.

which package would it be in - the kernel?

I don't think so. I can't suggest as I don't know details about this. But I face issues in lan (doesn't work at all) in the current parabola package for sure.

or is this related to the wiki documentation?

Nope.

+CONFIG_GMAC_TX_DELAY=4

uboot with above config isn't working for me (the one in my repo). I'm facing lags in connection. I recommend assignee to follow Unicorn all the way and not go for above config. Now trying
+CONFIG_GMAC_TX_DELAY=3
#6

Updated by bill-auger about 1 month ago

  • Assignee deleted (GNUtoo)
  • Status changed from unconfirmed to not-a-bug
#7

Updated by infinite_recursion about 1 month ago

It's a bug. If you read and try what I've said, you'll solve it.

CONFIG_GMAC_TX_DELAY=3

works correctly. No one can explain it better than how I've explained it above yet you want to close it.

#8

Updated by bill-auger about 1 month ago

ok, i must have missed where you named the package - i thought the issue was going stale - i probably could not try anything; because i do not have a lime2 - probably someone who has a lime2 would need to confirm and fix this

#9

Updated by bill-auger about 1 month ago

  • Status changed from not-a-bug to info needed
#10

Updated by bill-auger about 1 month ago

  • Status changed from info needed to unconfirmed
#11

Updated by bill-auger about 1 month ago

  • Assignee set to GNUtoo
#12

Updated by GNUtoo about 1 month ago

Hi,

While there is indeed an issue in u-boot, in what context do you experience that issue:
  • Are you trying to do something like tftp boot in u-boot?
  • Or does that issue also affect the kenrel?

According to Olimex_A20-OLinuXino-Lime2 wiki page on linux-sunxi it is fixed since Linux 5.1.

Since we have 5.8 that should be fixed.

For making Ethernet work again in u-boot itself, the ideal way would be to upstream a fix and backport that fix in Parabola.

I'll try to find the time to look at it in more details.

Adding new PHYs should not be an issue as they are detected through their IDs anyway.

#13

Updated by GNUtoo about 1 month ago

  • Status changed from unconfirmed to info needed

I've the RTL8211E:

# readlink /sys/class/net/eth0/phydev/driver
[sys]/bus/mdio_bus/drivers/RTL8211E Gigabit Ethernet

#14

Updated by GNUtoo about 1 month ago

If I recall well, in at least one of the MII standards, one of the trace has to be longer, which is counter intuitive.

As a result most hardware manufacturers do the mistake of matching the traces length.

The linux-sunxi wiki page has:

A workaround (or proper fix?) for rev. F and newer (and maybe rev. A-E as well?) is to build with trace length compensation.

The upstream config already has CONFIG_GMAC_TX_DELAY=4 for that.

In contrast Linux seems to workaround that in the PHY (too?) as suggested here:

I wonder if it should be done in the GMAC instead as it would work for all phys.

#15

Updated by infinite_recursion about 1 month ago

While there is indeed an issue in u-boot, in what context do you experience that issue:
  • Are you trying to do something like tftp boot in u-boot?
  • Or does that issue also affect the kenrel?

I don't tamper at all with kernel and bootloaders. I've learnt that the hard way. In future I intend to build my own kernels though.

For making Ethernet work again in u-boot itself, the ideal way would be to upstream a fix and backport that fix in Parabola.

I assume that means ask u-boot guys to change OLinuXino configs? Yes, I too think that's long term better solution.

I tried TX_DELAY=4. It failed horribly for me. There was delay between when I type my command and when I finally received network on Lime2. I'm currently using the u-boot with TX_DELAY=3 and it is working very well.

#16

Updated by bill-auger about 1 month ago

  • Subject changed from uboot4extlinux-a20-olinuxino-lime2 does not support lan to [uboot4extlinux-a20-olinuxino-lime2]: does not support newer 'MICREL' wired ethernet LAN chips
#17

Updated by GNUtoo about 1 month ago

I tried TX_DELAY=4. It failed horribly for me. There was delay between when I type my command and when I finally received network on Lime2. I'm currently using the u-boot with TX_DELAY=3 and it is working very well.

Which kernel version do you use exactly?
What is the latest version you tried?

If it affects the kernel (as you seem to imply) then it should probably be fixed in the kernel instead: here what might happen is that either the bootloader configures the hardware with that delay, then the hardware is already configured with that delay somehow which makes the kernel work, or it does something else that also sticks and makes the kernel work.

I wonder if we could add TX_DELAY=3 in the kernel instead by configuring the Ethernet controller in a way that is not too much intrusive and long to upstream.

Denis.

#18

Updated by GNUtoo about 1 month ago

I Linux we have:

drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c:      { .compatible = "allwinner,sun7i-a20-gmac" },

And in board/sunxi/gmac.c in u-boot:

void eth_init_board(void)
{
    [...]
#ifdef CONFIG_RGMII
    [...]
    setbits_le32(&ccm->gmac_clk_cfg,
                 CCM_GMAC_CTRL_TX_CLK_DELAY(CONFIG_GMAC_TX_DELAY));
#else
    [...]
#endif
    [...]
}

So maybe we need to port that in the Linux driver above somehow.

#19

Updated by infinite_recursion about 1 month ago

Which kernel version do you use exactly?
What is the latest version you tried?

I use 5.4.69-gnu-1-lts on lime2

If it affects the kernel (as you seem to imply) then it should probably be fixed in the kernel instead: here what might happen is that either the bootloader configures the hardware with that delay, then the hardware is already configured with that delay somehow which makes the kernel work, or it does something else that also sticks and makes the kernel work.

I'm not implying anything. I have no opinion on kernel. You're on your own here. I'm just showing my experience and what solved the problem for me.

But the linux stmmac/dwmac-sunxi.c would be for multiple boards right, not just for lime2. In that case, other boards will show problems.

#20

Updated by GNUtoo about 1 month ago

I use 5.4.69-gnu-1-lts on lime2

Does it work with the non-lts kernel?

If it affects the kernel (as you seem to imply) [...]

I'm not implying anything. [...]

Here you didn't state yet that Ethernet is broken in GNU/Linux. You just said that the "lan port didn't work". So I'm assuming that it's broken in GNU/Linux too and not just in u-boot.

But the linux stmmac/dwmac-sunxi.c would be for multiple boards right, not just for lime2. In that case, other boards will show problems.

That's my main issue here: I'm trying to understand how to fix it well without breaking support for other boards, especially the one with the RTL8211CL PHY: I can test for the RTL8211E, and you can probably test it for the KSZ9031, but I don't know anybody that has the version with the RTL8211CL PHY.

If I workaround in u-boot like you do, it might break the other PHY support and I can't test the RTL8211CL. The fact that it works for you is an important information (assuming I understood it right as explained before).

Fixing it is not simple indeed.

There is some documentation on how to increase the delays of the pads in Documentation/devicetree/bindings/net/micrel-ksz90x1.txt, so that looks good in theory but we need to find a way to add that and make sure that it is only applied for the Micrel PHY. Given that there are 3 PHYs and that they are automatically detected I'm unsure if we can do that easily.

In the worst case we might want to ask Olimex to ship us the missing lime2(s) to be able to test fixes.

#21

Updated by infinite_recursion 30 days ago

Does it work with the non-lts kernel?

To test this, I would have to use normal u-boot and install parabola. Currently I run my site https://designman.org on that lime2. It's not possible.

Here you didn't state yet that Ethernet is broken in GNU/Linux. You just said that the "lan port didn't work". So I'm assuming that it's broken in GNU/Linux too and not just in u-boot.

Lan port should not be broken in general. There's a delay in pin signal I guess. I checked which defconfigs have tx_delay line. Most have 3. To confirm things, you'll have to shout out to community who don't have these boards below and have one whose u-boot parabola supports and ask if 1 can install parabola correctly.

Lamobo_R1_defconfig
CONFIG_GMAC_TX_DELAY=3
Orangepi_defconfig
CONFIG_GMAC_TX_DELAY=4
A20-Olimex-SOM204-EVB-eMMC_defconfig
CONFIG_GMAC_TX_DELAY=3
bananapi_m1_plus_defconfig
CONFIG_GMAC_TX_DELAY=3
Orangepi_mini_defconfig
CONFIG_GMAC_TX_DELAY=3
Linksprite_pcDuino3_Nano_defconfig
CONFIG_GMAC_TX_DELAY=4
A20-Olimex-SOM204-EVB_defconfig
CONFIG_GMAC_TX_DELAY=1
Cubietruck_defconfig
CONFIG_GMAC_TX_DELAY=3
Bananapro_defconfig
CONFIG_GMAC_TX_DELAY=3
Bananapi_defconfig

That's my main issue here: I'm trying to understand how to fix it well without breaking support for other boards, especially the one with the RTL8211CL PHY: I can test for the RTL8211E, and you can probably test it for the KSZ9031, but I don't know anybody that has the version with the RTL8211CL PHY.
If I workaround in u-boot like you do, it might break the other PHY support and I can't test the RTL8211CL. The fact that it works for you is an important information (assuming I understood it right as explained before).

I suggest you don't go for kernel change. Make 2 packages, uboot4extlinux-a20-olinuxino-lime2 for latest H-L, uboot4extlinux-a20-olinuxino-lime2_RTL for your case and let CL cases dangle around. If one with CL comes up, they'll file an issue if and only if RTL does not work for them. So just a small patch would do it.

#22

Updated by GNUtoo 25 days ago

I've that in u-boot:

=> mii info
PHY 0x00: OUI = 0x0732, Model = 0x11, Rev = 0x05,  10baseT, HDX
PHY 0x01: OUI = 0x0732, Model = 0x11, Rev = 0x05,  10baseT, HDX

So maybe we could simply ship a script in the defconfig that patches the dts if the PHY is a micrel one.

#23

Updated by GNUtoo 25 days ago

=> mdio list
ethernet@1c50000:
1 - RealTek RTL8211E <--> ethernet@1c50000
#24

Updated by GNUtoo 25 days ago

I think we already have most of the primitives needed to have a generic configuration in u-boot:
  • We can detect the PHY type by reading the MDIO registers: the PHYs probably use the standard for that and we have only 3 phys to differenciate from. U-boot also have programming with if and so on from its environment. The PHY datasheet should be sufficient for that.
  • We can load the devicetree and patch it:
=> ext4load mmc 0:1 $fdt_addr_r /boot/dtbs/linux-libre/sun7i-a20-olinuxino-lime2.dtb
43190 bytes read in 11 ms (3.7 MiB/s)
=> fdt addr $fdt_addr_r
=> fdt list /soc/ethernet@1c50000/mdio/ethernet-phy@1/
ethernet-phy@1 {
    reg = <0x00000001>;
    phandle = <0x0000002f>;
};

The question is if we can manage to hook all that right after the dts has been loaded somehow.

#25

Updated by GNUtoo 24 days ago

Does it work with the non-lts kernel?

To test this, I would have to use normal u-boot and install parabola. Currently I run my site https://designman.org on that lime2. It's not possible.

Since https://linux-sunxi.org/Olimex_A20-OLinuXino-Lime2#GMAC_quirks states:

A possible cause for packet loss only for Micrel PHY is a bug fixed since mainline linux v5.1 and unfixed in mainline u-boot (as of v2020.07).

And on armv7h we have:

libre/linux-libre 5.8.13-1
libre/linux-libre-lts 5.4.85-1

So it's a bit complicated to fix blindly without being able to test.

Let's say we work around in u-boot with the fix above, the fix might be overwritten by new kernel versions which also touches the MII / Phy registers.

Like If I update the u-boot or the kernel gets updated and we blindly apply any of the fixes mentioned without understanding what happens, the Ethernet might break at some point.

So I guess the next step is to try to find people or help from Olimex to do the testing.

#26

Updated by GNUtoo 24 days ago

I got some help in #olimex from someone who already worked on the issue and has a better fix: setting the phy type to "rgmii-id" could fix it for all 3 phys and when looking at the dts documentation, some file have "rgmii-id" (Internal Delay) as possible value for phy-mode. If that doesn't work we could then try to add delays inside the dts as well. We also need to test with and without u-boot delays.

So if we use that it should fix all the boards. I'll try to see if that person intends to upstream that fix in Linux or not.

edit1: fixed mistake (the fix still needs testing / tunning etc)
edit2: add more background

#27

Updated by infinite_recursion 22 days ago

I can't test it. I have my server running. I can't play around with it. Sorry.

I'll ask some olimex guys. They must have lime2s around them. Could you also ask the olimex guy you met to test it?

#28

Updated by GNUtoo 20 days ago

I can't test it. I have my server running. I can't play around with it. Sorry.
Could you also ask the olimex guy you met to test it?

That person didn't have the time to test and she was just involved in helping fix the bug and doesn't work at Olimex.

I'll ask some olimex guys. They must have lime2s around them.

Bill Auger also contacted the Olimex people and right now we're trying to find if we need more boards than just the ones for fixing this bug as they also proposed us some 64bit boards as well.

Denis.

Also available in: Atom PDF