[Meta] Radxa Rock Pi 4C Plus and TeslaUSB

[KrzysztofHajdamowicz]

Describe the problem

I have an idea to compile issues mentioned in multiple issues example into single thread, allowing for faster searching.

Device

Rock Pi 4C plus

OS Image

Armbian

Car Model

Model Y

USB connection

Glove box

Logs

No response

Additional information

No response

[KrzysztofHajdamowicz]

So far, my progress is:

1. Get image https://github.com/radxa-build/rock-4c-plus/releases/download/20230312-1521/Armbian_23.05.0-trunk_Rockpi-4cplus_jammy_current_5.15.101_minimal.img.xz
2. Flash microSD card using that image
3. Plug ethernet cable to Rock Pi 4C+
4. Boot it
5. SSH into, using root/1234 credentials
6. Run through initial configuration
7. use nano to create file thermals.dts

/dts-v1/;
/plugin/;

/ {
        compatible = "radxa,rockpi4c-plus", "radxa,rockpi4", "rockchip,rk3399";

        fragment@0 {
                target=<&tsadc>;
                __overlay__ {
                        status = "okay";
                        /* tshut mode 0:CRU 1:GPIO */
                        rockchip,hw-tshut-mode = <1>;
                        /* tshut polarity 0:LOW 1:HIGH */
                        rockchip,hw-tshut-polarity = <1>;
                };
        };

};

8. run armbian-add-overlay thermals.dts
9. reboot
10. Run TeslaUSB installer: curl https://raw.githubusercontent.com/marcone/teslausb/main-dev/setup/generic/install.sh | bash
11. Use /boot/teslausb_setup_variables.conf from TeslaUSB that was running in glovebox on Raspberry Pi 4B (so, 1:1 configuration migration)
12. Plug USB drive that was used by Raspberry Pi 4B from step 10.
    12a. Iterate for a few times, fixing each error one by one:
    12b. mkdir /mnt/{cam,music,boombox}
    12c.

systemctl disable --now systemd-resolved
systemctl mask systemd-resolved
systemctl enable --now dnsmasq

12d. mv /mutable/varlib/misc{,.old}
12e. copy /etc/wpa_supplicant/wpa_supplicant.conf from Raspberry Pi 4B to Rock Pi 4C Plus
12f. Installer finally passes
13. Reboot
14. /backingfiles and /mutable are mounted
15. unfortunately, USB OTG in upper USB3 port is not working.
https://www.youtube.com/watch?v=ngMiCgQzwkI
dmesg:

[   46.419618] overlayfs: "xino" feature enabled using 2 upper inode bits.
[   46.803441] loop0: detected capacity change from 0 to 419428352
[   46.870567] exFAT-fs (loop0): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[   47.067020] ------------[ cut here ]------------
[   47.067040] WARNING: CPU: 1 PID: 1528 at drivers/usb/dwc3/gadget.c:3649 dwc3_stop_active_transfer.part.0.constprop.0+0xb4/0xcc
[   47.067064] Modules linked in: nls_utf8 cifs cifs_arc4 cifs_md4 fscache netfs usb_f_mass_storage libcomposite exfat lz4hc lz4 zram binfmt_misc xfs sg btsdio snd_soc_hdmi_codec bluetooth snd_soc_simple_card snd_soc_rk817 snd_soc_simple_card_utils snd_soc_core brcmfmac snd_pcm_dmaengine hantro_vpu(C) rockchip_vdec(C) snd_pcm brcmutil rockchip_iep rockchip_rga v4l2_h264 snd_timer videobuf2_dma_contig dw_hdmi_i2s_audio dw_hdmi_cec v4l2_mem2mem videobuf2_dma_sg snd videobuf2_vmalloc cfg80211 videobuf2_memops videobuf2_v4l2 soundcore rfkill videobuf2_common videodev mc cpufreq_dt sch_fq_codel ramoops reed_solomon pstore_blk pstore_zone ip_tables x_tables autofs4 uas realtek dwmac_rk stmmac_platform stmmac pcs_xpcs
[   47.067247] CPU: 1 PID: 1528 Comm: disable_gadget. Tainted: G         C        5.15.101-rockchip64 #1
[   47.067256] Hardware name: Radxa ROCK Pi 4C+ (DT)
[   47.067261] pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   47.067269] pc : dwc3_stop_active_transfer.part.0.constprop.0+0xb4/0xcc
[   47.067277] lr : dwc3_stop_active_transfer.part.0.constprop.0+0x78/0xcc
[   47.067285] sp : ffff80000d1abb20
[   47.067289] x29: ffff80000d1abb20 x28: ffff00000511ac40 x27: 0000000000000000
[   47.067300] x26: 0000000000000000 x25: 0000000000000000 x24: ffff000005237900
[   47.067312] x23: ffff0000052229b0 x22: 0000000000000000 x21: ffff000005222a78
[   47.067323] x20: 0000000000000000 x19: ffff0000053ad900 x18: ffffffffffffffff
[   47.067334] x17: 0000000000000000 x16: 0000000000000000 x15: 3d454d414e5f4344
[   47.067345] x14: ffff800009dcc4e0 x13: 0000000000000040 x12: 0000000000000000
[   47.067356] x11: ffffffffffff3f08 x10: ffff8000edff5000 x9 : ffffffffffff3f04
[   47.067368] x8 : 00004161a8e29e9d x7 : ffffffffffff3f00 x6 : ffffffffffff3f0c
[   47.067379] x5 : ffff800009aa9000 x4 : ffffffffffff3f0c x3 : 0000000000000000
[   47.067389] x2 : 0000000000000c08 x1 : ffff80000b90c900 x0 : 00000000ffffff92
[   47.067401] Call trace:
[   47.067405]  dwc3_stop_active_transfer.part.0.constprop.0+0xb4/0xcc
[   47.067413]  dwc3_remove_requests.constprop.0+0x2c/0xf0
[   47.067421]  __dwc3_gadget_ep_disable+0x5c/0x1a0
[   47.067428]  dwc3_gadget_pullup+0xc8/0x240
[   47.067435]  usb_gadget_disconnect+0x38/0x10c
[   47.067444]  usb_gadget_remove_driver+0x30/0xec
[   47.067451]  usb_gadget_unregister_driver+0x70/0xe4
[   47.067458]  gadget_dev_desc_UDC_store+0xb8/0x13c [libcomposite]
[   47.067490]  configfs_write_iter+0xc4/0x124
[   47.067501]  new_sync_write+0xe8/0x184
[   47.067510]  vfs_write+0x238/0x29c
[   47.067516]  ksys_write+0x68/0xf4
[   47.067523]  __arm64_sys_write+0x1c/0x2c
[   47.067529]  invoke_syscall+0x48/0x114
[   47.067539]  el0_svc_common.constprop.0+0x44/0xfc
[   47.067547]  do_el0_svc+0x28/0xa0
[   47.067554]  el0_svc+0x28/0x80
[   47.067564]  el0t_64_sync_handler+0xa4/0x130
[   47.067571]  el0t_64_sync+0x1a0/0x1a4
[   47.067579] ---[ end trace dfca4f5855ded11e ]---
[   47.186435] loop1: detected capacity change from 0 to 419430400
[   47.186735]  loop1: p1
[   47.263967] loop2: detected capacity change from 0 to 209715200
[   47.264289]  loop2: p1
[   47.481811] loop1: detected capacity change from 0 to 419428352
[   48.530664] Mass Storage Function, version: 2009/09/11
[   48.530689] LUN: removable file: (no medium)
[   48.542549] LUN: removable file: (no medium)
[   48.554082] LUN: removable file: (no medium)
[  107.841583] loop1: detected capacity change from 0 to 419428352
[  107.858035] exFAT-fs (loop1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 3588.566311] loop0: detected capacity change from 0 to 419430400
[ 3588.567791]  loop0: p1
[ 3588.771289] loop0: detected capacity change from 0 to 419428352

16. Wireless access point is not created

Diagnostics:
diagnostics.txt

[marcone]

I haven't had time to try your steps yet, but I would suggest using a recent Armbian build with a newer kernel, e.g. Armbian_23.8.1_Rockpi-4cplus_jammy_current_6.1.50.img.xz from https://redirect.armbian.com/rockpi-4cplus/archive/

[KrzysztofHajdamowicz]

I have tried it first. It does not see USB SSD (Samsung T7) and USB-NVME adapter with Samsung 980 Pro connected to USB 3.0 ports, only 2.0 ports see connected drive.

What's better, when I use image from first comment and do apt upgrade, newer system can't see those drives. Looks, like 23.8.1 is buggy somehow.

[miles267]

I’ve just used apt-get update and apt-get upgrade as well as unfreezing kernel updates. That way it’ll ensure the kernel stays current regardless of the installed image. Also there is now a new beta coding UI you can install that’s a convenient option.

[KrzysztofHajdamowicz]

Also there is now a new beta coding UI you can install that’s a convenient option.

What do You mean? I'm new in Armbian world so discovering something new is fun :)

[miles267]

Sorry. Please try this:

sudo apt update && sudo apt install armbian-config. You should then be able to run armbian-config to u freeze kernel installs and configure WLAN, etc. it’s the same as running nmtui.

[KrzysztofHajdamowicz]

Armbian_23.8.1_Rockpi-4cplus_jammy_current_6.1.50.img.xz from https://redirect.armbian.com/rockpi-4cplus/archive/

1. Flash image to microSD card
2. Boot
3. Do initial config
4. apt update && apt install armbian-config
5. use armbian-config to enable dwc3-0-host hardware overlay. SSD is now visible on lower USB3 port.
6. Also enable overlay rockpi4cplus-usb-host. After reboot, there is an error in dmesg

[    3.224357] dwc3 fe800000.usb: error -ETIMEDOUT: failed to initialize core
[    3.224499] dwc3: probe of fe800000.usb failed with error -110

7. Install TeslaUSB: curl https://raw.githubusercontent.com/marcone/teslausb/main-dev/setup/generic/install.sh | bash
8. Use /boot/teslausb_setup_variables.conf from TeslaUSB that was running in glovebox on Raspberry Pi 4B (so, 1:1 configuration migration)
9. Mon Sep 18 12:11:09 AM CEST 2023 : STOP: this device (Radxa ROCK Pi 4C+) does not have a UDC driver appeared in /boot/teslausb-headless-setup.log

Looks like #769 is present in current Armbian images.

---

EDIT

10. Created dwc3-peripherial.dts

/dts-v1/;
/plugin/;

/ {
    compatible = "rockchip,rk3399";
    fragment@0 {
      target = <&usbdrd_dwc3_0>;
      __overlay__ {
        dr_mode = "peripheral";
      };
    };
};

armbian-add-overlay dwc3-peripherial.dts
11. Lost USB SSD visibility.
12. dmesg.txt

[marcone]

6. Also enable overlay rockpi4cplus-usb-host. After reboot, there is an error in dmesg

The rockpi4cplus-usb-host overlay switches the top USB3 port to host mode (as described in /boot/dtb/rockchip/overlay/README.rockchip-overlays), thereby disabling the required OTG mode, which then leads to the error you see when trying to install TeslaUSB:

9. Mon Sep 18 12:11:09 AM CEST 2023 : STOP: this device (Radxa ROCK Pi 4C+) does not have a UDC driver appeared in /boot/teslausb-headless-setup.log

[KrzysztofHajdamowicz]

6. Also enable overlay rockpi4cplus-usb-host. After reboot, there is an error in dmesg

The rockpi4cplus-usb-host overlay switches the top USB3 port to host mode (as described in /boot/dtb/rockchip/overlay/README.rockchip-overlays), thereby disabling the required OTG mode, which then leads to the error you see when trying to install TeslaUSB:

9. Mon Sep 18 12:11:09 AM CEST 2023 : STOP: this device (Radxa ROCK Pi 4C+) does not have a UDC driver appeared in /boot/teslausb-headless-setup.log

overlay and SSD visibility:
no-overlay.txt
dwc3-0-host rockpi4cplus-usb-host.txt
dwc3-0-host.txt

dwc3-0-host overlay is the only overlay that gives SSD visibility in any of USB3 port (lower port, being specific).
Even with dwc3-0-host overlay, there is no UDC driver.

[KrzysztofHajdamowicz]

https://imola.armbian.com/dl/rockpi-4cplus/archive/Armbian_23.8.1_Rockpi-4cplus_bookworm_current_6.1.50_minimal.img.xz

spiced with:

1. apt install vim nano htop ncdu mc curl wget
2. wget https://github.com/radxa/overlays/raw/main/arch/arm64/boot/dts/rockchip/overlays/rk3399-dwc3-0-peripheral.dts -O rk3399-dwc3-0-peripheral.dts
3. armbian-add-overlay rk3399-dwc3-0-peripheral.dts
4. reboot
5. after reboot:

# dmesg | grep -i dwc
[    2.730303] dwc3 fe900000.usb: error -ETIMEDOUT: failed to initialize core
[    2.730408] dwc3: probe of fe900000.usb failed with error -110

No SSD visibility in lower USB3 port, had to use USB2 port to make drive visible.
For testing purporses, teslausb installed using microSD card as backing storage to simplify device.

Unfortunately, whole rig is not visible in PC.
diagnostics.txt

[KrzysztofHajdamowicz]

OK, I have managed to get something working:

1. Use image Armbian_23.8.1_Rockpi-4cplus_jammy_current_6.1.50.img.xz
2. apt update && apt upgrade
3. Run TeslaUSB installer: curl https://raw.githubusercontent.com/marcone/teslausb/main-dev/setup/generic/install.sh | bash
4. In teslausb_setup_variables.conf comment out SSID, WIFIPASS, AP_SSID, AP_PASS, AP_IP,
   teslausb_setup_variables.conf.txt
5. Perform configuration: /etc/rc.local

TeslaUSB works on Rock Pi.
Caveats:

1. After booting Rock Pi, devices appear and after few seconds disappear and re-appear after a second or two.
2. Lower USB3.0 port is not working, thus no USB3.0 for backing storage.

[mjpcomp]

For anyone coming through here and noticing there's a Wiki now on how to install and get the 4C+ working:

Under the https://github.com/marcone/teslausb/wiki/Rock-Pi-4C--Installation#software-requirements Software Requirements section, the link to the image no longer works as that listed version has been archived. You can find that particular version here: https://imola.armbian.com/dl/rockpi-4cplus/archive/

[marcone]

@mjpcomp the linked image was already archived, the problem is that that particular archive was deleted, as I'm sure the one you linked to will be deleted at some point too. This is because Armbian is switching to community images for the Rock Pi 4C+ due to lack of an official maintainer. The problem is that the community image does not have working OTG.

[mjpcomp]

@mjpcomp the linked image was already archived, the problem is that that particular archive was deleted, as I'm sure the one you linked to will be deleted at some point too. This is because Armbian is switching to community images for the Rock Pi 4C+ due to lack of an official maintainer. The problem is that the community image does not have working OTG.

Ah, thanks for the heads up - that's definitely good to know... I'm going to make sure I keep an extra copy of this image around.. Wonder if it may need to be hosted on archive.org or something just in case it does go the way of the Dodo...

[Crosenhain]

I found that the USB-OTG was unreliable, so I took a stab in the dark and removed the usbstoragequirks line from /boot/armbianEnv.txt and ran update_initramfs -u, rebooted, and it seems to be much more reliable from my initial testing. I don't use an external USB drive for storage, so ymmv.

I still see the drives appear for a little bit, then go away, and then come back again. I suspect this might be due to the sync script running on startup but I haven't confirmed this yet.

[DriftingShadows]

I can't seem to get my Rock Pi 4c+ to work with Model Y glovebox with USB3 (to avoid the warning about glovebox usb) in any configuration. The issue is that the Rockpi just doesnt get picked up by the Model Y (DashCam is unavailable in the settings). I've tried various combinations of the following with no luck:

• Using newer armbian builds with the overlay
• Using USB3 hub
• Using USB3 Y cable

There are ways to "trick" the car to pick up teslausb but these are mostly temporary as far as i can tell and eventually becomes unavailable again. For example, while the Rockpi is power, I plugged it into my laptop to make sure its mounted, then unplug from laptop and plug into USB hub connected to the glove box usb. Someone might be able to explain this phenomenon but it doesnt last long, or maybe it never actually works and is just visual.

I can take a USB3 configuration that works 100% time on a Model 3 and plug it into a Model Y and it wont work. I've tested on 2 Model Y's and 2 Model 3's.

Only thing I've gotten to work reliably just using USB2, but then that kinda defeats the whole purpose of using a Rockpi and could just go with a smaller raspberry pi.

If anyone has any insight i'm all ears.

[xybertech]

Have you checked another USB3 device, like an SSD to confirm it works? Does the RockPi power on or do you get nothing at all?

Tesla Y manual says it needs to be USB2 or USB3 that is compatible with USB2 and sustains 4MB/s sustained. After I read that I abandoned the thought of a Rock Pi.
https://www.tesla.com/ownersmanual/modely/en_us/GUID-F311BBCA-2532-4D04-B88C-DBA784ADEE21.html

[jheyneman]

Figured I'd post here in case anyone else is running into the same issue... my RockPi 4C+ had been working fine since May until a Tesla update, it would only mount the drive if I did a scroll wheel reset. I figured I'd try to run the teslausb updater and then it would no longer boot.

Using either images listed here or in the Wiki, the first time apt upgrade is run, it will no longer boot. Connecting the RockPi to HDMI just shows a U-Boot screen.

I flashed the latest Armbian image. It appears NetworkManager isn't the default, instead interfaces are managed by systemd-networkd. I was able to install NetworkManager, switch it to the default, and get WiFi working. I also added the overlay a few comments above and was able to install teslausb.

Hopefully this is a decent starting point for anyone encountering issues, if it works for me over the next week or so, I'll try to write up a more detailed guide. If it doesn't work, I'll be sure to at least update this comment.

edit: Less than a week later, the car no longer found it as a writable device and even though it connects to my wifi, it does not accept any SSH connections. Connecting via HDMI, I'm able to log into it just fine and everything looks normal, SSH is running, but even wired, it rejects SSH connections. I'm a bit out of my depth now unfortunately.

[nmiller0113]

Older Rock 4C+ Armbian builds, including the one in the installation instructions, have a boot stability issue. This issue renders the board unusable in cars as it often fails to boot and register as USB storage. This has been fixed by armbian/build#6414. Newer Armbian builds should perform better. However, they require this overlay to enable peripheral mode on the OTG port, which can be added using the armbian-add-overlay command.

TeslaUSB on a Rock 4C+ works well in my car, with no WiFi issues.

@gerculanum hopefully you still see messages from this old thread. I'm curious if you still knew what release you were using. I tried getting things going with this latest trunk https://github.com/armbian/community/releases/tag/24.11.0-trunk.167, and I was able to install it and compile the overlay. Were there other steps you took before installing teslausb? Right now I cannot get wifi to authenticate, keeps timing out even though it see's my wifi no problem. This was not an issue with the version linked in the wiki...though I did have the boot stability issue on that version. If you wouldn't mind sharing any other steps you took before installing teslausb, that would be awesome. Or link me to where you found it. Thanks!

[jheyneman]

@nmiller0113 I found that using the minimal image, there is some firmware or something missing. I also could not authenticate, and then once I got the extra packages installed, it failed boot and showed a U-Boot screen. I think the boot partition ran out of space.

About a month ago, I tried using the desktop image, obviously ran into issues with the install script since it's set to 3G partition. I edited it to 10G, ran the script and followed the rest of the normal instructions. It has been running and copying footage to my NAS with no issue for the better part of a month.

I also no longer get the red X as I did previously that required me to reboot the car to get it to start recording.

[nmiller0113]

Thanks @jheyneman! What extra packages did you install? If I use the image listed wiki instructions I have boot issues as @gerculanum stated were fixed in later releases. I'm not sure why you're not having the same boot issues, as it doesn't seem to be a boot partition size problem from what was stated...but maybe I misunderstood.

This new version, albeit minimum install image, is super stable...I just can't get my wifi to authenticate and don't know which packages are missing to do so. That's why I was hoping that @gerculanum may see this and be able to assist as it sounds like he's got it running.

[jheyneman]

sorry for the quick edit :)

installing the extra packages kinda worked but it started crashing a few days later.

[nmiller0113]

@jheyneman oh wait...I just noticed you edited your original response from full image (which I assumed was the one on the wiki) to desktop image. Where did you find that? Thanks again!

[nmiller0113]

UG! Nevermind, I'm an idiot :) haha. I totally forgot that I had locked the wireless MAC to my Garage AP, so every time it tried to connect from my office where I'm setting it up, it couldn't connect to the wifi since that AP is downstairs on the other side of the house!!! Once I removed that lock, everything magically worked! Well not magic haha. It worked like it was supposed to :)

[jheyneman]

@nmiller0113 I did use nmtui. I'm not sure what's up with the image in the wiki, but it always fails to boot after an update. I'm tempted to try to set it back up from scratch again so I can write up a guide, but I don't have another microSD handy at the moment.

[nmiller0113]

@jheyneman it looks like I replied at the same time as you. I figured it out. I'm a moron haha. If you read my post above yours you'll see why :)

[jheyneman]

@nmiller0113 just a heads up, I got 2024.32.10 yesterday and the car now shuts off 12V and USB when you're away from the car. It will keep USB on with Sentry though. It takes 2-3 minutes for it to start recording dashcam if Sentry was off.

[nmiller0113]

Thanks @jheyneman! I run my Sentry all the time, even at home, so no worries there. I've had my setup running for about a week now without a hitch. Everything is recording cleanly. Thanks for the help!

Oh, by the way, I was able to get the minimal version (non-desktop) running on the latest trunk. I gave it a try again once I realized my wifi issues were my own bonehead mistake haha. I installed network-manager to have nmtui, but I could have also configured wifi manually. I also setup the overlay. All is solid!

[marcone]

(converting this to a discussion since it wasn't really an issue report to begin with)

[nmiller0113]

Thanks @marcone, makes sense

[LeonLeeX]

I’m running into an issue with my ROCK Pi 4C Plus. When I plug in a USB 3.0 flash drive into the lower USB 3.0 port and power on the device, the flash drive is only recognized as USB 2.0 speed. But if I unplug it and plug it back in again (hot-plugging), it gets detected properly as a USB 3.0 device. This seems really strange and I’m not sure what’s causing it. Any ideas?

root@teslausb-ModelY:~# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 21c4:0cd1 JZAO USB3.2 Gen1
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
root@teslausb-ModelY:~# lsusb -t
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 480M
    |__ Port 001: Dev 002, If 0, Class=Mass Storage, Driver=usb-storage, 480M
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 005.Port 001: Dev 001, Class=root_hub, Driver=ehci-platform/1p, 480M
/:  Bus 006.Port 001: Dev 001, Class=root_hub, Driver=ohci-platform/1p, 12M
/:  Bus 007.Port 001: Dev 001, Class=root_hub, Driver=ehci-platform/1p, 480M
/:  Bus 008.Port 001: Dev 001, Class=root_hub, Driver=ohci-platform/1p, 12M
root@teslausb-ModelY:~#
root@teslausb-ModelY:~# uname -a
Linux teslausb-ModelY 6.6.52-current-rockchip64 #1 SMP PREEMPT Wed Sep 18 17:24:10 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux
root@teslausb-ModelY:~#

[herrfrei]

Hi, I'm trying to get teslausb up on a Rock 4C+ board (no RockPI). I want to use DietPi since it gives very short boot times. The board is equipped with an eMMC module (16GB) and I added a SD card (512GB). The wiki page suggests to use the generic installer. I tried it - it shrinked the eMMC partition and rebooted. Nothing else. How may I proceed now?

[marcone]

I think the Rock 4C+ is the same as the Rock Pi 4C+, they just dropped the "Pi" part from the names of all the formerly "Rock Pi" boards.
In any case, I would recommend using Armbian as that has been known to work in the past.
If you insist on using DietPi, I would suggest logging in to it, running /etc/rc.local, and see what it says.
My first guess would be that since DietPi claims to be an extremely lightweight and highly optimized distribution, it is missing some packages that TeslaUSB assumes are installed by default.

[herrfrei]

Made a step forward: disabled disk shrinking when a environment variable DATA_DRIVE is declared:

# no root partition check needed when DATA_DRIVE is defined
if [ -z "$DATA_DRIVE" ]
then
  rootpart=$(findmnt -n -o SOURCE /)
  rootname=$(lsblk -no pkname "${rootpart}")

  ...

    reboot
    exit 0
  fi
fi

See my fork for the changes (although the diff looks weird since I indented the code between then and fi).
This helped to install the required files.

Note

DietPI does not support hostnamectl (I think dbus is not installed), so the name given in the config file must match the device hostname for now.

[marcone]

I tried TeslaUSB-on-DietPi-on-RockPi4C+, but it failed due to OTG not being enabled, with no apparent way to enable it in the DietPi config tool.

[herrfrei]

I added a device tree overlay that activates the peripheral mode. I can send it if you want. But not today. marcone ***@***.***> schrieb am So., 15. Dez. 2024, 19:14:

…

I tried TeslaUSB-on-DietPi-on-RockPi4C+, but it failed due to OTG not being enabled, with no apparent way to enable it in the DietPi config tool. — Reply to this email directly, view it on GitHub <#883 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACWI2OLIQZWPSYOVKBNFF232FXBJNAVCNFSM6AAAAABPGOO3QGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNJXGM3DAOI> . You are receiving this because you commented.Message ID: ***@***.***>

[deepcoder]

Could you post your file and info on how to use this somewhere here? Thank you!

[herrfrei]

Sure, here it is.

rk3399-dwc3-0-peripheral.dts:

/dts-v1/;
/plugin/;

/ {
	metadata {
		title = "Set OTG port to Peripheral mode";
		compatible = "rockchip,rk3399";
		category = "misc";
		exclusive = "usbdrd_dwc3_0-dr_mode";
		description = "Set OTG port to Peripheral mode.
Use this when you want to connect to another computer.";
	};
};

&usbdrd_dwc3_0 {
	status = "okay";
	dr_mode = "peripheral";
};

This can be compiled with dtc -o rk3399-dwc3-0-peripheral.dtbo rk3399-dwc3-0-peripheral.dts to the binary overlay (I added it zipped to this post: rk3399-dwc3-0-peripheral.zip). Btw, why I cannot add the dtbo file directly and must zip it?

Put the extrated dtbo file into /boot/overlay-user (create if not existing) and add it to /boot/dietpiEnv.txt (without path and extension):

user_overlays=rk3399-dwc3-0-peripheral

That's all.

[marcone]

I gave this a try and eventually got it to work after a few tweaks in the TeslaUSB setup code (which are now merged).
It does seem to boot a few seconds faster than the Armbian build I had on there.

[mentorosso]

hi,
thank you very much for your work!
till now i can't correctly install teslausb on rock4c+; i tried many builds including the one cited here and others. Dietpi seems to be good, but i good 2 issues:
-the script to install the two overlays cited in your branch doesn't worked for me, it seems that the command diet pi add-overlay, wasn't installed. i tried doing it manually but maybe i missed something.
-the installation didn't started after compiling correctly teslausb setup variable file, it says lsblk not a block device.

[marcone]

hi, thank you very much for your work! till now i can't correctly install teslausb on rock4c+; i tried many builds including the one cited here and others. Dietpi seems to be good, but i good 2 issues: -the script to install the two overlays cited in your branch doesn't worked for me, it seems that the command diet pi add-overlay, wasn't installed. i tried doing it manually but maybe i missed something. -the installation didn't started after compiling correctly teslausb setup variable file, it says lsblk not a block device.

Dietpi worked for me, but I needed to

• apt install device-tree-compiler in order to run the dtc command mentioned above
• set export TESLAUSB_HOSTNAME=DietPi in the TeslaUSB config file because the way TeslaUSB sets the host name doesn't work on Dietpi
  I think those were the only things I needed to do to get TeslaUSB working on DietPi on Rock (Pi) 4C+.

[herrfrei]

Hi, I think you beat me to it. I checked in the first version yesterday and wanted to test it tonight. Please be patient! mentorosso ***@***.***> schrieb am So., 22. Dez. 2024, 13:49:

…

hi, thank you very much for your work! till now i can't correctly install teslausb on rock4c+; i tried many builds including the one cited here and others. Dietpi seems to be good, but i good 2 issues: -the script to install the two overlays cited in your branch doesn't worked for me, it seems that the command diet pi add-overlay, wasn't installed. i tried doing it manually but maybe i missed something. -the installation didn't started after compiling correctly teslausb setup variable file, it says lsblk not a block device. — Reply to this email directly, view it on GitHub <#883 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACWI2OIWZZ2RB7II3OPE3GD2G2YNDAVCNFSM6AAAAABPGOO3QGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNRUGI2DQOA> . You are receiving this because you commented.Message ID: ***@***.***>

[herrfrei]

The overlay installation should work now. At least for me they are okay!

[herrfrei]

I checked in the (compiled) dtbo files in my repo. So there is no need for the dtc. For the hostname, dbus is required (install and enable/start service). marcone ***@***.***> schrieb am So., 22. Dez. 2024, 17:53:

…

hi, thank you very much for your work! till now i can't correctly install teslausb on rock4c+; i tried many builds including the one cited here and others. Dietpi seems to be good, but i good 2 issues: -the script to install the two overlays cited in your branch doesn't worked for me, it seems that the command diet pi add-overlay, wasn't installed. i tried doing it manually but maybe i missed something. -the installation didn't started after compiling correctly teslausb setup variable file, it says lsblk not a block device. Dietpi worked for me, but I needed to - apt install device-tree-compiler in order to run the dtc command mentioned above - set export TESLAUSB_HOSTNAME=DietPi in the TeslaUSB config file because the way TeslaUSB sets the host name doesn't work on Dietpi I think those were the only things I needed to do to get TeslaUSB working on DietPi on Rock (Pi) 4C+. — Reply to this email directly, view it on GitHub <#883 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACWI2OL6L2UQTRWDVF22ZT32G3U6ZAVCNFSM6AAAAABPGOO3QGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNRUGM3DQNI> . You are receiving this because you commented.Message ID: ***@***.***>

[0023xx]

Yes I do - at the windows machine I even get the sound feedback, but then that the USB device was not recognised and is not working - which leads to my conclusion that the cable is ok? On the Mac I'm not seeing it at all even in the disk utilities.

[mentorosso]

i got similar issue; it was usb A cable not working.

[0023xx]

Just bought a new cable - same issue - I'm happy if anybody has any other ideas?

[mentorosso]

from diagnostics i see partition is Exfat; don't know if this could lead to recognition problems, anyway mine is on Fat32. I have formatted the sd with raspberry pi imager

[0023xx]

Thank you - I'll try it in Fat32, I think i did it before but you never know. I'll also try the raspberry pi imager - I've used the BalenaEtcher

[herrfrei]

Sorry for that, right now I'm unable to correct the errors. Thank you for the information! marcone ***@***.***> schrieb am Di., 24. Dez. 2024, 20:05:

…

There are two reasons for that. One is that the script uses the shell variable USER, which by default will be set to the name of the calling user, so if you run the scripts as root, it will try to download e.g. https://raw.githubusercontent.com/root/dietpi-rock4cp/main/dietpi-add-overlay instead of the intended https://raw.githubusercontent.com/herrfrei/dietpi-rock4cp/main/dietpi-add-overlay *Fun fact*: "root" is an existing GitHub user, so if that user were to create their own repository with the same name and put malicious scripts there, all kinds of "interesting" things could happen 😄 The second reason is that the scripts have the wrong download repository name, using "dietpi-rock4cp" instead of the actual name which is "dietpi-rpk4pc". You can work around both problems by doing something like: curl https://raw.githubusercontent.com/herrfrei/dietpi-rpk4cp/main/rock4cp_usb_otg.sh | USER= REPO=dietpi-rpk4cp bash (I haven't actually tested whether it works correctly using that, just that it will download the right things) — Reply to this email directly, view it on GitHub <#883 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACWI2ON3B26WZUKWHJYURPT2HGWBJAVCNFSM6AAAAABPGOO3QGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNRVHE4DIMY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[herrfrei]

Error corrected (hopefully for good), thanks again!

[luisg707]

Hi, I am configuring a brand new Rock pi 4C+. When I run the installer,

curl https://raw.githubusercontent.com/marcone/teslausb/main-dev/setup/generic/install.sh | bash

it runs, restarts, then provides

RESIZE_ATTEMPTED

I take it that it's erroring out trying to shrink the volume:

lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mmcblk1 179:0 0 238.3G 0 disk
└─mmcblk1p1 179:1 0 235.9G 0 part /var/log.hdd
/
zram0 251:0 0 1.9G 0 disk [SWAP]
zram1 251:1 0 50M 0 disk /var/log
zram2 251:2 0 0B 0 disk

deleting the RESIZE_* and rerunning does not fix the problem. This is on a 240GB Card. after a ton of research, I cannot figure out how to fix this, nor how come nobody else has this problem since I'm following the configuration line by line.

Using this image:
Armbian_community_24.11.0-trunk.167_Rockpi-4cplus_noble_current_6.6.52_gnome-kisak_desktop.img.xz

[marcone]

You can probably get a non-desktop image from wherever you downloaded that desktop image.

[jheyneman]

@luisg707 you'll probably want to try https://github.com/armbian/community/releases/download/25.2.0-trunk.86/Armbian_community_25.2.0-trunk.86_Rockpi-4cplus_bookworm_current_6.6.63_minimal.img.xz

Back when I last set up my Rock 4c+, I had to use the desktop image because once I ran an update on the minimal Armbian, it would no longer boot, but I adjusted the install script to keep the root partition larger. I also ran into the same problem where after a few months, it stopped booting last week.

For now, I'm trying the DietPi setup a bit higher in the discussion. It seems to be working well so far.

[luisg707]

Trying DiePi :) Looks like I got past the pre-setup. Thank you!

[luisg707]

Great news_ DietPi worked well! I will make a PR to the Wiki with the instructions that I followed as an alternative; thank you @jheyneman & @marcone

The only part that isn't working (and I do not believe it's related to RockPi4C+ is footage being archived--

I see I'm using 70% of /

I triggered archive; and the footage appears to still exist on local storage (as well as NAS). Do I need to purge weekly on local storage?

[marcone]

Great news_ DietPi worked well! I will make a PR to the Wiki with the instructions that I followed as an alternative;

(unfortunately) you cannot make PRs to Github wikis. You can only edit them.

The only part that isn't working (and I do not believe it's related to RockPi4C+ is footage being archived--
[...]
I triggered archive; and the footage appears to still exist on local storage (as well as NAS).

If it got copied to the NAS then it seems that archiving worked, no?

Do I need to purge weekly on local storage?

https://github.com/marcone/teslausb/wiki/FAQ#q-do-i-need-to-manually-clean-up-the-recording-drive