Rock Pi E V1.21 broken Gbit Lan

For Developers
1

Hello,

First of all thank you for all your hard work on this great Router OS!

But on topic:
There are Snapshots for the Rock Pi E and the V3.0 variant.

I recently purchased a V1.21 and the Gbit LAN Port on it is not working. It drops a lot of Packages and DHCP is not functional.

It seems that the 1.21 Version has a different chip (RTL8211F instead of RTL8211E) that according to this discussion

has some different timing requirements as far as I understand.

Is there a way to get support for that chip or a variant for the V1.21?

Unfortunately I would not know where to start doing it myself.

Thanks and cheers

2

What is the output of

ubus call system board

Have you checked your cables and the ports for any bent pins or debris?

3

Here is the Output:

{
        "kernel": "6.6.43",
        "hostname": "OpenWrt",
        "system": "ARMv8 Processor rev 4",
        "model": "Radxa ROCK Pi E",
        "board_name": "radxa,rockpi-e",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "SNAPSHOT",
                "revision": "r27059-6bb334c5cf",
                "target": "rockchip/armv8",
                "description": "OpenWrt SNAPSHOT r27059-6bb334c5cf"
        }
}

The cables and ports should be fine, as a different router works flawlessly with the same cables.
Also another one of the Rock Pi E V1.21 shows the same symptoms.

Edit: And thank you for the really quick reply :slight_smile:

4

Also this seems to be a known problem, but I couldn't find much OpenWRT related.

Here is another thread with an improvement, but seemingly no real solution:

5

If radaxas own image have the problem and it exists in other Linux distributions then the fix needs to come from upstream - from the manufacturer themselves or in the Nic kernel module

6

There are other boards, where this seems to be fixed:

Would it be possible to create a new variant for the Rock Pi E v1.21, that has such fix?
I guess the normal image doesn't have this fix as it uses the E version of the chip.

7

Certainly possible, but someone who owns the device will need to implement the solution, test it and submit a pull request.

That someone likely needs to be you. Check the wiki for contributing via GitHub and new device support. Start with the dts and support files for the existing revision

8

I think I'll try my best then...
This will be a lot to read. Oh well.
Thought maybe someone with more experience could try to implement it.

Building and testing would be no problem for me.

Thanks

9

Maybe you could point me furher in the right direction. After some research I found, this dts file, that should fix it:

Would it then just be a case of including it in the platform sources and add it to a new device configuration for a V1.21 variant?

10

it needs to be sent upstream as a patch to the official linux kernel git

11

It's easy enough to provide a quick patch if you're compiling it yourself, but for it to work official it means kernel patch so a different dtb file is generated, and then openwrt needs a selection for that specific revision so it knows to load that dtb file

technically you only need the correct dtb file, so if you find a place to get it or generate it yourself you can still download built snapshots and just replace the dtb file once you've flashed the image

12

I compiled a dtb file with the patch from that thread if you want to try it:

So you just need to replace the dtb file in the boot partition to test

13

Wow. Thanks a lot. I will try that later today and report back. :grinning:

14

Just for my curiosity - how are you using your piE with those asymetric ports (1x100m &1x1g)?

15

I use the 100m port to connect to the internet and initiate a VPN connection. The 1g port bridges the tunnel endpoint to the local network. Sure, it would be suficcient to have two 100m ports, but I need both working as the local net should be completely isolated.

1 Like
16

Sorry, I may be too stupid to find the boot partition on the sdcard. There are mmcblk0p1 which just has the kernel.img and the rootfs at /dev/mmcblk0p2.

Where would I need to put the dtb exactly?

17

hmm it must be integrated in
you'd have to add a line to the boot script to load the dtb sorry about that

18

ok, I changed the boot script to hopefully load that dtb file

so in the root directory of the boot partition there should be a boot.scr to overwrite, and you copy the dtb file there too

19

Thanks again. I won't be able to try it today but will give it a shot as soon as possible.

What modifications did you do to the dtb file?
I saw, that there are patches in the target folders for the rockchip devices, that patch the dts files during build. Could I also modify those with the changes if they are working and build a new image with them integrated directly?

Maybe a new target could be added like this without upstream addition of the variant like they seem to have done for the V3 here:

Have a nice day

20

PiEv3 is supported upstream. Openwrt doesn't accept patches for rockchip target without proper "upstreaming"