jock

@Maker39 The problem with power-on with remote is that the box is... powered off! The original firmware does never really shut the box off, but keep it in suspend state in u-boot, u-boot "listens" and then is able to react to remote power key and trigger the bootstrap. When you shut down in armbian or libreelec, the box is really powered down, so you need to do a full power-cycle. I didn't investigate too much into this problem, but this is a very common problem on most boards on different platforms when you switch away from original firmware.

You disguised very well I would have said you were American, or Mexican Nope didn't experience anything like that, but I will definitely check. Which image are you using? In the meantime, could you run openssl speed -multi 4 rsa and post the summary results here? It's just an openssl benchmark to compare performances.

I'm getting a bit suspicious about this ssv6x5x driver, which does not appear anywhere in rockchip source code. Maybe our ssv6051 is a stripped down or older release, or just an incompatible driver with 62xx series, despite it is heavily based on

My guess is that ssv6051p and ssv6256p share the same driver. Looking into the code I see no reference about ssv6x5x file name at all. This is the dmesg messages related to ssv6051 module with ssv6256p firmware: as you see, at a certain point it says something about a register not containing the expected value and then reports errors

@nokirunner yes, most probably it is the right firmware file, but for some reason the last time I tried it didn't work. The driver is not very helpful in describing what is wrong, just fails with a bunch of cryptic debug messages and so. But I guess I can give it another chance!

I didn't try to compile Kodi yet, but instead I did a quick test using the packaged one from Ubuntu Focal, which was 18.6 if I remember well. It starts, I get to the splash screen, but then it hangs the board and can't even change to another virtual terminal.

I'm interested in lima too. At the current moment on libreelec it works very well on different platforms (rockchip, but also amlogic, don't know about allwinner but I guess it works fine either). On my armbian builds here, i don't know the reason why, it fails both in running X11 (which can be expected), but also Kodi without the X server, which in theory is the same configuration as libreelec.

Seems a pretty interesting project. Good luck for that! Unfortunately the keep costs down, tv box makers use chips from unknown and unreliable sources, then happens that the vendor failed (at least rumors say so) leaving us with a very badly written driver. That is one of the reasons why I avoid cheap tv boxes when doing serious pet projects, a proper single-board-computer is much more suited. As @fabiobassa said, ssv6051p driver is suitable for ssv6256p also, but for some reason it does not work.

Yep I totally misunderstood

@nokirunner @Maker39 As far as I know, the only programming USB port should be the OTG port. Sometimes it is labeled on the PCB, sometimes the enclosure has the OTG label, sometimes there is nothing telling you which port is the OTG one. For example, the Scishion Model X (the same owned by @nokirunner) I got here has 2 USB ports, none of them is labeled OTG in any form and they are both labeled as "USB" on the chassis without any number on them. Other devices, like the MXQ Pro 4K has the OTG signature on the PCB corresponding to the USB 4 port labeled on the chassis. So it's a bit of hit and miss, but finding first the OTG port looking at the board can avoid many headaches later

in maskrom mode, before doing executing any command, you must upload the loader. rkdeveloptool db command may come in handy, you can see how to use it on the first page in the "Restore the firmware" section. But I would say it is far easier to just boot into linux. Just plug the sdcard into and boot with the eMMC shorted. Remember to unshort as soon as you see the red led.

I hope you didn't damage the eMMC. It could be that the eMMC is not available because you shorted the eMMC clock pin at boot. Shorting the eMMC to ground makes it unavailable to first stage bootloader. Keep us informed about progress.

@nokirunner sorry but I don't have ever used that tool so can't be of any help.

Hello, sorry for replying so late, but didn't get the mention from your previous post. The service file you quoted in that post contains the systemd service that activates the bluetooth userspace service. It contains the invocation to hciattach /usr/bin/hciattach /dev/ttyS0 bcm43xx 1500000 that will create the bluetooth device for use of other applications. First you need the firmware file in the right place. Unfortunately hciattach is a legacy program, it wants the firmware file in /etc/firmware, so: create the directory with mkdir -p /etc/firmware symlink the firmware wth ln -sf /lib/firmware/brcm/BCM4330B1.hcd /etc/firmware At this point I suggest you to do some tests using hciattach command above. You may need to modify the command line because /dev/ttyS0 device is the serial device the bluetooth is attached on rockchip boards. You should first find which is the UART the bluetooth is attached to on your board. Be sure it is active in the device tree (so it is exposed as /dev/ttyS* file in the filesystem) and then change it in hciattach command line above. Use hciconfig -a to see if the device is exposed to the system and hcitool scan to scan for bluetooth devices. Once you have found the right serial device: modify ap6330-bluetooth.service to use the right serial device copy ap6330-bluetooth.service file in /etc/systemd/system to make systemd aware of the new service, run systemctl daemon-reload to make the service run at every boot, run systemctl enable ap6330-bluetooth You can find the references in armbian scripts of above steps here

@nokirunner Very glad to hear you brought the board to life again

@nokirunner I got an identical board to yours here, thanks to @fabiobassa I can show you the eMMC clock pin. There is a small white circle in the upper left angle of the eMMC chips, that's the pin 1 of the eMMC. The eMMC clock pin is the 7th starting from the top on the other side. Now in this photo @fabiobassa soldered it for me, because he is much more experienced. Before proceeding any further please answer the question on the previous post and burn an image provided in the first page of this thread on your sdcard and check if it boots. If does not boot remove the power, and try to short the clock pin using a cross-headed screwdriver: push the head of the screwdriver with a bit of force (but not too much) between the 7th and 8th pins to connect the two pins. While you're shorting the two pins, attach the power cord, then remove the screwdriver. If the procedure went well, the red led should become very bright after a couple of seconds and after 15 seconds the blue led should start blinking. If this does not happen, power off the board and try again. I just tested this on my board and it works.

@nokirunner I'm really sorry this happened Everything seems odd to me, beginning from the unusual USB device ID, sdcard allocated to mmcblk1 (it should be mmcblk0) and now this unexpected brick. 1. Did you use the images provided by @Maker39 or those provided by me on first page? If you used one from Maker39, try to burn an image provided by me, put the sdcard into and boot again. 2. Did you run armbian-config and followed the instructions to install in internal eMMC or you did install in another way? 3. Did you run the hexdump command I suggested you in the previous post (here) ? It was useful to understand if you really got an rk3229, because that USB device ID is suspect.

Your board, your rules

Did you blacklist 8723cs module to let rtl8703bs work? The MAC address unfortunately is still an open problem, it requires further attention but I haven't any board with 8703/8723 chips to test This is strange. Are you using original images or those "cured" by you? I suspect that if you're using the cured you have to change the device tree manually creating the resource.img file from the device tree and put it in the right partition. Also can you post the whole dmesg output.

Can't you just backup /dev/mmcblk2 from armbian using dd? I have absolutely no experience with encrypted/secured devices because I never got any in my hands and I don't know what happens if the internal bootloader is wiped out here. Maybe @hexdump can give some advice. Also, could you please post here the result of this command: hexdump -C /sys/bus/devices/rockchip-efuse0/nvmem

That's a question I can't answer for sure, since I don't own any S905X3 devices. My experience on amlogic is limited to S905 soc and I can confirm that the "draconian" approach works: once you erase the eMMC (or ground the clock pin of the eMMC chip), it will try boot from the sdcard. Most probably nothing changed with later chips, since this seems to be the common behaviour among various chips and vendors too, so my answer can be "probably yes"

All the images in the first page have been updated with the following news: Single image for all boxes! Configure your box with sudo rk322x-config once the system has booted Support for Realtek 8188eu, 8189es/etv, 88x2bu and various other wifi chips General better stability eMMC in DDR mode for some boards Enjoy!

Yep, I'm finalizing the process of migrating all the boards into a single image, you should be able to find the board rk322x-box in the list if you want to compile. Tomorrow I will upload new images and new instructions.

@hexdump But that's exactly the point I want to highlight: those little differences and customizations of some unlucky boards make thinking about a framework hard and maintaining it even harder.

About VPN, currently there are much more opensource-friendly VPN alternatives, OpenVPN is de-facto standard nowadays and it available for linux, windows and macos. If you need a stable solution, you may try it out. Armbian also has support for wireguard, which is one of the most exciting VPN recently merged into linux kernel due to being very fast and secure, and it is ideal for embedded devices. About the 2GB partition size, normally armbian enlarges the partition on first boot to fit to the device size. You can, however, do it yourself enlarging the partition and then using ext4 standard tools to adapt the filesystem. It's a matter of seconds and there are plenty of tutorials on the internet on how to do that.