jock

@Slash402 Thanks for the log, I see that the ddrbin detected 1gb of ram. That is, there is nothing to do because that code is a proprietary closed-source rockchip blob and it does the detection:

@Slash402 Mmh, if you didn't cut the firmware on purpose, then it may be that the eMMC is broken, it has been reported in the past that these boards have very lousy soldering and the eMMC is often failing after a while, just be aware of this. About the soldering points, this is the front side of my board: You can see I soldered an array of holes in the bottom-left corner. You can solder directly some wires to the pads or do whatever you find better for your case. The pin with the downward arrow is Ground (GND) and this must be absolutely connected to GND of the serial adapter. The two immediate pins on the left of the GND pin are TX and RX. Honestly I don't remember which one is RX and TX, so you have to connect them to RX and TX pins of the serial adapter and see if it works; if it does not work, switch the pins. The leftmost pin should be left unused. About the software to use, I don't know if you use linux or windows. For Windows Putty is surely one of the best options, on Linux there is a pletora of suitable application like minicom or picocom. You can search with google. Transmission parameters are: 1500000 bps (1.5mbps), 8 bits per symbol, no parity, 1 stop bit ("8N1" for friends). Good luck!

@Slash402 checked the proprietary ddrbin of the firmware you supplied, it is exactly the same as the one available in the armbian image, so the problem must be somewhere else. The serial output from your box is definitely required.

@Slash402 Thanks for the firmware, it looks like there is only the first part of the firmware and not the whole eMMC image. It is sufficient to do some tests on my board, but beware that you won't be able to restore the original system with that, I hope you cut the file on purpose... About the serial adapter, yes it is the one you shown in the photo. On the "front" side of the board you have the serial pads (there are "GND", "RX" and "TX" label markings nearby) that you solder and connect to the serial adapter to grab the serial output of the box. The baud rate of the serial must be set to 1.5mbps

@Slash402 For the original firwmare, you should upload it on some services like google drive, mega, or whatever and then post the link here. For the serial output, I guess you don't have an USB-to-TTL adapter, so for now the original firmware will suffice.

@Slash402 Well actually *i suppose* you have 8 chips (the other 4 should be on the other side). To be sure I need both the serial output of the box when it boots and the original firmware of your board. There are several reports that armbian detects a lower amount of memory than installed chips, but we have not yet understood if the chips are fake or the issue is really software-related.

I have the same board and the specs on the chassis of the tvbox says 4GB of RAM and 32GB of flash; the flash amount is correct, but the amount of RAM is actually 2GB 😕 In your case, this is the datasheet: each memory chip is 2 gigabit, so 8 chips account for 2 gigabytes.

That's a deliberate choice to avoid proprietary rockchip binaries as most as possible or use "tested" binaries, use mainline u-boot and keep the bootloader part "tiny". In reality, these assumptions were made initially for rk322x images, where the bootloader has been compacted into the first 2 megabytes of emmc, but on the rk3318 images this is partially true. To make the long story short, the multitool uses the rockchip proprietary boot layout, while on armbian there is a custom layout and custom binaries. Since rockchip socs always boot from eMMC first, the stock bootloader is fired first and it does not like custom layouts. To run armbian from sdcard you need to remove the stock bootloader, thus the fastest way is to erase the eMMC.

Yup, often you need some other "recommended" packages to get the whole thing working right. Sometimes they are listed as reccomended/suggested packages by apt itself, some other time they even are not That's the same for weston, for example: if you install the "weston" package it just does not work if there aren't the EGL/OpenGL libraries already installed.

@regepower Hello, don't expect great desktop performance, the SoC is generally very limited and it was not its purpose to run x11 desktop. The best thing you can do, if you already didn't, is to disable the desktop compositor from setting -> windows manager tweaks -> compositor. Generally this helps a bit with performance, but as said, it won't change a mouse into a kangaroo 🙃

@Dario Murgia Don't worry, it is not essential, it was just good to know. However the fix has been mainlined in armbian

@Dario Murgia ok thanks also for this other clarification and yes, that's exactly the way you describe: so, only the X88 Pro overlay will receive this fix 👍 edit: do you remember the other board signature on the pcb?

@Dario Murgia Very, cool thanks for reporting! In fact I had no chance to test SPDIF when I originally worked on rk3318-box dts because my old board had no spdif. I will check on the newer board if the spdif is working selecting the other pin configuration and put a general fix for the dts!

@Dario Murgia Mmmh, I had the chance to try an image with latest 6.1 kernel on a rk3328 box and audio was not properly working in any case. Analog audio is working with speaker-test/aplay but not with pulseaudio on xfce, SPDIF was completely not working. Pulseaudio also was missing one of the three audio devices. Definitely I need to take a look to this, I recently received a rk3328 board with SPDIF coaxial connector and thus I can try, but you have to be patient. The nodes in the device tree seems to be in place, but perhaps some setting is wrong or a gpio that enables/disables the spdif output is missing. I need to check that.

Well, I don't know exactly, but I don't think your board has a problem. Most probably the issue is in the closed binary code that does something that put the board in suspend. Usually this does not happen with other boards, just with yours and I have no explanation for that. A possible solution would be to use an opensource trust os, which is available for rk322x, but it is something I can't do in a matter of few days but requires some further study to integrate it into the rockchip boot flow successfully.

The trust os of the original firmware is very old, but yet I don't know the reason why the trust os from the multitool is acting weird. Unfortunately that piece of code is a closed binary blob and I don't know what it is actually doing. I arranged another multitool with a different trust os. It is not guaranteed to work, but you may try: https://drive.google.com/file/d/1b0BOwdr0J6XxYDyn1HfprtmBPhMHIfnV/view?usp=share_link

@tommyboy mmmh, it looks like the trust os is bringing the board down for some reason. You can see that from the strange characters [6eggK... you get at the serial prompt. Now I don't know which piece of software is misbehaving, if the trust of the multitool or the trust on the board, because the very first piece of the log is missing. You should set the serial adapter to 1.5mbps to grab the first part of the log, then post it here.

@tommyboy what do you mean with "multitool stops"? You are supposed to interact with it with a monitor attached to the board HDMI port or via SSH, not using the serial adapter port that is just for debugging. The log looks pretty fine to me, you should be able to use the multitool.

@Dario Murgia u-boot dtbs are not really useful because are stripped down versions of the kernel dtb (not dtbo), which is the right one to inspect. I usually extract manually with hex editor finding the signature 0xd00dfeed, but perhaps that tool is way easier or there is another tool from Sergio Poverony that maybe @fabiobassa can help with!

@tommyboy You did not specify if armbian stops working or the multitool. I guess you're talking about the multitool, since you posted the dmesg of that one. Try to substitute rk322x-box.dtb in the multitool partition with this one: rk322x-box.dtb and try again

v2022.07 should work fine either too; the ddrbin was clearly the issue there. It can indeed; the spdif nodes are surely different because the original android rom surely uses kernel 4.4 and in the meantime the syntax on how to declare the sound nodes changed. There may be some different gpios involved though, and the original dtb may help detecting them.

@Dario Murgia It looks like the ddrbin @666Mhz is not working on your board. I was suspecting such bad behaviour from long time because in the past some other people with X88 lamented booting problems but no serial logs were provided, now there are some evidences that frequency is not universally compatible. That's a shame because 333Mhz for the DDR is limiting performances a lot, but I guess I will revert that change and use the ddrbin @333Mhz for the time being; I suggest you to take the previous binary from that commit and use that one to build your images.

@Dario Murgiahello, very glad you had no issues installing the image. About the SPDIF issue, actually I don't remember having really tested it on rk3318, I will check as soon as I can. Perhaps the alsa mixer worth a check, maybe the volume is low or there is some other setting (mute?) preventing the audio from spdif.

4gb of ram and quad-core cpu are not a guarantee of good performance. The rk3328 armbian branch lacks some DRM kernel optimizations that rk3228 has, and in fact the desktop performance is a bit better on rk3228. You could try KDE Plasma or gnome: despite being fully-featured desktop environments, they work much better than xfce or lxde. Ah, on xfce you should also disable composition from Settings -> Windows Manager Tweaks to improve performance.

Yes, but you have to install armbian on the eMMC because the stock bootloader does not allow USB boot (armbian bootloader does).