All Activity

Yes, your logs show hundreds of errors, so it will be hard to pinpoint which one it is exactly. Here's a few things I can suggest that might move you along. "sudo service restart lightdm" # see if X now comes up on your TV, assuming that lightm is what you are using "sudo nano /home/*/.xsession-errors" # check the errors listed in those log files, they are more specific Can you try to flash an (older) image to a microSD card, boot off it and see what the results are? @Efe Çetin is the maintainer of your board, maybe he has a comment? Your board is in community-maintained status for armbian. There are no guarantees.

Do you know how to compile your own images? Do you know how to use "git bisect"?

@WERNER If I try to use xrandr through an SSH connection using putty I get the response 'Can't open display' I can use it in terminal via remote connection and the basic command returns: Screen 0: minimum 256 x 256, current 1364 x 768, maximum 16384 x 16384 rdp0 connected primary 1364x768+0+0 0mm x 0mm 1364x768 50.00* Messing around with xrandr, there seems to be more than one way to skin a cat, if I try something like: xrandr --output rdp0 --mode 1280x720 I get a response of 'cannot find mode 1280x720' I experimented with all manner of normal resolutions that I have used before and even tried both the minimum stated by the plain xrandr command, 256x256 and 16384x16384 but get exactly the same response. It would seem likely that 1364 x 768 is why my TV is not showing the desktop because I suspect the resolution is not supported. But I feel between a rock and a hard place for something that seems become hard locked. @laibsch I poured through the log I posted above but much of it seem to be more rocket science, so hard to pick out something that logically points me in the right direction.

The last working image is 25.5.0-trunk.256, which is still available for download. I will try to look into the situation as my time allows. Thanks for the hint where to start.

I am always happy to see people keeping old hardware running. But I think it would be best to make the necessary changes in Armbian itself. I am happy to help out where I can be useful.

The ones I linked. You mentioned that you have no experience to compile stuff. One option is to target another SBC or a virtual machine so that you can focus on learning the build framework (explicit instructions are already given in some of the links) instead of having to deal with a multitude of issues (setting up your compilation host, getting compilation to succeed, finding the artifact to flash, only to then run into the next issue that armbian currently does not support your board). With a virtual system, you can be sure that you should get a working image. You can then focus on the compilation and familiarize yourself with that before jumping into real hardware enablement.

Do you have specific instructions for installing the X96 X6? @Chris4arm Thank you very much.

I added a suggestion at the PR how to implement the driver while building to allow network oob.

I suggest you check the logs for clues what is going wrong. syslog, .Xsession-errors, etc.

Thank you for reporting about this issue. What is the latest image that still works? Is it still available for you to download? Maybe this is the change you want to revert and see if that brings things back in line? But supposedly, that commit was boot-tested by Niklas. Your board does not have an official maintainer in armbian, so I suggest you contact Niklas to find out what the situation is for him.

Ok I was able to get the LCD working with a self built image, by copying the linux config from the armbian.com image to the build/userpatches/linux-sunxi64-edge.config Currently rebuilding without the successful linux config, and then I will look at the difference Update: I didn't find any differences and the new image without the userpatches config accepts the LCD DTS and bin file. Ok, I dont understand what was happening before. Now I am getting the same X11 error as before: MESA-LOADER: failed to open panel-mipi-dbi: /usr/lib/dri/panel-mipi-dbi_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/aarch64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri) I see that this panel-mipi-dbi_dri.so is part of libgl1-mesa-dri debian package, in DEBIAN SID, but not Bookworm https://packages.debian.org/sid/arm64/libgl1-mesa-dri/filelist https://packages.debian.org/bookworm/arm64/libgl1-mesa-dri/filelist Next, when I rebuilt the armbian OS with xfce desktop, I get the same panel-mipi-dbi-spi error: can't find the bin file. I checked the config again... and it was the same Update: It was easier to build Sid minimal, and install labwc (wayland), just remember to install seatd: https://eirenicon.org/labwc-a-tutorial/

@C127 Thank you for taking the time to try and make this work! I tried running the image from your github on two of my Orange Pi 5 Pros, and unfortunately all I get is a solid white LED without any progress even after ~2-3 min. Joshua's 6.1 Ubuntu works fine. Any idea on what I need to do to make the Orange Pi 5 Pro boot with your image / build? Happy to help debug or enable you to make progress. Vulkan on an RK3588 board would be amazing!

try code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } xrandr

Hello everyone, I have an old POS machine that uses the Rockchip RK3288 processor. It has a 1920x1080 screen and works fine, but I don’t have any root or bootloader unlock permissions. I would like to flash Armbian on it and make better use of the device. So far I’ve tried: ADB access (only recovery available) Tried using adb reboot bootloader, but the device just powers off Identified some test points like KEY, T3, T2, T52, T51, but not sure which one is for MaskROM shorting Found no physical recovery button, only a reset and power button There might be a UART port, but I’m not sure 👉 Can someone please help me: Identify which test points or pads I can short to enter MaskROM mode Locate a possible UART debug port on the board Any advice for dumping original firmware or unlocking bootloader I've attached front and back photos of the mainboard. Any suggestions or experience with RK3288 boards are greatly appreciated! Thank you 🙏

I noticed that the resolution had been changed from 1920x1080 to 1364x768 but when using remote desktop there is no way to change the resolution using the GUI. Is there a terminal command that can do it?

FYI: I managed to fix my eMMC again, I found a working spl_loader bin file to flash with rkdeveloptool. See the following post for details:

To add a datapoint: In the past, I've been succesfully installing to eMMC using `armbian-install` using an Armbian 24.2.1 Jammy image. IIRC I had to change the `ftdfile=` line in `/boot/armbianEnv.txt` (as documented at https://www.armbian.com/orangepi-5/) but it otherwise worked right away. Now recently I have been playing with newer bootloaders and images and kernels (in order to fix an issue where a reboot hangs), and in that process I updated the U-boot on the eMMC, which caused booting from eMMC to fail, and when booting from SD card, I no longer have the eMMC device so I cannot fix this (I think this might be exactly what @sns1081 describes in the first post of this topic). I've been trying to fix this (see this post for details), but on my previous attempt I could not get `rkdeveloptool` to work: it kept giving "Write LBA failed!" errors on on the `wl` command. I suspected this was because I needed the `db` (download bootloader) command first to download and run a bootloader to then handle the `wl` command, but I could not find the right spl_loader file. But with this thread (and in particular this post by @Andrius Vainorius) offered a filename I could google and then found it here: https://dl.radxa.com/rock5/sw/images/loader/rock-5b/release/ With that, at least the db and wl commands work: ❯ sudo ~/bin/rkdeveloptool db ~/Downloads/rk3588_spl_loader_v1.15.113.bin Downloading bootloader succeeded. ❯ sudo ~/bin/rkdeveloptool wl 0 some_img.img Write LBA from file (100%) For this, I cannected USB-C cable to the J11 USB connector in the middle, powered up via the USB-C connector in the corner and pressed the maskrom button on powerup. Note that it did not seem to be necessary to have the rkdeveloptool and the images to write in the same directory, as suggested by others here. Note that the the "some_img.img" is an image I lifted from an SD-card with Armbian 24.2.1 Jammy, so it is not the original clean image, but it does have the same stuff on it. Just the above commands recovered my board: It can boot from eMMC again and the /dev/mmcblk0 eMMC device is available again (both when booting from eMMC and when booting from SD). Analyzing why eMMC was broken before, I compared the serial output from the broken and fixed cases. The main difference is here seems to be the u-boot SPL version. AFAIU, this is what happens: Some ROM bootloader boots, which loads U-boot SPL from eMMC U-boot SPL checks SD-card and then eMMC to load the main U-boot Maybe there is another bootloader stage involved (between ROM and SPL, since there is some serial output before SPL shows up that is different between both cases). Here's a diff of the serial output between both cases (up to the moment where U-boot runs and no more interesting differences appear): --- old-opi5.txt 2025-07-02 21:20:08.631329154 +0200 +++ old-opi5-emmc-fixed.txt 2025-07-02 23:01:17.982196616 +0200 @@ -1,26 +1,24 @@ -üDDR d5483af87d cym 23/11/23-16:15:24,fwver: v1.15 +þDDR V1.11 f1474cf52f cym 23/05/09-11:02:36 LPDDR4X, 2112MHz channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB Manufacturer ID:0x1 -CH0 RX Vref:29.3%, TX Vref:22.8%,21.8% -CH1 RX Vref:28.9%, TX Vref:20.8%,21.8% +CH0 RX Vref:28.5%, TX Vref:23.8%,22.8% +CH1 RX Vref:29.3%, TX Vref:20.8%,20.8% CH2 RX Vref:29.3%, TX Vref:22.8%,21.8% -CH3 RX Vref:27.9%, TX Vref:20.8%,20.8% +CH3 RX Vref:26.7%, TX Vref:21.8%,21.8% change to F1: 528MHz change to F2: 1068MHz change to F3: 1560MHz change to F0: 2112MHz out U-Boot SPL board init -U-Boot SPL 2017.09 (Feb 25 2025 - 08:48:59) -sfc cmd=9fH(6BH-x4) -unrecognized JEDEC id bytes: ff, ff, ff -unknown raw ID ff ff ff -Trying to boot from MMC2 -spl: partition error +U-Boot SPL 2017.09 (Feb 09 2024 - 18:56:36) +unknown raw ID 0 0 0 +unrecognized JEDEC id bytes: 00, 00, 00 +Trying to boot from MMC1 Trying fit image at 0x4000 sector ## Verified-boot: 0 ## Checking atf-1 0x00040000 ... sha256(7efcd01a0f...) + OK @@ -29,7 +27,7 @@ ## Checking atf-2 0xff100000 ... sha256(1163474a5b...) + OK ## Checking atf-3 0x000f0000 ... sha256(da90adf3a4...) + OK Jumping to U-Boot(0x00200000) via ARM Trusted Firmware(0x00040000) -Total: 304.579/460.237 ms +Total: 245.95 ms INFO: Preloader serial: 2 NOTICE: BL31: v2.3():v2.3-589-g3389cfdda:derrick.huang @@ -42,11 +40,10 @@ INFO: valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0 INFO: system boots from cpu-hwid-0 INFO: idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001 -ERROR: dfs get fsp_params[0] error, 0xfead0004 != 0xfead0003 -ERROR: dfs get fsp_params[1] error, 0x1111 != 0xfead0003 -ERROR: dfs get fsp_params[2] error, 0x0 != 0xfead0003 -ERROR: dfs get fsp_params[3] error, 0x60241520 != 0xfead0003 -ERROR: loader&trust unmatch!!! Please update trust if need enable dmc +INFO: dfs DDR fsp_params[0].freq_mhz= 2112MHz +INFO: dfs DDR fsp_params[1].freq_mhz= 528MHz +INFO: dfs DDR fsp_params[2].freq_mhz= 1068MHz +INFO: dfs DDR fsp_params[3].freq_mhz= 1560MHz INFO: BL31: Initialising Exception Handling Framework INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK @@ -67,18 +64,8 @@ CR: M/C/I Using default environment -no mmc device at slot 1 -Card did not respond to voltage select! -do_rkimg_test: dev_desc is NULL! mmc@fe2c0000: 0, mmc@fe2e0000: 1 -Card did not respond to voltage select! -PCIe-0 Link Fail - -Device 0: unknown device -Card did not respond to voltage select! -switch to partitions #0, OK -mmc0 is current device -Bootdev(scan): mmc 0 +Bootdev(atags): mmc 0 MMC0: Legacy, 52Mhz PartType: EFI DM: v2 Since in both cases, the main U-boot (Feb 09 2024) runs from the SD-card, I suspect that the U-boot SPL (or the preceding bootloader, if any) is somehow involved in setting up the eMMC properly, and the new one does not do the setup properly (or otherwise messes something up). Next things I could try are: Flash a recent Armbian image (different version/flavors) to eMMC using rkdeveloptool and see if any of those produce a working system/eMMC. Figure out how the boot process *really* works and what parts of the eMMC are loaded in what order and how Compare a working and broken armbian image (in the areas that contain bootloader-stuff) and swap out some of these parts to see what is the part that breaks it. However, my main issue is fixing reboots on the older armbian system we are using, so I might not get around to the above anytime soon (OTOH, it seems the newer U-boot SPL actually fixes the reboot issue, so that could motivate me to see if we can upgrade to the new u-boot version without losing eMMC).

@C127 any chance to make a release that already has the ethernet driver compiled and working ?

Thank you for the response. I've reviewed the PR you linked, and based on that, I have created my own: https://github.com/armbian/build/pull/8348 I appreciate the review. I have fixed the issue with the unnecessary wrapper in my `orangepi5pro.csc` file and have also addressed the other recommendations. Regarding the use of the latest U-Boot version, I did test it. However, it seems that with versions newer than 2024.04, U-Boot takes a very long time (~60 seconds) just to start the kernel. This is likely due to an issue from the refactoring that occurred after the 2024.04 release. Thanks again for your guidance.

I keep having trouble with panel-mipi-dbi-spi not finding /lib/firmware/panel-mipi-dbi-spi.bin even if it exists and it works in another Armbian and Raspberry. This happens only with the armbian OS that I compiled with default linux configuration. The armbian OS image that I downloaded from armbian.com can drive the LCD (but has other problems with X11). When I boot my image while watching the serial output, I only see "Starting kernel", then a few lines regarding udev, then the login prompt (sorry, I will be more exact when I get back home). I changed console=both to console=serial, in armbianEnv.txt but I still don't see more kernel or init messages while booting. How can I activate this verbose boot? Is there any chance that the /lib/firmware is not mounted and available to the kernel module in this early stage?

I did so, but openvfd still doesn't work and can't compile.

This partnership ensures customers can build embedded products with long-term maintenance viability that will meet the challenges of tomorrow, such as compliance with the CRA, all built on proven Toradex platforms and upstream-first software. View the full article

I meant to say "armbian", my apologies

Dear all, How can i auto login h96max armbian without input user name&password. Every time i turn on the box, i have to enter the user name&password. I don't want to do that the same to windows OS Thank you,

Hi. I get recent Standard Images for this Board Lamobo R1 with the A20 Sunxi from here: https://sd-card-images.johang.se/ works great. Cheers