CSC Armbian for RK3318/RK3328 TV box boards

[jock]

@Netraam31 hello! You're in the right direction, dr_mode="otg" simply can't work without a micro/typec usb connector. The main feature of the OTG port is the capability to switch on the fly in host or peripheral mode, but to do that a fifth pin in required. Regular USB-A ports have only 4 pins, so when you get them you surely cannot exploit the OTG feature.

The USB port is still called OTG because it is "dual role" (host vs. peripheral), but simply cannot switch automatically, hence you have to change it in the device tree.

 

Finally what is true for the rk322x is true also for rk3318: during my tests the peripheral mode was not behaving correctly without disabling the clock gating and adjusting the core reset timing. The clock gating issue has been fixed in kernel 6.8 (the patch addresses the issue on 6.6), but the reset timing can still give some trouble.

 

Mass storage mode was my testbed, along ethernet emulation; what is still not working at all is the audio gadget which, I guess, uses isochronous mode which is still buggy.

 

Anyway you surely have to set the OTG port as device mode you have to use dr_mode="peripheral" in the device tree. On rk322x there is a quick device tree overlay to do that, without editing and fiddling with details. I don't remember if there is a similar overlay for rk3318/rk3328, but I guess not.

 

Notice also that you will not see any USB device connected on the other side when USB2 port is in peripheral mode until a gadget is set up.

There are several guides around (especially for raspberry pi) on how to setup a gadget, you can use them to actually test the port.

 

 

 

[Netraam31]

Hi @jock, thanks for your quick reply. I originally used dr_mode="peripheral" as I indeed read earlier that the auto-switching otg wouldn't work on standard old USB A interfaces. So that it didn't work properly in dr_mode="otg" confirms my understanding.

But even when I have it in dr_mode="peripheral", and while kvmd is running and in its logs says something about configuring the gadgets (keyboard, mouse), the USB A - USB A connection to the other host seems to be "dead". Nothing to be seen at either end. Tried with only ground/data+/data- and with ground/data+/data-/5v connected. Neither seems to work.

 

In the documentation, there's also something about adding "overlays=usbhost0 usbhost1 usbhost2 usbhost3" to /boot/armbianEnv.txt but unclear if that applies to rk3318 as well. Tried with and without, but that also doesn't seem to help.

I'm comfortable with editing dts/dtb files, but don't have enough knowledge about all the details in there.

 

As I've been trying to tinker with too many things over the past days, I think I'll first revert back to a fresh img to make sure there's nothing from older xe5700 kvmd-armbian in the way blocking srepac's version from working properly.

 

One last question for now: the changes you backported from 6.8 to 6.6 for rk322x, are those also already included in the 6.6.23 (306) image for rk3318-box? Or should I expect clock gating issue to still be present in the rk3318-box files?

 

 

Edited April 4 by Netraam31

[jock]

1 hour ago, Netraam31 said:

One last question for now: the changes you backported from 6.8 to 6.6 for rk322x, are those also already included in the 6.6.23 (306) image for rk3318-box? Or should I expect clock gating issue to still be present in the rk3318-box files?

 

Actually the issue was fixed only for rk322x in 6.6; if you take a look to the patches, I didn't backport but made a special case for rk322x on my own: I was not aware if other rockchip chips were affected by the issue. A few days after, the same clock gating fix materialized in the 6.8 kernel for all the rockchip chips. Anyway, this is just for the chronicles; about your specific question the answer is yes, the issue is still present for rk3318/rk3328 in kernel 6.6.

 

I'd like to take a look this evening and do some tests and in case make a patch for rk3318 too, stay tuned for news!

 

[jock]

@Netraam31 I did a quick check on a board with rk3328 (not rk3318, but should be the same) and you can use both the USB2 OTG port or the USB3 port as peripheral.

in the device tree the device usb@ff580000 is the USB2 OTG port controller and usb@ff600000 is the USB3 port controller.

 

I quickly tried ethernet gadget to check if it works. This command loads the USB ethernet gadget module. which is a bit of "deprecated" in favor of configfs, but it is handy for tests (run it with the USB cables connected):

 modprobe g_ether iSerialNumber=0x00000001

 

Then a device usb0 should spawn on both the machines, which is nothing more and nothing less than a regular network interface. You have to give an address to both the endpoints and then you should be able to ping and exchange data.

 

The result is that, at the current state of the kernel 6.1 I have right now (but 6.6 is exactly the same, since nothing changed), the USB 3.0 port is working plenty well, instead the USB 2.0 port is suffering the same problems experienced for rk322x, which disconnection and system freeze.

 

Things seems to have changed with kernel 6.8, where also the USB 2.0 ports seems to work, thanks to the upstreamed fix for clock gating. You should be able to upgrade to kernel 6.8 installing the linux-image-rockchip64-edge package or, more appropriately, via armbian-config.

 

Don't forget to put kernel and dtb packages in hold if you modify them manually, otherwise updates will overwrite your modifications!

 

 

 

[Netraam31]

It appears that the

overlays=usbhost0 usbhost1 usbhost2 usbhost3

mentioned in the readme at https://github.com/srepac/kvmd-armbian is not necessary for rk3318-box.

As you said, setting dr_mode to peripheral works for both the usb2 port and the usb3 port. Not tried both in peripheral mode at the same time, as the other port would be in use for the usb hdmi capture 😉 

Behaviour is the same (or at least while running the 6.8.4 edge kernel) when using usb2 or usb3 port for otg hid.

It appears the two sets of kvmd files (parts in /usr/local/lib/python3.11/ and parts in /usr/lib/python3/) didn't go too well together and I just had to restart from clean image and only use srepac version.

 

Sometimes the hid keyboard/mouse don't survive a host reboot.

I've seen the same when using pikvm on an older pi3b with the pico hid, if you connect the pico to the pi's 5v line through a diode.

Disconnecting otg cable's 5v wire appears to make this more reliable here as well, and also wouldn't backfeed the rk3318-box through the host's usb ports. That gives random weird issues anyway, and the rk3318-box would even continue running when you disconnect the rk3318-box's barrel plug. But some parts would probably fail due to lack of stable power supply, and random issues would arise until powercycled properly.

 

So thanks a lot @jock for your assistance!

[jock]

Hello, for anyone who is having difficulties with HDMI, I made an experimental 6.6.25 kernel with a very small number of patches from LibreELEC project available here.

I can't test by myself because the rk3318 board I have was already working with my monitor, yet the patched kernel did no harm on my setup.

 

If there are some successful reports, the patches will be merged into armbian and hopefully the HDMI issues will be fixed once and for all.

Thanks!

[astrosky]

@J Black KatI'll try it.  Hoping it fixes things     @jock

Edited April 7 by astrosky

[astrosky]

@jock so basically i tried to install your patch and this broke my setup and all i see is a red led.  not sure why i cant seem to get this working with a newer kernal.  but i guess i need to go back to what i did before or try to fix it  no hdmi and now no way to ssh as the board is in some kind of frozen state  i rebooted after applying the patches   

 

I prepared for the installation by ensuring that the necessary .deb files were in my Documents directory. These files were named linux-image-current-rockchip64_24.5.0-trunk_arm64__6.6.25-Se475-D0618-P53bb-Ca832H66b1-HK01ba-Vc222-B2804-R448a.deb and linux-dtb-current-rockchip64_24.5.0-trunk_arm64__6.6.25-Se475-D0618-P53bb-Ca832H66b1-HK01ba-Vc222-B2804-R448a.deb.

I ran the command sudo dpkg -i for each .deb file to install the new kernel and DTB packages. The output indicated that the installation process included preparing, unpacking, and setting up the new packages over the old versions.

During the kernel package setup, an update-initramfs process was executed, generating a new initial ramdisk for the 6.6.25-current-rockchip64 kernel and converting it to U-Boot format. The system then updated symlinks for /boot/Image, /boot/initrd.img, and /boot/uInitrd to point to the new versions.

For the DTB package installation, it was similarly unpacked and set up, with a symlink from /boot/dtb to the new DTB directory for the 6.6.25-current-rockchip64 kernel being created.

I concluded the update process by rebooting my system to apply the changes. This was done using the sudo reboot command.  but now red led is shown and no signs of life 

[jock]

@astrosky mmmh, pretty weird that it broke your setup, it is a quite standard 6.6 kernel, also it does not touch the bootloader.

Did you perhaps alter a device tree and changed it in /boot/armbianEnv.txt? because the /boot/dtb directory is replaced when the new dtb package gets installed.

[astrosky]

@jock this im not sure ........  can you recommend a image i can just install and then work from there? preferably something that starts out with things not as broken then i can simply configure it and install your patched kernal stuff AFTER?  im thinking a fresh install then straight to the patch could be the ticket  then ill disable kernel updates  straight after, even if it breaks hdmi out as long as it lets me ssh in ill be ok 

 

 

well i installed Armbian-unofficial_24.5.0-trunk_Rk3318-box_bullseye_current_6.6.23_minimal.tar  no hdmi output but i could ssh in   then i installed your patch.   setup the default config stuff now i got a blue  led and red      no hdmi out still    also could not install armbian config or run it as it does not exist for some reason in this build.... its just super confusing  as my box is a x 88 pro  like everyone else 

Edited April 10 by astrosky

[jock]

@astrosky I can't recommend you an image you can just install and everything works... tvboxes have this little problem about the changing hardware and that's not so easy.

I have repeated dozen of times that tvboxes are not the way to go, buy an SBC if you need reliability.

 

About 6.6.25 kernel, now I understand that you repeated the procedure starting from 6.6.23 image and this time the board rebooted fine but still without HDMI, am I right?

[lucky62]

Hi all,
I have a problem with OpenVFD compilation with the kernel 6.7.4-edge-rockchip64.
Seems the gpiochip_find() was removed...

Can someone help?

 

[astrosky]

@jock yeah basically no HDMI out on any Verizon 6 and above kernal based on what I tested.    The older 5 kernal works on basic desktop though. 

[jock]

@lucky62 looking with elixir, it turns out that the function was already deprecated in 6.6: https://elixir.bootlin.com/linux/v6.6.27/source/drivers/gpio/gpiolib.c#L1022

 

You could copy the body of the deprecated function in place of gpiochip_find

 

About of_get_named_gpio_flags you should see if you can afford to use the suggested function

[tERBO]

Anyone running gnome on this chip?
I have 3318 paired with 4Gb of RAM and the GUI is very slow. Choppy mouse movements, loading youtube front page with chromium takes forever, cant play videos without stutters even at 480p.
Is it supposed to be like that or do I have to enable 3D accel somewhere/somehow?

 

I know stock android fw renders at 720p (even tho you can select 4k resolution for your display) so it wont surprise me this chip just have a bad graphics core...

[astrosky]

@tERBO I run xfce4 when my HDMI works and I find it runs ok.   But yeah YouTube videos play very bad for me in general. Maybe hardware acceleration isn't working? 

[pocosparc]

@lucky62 Change your line 736 to

pin->pin = of_get_named_gpio(pdev->dev.of_node, name, 0);

 

[jock]

@astrosky @tERBO this may help you getting hardware decoded videos, but don't expect your browser work with them.

Mixing hardware video decoding into browsers compositors is not an easy task.

[s1cx]

Installed this on an old Heltec Helium miner

Any idea how to enable SPI so spidev shows in /dev/?

 

[pessimism]

Hello, wanted to post up a success note and thank you to Jock and everyone else who has contributed to this work.  I bought myself a stack of four tv boxes to play with each with different processors.  Started with the H96 Max V11 RK3318 4GB/64GB.  I read up on this thread and this person's guide and opted to build myself a trunk image from mainline to see how its doing, using the non-edge 6.6 kernel.  So far its been the most painless bringup on a TV box I've done so far (owned a couple of older amlogic ones in the past that were pretty rough to work with), the tooling has come a long way in the past few years.  I found a copy of the vendor firmware and used AmlogicKitchen to unpack it and retrieve the nvram file for the broadcom-based wifi to work, its an HS2734C, with the proper nvram file I have 2.4 and 5ghz wifi working.  I've attached a copy if its of any use, I see now that there are a few versions floating around the internet already.

 

TODO: Get HDMI audio to work.  Don't see an HDMI audio output and haven't had time to investigate.  Will report back.

 

I applied your 1.3ghz CPU tweaks in rk3318-config along with both EMMC tweaks (DDR and HS200) and they appear to be holding.  I see an HS200 message in dmesg about the EMMC and the CPU is boosting to 1.296ghz.  I'm currently burn-in testing it by bootstrapping a gentoo prefix inside the armbian environment, she's been maxed out for an hour now and holding strong, core temps are peaking at 82C maximum load then settle into the low to mid 60s, which is pretty good for this QC reject chip from what I've been reading about how leaky they are

 

One question:  When I did the installation, I opted to do a full emmc backup.  I am able to see that the resulting (60GB!) image has a GPT and named partitions inside.  I attempted to loopback mount them via kpartx and mount, but only a couple out of the 15 partitions will mount.  The rest seem to have no recognizable file system.  AmlogicKitchen won't work as it doesn't start out as a rockchip packed image like the recovery firmware from the vendor's website.  Do you have a script or tool to fully unpack the backups that multitool creates? (for grabbing nvram, firmware, dtb etc.)

 

Anyhow, sketchy TV box made of reject parts now a functioning desktop computer compiling software for itself.... awesome! 

brcmfmac4334-sdio.rockchip,rk3318-box.txt

Edited April 26 by pessimism

[ThaisTaki]

Hello, I am a user of your version, my English is quite bad, I am using a TVbox T9 series and it uses rk3328
it's fine in the file version
Armbian_22.05.0 wlan is fine but I use upgrade or use file version
Armbian_23.08.0 no longer recognizes wlan, some unimportant things like LEDs are not recognized when I use rk3318-config, hope to be supported soon ^^

The picture I sent is quite similar to my device, sorry for not being able to take a photo of my device.

[jock]

On 4/26/2024 at 2:18 PM, pessimism said:

One question:  When I did the installation, I opted to do a full emmc backup.  I am able to see that the resulting (60GB!) image has a GPT and named partitions inside.  I attempted to loopback mount them via kpartx and mount, but only a couple out of the 15 partitions will mount.  The rest seem to have no recognizable file system.  AmlogicKitchen won't work as it doesn't start out as a rockchip packed image like the recovery firmware from the vendor's website.  Do you have a script or tool to fully unpack the backups that multitool creates? (for grabbing nvram, firmware, dtb etc.)

Hello!

 

First of all, multitool creates a 1 to 1 image of the content of the eMMC; no bits are changed and nothing is rearranged in any way.

What you get in the backup is the exact content of the eMMC, some of those partitions are raw partitions that does not contain a filesystem, but rather just raw data. For example the uboot and trust partitions normally contain binary data, so you won't be able to mount them in any way because they are not filesystems. You could inspect with a hex editor though.

[jock]

@ThaisTaki Hello! I did not remove any particular driver or feature from earlier versions.

Perhaps you were using the older vendor kernel 4.4 in the previous installation? In such case, it is not supported anymore, so some device may have lose support.

 

Also notice that, depending on your board (I can't read the signature/silkprint on that from the photo), you may have to run rk3318-config twice to enable the correct driver.

[Hqnicolas]

On 4/26/2024 at 9:18 AM, pessimism said:

I am able to see that the resulting (60GB!) image has a GPT and named partitions inside.  I attempted to loopback mount them via kpartx and mount, but only a couple out of the 15 partitions will mount.  The rest seem to have no recognizable file system. 

 

You can use this method: https://forum.armbian.com/topic/28895-efforts-to-develop-firmware-for-h96-max-v56-rk3566-8g64g/?do=findComment&comment=189369
to shrink your 60gb image onto small file

 

[Netraam31]

Hi again,

 

Quick update for potential other readers, and some questions.

 

I've now also got overlayroot setup to keep the internal flash mounted as readonly for normal operation. So as to not burn through the flash's endurance counters within a year on a device that's writing logs, status information, etc. to flash continuously. And also to protect it against issues when people just pull the plug while it's operational, potentially corrupting flash and making it unusable without physical recovery. Seems to be working great, but had to adjust the initramfs hook and script files (mount -o move instead of mount --move in script, and adding lines to copy_exec /bin/grep, /usr/bin/stat, and /bin/echo to the initramfs.

Seems to be working just great including with pikvm.

 

Two questions:

1. My rk3318 android tv box "H96 Max v11" does have the two red/blue leds on the pcb, but no clock display. There are solder points on the pcb though. Would it be possible to use these pins for GPIO access (maybe even add an I2C RTC module), or would that not be possible within the limits of hardware/firmware? Any pointers on where to start looking, if at all possible?
2. In pikvm config, following generic instructions, I was able to easily add the usb ethernet gadget and do routing/masquerading for the attached device. Yet, when I tried to configure usb mass storage gadget, the result was that the keyboard/mouse stopped responding in pikvm. From the pikvm documentation (unfolding the USB limitations section) it looks like there could be an issue with capabilities of the chip in relation to the number of endpoints needed. Yet, that page mentions mass storage would require 2 endpoints for each msd, and usb ethernet would require 3 endpoints per emulated device. So it's strange that ethernet does work but msd does not. Enabling only one at a time, of course. Is there any data on the number of endpoints available on the rk3318 chip? Or maybe someone knows how to make msd working? Or.. maybe it was intentionally disabled in srepac's kvmd-armbian because it's not working either way? The usb ethernet gadget was disabled in the config as well but works like a charm, so not sure why msd didn't work as expected. Or maybe msd is only supported for the usb3 port and not on the usb2 port that I'm now using for otg connection to the remote? Sorry, too many question marks here... Any pointers would be much appreciated!

 

[jock]

On 5/2/2024 at 4:10 PM, Netraam31 said:

I've now also got overlayroot setup to keep the internal flash mounted as readonly for normal operation. So as to not burn through the flash's endurance counters within a year on a device that's writing logs, status information, etc. to flash continuously. And also to protect it against issues when people just pull the plug while it's operational, potentially corrupting flash and making it unusable without physical recovery. Seems to be working great, but had to adjust the initramfs hook and script files (mount -o move instead of mount --move in script, and adding lines to copy_exec /bin/grep, /usr/bin/stat, and /bin/echo to the initramfs.

Not really needed to do that for wear prevention: armbian is already optimized to write logs in a zram device (so they are kept in ram and compressed on the fly) and also swap space is by default a zswap device.

 

On 5/2/2024 at 4:10 PM, Netraam31 said:

My rk3318 android tv box "H96 Max v11" does have the two red/blue leds on the pcb, but no clock display. There are solder points on the pcb though. Would it be possible to use these pins for GPIO access (maybe even add an I2C RTC module), or would that not be possible within the limits of hardware/firmware? Any pointers on where to start looking, if at all possible?

Don't know, it could be possible if some pins are directly connected to gpios, but for what I know they are connected to another led driver chip which is surely missing on your board, so the answer is probably no.

 

On 5/2/2024 at 4:10 PM, Netraam31 said:

In pikvm config, following generic instructions, I was able to easily add the usb ethernet gadget and do routing/masquerading for the attached device. Yet, when I tried to configure usb mass storage gadget, the result was that the keyboard/mouse stopped responding in pikvm. From the pikvm documentation (unfolding the USB limitations section) it looks like there could be an issue with capabilities of the chip in relation to the number of endpoints needed. Yet, that page mentions mass storage would require 2 endpoints for each msd, and usb ethernet would require 3 endpoints per emulated device. So it's strange that ethernet does work but msd does not. Enabling only one at a time, of course. Is there any data on the number of endpoints available on the rk3318 chip? Or maybe someone knows how to make msd working? Or.. maybe it was intentionally disabled in srepac's kvmd-armbian because it's not working either way? The usb ethernet gadget was disabled in the config as well but works like a charm, so not sure why msd didn't work as expected. Or maybe msd is only supported for the usb3 port and not on the usb2 port that I'm now using for otg connection to the remote? Sorry, too many question marks here... Any pointers would be much appreciated!

I tried msd on the usb2 port for both rk3318 and rk322x socs and it kinda works. The rockchip implementation of the dwc2 IP (the silicon behind the USB2 port) seems to be a bit buggy and the dwc2 driver also seems to be a bit buggy, so the whole thing is a bit buggy. Nonetheless it worked on my side, but had to make some patches for the kernel (see this) that you don't really need if you're running kernel >= 6.8 but definitely if < 6.8. As a note, audio gadget was totally out of reach.

 

Did not try having two or more USB gagdets at the same time. From the uboot dwc2 driver I'm inspecting, I see #define MAX_ENDPOINT 16, but take it with a grain of salt.

 

USB3 port seems to work a bit better.

 

edit: dmesg tells that the 3318/3328 has 10 EPs, so I guess it is an accurate number