jock

This makes me think you have some fake specs: rk322x cannot address more than 2GB of RAM and 4GB NANDs are pretty uncommon - never seen any rk322x with that amount of flash memory. Looking at the log dump I see 1Gb of RAM for your board. Anyway I don't understand why you are such an old image from 2020...

@fukowaka glad to hear your board works fine. I suggest you to use a mainline kernel if you don't have a NAND, the kernel is way more up to date. Legacy kernel builds are very old and I just keep them for people with NAND boards. The eMMC tuning options (which obviously applies only to boards with eMMC/eMCP and not NAND) can give a consistent boost to eMMC throughput, but your mileage may vary.

@Seth Your issue is due to the low pin strength used for GPIO, in some earlier tests I found that lower pin strength for wifi increased overall stability so it is set that way by default, but probably the stability issues were caused by something else. I should set them back to default values. Anyway you should tell what is the real board in your scishion v88 box, as far as I remember, there were some chiptrip mx4vr or something like that into...

armbian does not boot from sdcard with Android bootloader. It will boot from sdcard once it is installed in emmc, so you can test other armbian images from sdcard without overwriting emmc.

Four or five posts above there is the answer: https://forum.armbian.com/topic/17597-csc-armbian-for-rk3318rk3328-tv-box-boards/?do=findComment&comment=146012

Looking at the USB vendor and device IDs, your chip is not a rk3228a but an rk3128. You may say "But the chip is labelled rk3228a!": there have been past evidences that labels on the chip have been manipulated; I remember a case of a user were the chip was an rk3228a but the label was "Amlogic S905W". rk3128 in different unsupported chip.

LIRC comes after the kernel-based handler. You should investigate ir-keytable instead, that will change the kernel-level key bindings for the remote.

If you run echo b > /proc/sysrq-trigger from root does the board reboot or turns off?

The multitool should boot in every case, don't know the reason why it does not boot 🤷‍♂️

I have no tv boxes with rk3328; also the marketing name does not really mean what is the board inside. If you have such a board you can try and select led-conf3 in rk3318-config which currently is the most suitable for rk3328 boards

@Willy Moto I had time to check the apt issue about being slow... it definitely too slow when it generates the dependencies tree, so a get a bit deep into. In my case I solved going into /etc/apt/sources.conf.d, renaming of any repository (I suggest box64.conf or nala.conf) with suffix .disabled, run apt update, then enabling back the repository and running again apt update. Now the dependencies tree is built in a blink of an eye.

Well, I may guess there is a problem somewhere else. It could be an issue with the sdcard/emmc or a power issue (does openssl speed -multi 6 rsa turn off the board?), because the unresponsive system - not being able to ssh in - means not only the monitor blanks, but the board turns off or freezes. The board should also have a blinking led by default, does the led stop blinking when the system is unresponsive?

@Willy Moto well, I have an eMMC too but I have no such error. Maybe it is because I'm booting from sdcard, but absolutely I don't know what to say. Surely the "degraded" systemd status does not hamper the system in any way, but you should debug more to understand the real cause of that.

That's right: on first boot it is configured to do autologin, so you configure the root and user passwords and then the desktop appears automatically. I tried the steps you did, but apt update and then apt upgrade worked pretty well, the system was perfectly functional even after reboot. The issue though is something I never heard about. In practice, whenever you are asked and enter the password, either from GUI or CLI, the screen goes blank. It looks totally weird to me, really never ever heard about such issue on any of my platforms and boards! I wonder if the board is still responsive when the monitor goes blank: could you login via ssh? do dmesg says something intersting about display? what is the output of sudo systemctl status lightdm (or sudo systemctl status gddm if you are on gnome) ? if you run, from ssh console, sudo systemctl restart lightdm (or gddm if on gnome) what happens? You should get again the login prompt and be able to login

@Willy Moto uhm, smartmontools should not die so bad, as long as eMMC have no smart capabilities AFAIK; maybe debian sid has a wrong configuration in /etc/smartd.conf that causes the error, because right now have installed a fresh ubuntu jammy image on a sdcard (and no SMART devices attached) and has no such issue. The only enabled directive in my /etc/smartd.conf is this one: DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner

Hmmm, please confirm the timeline: Fresh new image burned on sdcard: everything works, you can login and you get a fully working desktop. Then you do apt update (but no apt upgrade ?), reboot, then you can login and then the monitor turns off? apt update alone does not do much to the system, it just downloads the catalogue of updates, but does not install/change anything. From Xorg.0.log you posted, the X.org server correctly detects 1920x1080 resolution (there is no 75Hz, just 60Hz refresh rate though) and tries to use that, but as far as I understand you took that log while you had your desktop running: this does not give any clues about the failure reason just because there was no failure, since the desktop was working fine 😅 I will check a fresh image and do apt update && apt upgrade to see if anything breaks on my system.

Well, I just checked the jammy cli image and it looks pretty normal to me. After configuring it with rk3318-config and rebooting, I don't have the "degraded" systemd status, cpufreq-info shows the board running at most 1.3ghz, dram is running at expected 667 Mhz and everything seems at the right place. Also openssl speed -multi 4 rsa gives me expected speed results (I usually take a look to the 4096 bits benchmarks) rsa 512 bits 0.000065s 0.000005s 15428.9 182723.3 rsa 1024 bits 0.000313s 0.000016s 3195.9 62525.2 rsa 2048 bits 0.002079s 0.000056s 480.9 17820.1 rsa 3072 bits 0.006352s 0.000122s 157.4 8218.6 rsa 4096 bits 0.014272s 0.000212s 70.1 4725.6 rsa 7680 bits 0.110870s 0.000728s 9.0 1374.1 rsa 15360 bits 0.667811s 0.002874s 1.5 348.0 edit: maybe apt update is slower because there are more packages installed (my images were minimal cli images, these looks like standard cli images; still server-oriented, but carry some more preinstalled packages)

Hmm, no it is not normal. There is no secret sauce in my builds, actually recent builds I tested privately were built against armbian master, as like as nightly are. I checked the rk322x builds but not the rk3318 ones; I will take a look!

Thanks for the EDID, I don't see anything particularly wrong there and also the monitor is correctly detected. I may just believe that since that 1920x1080@75Hz may be untested/incompatible with some HDMI timings programmed in the kernel. Please also post the file /var/log/Xorg.0.log, but honestly I don't know what can be wrong with your setup. You could also find instructions on the internet on how to force 1920x1080@60Hz when X.org boots, instead of autoprobing the resolution mode, maybe this could help giving you a usable graphical interface. For example, the file that contains the monitor configuration is ~/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml, editing from the command line using nano could help.

@oolonthegreat This thread is for rk3318 and not rk3188; please open a new thread for that request and also remove the long log lists from here because they make the browsing from mobile very difficult. @Aapo Tahkola I meant the four pads at the right of the IR receiver, not the three pads near the led array: those are clearly pads for diodes if you pay attention to the symbols. Looking at the back of the @uehqsvbm's board, those four pads have a different wiring than the IR receiver and from the front side there is no immediate connection to the IR receiver; It is not 100% sure because there could be some in-board layer connecting them to IR, but I may guess those are not for IR. Also the central pads immediate connection is to a couple of components that seem to be resistances. They could also be spare connection for leds, but in such case a single resistance would suffice and placing resistors there is a waste of components since the board does not have leds there. Looking at the front side, the rightmost pad is surely ground (it has the reverse triangle symbol), and the leftmost maybe is VCC (there is a path going to IR receiver), maybe the two central pads are uart RX/TX. About the led blinking led issue, this is what google suggests as first answer: https://linuxreviews.org/HOWTO_Control_LED_Lights

ethernet is always working in armbian, it is embedded in the soc, so if it does not work it means that armbian did not boot. Also the led should be blinking if the kernel is alive, but I see no leds on your board, am I right? You may try one of the newer images built from trunk above, maybe you got an image with the invalid voltages I published by error some weeks ago. The definitive way is to to debug this is using a USB-to-TTL serial adapter connected to the serial pads of the board, which are sometimes under the heatsink (but just sometimes...), or maybe are those pads in the lower right corner, near the IR receiver.

Announce: Hello, I want to announce that Community Supported Configuration (CSC) board images are now built again by Armbian servers on a weekly basis! This means that you can now download images for CSC boards (including xt-q8l-v10) browsing from https://github.com/armbian/community Images are built from trunk, GPG-signed and SHA-sum is provided. Feel free to donate if you find this useful and wish to offer support to the Armbian developers and maintainers. Enjoy!

Announce: Hello, I want to announce that Community Supported Configuration (CSC) board images are now built again by Armbian servers on a weekly basis! This means that you can now download images for CSC boards (including rk322x-box) browsing from https://github.com/armbian/community Images are built from trunk, GPG-signed and SHA-sum is provided. Feel free to donate if you find this useful and wish to offer support to the Armbian developers and maintainers. Enjoy!

Announce: Hello, I want to announce that Community Supported Configuration (CSC) board images are now built again by Armbian servers on a weekly basis! This means that you can now download images for CSC boards (including rk3318-box) browsing from https://github.com/armbian/community Images are built from trunk, GPG-signed and SHA-sum is provided. I also removed the manual instructions for upgrades: Armbian 22.08 release is imminent and from that time on it will be sufficient to use apt to get kernel upgrades too! Thanks for your patience! Feel free to donate if you find this useful and wish to offer support to the Armbian developers and maintainers. Enjoy!

@armbianorange2hero hello! esp8089 unfortunately has some rough edges that need to be addressed. And AFAIR the driver is not included in mainline kernel but only in legacy kernel. The driver was just not compiling on mainline kernel. Modifying and trying to fix a kernel module without being able to test it later - I don't have any board with esp8089 - is a bit pointless IMHO 🤷‍♂️