Active threads

https://forum.armbian.com/topic/46824-orange-pi-zero-3-ili9486-tft-lcd/ user wdr_s had success with that same lcd. Try it with linux 6.1 (check the success case) If you have a file named orangeEnv.txt... you arent using armbian yet!

About wrong color i think the driver cause it. Driver for render image in this kernel sunxi is ili9486drmtft. I get right color in raspberry pi 4 but raspberry pi 4 use fb_ili9486. On this orangepi zero 2 w, i try 3 different OS but still get same wrong color after adding dts for ili9486 1. Orangepi OS Kernel 6.1 2. Armbian OS Kernel 6.1 3. Debian Bookworm 12 Kernel 6.1 All using ili9486drmtft and get wrong color I also try to change bgr value in dts, but it only create change in .../spi@1.0.../bgr not the color on screen I try to get source code https://github.com/orangepi-xunlong/linux-orangepi/tree/orange-pi-6.1-sun50iw9 to change the bgr field in driver, but i can't insmod the module i build. It say invalid symbol I see someone comment that after kenel 5.4 in repo sunxi remove fbtft_device, so we can't add the fb_ili9486 . The Offical OS supported by Orangepi has Kernel 5.4 Debian, i use it, but after add overlays and reboot, it seem wrong setup, ethernet not working, and i don't know why.

So yes, HDMI does work on the archived image. Interestingly, USB does not work. I tried to connect a keyboard and a mouse but that did not work. So, on the HDMI terminal I successfully reach the login screen but can't go past that. But through ssh/serial I can work on the system. I tried memtester and it does show some issues with the memory, but overall, this archived image has worked without issues. I was able to use octoprint_deploy to install Octoprint, but again since USB does not work couldn't connect the printer itself. To replace the dts file easily I need input devices to work, I will try and see if I can do that over serial. And the next thing to try is to compile using an edge kernel and report back. Thanks, Shivam

If you are talking about lag with discord webpage, vpu accel won't help because there is no video played in discord. You can check chromium's gpu status at chrome://gpu, see if the gpu driver is working. My ppa only packages chromium for noble, ubuntu 25.04 is not supported. While chromium in my ppa only add patches to let chromium use vpu when playing videos, this should not help improving discord webpage performance.

Hi, Great work thanks! Why no 25.05 for banana pi M4 zero? Perhaps are you waiting for some additional work on missing bluetooth support for rev2? @c0rnelius ? Denis

I'm in a similar situation. But I can't access my board anymore. I cannot put the board in maskrom mode anymore. Still stuck on this one?

@KrzyPac Ur welcome.

I can not get sound out of AnalogCodec LinOutL/R pins either.

Actually its the opposite so it must have been something else. Etcher is known to be broken for bigger images (desktops). There is some bug in the .xz decompression method used by Etcher. I am using only USB imager for at least a year and haven't run into any problems. At least not on this level.

moved

yes I can confirm

Thanks - I'm worried my main issue was with the overlay loading issue I mentioned. I did try 6.15 but prob need to retry with the hack with overlay-user. But man... it is SO incredibly simple to switch the kernels.

See for more details but without using the overlay-user folder - I was not able to get the pwm to work on a fresh download.

https://paste.armbian.com/cawuyeyice

Armbian 24.5 works normally, but this issue occurs in versions 24.8, 25.5 and 25.8 [ 0.872698] dwhdmi-rockchip ff940000.hdmi: supply avdd-0v9 not found, using dummy regulator [ 0.872852] dwhdmi-rockchip ff940000.hdmi: supply avdd-1v8 not found, using dummy regulator [ 2.361552] dwhdmi-rockchip ff940000.hdmi: supply avdd-0v9 not found, using dummy regulator [ 2.361723] dwhdmi-rockchip ff940000.hdmi: supply avdd-1v8 not found, using dummy regulator [ 2.361912] dwhdmi-rockchip ff940000.hdmi: Detected HDMI TX controller v2.11a with HDCP (DWC HDMI 2.0 TX PHY) [ 2.363007] rockchip-drm display-subsystem: bound ff940000.hdmi (ops 0xffff80008120fe60) [ 22.444508] hdmi-audio-codec hdmi-audio-codec.8.auto: Only one simultaneous stream supported! [ 22.444524] hdmi-audio-codec hdmi-audio-codec.8.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -22 [ 0.871390] rockchip-drm display-subsystem: bound ff8f0000.vop (ops 0xffff80008120b5e8) [ 0.872604] rockchip-drm display-subsystem: bound ff900000.vop (ops 0xffff80008120b5e8) [ 2.360057] rockchip-drm display-subsystem: bound ff8f0000.vop (ops 0xffff80008120b5e8) [ 2.361397] rockchip-drm display-subsystem: bound ff900000.vop (ops 0xffff80008120b5e8) [ 2.363007] rockchip-drm display-subsystem: bound ff940000.hdmi (ops 0xffff80008120fe60) [ 2.364674] [drm] Initialized rockchip 1.0.0 20140818 for display-subsystem on minor 0 [ 2.510919] rockchip-drm display-subsystem: [drm] fb0: rockchipdrmfb frame buffer device

I just did some new experiments, trying to get touch working in ili9488 LCD v2.1 Increasing or decreasing the SPI MHz in both the LCD and touch section of the DTS DONT WORK... I couldn't get touch working Next is to use a software defined SPI with spi-gpio (based on my experience in my ili9341 thread) does anybody know a Python soft spi program which can talk to ads7846/xpt2046?

And could you tell me how to add a patch to my .dtb or .dts file. I installed linux-headers but I don't know what to do next with the patch posted above by c0rnelius.

So I was able to reproduce the issue when trying to boot via NVMe after using armbian-config to switch from emmc. Using rkdeveloptool to flash the SPI with https://dl.radxa.com/rock5/sw/images/loader/rock-5b+/release/rock-5b+-spi-image-8ea7ee4-20240730.img (short guide in the spoiler) I was able to boot into the NVMe. Looking into fixing the broken SPI installation

Check here https://github.com/armbian/community/releases/tag/25.5.0-trunk.256 or on a mirror with archive https://docs.armbian.com/Mirrors/#current-mirrors for what you are looking for. We're aware that some links are broken for yet to be determined reason.

I think using the ubuntu keyserver is good as well but that this is a 'small' issue, it is easy to miss a small thing in a project this huge consider the number of boards, kernels, and distributions (including the different releases). if this little thing breaks, we can fix in our installed os using these methods.

this soldering is visionally not very attractive 😛 , but at lest the result is what counts 👍

We don't deal with Android. Better check xda developers forums.

Description As per title How Has This Been Tested? [ ] hasn't Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description This is a draft/wip for adding https proxy caching. This is especially designed for machines hosting lots of github runners to reduce their bandwidth usage by sacrificing disk space. http caching has been merged already and only needed minor changes. Caching https however is way more complicated. Encryption needs to be broken and rewrapped and then obviously downloads will fail due to cert issues. Classic MITM. So a new certificate authority (CA) needs to be put in place to allow these "fake" certs. Why is this even necessary? Well one major part is downloads from upstream apt repositories. The other major part is downloading 3rd party repositories and artifacts from OCI/ORAS/whatever the correct name for that system is. They do not allow plain http downloads but redirect to https. So in order to cache these encryption must be broken on the fly. On custom runs this works already with the mentioned extension. However when the build framework is used within a GH Actions Runner environment it would need to detect this and enable the extension automatically. No clue how to do that or overall if it is worth diving even deeper into this topic. Therefore this RFC to collect feedback. Also lots of fail-safe checks are missing. Sometimes I had to mix run_host_command_logged and chroot_sdcard since pipes don't work using latter. Documentation summary for feature / change Yes, this would need documentation. How Has This Been Tested? [x] custom builds with ENABLE_EXTENSION [ ] Test B Checklist: [no idea] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description as per title How Has This Been Tested? [x] build [ ] nope, no hw on hand right now Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article