All Activity

Hi there, I ran octoprint and klipper on a orangepi zero (not at the same time). Octoprint from docker and klipper I cannot remember. Octoprint ran fine but it did have some issues when the CPU got overloaded with loading a new gcode file while printing for example. If you do things one by one it should be OKish. Btw i ran octoprint in a 512MB version, not on the 256MB one. Groetjes,

So I looked into this, and unfortunately, no dice. I am happy to investigate further, if you so wish, but I'm happy enough with the way it works currently (auto patching the dtb after a kernel update) so am unlikely to go exploring further on my own. To let you know what I did: copied the dtbo to /boot/dtb/amlogic/overlay/meson-gxl-s905w-tx3-mini-openvfd.dtbo Added to /boot/extlinux/extlinux.conf: fdtoverlays /dtb/amlogic/overlay/meson-gxl-s905w-tx3-mini-openvfd.dtbo (I also tried with /boot prepended to the path as well, but same issue) note: I assume FDTOVERLAYS is a typo from the armbianEnv.txt days, so I went with the lowercase as that is standard for extlinux The device would not come up on the network. I plugged in an HDMI monitor and found that it would hang at: ethernet end0: renamed from eth0 Which is.... odd. I suspect one of 2 things: My entry in extlinux.conf is incorrect (entirely plausible, I'm struggling to find documentation, I've just gone on what you've said, and also changed the capitalisation!) U-Boot overlays are applied differently than fdtoverlay in Linux. It’s possible U-Boot leaves something unaligned or adds an unexpected property, and the kernel hits a corner case. I realise that the above is noway near enough information, however, connecting directly to serial is not realistic at this stage, but I can attach a netconsole if needs be, as we are reaching the kernel, and provide further output. Like I say though, I will only do this if you think there is value in it. Whilst my method might not be the preferred way, it does work, at least.

@pochopsp You would need to use the information in that readme and patch and apply it to a newer u-boot (i.e port the patch to a newer u-boot) and build then a newer u-boot than the 2020.07 currently shipped.

Hi @SteeMan thanks for your reply. I'm not sure I understand your suggestion, however, I tried going in /boot/build-u-boot and the instructions (file readme.txt in the very same folder) suggest that the latest available u-boot for my device (s905x) is indeed the one that I already have (2020.07 from march 2023). The newer u-boot are for s905x2 or s905x3

Addendum: How To Include Devicetree Overlays Since Grub does not have devicetree overlay support, we need to merge the desired overlay(s) in with the main devicetree (.dtb) file we're using. Part of the device-tree-compiler package is this command: fdtoverlay An example from Armbian 25.8.1 Trixie running on the Orange Pi 5 Plus, to enable GPU acceleration in the Vendor (6.1) kernel. In sudo: cd /boot/dtb-6.1.115-vendor-rk35xx/rockchip fdtoverlay -i rk3588-orangepi-5-plus.dtb -o rk3588-orangepi-5-plus-panthor.dtb overlay/rockchip-rk3588-panthor-gpu.dtbo Of course, to have that load automatically from grub using the modification above, you'll need to rename (or move) the original .dtb to something else, then rename the one with the -panthor suffix to the original name to take its place.

I think it will run out or RAM... but try it anyway

@Werner, I merged the Panthor overlay with the Vendor devicetree using the fdtoverlay command (since I'm using efi/grub instead of u-boot), and now Vendor kernel with GPU is an option!! Thank you so much!! https://forum.armbian.com/topic/55266-add-devicetree-to-grub-automatically-heres-how/#findComment-226070 Question: I've noticed (at least in Debian on the Orange PI 5 Plus) that the Vendor kernel (with Panthor GPU overlay) works well under X and Wayland, but the Edge kernel only works well under Wayland. With the Edge kernel under X, the GPU is "there", but it doesn't seem to offer any kind of acceleration. I noticed this the first time I tried the Edge kernel several months ago, and it's still the case. Do you know of a fix for this as well?

@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?