Rock Pi 4 Model A+

[mrbluecoat]

Creating an image request

Formal device information

• Device name | Rock Pi 4 Model A+
• Official product URL | https://shop.allnetchina.cn/products/rock-pi-4-model-a-board-only-without-wifi?variant=39415783063654
• GitHub resource URL (if available) | https://github.com/radxa-build/rockpi-4a
• Image download URL | https://github.com/radxa-build/rockpi-4b/releases

Is the SBC officially supported by the Debian installer?

Yes, you have an image for Rock Pi 4 but it doesn't work with the Model A+ (OP1 CPU with onboard eMMC)

[mrbluecoat]

Did you retire https://raw.githubusercontent.com/MichaIng/DietPi/master/PREP_SYSTEM_FOR_DIETPI.sh ? I was going to build a custom image but that link no longer works.

[Joulinar]

The script has been renamed on latest version. It now called https://raw.githubusercontent.com/MichaIng/DietPi/master/.build/images/dietpi-installer

[MichaIng]

Hmm, Radxa itself doesn't differentiate between the multiple ROCK Pi 4 variantes, see model A GitHub source redirecting to model B GitHub and releases page, with only 4B images.

Model B has eMMC as well, isn't it? Is there a difference between A+ and A?

~... ah, right completely different SoC, so the ROCK Pi A GitHub and releases ain't gonna work either, there need to be dedicated A+ releases.~

[mrbluecoat]

https://github.com/radxa-build/rockpi-4b/releases/download/main-ce723808/Armbian_22.05.0-trunk_Rockpi-4b_bullseye_current_5.15.35_minimal.img.xz booted for me and I was able to load it to eMMC

[mrbluecoat]

I'll use the dietpi-installer on it and let you know how it goes.

[MichaIng]

Ah nope, looks like "OP1" is an alias for RK3399. Confusing...

Okay, I'm not sure about the plus/non-plus differences, but generally all share the same SoC and all have eMMC (isn't it?), so I don't see so far why they would require a different image, which matches the fact that Radxa itself ships a single image only.

Our image failed to boot from SD card as well?

[mrbluecoat]

Correct, your image failed to boot from SD card (at least it didn't activate SSH access). I'll have to dig out my UART to debug further.

[mrbluecoat]

Okay, I'm not sure about the plus/non-plus differences

Slightly higher CPU clock speeds (2.0 GHz vs 1.8 GHz) and soldered onboard eMMC

[MichaIng]

Ah, probably that soldered eMMC requires a changed bootloader. Most confusing is that the ROCK Pi 4C has a dedicated release page with own images, but A+ links to B non-plus, and they even have Armbian releases there, while Armbian itself doesn't support this device anymore.

However, this means probably we only need to update our image as is and it works with latest kernel and bootloader (if any now is available).

[mrbluecoat]

The dietpi-installer seemed to work and I got to the command to reboot. After rebooting and waiting a couple minutes I can see "DietPi login:" on the HDMI-connected monitor but no SSH IP to connect to.

[MichaIng]

Please login on local console and check Internet connection status.

So it does boot then, and network (or SSH) is the only issue.

[mrbluecoat]

Correct, boot is fine, just network. I was able to login and the setup error was Exit code 2 Error log: ping: connect: Network is unreachable. After bypassing the ping and time sync steps I checked ip a which showed I had an IPv6 address but no IPv4 address. I ran dhclient and an IPv4 address was created and I was able to login remotely and allow the remainder of the DietPi setup to complete.

[Joulinar]

How does it looks like after a reboot?

[MichaIng]

As long as you didn't assign a static IP (or change dietpi.txt at all), the DHCP client should start automatically 🤔. I'll update the image regardless, since there were quite some changes network-wise.

[mrbluecoat]

Good call, Joulinar. After a reboot, here are the errors (and IPv4 is gone again):

rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout!
rk_gmac_dwmac fe300000.ethernet: cannot get clock c1k_mac_speed
systemd-fstab-generator[347]: Failed to create unit file /run/systemd/generator/tmp.mount, as it already exists. Duplicate entry in /etc/fstab?
systemd[345]: /usr/lib/systemd/system-generators/systemd-fstab-generator failed with exit status 1.

[mrbluecoat]

Not sure if this is the right place to look but https://github.com/MichaIng/DietPi/blob/a11300ae39d7ecc064355f5bbf3d49968fc8736b/dietpi/dietpi-config#L2041 uses ifup eth0 -- force which didn't work but dhclient did.

# ifup eth0 --force
Internet Systems Consortium DHCP Client 4.4.1
...
Listening on LPF/eth0/96:c8:78:90:d9:20
Sending on  LPF/eth0/96:c8:78:90:d9:20
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

[MichaIng]

As you can see, ifup invokes dhclient internally if set in /etc/network/interfaces (by default on DietPi unless static IP set). It doesn't not receive a DHCP offer via eth0.

How did you call dhclient manually? Check from which interface it does get the DHCP lease from, probably the interface name is wrong.

[mrbluecoat]

Sorry, ignore my previous comment - didn't fix the issue, but as a next try I put dhclient on line https://github.com/MichaIng/DietPi/blob/a11300ae39d7ecc064355f5bbf3d49968fc8736b/dietpi/func/dietpi-globals#L1121 and the install is getting farther. I'll do some additional troubleshooting and let you know how it goes.

[mrbluecoat]

Hmm.. didn't survive a reboot. If I connect it to a monitor and keyboard, login, and type dhclient it will get an IPv4 address but it isn't getting one automatically with the DietPi image (but does with the Raxda-provided image). Where would I look to see which interface it's getting the DHCP lease from? /var/lib/dhcp/dhclient.leases indicates interface "eth0" after I run dhclient.

[MichaIng]

Does the following bring up DHCP?

ifdown eth0
ifup eth0

[mrbluecoat]

# ifdown eth0
Killed old client process
...
# ifup eth0
Internet Systems Consortium DHCP Client 4.4.1
...
Listening on LPF/eth0/96:c8:78:90:d9:20
Sending on  LPF/eth0/96:c8:78:90:d9:20
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 2
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

I also set eth0 in /etc/network/interfaces to

auto eth0
iface eth0 inet dhcp

but still no luck

[MichaIng]

Can you compare the dhclient process started by ifup in htop and compare this with how you start it manually? Respectively try to find the flag/option that makes the difference.

[mrbluecoat]

Here's the command DietPi is trying to run: /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases eth0

The command that works is simply /sbin/dhclient -v

I compared it to the man page and found a couple issues:

1. -i is not a valid argument. If I run /sbin/dhclient -v -i it fails
2. -I needs to be followed by a dhcp-client-identifier

If I run /sbin/dhclient -4 -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -df /var/lib/dhcp/dhclient6.eth0.leases eth0 it works

[MichaIng]

-i is valid: https://manpages.debian.org/bullseye/isc-dhcp-client/dhclient.8.en.html#i

This is used by ifup internally, if it wasn't valid, no Debian user would be able to use ifup 😉.

What is the error message you face with it?

[mrbluecoat]

Thanks for that correct man page. You can disregard the -I point since it appears to work okay standalone. Here's my testing with and without -i

[mrbluecoat]

Ugh. On a whim I switched out my router for another and DietPi booted like a charm. Looks like my other lame router isn't DUID RFC4361 compliant 😠

I'll play around with it a bit more but you can focus on other tasks if an immediate workaround doesn't come to mind.

[mrbluecoat]

P.S. Is there supposed to be a space at the end of the DUID (as shown in my screenshot above)?

[mrbluecoat]

I can get it to work by changing https://github.com/MichaIng/DietPi/blob/86c5e377c607c2e1d8e97138c7cb9d377120a55d/rootfs/etc/systemd/system/ifup%40.service.d/dietpi.conf#L5 to ExecStart=/sbin/dhclient %I but it reverts when DietPi updates to the latest version and eth0 breaks again until I manually login via a connected keyboard/monitor to apply the fix again.

[mrbluecoat]

Here's a workaround/hack for anyone that encounters this edge case:

Create /etc/network/if-pre-up.d/patchup with this content and make it executable:

#!/bin/sh
grep -q "iface $IFACE inet dhcp" /etc/network/interfaces && ((ethtool "$IFACE" | grep -q "Link detected: yes") || (dhclient "$IFACE" && exit 1))
exit 0

Create /etc/network/if-down.d/patchdown with this content and make it executable:

#!/bin/sh
grep -q "iface $IFACE inet dhcp" /etc/network/interfaces && (ethtool "$IFACE" | grep -q "Link detected: yes") && dhclient -r "$IFACE" && exit 1
exit 0

[MichaIng]

I generated a new image for testing. It uses dev branch (due to some change required for applying correct UART baudrate). Probably it boots from eMMC OOTB: https://dietpi.com/downloads/images/testing/

[mrbluecoat]

@MichaIng, the new image didn't fix the IPv4 issue above (tried with SD card) but otherwise appears to be a working image. Applying my patchup/patchdown fix worked on the new image.

[MichaIng]

So far so good, still strange with the DHCP client. Can you show the following:

journalctl -u network.target -u network-online.target -u networking -u ifup@eth0

And is there actually a dhclient process running after boot? E.g. check via htop.

[mrbluecoat]

journalctl command results:

DietPi systems[1]: Starting Raise network interfaces...
DietPi systems[1]: Finished Raise network interfaces...
DietPi systems[1]: Reached target Network.
DietPi systems[1]: Reached target Network is Online.

htop shows dhclient command running

# ping 9.9.9.9
ping: connect: Network is unreachable

[MichaIng]

Was the following running at all?

systemctl status ifup@eth0
journalctl -u ifup@eth0

[mrbluecoat]

# systemctl status ifup@eth0
ifup@eth0.service - ifup for eth0
Loaded: loaded (/lib/systemd/system/ifup@.service; static)
Drop-In: /etc/systemd/system/ifup@.service.d
    dietpi.conf
Active: inactive (dead)

# journalctl -u ifup@eth0
-- No entries --

[mrbluecoat]

[MichaIng]

So the DHCP client starts up as expected but simply fails to receive an IP. Looks like an issue with the router indeed then, also since you were able to get it working with a different router, if I understood correctly?

This was on first boot, right? On subsequent boots, without your workaround in place, I guess there is a DHCP client timeout shown by these commands?

[mrbluecoat]

Yes to all. I've been using the workaround for a few weeks on a number of test routers and it seems to work fine so I'll go ahead and close this ticket. Thanks for all your help and the amazing DietPi platform.

[MichaIng]

Still strange that DHCP fails on boot but succeeds later. However, I'll keep it in mind in case a similar report is done which would indicate that we need to have a closer look into whether there is something to be done our end.