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

https://notabug.org/sagaracharya/parabola_openrc_olinuxino_lime2

if they want to.

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?

GNUtoo -
could you look into this?

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

+CONFIG_GMAC_TX_DELAY=3

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.

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

Hi,

• 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.

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.

• RTL8211e fix: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bbc4d71d63

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

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.

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.

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.

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.

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.

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.

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.

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

• 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.

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.

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

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?

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.

i noticed perhaps a clue from the freedombox system - that has a custom uboot, which is configured to work-around a known bug in the ethernet device on the lime2 revG2 - the ethernet device on that board does not work OOTB on debian - the custom uboot configures it into 100mb mode (rather than the default 1gb), which allows it to function

when i boot that same freedombox system on the lime2 revK (the one with the micrel ethernet), the ethernet works

is this the bug? - the sunxi wiki says it is fixed

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

GMAC-related software bugs
Rev. H-L would fail to work or lose packets at 100 megabit or gigabit speeds,
because Micrel PHY driver was not loaded by default.
Fixed since mainline linux v5.5 and mainline u-boot v2021.01.

maybe we just need to upgrade?

libre/linux-libre-lts                    5.4.85
libre/uboot4extlinux-a20-olinuxino-lime2 2020.04

I have a revision K and a revision L of this board (for the last one, the version with flash memory on the board).

I used the images provided in the first links of this message and then I could update the system via the network so it works, but I understand these images are a workaround precisely for the reported bug.

I can do some testing with my boards if useful but please let me know what to test exactly. Note that this is the first time I am using Parabola so every step takes me a lot of documentation reading time. Besides, I don't have a computer running Parabola ( I cannot write the name of the distribution I a using because my post will be blocked otherwise).

Avron wrote:

I have ... the version with flash memory on the board).

FWIW, that distinction is too vague; because there are several variants "with flash memory" - some have NAND flash, some have EMMC flash, and some have SPI flash - i read (cant remember where now) that all boards from revK and later, come with SPI flash by default - i have a revK with no flash though; but it may be a refurbished or b-stock

Avron wrote:

I used the images provided in the first links ... it works

i got it working with the parabola kernel also - the patch in the OP was sufficient -

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

Avron wrote:

I don't have a computer running Parabola

its not difficult to install parabola - the beauty of the uboot+extlinux is that it supports multiple installed OSes - its probably not necessary though - for this particular task, the only essential component of parabola to test against, is the linux-libre kernels - its quite likely that the parabola kernels would "just work" with whatever OS - the init-system and network services are probably the same as parabola/systemd

FWIW, that distinction is too vague

It is eMMC, I did not write it before because I was blocked by the dictionnary check.

i got it working with the parabola kernel also - the patch in the OP was sufficient

Actually I am not sure how to do that.

I now have installed Parabola (first time I did that) on a old laptop and followed the procedure to make an installation on an SD card for ARM with Parabola's packages, including u-boot. I used pacstrap in order to get up to date packages.

It boots ok but even though networkmanager is installed and set to start automatically (I decided to use the systemd version as it has better documentation), I din't get the network interface to work, unlike on my laptop which I configured exactly the same way. I could have done a mistake in the installation, or that could be due to the ethernet issue.

I followed the guidelines at https://linux-sunxi.org/Mainline_U-Boot#Compile_U-Boot to compile U-boot on my desktop running Trisquel 9, got v2021.04, did the indicated changes to A20-OLinuXino-Lime2-eMMC_defconfig, ran as advised
make CROSS_COMPILE=arm-linux-gnueabihf- A20-OLinuXino-Lime2-eMMC_defconfig
make CROSS_COMPILE=arm-linux-gnueabihf- menuconfig
make CROSS_COMPILE=arm-linux-gnueabihf-

but I am not sure what to do actually with menuconfig, so I did nothing.

I have put the generated u-boot-sunxi-with-spl.bin with dd instead of the one from Parabola's package but then it does not boot, it resets even before the step to launch the kernel. So either my u-boot-sunxi-with-spl.bin is wrong or something else is needed. I noticed that there are quite a number of other files generated:

u-boot      u-boot.cfg          u-boot.dtb      u-boot-dtb.img  u-boot.img  u-boot.map        u-boot.srec                u-boot-sunxi-with-spl.map
u-boot.bin  u-boot.cfg.configs  u-boot-dtb.bin  u-boot.dtb.out  u-boot.lds  u-boot-nodtb.bin  u-boot-sunxi-with-spl.bin  u-boot.sym

but I don't know if I need to do something with them.

What is the way to apply the patch? Does anything look wrong or missing in what I did?

Someone working on yunohost pointed me to that patch: https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sunxi/board_lime2/GMAC_TX_DELAY_autocorrection.patch

It might fix it for at least the MICREL PHY and the Realtek RTL8211E PHY.

That patch is being in use in both armbian and yunnohost.

Denis.