jock

@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 🤷‍♂️

@Vittorio Mori I was thinking about just the other day about, indeed OpenWRT is a great addition for such cheap hardware and is very welcome! Reading the post I intend it is a "hacked" rpi2 image to work on rk322x I guess it should not be too hard to fork the openwrt project and add bullt-in support for rk322x, as long as the base architecture is armhf as much as rpi2 and below. The challenging part is the bootstrapping which is totally different. Maybe opening a thread on the official openwrt forum could attract more interested people there, I would be one for example... edit: for example, openwrt already has official support for Xunlong OrangePi SBC boards; roughly our tvboxes are in the same area. Indeed OrangePI boards have all the same hardware, instead tv boxes boards hardware is a mix and match, that is troublesome for having official support, but at least having a repository which can be clone and used as a reference for the image generation is indeed a big step forward!

@uehqsvbm Hello, are you able to ping the machine once armbian boots? You should at least have a blinking led if the kernel is alive. Even if there is a problem with HDMI or generally with the display output, your board at least should boot, get an IP from the network and be reachable; you should be able to access via ssh using root user (default pass: 1234).

Ok, took a look to this. xrandr of course works only when there is an X11 session running; it must can be run from a SSH session of the same user logged in X11 this way: export DISPLAY=:0 xrandr --verbose About get-edid, it requires the right bus on the command line because autoscanning does not seem to work (can be run either from SSH session or a terminal): sudo get-edid -b 7 | parse-edid This is what I get, for example, on my system with a basic 21" HP monitor: paolo@orangepi4-lts:~$ sudo get-edid -b 7 | parse-edid 7 This is read-edid version 3.0.2. Prepare for some fun. Attempting to use i2c interface Only trying 7 as per your request. 256-byte EDID successfully retrieved from i2c bus 7 Looks like i2c was successful. Have a good day. Checksum Correct Section "Monitor" Identifier "HP 22w" ModelName "HP 22w" VendorName "HPN" # Monitor Manufactured week 15 of 2019 # EDID version 1.3 # Digital Display DisplaySize 480 270 Gamma 2.20 Option "DPMS" "true" Horizsync 30-80 VertRefresh 50-60 # Maximum pixel clock is 170MHz #Not giving standard mode: 1920x1080, 60Hz #Not giving standard mode: 1280x720, 60Hz #Not giving standard mode: 1600x900, 60Hz #Not giving standard mode: 1680x1050, 60Hz #Not giving standard mode: 1440x900, 60Hz #Not giving standard mode: 1280x800, 60Hz #Not giving standard mode: 1280x1024, 60Hz #Extension block found. Parsing... Modeline "Mode 10" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 0" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 1" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 2" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 3" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync Modeline "Mode 4" 74.250 1280 1720 1760 1980 720 725 730 750 +hsync +vsync Modeline "Mode 5" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 6" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync Modeline "Mode 7" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 8" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync Modeline "Mode 9" 25.200 640 656 752 800 480 490 492 525 -hsync -vsync Modeline "Mode 11" 148.50 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync Option "PreferredMode" "Mode 10" EndSection

@deciorocha I don't see anything special to run a lamp server on armbian. Just follow any tutorial for debian (I guess you're using a debian minimal image) and it will be fine; there's really nothing special in armbian to do, since the image is a totally regular debian distro.

@fukowaka Hello, some answers: no mixed android/armbian boot. It is done this way on purpose: no random proprietary pre-installed crap, for a number of reasons. It is possible to manually make the thing work, but on first u-boot upgrade the installation will probably break and you will come here asking why apt upgrade broke your system the "dts from lakka" is not suitable, don't mix things, they won't work as @RaptorSDS said, minimal variant is suitable for headless server usage again, as @RaptorSDSsaid, armbian makes use of device tree overlays and rk322x-config makes easier to configure board specialties. There would be hundreds of device trees to support boards minor and major differences, device tree overlays solves this thing. Don't use other distro dtbs, they will break things.

I agree with @Werner, I was asking if an adapter was in use to understand if there could be an interference with the HDMI signal. The output of these commands can be useful: xrandr --verbose get-edid | parse-edid (you may wish to install read-edid package first for get-edid and parse-edid utils)

@MX10.AC2N Didn't you try already 5.18? I remember you already had issues with 5.18, but that was my fault because I downvolted the CPU by mistake; upgrade debs should be fixed now and there should be no issues anymore, as long as also other people found them working stable so far. About the Jammy edge image, it is an experimental image with KDE Plasma preinstalled. It works, but there is a kernel bug in lima that often causes kernel panics, so it is not "public" not suggested to put in any kind of use. The bug seems to be fixed in 5.19, so I guess soon there will be a proper publishing.

I did not test 5G wifi connection, this issue seems it has been already raised in the past and honestl I see little room for improvement from armbian side: IMHO there is something missing from the driver or the firmware for the wifi chip. It was unexpectedly painful to integrate the wifi driver into mainline 5.15 kernel (it worked fine on 5.10) that I totally forgot to test 5G connection; anyway the driver has several shortcomings on its own that the missing 5G functionality does not surprise me. About the HDMI issue, can't say anything: never experienced such issue on my full-hd basic monitor. What monitor are you using? Did you try another cable or another monitor port? Do your monitor has audio? Are you using any kind of adapter?

Yep, it is way strange, "unfortunately" HDMI works fine on my board with both 5.15 and 5.18, so I can't experiment such issue. dmesg may provide some useful information about, there is a dmesg attached to an older post were there was clearly a drm error I never encountered before and can't guess the reason causing it. Anyway congrats to bringing the board up!

Well I didn't expect a fully conformant Vulkan driver since hardware is not thought for such API. I expected something more like this https://github.com/Yours3lf/rpi-vk-driver as long as Videocore IV is way older and limited than Midgard or Bifrost (which, according to Alyssa, has been sawed away from PanVK as well... 😕 )

You're welcome. I hope someone will try to bring an open Vulkan driver over Mali hardware, that would be very nice when will happen.

@DmitryS There is no opensource OpenCL driver in mesa, what you want to use is the closed source binary. The closed source binary requires the closed source drivers; it can be installed and probably brought into working state, but it is a real PITA since it requires the proprietary mali kernel driver first, then the closed source blobs and finally the closed source OpenCL driver. I hope I scared you enough, because that way is very scary by itself. Just a side consideration: people, in general, should be very thankful for opensource drivers that make things work out of the box and should heavily blame companies that put obstacles - like ARM does.