Netraam31

I have an X88 PRO-B-RK3318-D4-V1.6 (2021-09-25) here with led display. (Commercial name X88 Pro 10) Led display chip marking was barely readable but with the lighting in a specific angle I was able to read: AiP1628. Which does not appear to be pin compatible with the fd6551, but looks like it could be fd628 compatible. Not sure how far off those two are - didn't look into datasheets yet. So could very well be out of scope for your driver. Happy to upload original "chinese" firmware/find relevant files/... if that would help. Also have an RK3318_V1.4 202303.200629 that appears to have a compatible PCB for fd6551 chip but this doesn't have the chip populated (and no leds other than blue and red smd leds on the pcb).

Happy to assist - any instructions on getting the file needed? So far my attempts to mount an android partition in multitool didn't really seem to work well, and I've been using "strings" on the bare partition to get a few text files that I wanted..

I want to share an observation, and have a question linked to that. Not sure if this is the right place to ask, so please guide me to other threads if it would be more applicable there. Observation / steps: - installed one of the standard trunk images (bookworm/minimal), running a -current kernel - go into armbian-config and switch to -edge kernel - apt update, apt upgrade - that would install newer -current kernel and seems to be booting from that instead of from -edge (or at least there are cases where this happens, probably related to availablility of new -current and no new -edge packages in the repo) So it looks like armbian-config wouldn't remove the -current kernel package (even though I do see so messages during that process, indicating it would be removing the current kernel) and just installing the -edge kernel (+dtb) package alongside. Question: could it be that the switch to -edge kernel would indeed not uninstall the -current kernel package but only remove some of the files in /boot, that would be placed back by an upgrade of the -current kernel package? My current workaround to prevent going back to -current, and to prevent having an unbootable system, is to first remove the -current linux-image and linux-dtb packages, and then reinstalling the -edge linux-image and linux-dtb packages. But it seems a bit backwards to first go through armbian-config and then still doing this manually. Not sure if armbian-config does more than just install these two packages?

Partly a "parse error" for me (also not a native speaker so could be me), so not sure what you agree with 😉

Thanks @jock Well aware of the second fact. Yet deploying 15-20 times a supported ~400 euro "official" configuration versus the ~35 euro alternative was made consciously. And once deployed, as read-only devices with automatic updates being disabled, and no direct internet exposure, the "acceptable risk" was that it would just need to be delivered in a working state. The only thing that had not been fully thought through was the initial setup part for additional deployments, which is surfacing now, and may indeed very well lead to a revised decision on budgets versus "operational" risks. As for the fix: good to see the single line fix is already being discussed and would be in mainline kernel soon. For us, no need to rush. With the summer holiday season kicking off in Europe, we can stretch this process for another 2-3 weeks if necessary. Thanks for the update!

In terms of expectations management towards some people here: would there by any timeline for expecting the regular -current and/or -edge kernel updates would incorporate these reverts? So far it seems that with the current trunk.399 kernel the emmc is still not visible. Or, could this be resolved by updates to the device tree? I didn't look at too much detail, but given the error message and the patch, it could be that some device tree updates with more explicit configuration lines could also help in having the kernel code take the correct paths towards a working configuration? As a backup plan I could proceed with copying a pre-existing device's flash to a new device, wipe and regenerate ssh keys and tailscale secret, to get a new device into production. But aside from those two keys/ID's I would expect some more device-unique parts would be set up on a device during initial boot. Such as some form of machine ID or something. So without knowing all of those details, the backup plan route feels a bit tricky.

Side note: I noticed that the older u-boot (also -edge, from around end May 24) appears to be progressing quickly, while the u-boot from both the -314 release image appears to hang for 2 sec between showing ff580000 and DWC2. (I think both u-boot-current and u-boot-edge, but I've been trying so many combinations that I could be mistaken here... at least the u-boot included in the -314 image does this) Didn't dare trying to update u-boot on my working H96, but this is what I noticed when first burning the -314 image (minimal, bookworm) on my X88 and later restoring the backup from the H96 onto the X88. Possibly related: after burning the -314 image on the X88, my keyboard stopped working in the usb2 port but did work properly in the usb3 port. With the usb2 port indeed being ff580000, this could very well be linked to u-boot failing/timing out to talk to the usb2 controller. If you want me to do some more debugging, just let me know. After wasting several hours on trying to get started with a fresh install I now just threw it aside 😉

Same for the 6.9.9 -edge kernel currently in the repository. I had a new X88 Pro 10 delivered, used multitool to erase flash and load the -314 release image, and it consistently kept failing after trying to changie to -edge kernel. I was already doubting the build quality of the device (also seeing the wifi antenna as a PCB trace versus the real component flying above the PCB as in my H96 Max V11), but this would indeed explain why it fails. Seeing the exact same repeated errors as in @tERBO's thread. Dumping a backup copy of my H96 onto the X88 using multitool (and adjusting for the ap6334 wifi module) resulted in a working system with an older 6.8 kernel.

I did the change to peripheral mode as suggested by Jock, by manually editing the dtc through armbian-config. But that would be required to be repeated every time you upgrade the kernel. (Similarly, I have to fix the brcm sdio file every time the armbian-firmware package is updated, but that was easily solved by an @reboot cron job.) Is there some guidance in preparing a device tree overlay for this to make it more "automated" wrt kernel upgrades? Or would that only be possible when the overlays are provided through some official armbian package? I found that with the -edge kernels, the usb2 port is also perfectly stable, and appears to have more EPs (endpoints) available, enabling the use of both keyboard/mouse, usb network and usb storage through kvmd. When trying that with the usb3 port, everything silently stopped working when trying to add more EPs than it could handle. For the USB2 port, it shows 10 available EPs in dmesg. For USB3 port, it doesn't show anything. But it's less than 10.

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: 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? 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!

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!

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?

Hi all, Thanks for all the hard work to get this running so extremely smoothly (multitool, 306 bookworm image) on my H96 Max 11, 4/64GB, with adjusted wifi nvram settings file) I'm trying to run srepac's kvmd-armbian on my rk3318-box. That install process is also very straightforward. The web portal and video capture (USD 4 usb hdmi capture device) work like a charm, but the HID doesn't. I've tried editing the dtb (dts) to set the ff580000 usb port to dr_mode otg and dr_mode peripheral, but the other host doesn't see anything being plugged in. The usb port (black, usb2) doesn't see e.g. usb keyboard plugged into the rk3318 box, so that looks like it is indeed being switched to no longer be usb host. In dr_mode otg is saw this error: 2024-04-03T14:23:32.465401+02:00 rk3318-box kernel: [ 28.008282] dwc2 ff580000.usb: dwc2_core_reset: HANG! Soft Reset timeout GRSTCTL_CSFTRST but in dr_mode peripheral this error message isn't shown. Yet, nothing is detected at the other end of the cable. The kvmd hid keyboard and mouse "devices" were created and kvmd seems to be initializing properly using these. Then I came across this page mentioning something with usb gadget issues on rk322x that would be identical to issues encountered for rk3318 devices. I see @jock did pick this up for rk322x last month, but no reference to whether or not it was also included for rk3318. Is there something I'm doing wrong, or maybe OTG only works for the usb3 port instead? Or is related to the fix that was provided for rk322x last month? Couldn't find a lot of documentation on usb otg / gadget configuration, aside from this topic mentioning OTG explicitly as being supported... I'd be happy to have keyboard and mouse working, not really interested in other interfaces, such as emulated network or emulated mass storage if those are hard to get working (as mentioned here). Just trying to find a simple solution for a non-profit to be able to simply remote support their workers in remote areas (1 or 2 workers in most cases) without proper local IT support, but trying to avoid having to procure larger numbers of 300-400 USD official pikvm devices if it can be done for 30 instead.