Rock64 flaky ethernet?

[Adriaan de Groot]

I've got an old-ish (2018 .. v2) Rock64 that hasn't been used much. I have
fetched and booted it into the 13-RELEASE image:

FreeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img.xz 452690956 2021-Apr-09 06:46

I have written this to an 8GB generic micro-SD card. For good measure, I have
written a recent Armbian image to the same brand and age of micro-SD card, so
I have comparison material. (I could also write everything to the 32GB eMMC
chip that's in the Rock64, if needed, but I'm holding off on that until I have
something that works).

After boot, dwc0 gets an address from DHCP, and I start pinging 10.0.0.2 in my
home network. I get ~3% packet loss if I'm lucky, more often around 7%. If I'm
pinging a machine in the network and also pinging my Rock64 from that machine,
I hit around 22% packet loss on both sides.

Armbian works fine - poweroff, swap SD card, power on - in the same setup.

With this kind of packet loss I can't really do anything with the board in
FreeBSD; `pkg bootstrap` for instance seems to sit there forever.

.. ok, digging in the archives gets me lots of threads from june/july 2020
about dwc timing, I'll dig through those first before carrying on.

[ade]

PS. Pine H6 never did catch on in FreeBSD-land, did it. Pity, I've got a
couple that I'd be happy enough to use instead of the Rock64 if they worked.

[Daniel Engberg]

Hi,

Regarding our Rock64 board this looks relevant,
https://forum.pine64.org/showthread.php?tid=7545

As for your H6 board I guess you mean H64?
https://www.freshports.org/sysutils/u-boot-pine-h64/
https://linux-sunxi.org/PineH64

Just overwrite u-boot from that port to the
FreeBSD-13.0-RELEASE-arm64-aarch64-PINE64-LTS.img.xz image (extracted)
and with a bit of luck you should be able to get it booting.

Best regards,
Daniel

[Adriaan de Groot]

Post by Daniel Engberg
Regarding our Rock64 board this looks relevant,
https://forum.pine64.org/showthread.php?tid=7545

Yes. (Re-)soldering SMD components is not my idea of fun, though (heck, I need
to take off my glasses even to read the silkscreen on the board). I tried some
of the timing hacks and so from the earlier threads, but nothing seems to
help. I'll file that board away as "fun with Linux" (which means "return to
the box of dusty stuff I mean to do something cool with some day").

Post by Daniel Engberg
As for your H6 board I guess you mean H64?
https://www.freshports.org/sysutils/u-boot-pine-h64/
https://linux-sunxi.org/PineH64

Yep!

Post by Daniel Engberg
Just overwrite u-boot from that port to the
FreeBSD-13.0-RELEASE-arm64-aarch64-PINE64-LTS.img.xz image (extracted)
and with a bit of luck you should be able to get it booting.

You just helped me close 21 browser tabs worth of wikis and searches, thank
you.

FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261f: Fri Apr 9 06:07:07
UTC 2021
***@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC
arm64
FreeBSD clang version 11.0.1 (***@github.com:llvm/llvm-project.git
llvmorg-11.0.1-0-g43ff75f2c3fe)
VT: init without driver.
module firmware already present!
real memory = 3221024768 (3071 MB)
avail memory = 3119251456 (2974 MB)

This was amazingly painless. I'll do a bit of a write-up and add it to the
wiki.

[ade]

[Peter Jeremy via freebsd-arm]

Post by Adriaan de Groot

Post by Daniel Engberg
Regarding our Rock64 board this looks relevant,
https://forum.pine64.org/showthread.php?tid=7545

Yes. (Re-)soldering SMD components is not my idea of fun, though

It's not easy. And after making those changes, my board no longer
worked with the "corrected" if_dwc tx and rx delays and I had to
locally revert that commit.

I'm running my Rock64 diskless (it boots from U-Boot using DHCP &
TFTP), rebuilding and updating head daily. It's been completely
reliable except that occasionally loading the kernel will stall on the
reboot after installworld. So far, that hasn't become enough of an
annoyance to make me dig into in more.

[Adriaan de Groot]

Post by Daniel Engberg
As for your H6 board I guess you mean H64?
https://www.freshports.org/sysutils/u-boot-pine-h64/
https://linux-sunxi.org/PineH64

I used the Rock64 image (since I had downloaded it already, and it's all
aarch64 anyway) and replaced the u-boot and all went well. I have since
totally spammed the wiki admins with edits so that you can find information
about the H6, and published some bloggy bits too.

[ade]

[Emmanuel Vadot]

On Fri, 14 May 2021 12:13:21 +0200

Post by Adriaan de Groot

Post by Daniel Engberg
As for your H6 board I guess you mean H64?
https://www.freshports.org/sysutils/u-boot-pine-h64/
https://linux-sunxi.org/PineH64

I used the Rock64 image (since I had downloaded it already, and it's all
aarch64 anyway) and replaced the u-boot and all went well. I have since
totally spammed the wiki admins with edits so that you can find information
about the H6, and published some bloggy bits too.
[ade]

Thanks Adriaan,

H6 support is still pretty early (I've "only" added support for this
SoC to test the dwc3 driver on another board) but should work ok.
Let me know if you have major features not supported on the Pine H64
board.

[Mark Millard via freebsd-arm]

Post by Adriaan de Groot
I've got an old-ish (2018 .. v2) Rock64 that hasn't been used much. I have
FreeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img.xz 452690956 2021-Apr-09 06:46
I have written this to an 8GB generic micro-SD card. For good measure, I have
written a recent Armbian image to the same brand and age of micro-SD card, so
I have comparison material. (I could also write everything to the 32GB eMMC
chip that's in the Rock64, if needed, but I'm holding off on that until I have
something that works).
After boot, dwc0 gets an address from DHCP, and I start pinging 10.0.0.2 in my
home network. I get ~3% packet loss if I'm lucky, more often around 7%. If I'm
pinging a machine in the network and also pinging my Rock64 from that machine,
I hit around 22% packet loss on both sides.

For my mid-March non-debug build of main [so: 14] I get,
for example, (.149 is the Rock64 V2.0; .120 is a
ThreadRipper 1950X, both going at the same time
here):

--- 192.168.1.149 ping statistics ---
72 packets transmitted, 72 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.136/0.230/1.903/0.279 ms

--- 192.168.1.120 ping statistics ---
81 packets transmitted, 81 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.211/0.241/0.286/0.013 ms

So, no problem observed.

The root file system is on a USB3 SSD. A removable eMMC is
involved in the booting but no microsd card is present.

For reference:

# ~/fbsd-based-on-what-freebsd-main.sh
FreeBSD Rock64_RPi_4_3_2v1p2 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG arm64 aarch64 1400005 1400005
def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context.
merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2
merge-base: CommitDate: 2021-03-12 20:29:42 +0000
7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all XPT_ASYNC ccbs in a dedicated thread
n245444 (--first-parent --count for merge-base)

Post by Adriaan de Groot
Armbian works fine - poweroff, swap SD card, power on - in the same setup.
With this kind of packet loss I can't really do anything with the board in
FreeBSD; `pkg bootstrap` for instance seems to sit there forever.
.. ok, digging in the archives gets me lots of threads from june/july 2020
about dwc timing, I'll dig through those first before carrying on.
[ade]
PS. Pine H6 never did catch on in FreeBSD-land, did it. Pity, I've got a
couple that I'd be happy enough to use instead of the Rock64 if they worked.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

[Mark Millard via freebsd-arm]

Post by Mark Millard via freebsd-arm

Post by Adriaan de Groot
I've got an old-ish (2018 .. v2) Rock64 that hasn't been used much. I have
FreeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img.xz 452690956 2021-Apr-09 06:46
I have written this to an 8GB generic micro-SD card. For good measure, I have
written a recent Armbian image to the same brand and age of micro-SD card, so
I have comparison material. (I could also write everything to the 32GB eMMC
chip that's in the Rock64, if needed, but I'm holding off on that until I have
something that works).
After boot, dwc0 gets an address from DHCP, and I start pinging 10.0.0.2 in my
home network. I get ~3% packet loss if I'm lucky, more often around 7%. If I'm
pinging a machine in the network and also pinging my Rock64 from that machine,
I hit around 22% packet loss on both sides.

For my mid-March non-debug build of main [so: 14] I get,
for example, (.149 is the Rock64 V2.0; .120 is a
ThreadRipper 1950X, both going at the same time
--- 192.168.1.149 ping statistics ---
72 packets transmitted, 72 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.136/0.230/1.903/0.279 ms
--- 192.168.1.120 ping statistics ---
81 packets transmitted, 81 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.211/0.241/0.286/0.013 ms
So, no problem observed.
The root file system is on a USB3 SSD. A removable eMMC is
involved in the booting but no microsd card is present.
# ~/fbsd-based-on-what-freebsd-main.sh
FreeBSD Rock64_RPi_4_3_2v1p2 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG arm64 aarch64 1400005 1400005
def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context.
merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2
merge-base: CommitDate: 2021-03-12 20:29:42 +0000
7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all XPT_ASYNC ccbs in a dedicated thread
n245444 (--first-parent --count for merge-base)

Post by Adriaan de Groot
Armbian works fine - poweroff, swap SD card, power on - in the same setup.
With this kind of packet loss I can't really do anything with the board in
FreeBSD; `pkg bootstrap` for instance seems to sit there forever.
.. ok, digging in the archives gets me lots of threads from june/july 2020
about dwc timing, I'll dig through those first before carrying on.
[ade]
PS. Pine H6 never did catch on in FreeBSD-land, did it. Pity, I've got a
couple that I'd be happy enough to use instead of the Rock64 if they worked.

For reference as far as U-Boot goes:

U-Boot 2021.04 (Apr 09 2021 - 17:05:14 +0000)

Model: Pine64 Rock64
DRAM: 4 GiB
PMIC: RK8050 (on=0x40, off=0x00)
MMC: ***@ff500000: 1, ***@ff520000: 0

It is from a sysutils/u-boot-rock64 build with no
local patches. Previously 2020.10 was in use,
also without problems. (But one of my non-debug
builds of main was in use.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

[Mark Millard via freebsd-arm]

Post by Mark Millard via freebsd-arm

Post by Mark Millard via freebsd-arm

Post by Adriaan de Groot
I've got an old-ish (2018 .. v2) Rock64 that hasn't been used much. I have
FreeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img.xz 452690956 2021-Apr-09 06:46
I have written this to an 8GB generic micro-SD card. For good measure, I have
written a recent Armbian image to the same brand and age of micro-SD card, so
I have comparison material. (I could also write everything to the 32GB eMMC
chip that's in the Rock64, if needed, but I'm holding off on that until I have
something that works).
After boot, dwc0 gets an address from DHCP, and I start pinging 10.0.0.2 in my
home network. I get ~3% packet loss if I'm lucky, more often around 7%. If I'm
pinging a machine in the network and also pinging my Rock64 from that machine,
I hit around 22% packet loss on both sides.

For my mid-March non-debug build of main [so: 14] I get,
for example, (.149 is the Rock64 V2.0; .120 is a
ThreadRipper 1950X, both going at the same time
--- 192.168.1.149 ping statistics ---
72 packets transmitted, 72 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.136/0.230/1.903/0.279 ms
--- 192.168.1.120 ping statistics ---
81 packets transmitted, 81 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.211/0.241/0.286/0.013 ms
So, no problem observed.
The root file system is on a USB3 SSD. A removable eMMC is
involved in the booting but no microsd card is present.
# ~/fbsd-based-on-what-freebsd-main.sh
FreeBSD Rock64_RPi_4_3_2v1p2 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG arm64 aarch64 1400005 1400005
def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context.
merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2
merge-base: CommitDate: 2021-03-12 20:29:42 +0000
7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all XPT_ASYNC ccbs in a dedicated thread
n245444 (--first-parent --count for merge-base)

Post by Adriaan de Groot
Armbian works fine - poweroff, swap SD card, power on - in the same setup.
With this kind of packet loss I can't really do anything with the board in
FreeBSD; `pkg bootstrap` for instance seems to sit there forever.
.. ok, digging in the archives gets me lots of threads from june/july 2020
about dwc timing, I'll dig through those first before carrying on.
[ade]
PS. Pine H6 never did catch on in FreeBSD-land, did it. Pity, I've got a
couple that I'd be happy enough to use instead of the Rock64 if they worked.

U-Boot 2021.04 (Apr 09 2021 - 17:05:14 +0000)
Model: Pine64 Rock64
DRAM: 4 GiB
PMIC: RK8050 (on=0x40, off=0x00)
It is from a sysutils/u-boot-rock64 build with no
local patches. Previously 2020.10 was in use,
also without problems. (But one of my non-debug
builds of main was in use.)

I dd'd FreeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img to
a microsd card and booted it (no eMMC or USB storage
attached). This created .185 instead of the .149 for
networking:

--- 192.168.1.185 ping statistics ---
102 packets transmitted, 102 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.126/0.198/1.925/0.244 ms

--- 192.168.1.120 ping statistics ---
102 packets transmitted, 102 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.175/0.206/0.629/0.044 ms

(.120 is a ThreadRipper 1950X.)

Consistent with the past, it appears that various Rock64 v2.0's
may not be equivalent. At least for my context,
FreeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img of itself does not
seem to be a problem for the Rock64 v2.0 that I have access to.
That spans U-Boot and FreeBSD being the same as you tried.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)