Armbian Bullseye minimal Rock Pi 4C+ Setup Help

[miles267]

Describe the problem

@marcone Am setting up a new Rock Pi 4C+ with Armbian Bullseye minimal (command line only). Have successfully imaged and booted the new device but cannot seem to get Wi-Fi connection to setup even with nmtui utility. Am only able to connect with Ethernet. Have setup OpenSSH Server. Have pulled down teslausb to the device.

ip a -- returns the following:

wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether e8:fb:1c:34:aa:f9 brd ff:ff:ff:ff:ff:ff

Device

Rock Pi 4C plus

OS Image

Armbian_22.11.1_Rockpi-4cplus_bullseye_current_5.15.80_minimal.img

Car Model

Model 3

USB connection

Glove box

Logs

No response

Additional information

ifconfig wlan0 up --- this does not return any error. My wifi interface is appearing as wlan0

sudo nmcli r wifi on sudo nmcli dev wifi connect ”” password “”

Results return:

ERROR: No network with SSIDArmbian_22.11.1_Rockpi-4cplus_bullseye_current_5.15.80_minimal.img.xz

[marcone]

This is more of a question for the Radxa or Armbian forums, since it has nothing to do with TeslaUSB. All I know is that if you run nmtui and select "Activate a connection", it should show you which networks are available to connect to. You can also try iw dev wlan0 scan which will do a wifi scan and print lots of information about all the networks it found.

[marcone]

(closing because not a teslausb issue)

[miles267]

@marcone I know this is closed but have made a lot of progress on it. Got Teslausb running on the Rock Pi 4C+ and Armbian (since yesterday). Just wanted to ask your guidance or experience on powering the RP4C+ in the Tesla glovebox? I do have a USB3-A to USA3-A cable. But the RP4C+ seems to only power over the USB-C port, unless I'm wrong.

[marcone]

You'll need a USB hub or a Y-cable.

[ken830]

@miles267 : I'm seeing the same issue after setting up TeslaUSB. nmtui's activate connection doesn't work (failure message: "settings plugin does not support adding connections"). Manually running wpa_supplicant and the dhclient works, but how did you eventually get WiFi to auto connect on boot?

[marcone]

That message is generally what you get if you run nmtui after installing teslausb. It's caused by the root filesystem being read-only. To get around it you need to modify fstab so it's read/write, reboot, then run nmtui again. It's not sufficient to remount the fs as read/write without rebooting.

On Sat, Jan 14, 2023, 19:30 Kenneth Leung @.***> wrote:

@miles267 https://github.com/miles267 : I'm seeing the same issue after setting up TeslaUSB. nmtui's activate connection doesn't work (failure message: "settings plugin does not support adding connections"). Manually running wpa_supplicant and the dhclient works, but how did you eventually get WiFi to auto connect on boot?

— Reply to this email directly, view it on GitHub https://github.com/marcone/teslausb/issues/748#issuecomment-1383046215, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALPQBDUPUEV2CNGWOTDIGHLWSNVO3ANCNFSM6AAAAAASUYA2WY . You are receiving this because you were mentioned.Message ID: @.***>

[ken830]

Thanks, @marcone ! That was spot-on. Had to run /root/bin/remountfs_rw before I could edit /etc/fstab. After that, it worked and I re-edited fstab.

For others (and myself) that may be reading this later: nmtui just doesn't show the wireless adapter by default. I tried to get WiFi working before setting up TeslaUSB by installing wpa_supplicant, creating a wpa_supplicant.conf, and then manually running wpa_supplicant and dhclient. It connected, but nmtui still couldn't see the wireless adapter. After installing TeslaUSB, nmtui could suddenly see the wireless adapter and I just needed to make the root fs writeable to make the connection active as described above.

After I got everything up and running on my test SD Card, I went ahead and re-did all of the steps again on my larger SD Card. This time, I installed TeslaUSB without installing wpa_supplicant first. Afterwards, nmtui didn't see the wireless adapter. I played around with it by installing wpa_supplicant and connecting to WiFi manually. Then I think I had to re-run /etc/rc.local (and reboot??) before nmtui would finally see the wireless adapter.

My Linux knowledge is too limited to understand exactly what happened to get it working. I just know the rc.local script does attempt to set-up WiFi, but seems to need wpa_supplicant installed first. And finally, running nmtui allows it to activate the connection (it still asks for SSID and password despite TeslaUSB's attempt to set it up). But afterwards, it seems to re-connect at boot-up.

At the current rate, syncing 22+GB of music is going to take between 12-24 hours over wired gigabit Ethernet, so I'm not going to attempt a third install to test the proper set-up steps. I always thought it was slow on the RPiZero over WiFi, but the RockPi4C+ over gigabit Ethernet seems even slower.

[miles267]

@ken830 appreciate the further testing. So far my Raspberry Pi 4 still consistently outperforms my Rock Pi 4C+ with Teslausb (my only use case for these devices) in every way. That said, I’ve discovered my Rock Pi Wi-Fi issues are more a function of it not having an integrated Wi-Fi antenna. I plan to pick one up and test further but am having challenges finding both a Rock Pi 4C+ enclosure and a 2.4/5.8 GHz external antenna that can be installed within the enclosure (adhesive, tape mount).

[marcone]

nmtui just doesn't show the wireless adapter by default

That is definitely not the case for me. Here's my process:

1. flash Armbian onto sd card (I used the "bullseye current 5.15.80 minimal" image from here)
2. boot Armbian and wait for it to finish resizing the root filesystem and start the initial setup (choosing root password, configuring initial user, etc)
3. if the 4C+ is not connected to ethernet it will ask you if you want to connect via wireless. Answer "Y". This brings up nmtui. Continue at step 5.
4. if you connected ethernet it won't ask for wireless because you're already connected to the network. Continue and finish setup until you have a command prompt, then run nmtui manually.
5. once in nmtui (whether as part of setup or run manually), choose "activate connection", select your SSID, enter password, then hit "escape" until you're back in setup or on the command prompt.

[ken830]

That is definitely not the case for me. Here's my process:

I guess the difference is that I'm setting it up headless, so I had Ethernet connected from the beginning.

@ken830 appreciate the further testing. So far my Raspberry Pi 4 still consistently outperforms my Rock Pi 4C+ with Teslausb (my only use case for these devices) in every way. That said, I’ve discovered my Rock Pi Wi-Fi issues are more a function of it not having an integrated Wi-Fi antenna. I plan to pick one up and test further but am having challenges finding both a Rock Pi 4C+ enclosure and a 2.4/5.8 GHz external antenna that can be installed within the enclosure (adhesive, tape mount).

Last week, as soon as marcone pointed out that the 4C+ was already supported, I did a quick search on Google Shopping and found the board in-stock at Rokland for only $59.00 with free shipping and ordered it immediately. I almost couldn't believe it because it was priced WAY below anywhere else and I was tempted to buy more. I ended up deciding to test one first, but before it even arrived, it became "Sold Out". https://store.rokland.com/products/rock-4c-plus-single-computer-board-with-dual-hdmi-4k-wifi-usb-3-0

I was confused about the RockPi 4C+ too. In most images and a Youtube video I found, the board looks different from the one I ordered and received. Most sites show a board with what looks like M.2 slots. and a version v1.1 or v1.2. Mine doesn't have an M.2 slot, but silkscreen indicates v1.41. The one I ordered does show an external antenna and indeed, I received exactly what is shown -- a Radxa antenna came attached to the board. Radxa's own website doesn't even seem to acknowledge the newer version of the 4C+ boards and their product brief & schematics only reference older versions while the Rokland website actually has a newer product brief (v1.3)

I did some more testing and I have a few observations:

As I've noted above, the music sync over Gigabit Ethernet was very slow. After ~12 hours, it seemed to have stopped at around ~40% of the music copied over. I decided to just plug it into the car to test it as is. The board booted up and started music sync again over WiFi but I was shocked at how quickly it went. It's connected on 5Ghz AC and data rate hovered between 80-120Mbps and it completed syncing the remaining ~13GByte in 25 minutes. I'm very happy with WiFi performance!

I powered the board via the USB-C plug and noted minimal current draw (well below 200mA most of the time). But when I unplugged the USB-C cable, the board did NOT turn off! I was shocked that it remained powered via the USB OTG port. Unfortunately, it won't power-on with the OTG port alone. It seems after the OTG port is configured by software, then it can remain powered by it. I guess that's why it was drawing minimal power from the USB C port. I looked through the v1.2 schematics briefly, but haven't studied it enough to figure out the full power deliver circuit. USB-C power ties directly to VCC5V0_SYS through a 0-ohm resistor and VCC5V0_SYS is the root of the power tree. There're some SY6280AAC power switches that tie it to VBUS_TYPEC and VCC5V0_HOST_S0 to VCC5V0_HOST1. I think HOST1 is the OTG port, but I'm not super clear. I will need to dig into this further. But the SY6280AAC has reverse current blocking, so I don't think the power from the OTG port is accidental.

Finally, no more complaints from the car about slow USB drive. I didn't notice any music skipping while in park, but the new FW doesn't seem to be able to record/save Sentry videos while sitting in the car in park (I think this is a mistake - things can happen while you're sitting in a parked car). I did unplug the car and put it in drive and saved a sentry video while music was playing I didn't notice any skipping either. Will have to do a test drive to make sure, but things are looking promising.

[marcone]

I guess the difference is that I'm setting it up headless, so I had Ethernet connected from the beginning.

Even if ethernet is active, you should still be able to use nmtui immediately after Armbian setup (but before TeslaUSB install) to configure wifi. If you run ifconfig immediately after Armbian setup it should show 3 network interfaces: eth0, lo, and wlan0, and nmtui's "activate connection" should work as I described above.

Mine doesn't have an M.2 slot, but silkscreen indicates v1.41

Unfortunately Radxa removed the M.2 slot from later revisions of the board. Supposedly this is because Rockchip never officially told Radxa that it is supported (per this comment).

As I've noted above, the music sync over Gigabit Ethernet was very slow

Weird, ethernet is substantially faster than wifi for me, showing around 700 Mbps with the speed test in TeslaUSB's web ui.

[miles267]

Once I can finally locate and receive an external antenna that supports both 2.4 and 5 ghz wifi, I'm going to re-test Rock 4 Model C+. Though I have an earlier one with an M.2, it's already sitting here setup with an SD card which should be fine for me. Am curious how much faster it will perform than my Rock Pi 4B setups which have been bulletproof and fast syncing via wifi in garage.

[ken830]

It's been a few months since setting up the 4C+. Although the "slow USB drive" error has completely gone away, we still get occasional skips when listening to music. And quite often (several time per week), the car would not see the drive until a scroll-wheel reboot. The reboot usually, but not always, fixes it. Unplugging and re-plugging the 4C+ doesn't appear to fix it, so it looks like a Tesla FW issue. I'm hoping when we finally get to the 2023 branch of the FW, a lot of bugs go away -- especially the one where the roof ultrasonic sensor stops working for a few days at a time.

[miles267]

Thanks for sharing @ken830. This is quite peculiar considering the Pi 4B will still report slow drive errors though they can largely be ignored. Do not experience skips and rarely need to reboot the car as it the device disconnects are infrequent. Could these be some sort of USB3 issue with the 4C+?

[ken830]

I could be wrong, but I don't believe so. If it were, I think unplugging-then-replugging would resolve it, but it never does. Scroll-wheel reboot of the car does nearly always fix it. On occasion, it requires a second reboots of the car's screen.