jock

The ddrbin is "packaged" by the u-boot command mkimage, then some other code (uboot SPL) is appended to the resultant binary. In theory the ddr frequency is set in just a bunch of bytes in the ddrbin, so substituting the ddrbin (or altering the target bytes) on the sdcard/emmc with a bare "dd" command would work. But that requires some math and a hex editor to find the exact position where to put it with dd command AND I don't know if there are some CRC checks that would break the whole thing. I need to investigate a bit about, surely it is a job for a script because manual intervention would be a bit risky.

AFAIK rk3128 is not supported in the mainline armbian code, perhaps some forks may exist but I doubt a lot they do.

I confirm this 👍

Ground must be connected on both the edge (the USB serial and the board), otherwise you can't get proper communication. That is essential and you can easily electrically break things when you don't connect the shared ground. Ground first, always! For the other problem about emmc erase: if you did erase from multitool and you can run multitool but not armbian from sdcard there could be two main reasons: your armbian image is a bit old and has the 667Mhz ddrbin; recent images have a slower but more compatible ddrbin your emmc is faulty and accepts but really does not execute erase/write commands (ie: you erase it, but the contents still remains)

If you meant a working image of the original firmware, note that only the Multitool can boot only from sdcard when a stock Android is installed.

@some0ne I can't tell you why multitool does not find the eMMC anymore, could be several causes, but without the multitool log it is difficult. A note about maskrom mode emmc clock pin, in case you are using or used that in the past: when the emmc clock pin is gated, emmc is de facto turned off. If you are able to get in maskrom mode, then you can erase manually the eMCP connecting the board via male-to-male USB cable and using rkdeveloptool: ./rkdeveloptool db rk322x_loader_v1.10.238_256.bin Downloading bootloader succeeded. ./rkdeveloptool ef The loader file and other instructions are on first page. However, at the moment I don't understand what you have on your eMCP, if Android boots, or is already empty or what? Lastly, I don't know where your 60 seconds issue comes from. You should first clean the eMCP from anything on it and then boot pristine armbian from sdcard, then we may talk about that.

Probably there is a GPIO that enables the toslink. Your board is new because I have never seen an rk322x with toslink. You should post photos of the board and the original device tree to get toslink supported. esp8089 works only on mainline, legacy is not maintained anymore

@some0ne Multitool has a menu entry with "erase internal flash" or something like that. It surely takes less than 60 seconds to reach that. For details on maskrom mode, see the first post.

@Sean Perez Sorry for the very late answer; I'm not sure the orange pi debian contains the proper patches or the proper device tree things; I strongly suggest you to use on of the latest armbian images. I tested it on Allwinner H3 with 1gb of RAM and it worked well, but don't know the status of the hardware video decoders of H618. Probably it is better to use a kernel 6.6 and ask support in the allwinner forums just to know what kind of hardware decoders have. Don't know if CMA is an issue, 128mb should be more than enough to decode full-hd content. rockchip has no need for large CMA buffers since hardware decoders have their own MMUs. If allwinner has a similar design should even not need CMA buffers. Raspberry Pi (1, 2, 3 and probably 4) GPU/VPU instead has no MMU, so it requires CMA for video decoding and 3d graphics.

Sorry but I don't have the older versions around; they can be rebuilt cloning the github repo and moving to the commit of interest. Usually the latest is always the best and more compatible. If the board reboots there is something else going on and the fact that after the spontaneous reboot there is no eMMC makes me think there is indeed something else going on, out of the control of the multitool. Erasing the internal eMMC and booting armbian from sdcard may help you trying to isolate where the issue could be, maybe your eMMC is just faulty or defective and is causing weird behaviour.

You're welcome This is actually not possible with the openvfd driver because it is not wired to the kernel led framework but is a totally custom module that just exposes the hardware to userspace.

@some0ne in the first page there is the updated multitool version. For some reason a closed source binary blob, on some very rare boards, turns off or put the board in suspend. The reason is not known, since something happens in a closed source blob. I don't know if it is your situation, but it looks something that already happened.

It would be nice to have a proper kernel driver for such device. As far as I remember, it uses a i2c-like bus with some minor differences; I looked into some time ago, but had to give up due to not enough time, but a proper driver would wire the led chip hardware with the kernel led framework to exploit all the kernel triggers and goodies.

Hello, I don't think any tv box has a microphone or microphone header anywhere. Some SBCs instead have the microphone on-board (like some Orange Pi boards)

Very weird, if the kernel module is loaded, there should be the device under /dev too. From dmesg I see something suspicious: [ 1249.869135] usbcore: registered new interface driver ch341 [ 1249.869317] usbserial: USB Serial support registered for ch341-uart [ 1249.869609] ch341 1-1.3:1.0: ch341-uart converter detected [ 1249.872306] usb 1-1.3: ch341-uart converter now attached to ttyUSB0 [ 3599.906107] input: BRLTTY 6.5 Linux Screen Driver Keyboard as /devices/virtual/input/input20 [ 3599.919207] usb 1-1.3: usbfs: interface 0 claimed by ch341 while 'brltty' sets config #1 [ 3599.921891] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0 [ 3599.921965] ch341 1-1.3:1.0: device disconnected so perhaps brltty is clashing with the usb device. If you are not using a braille device, you can try uninstalling it

Yes Yes, but you won't get any lima or panfrost anyway, 4.4 is way too old kernel. Also Panfrost is of no use, since it does not support Utgard (Mali-400) but only Midgard and above

I bet: your internal flash is NAND and you are installing the image in the internal flash. Read the first page for more info. Use sdcard and mainline kernel if you don't want up to date kernel and opensource drivers.

@Jaisere Hello, I wonder why you are using an image with the legacy 4.4 kernel, which I don't maintain anymore. That is an ancient kernel supplied by the vendor and it is several years old; the vendor (rockchip) maintained up to a couple of years ago, but now it is totally deprecated and unmantained. The only usefulness for that kernel is that it works with the internal NAND flash. Use images with current kernel (at the moment, current version is 6.1), which is mainline kernel. It does not support NAND, but it is maintained and supports practically everything.

@ego worker journal rotation is normal, the disconnection of the USB devices are typical of tv boxes adapted to do something else: tv boxes are not able to supply too much power and if the USB devices are not low power, they often disconnect. Nb: please put logs in a spoiler section, not code

Ah ok, thanks for this, I'll keep in mind with newer versions.

@ego worker Now I'm checking edge 6.6.7 kernel and it works like a charm: made some stress tests with openssl speed -multi 4 while running KDE and hardware video decoding with no particular issues My eMCP reads at most at 28.4mb/s in DDR mode, sometimes also times out, but it is a scrap board with plenty of issues; decent and non-abused eMCPs read up to 90mb/s in DDR mode.

But that's not a supported setup for ubuntu jammy or debian bookworm with this repository, perhaps it is better to discuss in a separate thread?

@ego worker during my tests the board was stable with days of uptime, but when some tasks were run it hang as well. Could not really understand where is the issue, but I did not dedicate any time to it. What overlays did you enable? R29s are very limited, they have no power regulators for cpu and logic so voltage is fixed. For this reason, cpu, ddr and gpu frequencies cannot scale up to nominal frequencies.

vo=gpu-next fails on my setups, but the rk3288 tinkerboard-s was one of my test beds and it did not show any reset issue. Also other boards did not show any particular stability issues.

Use the multitool and install the "Jump start" feature, then you should be able to boot from either sdcard or usb.