All Activity

I merged the Panthor overlay with the Vendor devicetree using the fdtoverlay command (since I'm using grub instead of u-boot), and now Vendor kernel with GPU is an option!! Thank you so much!!

@DiplDi I was doing some experiments on Armbian 25.8.1 Trixie, and I decided to do a quick try of installing the XFCE desktop (along with some others): sudo apt-get -o APT::Install-Recommends="true" install task-xfce-desktop It works under X, but not under Wayland. I found out that its Wayland support is experimental, and that if you install the labwc package, that will get it running (very very badly) under Wayland. But it does work well under X. It's possible a different wayland compositor (than labwc) will work better? I also tried with the Vendor kernel (with the Panthor GPU overlay), and the edge kernel. Edge GPU performs seemingly not at all under X, but vendor with Panthor overlay performs well in X. I initially logged in via the SDDM display manager, but I switched to LightDM, and that worked as well, although with a hiccup.

Hello, I just apt upgrade-ed my Armbian 25.5 from mid-August to 25.8.1 and it doesn't start after software reboot. It is usually headless, I plugged it into a monitor and all I get is a uboot logo in the top left corner. No message, nothing. The board is the Rockpi 4A. The system is on eMMC 😩 What do I do now to at least roll back ? At worst make a browsable copy of the eMMC ? Thanks! Antoine

That change is already merged into Armbian for the orange pi zero LTS. It was such a long time ago, I don't remember how to use it right now. https://github.com/armbian/build/blob/9ef5b99b220c5e77b55514136e025008c16ccbfd/patch/kernel/archive/sunxi-6.12/patches.armbian/enable-TV-Output-on-OrangePi-Zero-LTE.patch#L8 https://github.com/armbian/build/commit/41260ac309b487d241fec97ffbdeced730bc2d04 Partial progress log https://forum.armbian.com/topic/22226-orange-pi-zero-lts-tv-out-in-2022/#findComment-162035

Is it the 128x160 1.8" red screen? Combine the knowledge of https://forums.raspberrypi.com/viewtopic.php?t=380704&hilit=ST7735S#p2275556 and https://forum.armbian.com/topic/47971-driving-the-ili9488-lcd-40-inch-cheap-chinese-clone/ To use the panel-mipi-dbi-spi driver, which is more universal for SPI screens Warning: you will not get the spidev, and the linux OS will handle all the rendering. Also, X11 may have a problem with Linux 6.14, unless someone fixes a bug

I'm not sure what this adds? I saw a user struggling to get it working, I managed to get it working, so thought I would give my steps that they may help other people. I apologize. I have not read what you wrote earlier. Please write whatever you see fit your work can be very useful. Success to you in your endeavor.

dmesg | grep -E 'hdmi|gpu|drm' ?

I'm not sure what this adds? I saw a user struggling to get it working, I managed to get it working, so thought I would give my steps that they may help other people. I am happy to improve my instructions based on feedback from users like @SteeMan above, but I was not specifically looking for help. If my tutorial and responses are in anyway not wanted here, then feel free to delete them.

Ok, this I was not aware of. When I get a second I will try it out. I'm not sure how long editing remains open on my post, but if it works, and if I can, I will go back and edit

What can be said about this (help)? Answer: nothing. Please show the output of the UART download, show the source code of the overlay you are using. By reading specific data, users will be able to give you advice.

Yeah that won't work as that code has no support for extlinux. The extlinux way would be to add a line FDTOVERLAYS /path/overlayfilename.dtbo to your extlinux.conf file. Again, I haven't tested this, (I've had no overlays that I've needed to use for anything), but theoretically this is supposed to work.

I mean that creating the dts and executing: sudo armbian-add-overlay openvfd.dts Results in: grep: /boot/boot.cmd: No such file or directory Overlays are not supported on Meson64 based boards. I started to investigate, but realised it was a massive rabbit hole, and what with the note in the documentation saying: I decided that directly applying the overlay to the DTB and running an /etc/kernel/postinst.d/ script following a kernel update would be my path of least resistance. If I have overlooked something, I would happily update the instructions as, clearly, using an overlay would be far more preferential. EDIT: I should add, that I also tried compiling and adding the overlay manually, and adding an armbianEnv.txt for boot, but the overlay was not loaded.

I'm curious what you mean by this. I thought they were working via the extlinux.conf way of specifying them (although I will admit I've never tested this).

Simply mark whatever you want to quote and a box will appear to click:

Abandoned vendor-provided BSP roadblocks can be overcome when mainline Open Source projects like the Linux kernel are integrated directly. Get your upstreamed BSPs from day one. View the full article

I tested the upstream Debian and I only got 4GB as well, I don't know if that was stable or not. Actually some upstream Debian images I tried didn't work at all at first. Then I upgraded the firmwares on my board, following these instructions: https://forum.rvspace.org/t/visionfive-2-debian-image-released/994/75 Bu I was more precise than that, first I used the sdcard image and fimware files from 2.6.0 (said to work in that page): https://github.com/starfive-tech/VisionFive2/releases/tag/VF2_v2.6.0 Note: I had no display, I ran the firmware update commands over SSH. Then I rebooted, using the sdcard image from 2.11.5 (arbitrary chosen): https://github.com/starfive-tech/VisionFive2/releases/tag/VF2_v2.11.5 But I used the latest (5.11.3) firmware files to update the firmware: https://github.com/starfive-tech/VisionFive2/releases/tag/JH7110_VF2_515_v5.11.3 After that, I flased the latest image (202409), for sdcard: starfive-jh7110-202409-SD-minimal-desktop-wayland.img The whole 8GB is displayed and everything looks stable, the board is running since 9 hours without problem. But one problem is that this Debian image is based on an now-old Debian Trixie/Sid snapshot, which is painful to deal whit. I'll try again the Armbian image later to see if the firmware update fixed the memory size problem and the stability.

<off topic: If someone wants to tell me how to "reply" to a post on these forums, that would be appreciated!> Sadly, Meson64 does not have DTB Overlays enabled. That would, of course, be my preference. I have, however, updated my instructions to create an overlay and apply it directly to the DTB (rather than manually editing the DTB) and pointed users in the direction of postint.d if they wish to automate this (out of scope to provide specific instructions here). It should now be easier to create an overlay rather than directly apply to DTB if the user's box supports this. Unfortunately, I did not see this until I was well underway getting OpenVFD working. The box is now in production, so it is not straightforward taking it out and experimenting with it. However, having more than one way to achieve an end goal is no bad thing imho.

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Also, did you experiment with this alternative to openvfd?

Did you try doing this with a device tree overlay file instead of editing the device tree? That way on kernel upgrades you shouldn't need to redo the device tree edits each time.

HW: OrangePi5 Plus 32 32 GB RAM 512 GB NVME 5K Monitor Image: Armbian_25.8.1_Orangepi5-plus_trixie_vendor_6.1.115_xfce_desktop.img prepare system before each case dd if=u-boot-V2024.04-orangepi5-plus-spi.img of=/dev/mtdblock0 flash_erase /dev/mtd0 0 0 case 1: 1. copy image to 64GB uSD 2. booting 3. system comes up with xfce 4. sudo apt-get -y update; apt-get -y upgrade 5. reboot 6. system comes up, without desktop. system is reachable with ssh case 2: 1. copy image to 64GB uSD 2. booting 3. system comes up with xfce 4. armbian-install 5. choose boot from mtd flash 6. choose nvme0n1p1 6. update mtdblock0 7. reboot 8. system comes up, without desktop. system is reachable with ssh any idea whats going wrong?

S905W2 I didn't find a solution to my problem on the forum.

moved

Armbian 25.8.1 Noble XFCE (mainline Kernel: 6.16.6-edge-rockchip64) + PanVk - mesa 23.0 (https://launchpad.net/~ernstp/+archive/ubuntu/mesaaco) + box64 3.7 (https://ryanfortner.github.io/box64-debs/) + wine-10.15-staging-tkg-ntsync-amd64-wow64 (https://github.com/Kron4ek/Wine-Builds/releases/tag/10.15) + DXVK-stripped v2.7.1 ~30fps@720p Dark Souls 2 - SotFS

I've just been through this process myself. Those instructions are not close to working, and I'm not sure they ever worked. I have documented how I got the LCD display working on the T3-Mini here: