jock

@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).

Hello, the problem is generally a bad quality software product (the driver) of the chinese wifi chip on the Opi4 LTS

@Eli Ribble Thanks for testing. The missing ethernet is quite strange on that board. I have a sample of that board and it works fine on mine; maybe they are two different revision, but don't know. About the HDMI problem, the 5.19.15 image you probably found here in the forum is an experimental image that uses the libreelec patches: when you upgraded the kernel, you got installed the standard armbian kernel without the libreelec patches and so the issue came back. For now, the discussion to implement those patches is stuck, so don't expect seeing them as in armbian kernels soon. Sorry, but that's not my choice 😕 (see here for reference

I'm not sure I understood what you mean with "normal armbian archive" and "experimental stable" terms What I really would like is one and only one place for public images to be produced and deployed; at the moment this place is the github community repository and it is perfectly fine to have one single place with the images, just missing the stable kernel images for the reason I said above (ie: edge kernel is not guaranteed to always work). The other images you find here and there, especially on users.armbian.com/jock URL, are old or experimental images, but surely unmaintained and prone to be erased sooner or later. For all the other needs, there is always the option to build a custom image, it will receive regular updates via apt just as well as public images do.

Never had particular problems with USB on rk322x/rk3288, but on rockchip 64 bit (in particular rk3328) the USB3 implementation has some issue that makes it quite a bit troublesome. I never investigated very througly in it though.

@MattWestB @SteeMan I've been thinking about that too and I would have liked to ask @Igor in the last release meeting but I did not want to be off-topic. Perhaps the community images are "too edgy", and perhaps it is more savvy to produce images with current kernel, then upgrade to edge via apt install, than starting with edge kernel, that is not guaranteed to work correctly, and then downgrade to current. I just had a very brief test after burning an image with kernel 6.1 and, against all my thoughts because I was sure I already checked kernel 6.1, it does not boot on my rk3318 box, while kernel 6.0 had no troubles in booting (broadcom bluetooth was broken although). Did not have the time and tools at hand to dig into the issue (moving into a new house...), but I hope to check better very soon, perhaps during the weekend. About moving rockchip64 to 6.1 for the next release, I'm a bit reluctant and maybe a bit more testing is required. 32 bit rockchips although seems rather acquainted with 6.1, no issue and no troubles so far (my HA testing rig on rk322x has an uptime of 10 days and doing a variety of jobs that is pretty amazing for the piece of junk it was )