pixdrift

Thanks a lot! If, by some miracle, it happens to work, how would I activate it? Activating the analog out shuts down HDMI. So when HDMI works, it means the analog out isn't working. I've found there is a Linux kernel config/module DRM_SUN8I_TCON_TOP that might be needed. P. S. I don't need audio, so no problem. On the topic of audio, I have started looking at it and should have something working over the next couple of days. The early patches from warmpe merge fine, which is a good sign.. it's just getting the h616 dtsi and dts patches in next. My working branch is here, which compiles fine with some of the additional patches but board configuration patches aren't there yet. https://github.com/pixdrift/armbian_build/tree/zero23_audio

Excuse me? This is a completely absurd statement.

Welcome @VioletGiraffe, thanks for joining the forum and letting us know you can test Must be quite a journey reading the whole thread for the history now, well done In terms of video out, I don't think there has been any specific focus on it and as @Stephen Graf may not be currently supported, but keep an eye out for updates here. I think mainline is good to build off currently, there are no big PRs pending except the Overlay work which may not interest you as it's GPIO related. The options vary based on what OS you're using, but I generally use Edge Kernel, Debian OS and XFCE Desktop options for testing. I can be more specific if you need

@highlander0681, not sure what to say about this image not working https://dl.armbian.com/orangepizero2/archive/Armbian_23.11.2_Orangepizero2_bookworm_current_6.1.68.img.xz My apologies, I missed something obvious as I always test/boot boards using serial/UART. I plugged in a monitor this morning and I don't appear to be getting HDMI out on this image. Not sure if this is a regression or the patches were never added to 'currrent'. It takes about 10 minutes to resize filesystem on my (fast) 64GB SD card (red blinking)., there also appears to be a bug where it resizes filesystem on every boot which is strange. This is from the serial console for the image. No HDMI on this build does look like a problem though, thanks for reporting it @highlander0681. Armbian 23.11.2 Bookworm ttyS0 orangepizero2 login: root Password: ___ ____ _ _____ ____ / _ \| _ \(_) |__ /___ _ __ ___|___ \ | | | | |_) | | / // _ \ '__/ _ \ __) | | |_| | __/| | / /| __/ | | (_) / __/ \___/|_| |_| /____\___|_| \___/_____| Welcome to Armbian 23.11.2 Bookworm with Linux 6.1.68-current-sunxi64 System load: 103% Up time: 10 min Memory usage: 11% of 984M IP: CPU temp: 46°C Usage of /: 94% of 1.9G [ General system configuration (beta): armbian-config ]

I just downloaded, flashed, and booted this image on a Zero2 with no issues. https://dl.armbian.com/orangepizero2/archive/Armbian_23.11.2_Orangepizero2_bookworm_current_6.1.68.img.xz

@highlander0681 can you provide a direct link to the images you used and I will verify on a Zero 2 here. I am regularly building from main Armbian branch and testing on Zero2 and haven't had issues, but it will be quick to test/validate the image you had issues with. I want to confirm you were using images from here as the 'Orange Pi Zero +2' can be confusing (and is a different board). https://www.armbian.com/orange-pi-zero-2/

Yes, absolutely, it has been a great source of information.. make sure you leave the credit on any patches you bring over. The list here is great, and this is where I plan to pull over the h61x sound patches from for testing https://github.com/warpme/minimyth2/tree/master/script/kernel/linux-6.6/files

Has anyone got information on this slightly different Transpeed variant (M98-8K)? https://www.aliexpress.com/item/1005006078280236.html Apparently it's also H618 based, but advertised as Android 13 with a different case without the clock on the front (but most other specs look the same). Would be interesting to see if this board is the same internally and would also work with the same images being built here. If you have this TV box or have photos of the insides, please let us know!

I had a quick chat to @Nick A and confirmed the images work, but we needed a desktop image for others here to test. I just built a Debian XFCE desktop image and it's now also available from here (a little bit bigger than the previous server images) https://armdev.pixeldrift.net/transpeed/8k618-t/ If you are finding this post through a random Internet search, please register for the forum and get involved with some testing and feedback by letting us know if it worked for you

So it appears the builds I have uploaded aren't booting according to @Nick A's testing, so let us figure out why that is before anyone tests these images.. I unfortunately don't have hardware for testing these images, unlike the Orange Pi boards.

I have posted two builds here from @Nick A's GitHub repo, make sure you mention what build you're using when testing so @Nick A can make effective use of the feedback. https://armdev.pixeldrift.net/transpeed/8k618-t/ Nick A's repository in GitHub: https://github.com/NickAlilovic/build They are date/time stamped based on the last commit to the repo at build time, so you probably want the latest one (20240202) but I will let @Nick A comment on that

Hi @heiko910, welcome to the forum! I can generate a build off Nick A's branch and give you a link for testing, but it comes with no guarantees as it's a test image that is in active development Always good to have more people willing to test

My first review of this PR6241 is that it contains a lot of non-zero3 configuration that will only confuse end users. I still maintain my position that this approach isn't best for end users, and a board specific overlay file is a better solution, even if it comes with more overhead. The current list is confusing to me, and I have spent a lot of time with the board, I can't imagine what a new user 'just wanting it to work' would think when presented with this list of options. Additionally, this list will only increase with this approach as more H61x boards are added. I understand your viewpoint @Gunjan Gupta, but I respectfully disagree with this approach. The amount of burden (managing more board specific overlay files) put onto developers in Armbian is far better than the impact that including all boards has on the user experience (UX) for (potentially inexperienced) end users using armbian-config. I can't think of a good reason for anyone developing a product to intentionally make the experience worse for users to save a small amount of time (and disk space) for developers. Another potential option is to update armbian-config to support more complex filtering, or the option to pass a list of overlay filters in the configuration file to allow a board to specify the generic/shared h61x overlays, and then also some board specific ones, but in the interim, I would prefer to avoid the path PR6241 is taking, even if we only make that change for Zero2 / Zero3 for now so we can protect the user experience for these specific boards.

Latest PR from @Gunjan Gupta is here if anyone is available to test, this adds overlays which has been discussed at length in this thread. https://github.com/armbian/build/pull/6241 I have also built an image of this PR6241 if people want to test, it's available here: https://armdev.pixeldrift.net/orangepi/zero3/pr_testing/PR6241_20240202_9a1950d37_Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.7.3.tar.xz

-edit- Removed comments abut PR process and taken to PMs to focus on technical discussion here. On this comment, I think it's a fair position to expect the board to operate as per the manufacturer's documentation out of the box. Can we not configure spi1_cs1_pin as PH9 as suggested (not touching the spi1_cs0_pin PH5), and then use that for spi1 out of the box?

This is from the H616 data sheet from here: https://linux-sunxi.org/images/b/b9/H616_Datasheet_V1.0_cleaned.pdf @Stephen Graf can you run me through this pin change? I believe I originally took it from your overlay, and there was some discussion about it. In the kernel sun50i-h616.dtsi there is the following which both define PH5: i2c3_ph_pins: i2c3-ph-pins { pins = "PH4", "PH5"; function = "i2c3"; }; /omit-if-no-ref/ spi1_cs0_pin: spi1-cs0-pin { pins = "PH5"; function = "spi1"; }; My concern is the sun50i-h616.dtsi for spi1-cs0-pin matches what the datasheet shows for SP1_CS0 , but we are proposing a change to PH9. What was the rationale here? was it that the datasheet is wrong? Sorry just getting some words together for the PR.

Looks like the latest PR from @Gunjan Gupta merged a fix for the wifi load average problem thanks to github user @pyavitz. https://github.com/armbian/build/pull/6228 Good news because it was an annoying issue -edit- Looks good orangepizero3:~$ uptime 18:42:56 up 45 min, 2 users, load average: 0.07, 0.02, 0.00 I have posted a build here if anyone wants to validate the load average change https://armdev.pixeldrift.net/orangepi/zero3/pr_testing/PR6228_20240130_b600ead20_Armbian-unofficial_24.2.0-trunk_Orangepizero3_bookworm_edge_6.7.3.tar.xz

Hi @Gunjan Gupta, I am having a difficult time following the logic here. You want me to add a single character change PH5 -> PH9 to a new PR, rather than adding it to your PR for orangepi fixes? I will raise it now.

Just a quick note for those who don't venture out into the wider forum beyond their boards of interest (this was me until a couple of days ago)... I'd like to introduce @Nick A. @Nick A dropped me a message earlier this week and linked me to a thread he has been working in with several others for an H618 based TV Box from Transpeed. Looks like @ag123 already knew about it, but just wanted to introduce @Nick A and others from this thread as additional collaborators for H61x work. It was an interesting thread to go through as I don't have any TV boxes currently, and it was also great to see the work on H61x that everyone has been contributing to... getting picked up and used by others.

Hi all, I have been working on the Orange Pi Zero 2, Zero 2W, Zero 3, and Sipeed Longan Pi 3H (all from the H61X) family. @Nick A just introduced me to this thread, I didn't realise this was even here.. but great to have more people looking at these SoCs. Thanks for posting the image of the TV box open @rick0cm, I couldn't find many good photos of it online. It's a pretty interesting device for the price!

That sounds good. Could you stage a PR for this in WIP? and I can get some builds done from the PR so people can test the changes here (and also review if there is anything else we should add).

Thanks @Gunjan Gupta saves me raising a PR for such a minor change. Would you also be able to add this pin change for spi1 to your PR6228? it's another minor update that has been pending for a while https://github.com/armbian/build/compare/main...pixdrift:armbian_build:zero23_enable_all#diff-fd8dde60be0ca66f34e87999a632958889bf41b5ff6b047627ee4d91a7f1e04dR119-R123

I have raised the thermal config issue with the Sipeed developers here: https://github.com/sipeed/LonganPi-3H-SDK/issues/16 Not keen on having to manage this in Armbian, so will wait to see if they come up with a patch to resolve the temperate reporting. I haven't looked at any of the thermal code myself yet.

Changing the linux-sunxi64-edge.config to the same as Debian resolved the issue CONFIG_LOG_BUF_SHIFT=17 Boot root@orangepizero2:~# dmesg | head -n20 [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] Linux version 6.7.2-edge-sunxi64 (armbian@next) (aarch64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #10 SMP Thu Jan 25 23:45:31 UTC 2024 [ 0.000000] KASLR disabled due to lack of seed [ 0.000000] Machine model: OrangePi Zero2 [ 0.000000] OF: reserved mem: 0x0000000040000000..0x000000004007ffff (512 KiB) nomap non-reusable secmon@40000000 [ 0.000000] NUMA: No NUMA configuration found [ 0.000000] NUMA: Faking a node at [mem 0x0000000040000000-0x000000007fffffff] [ 0.000000] NUMA: NODE_DATA [mem 0x7fdcd040-0x7fdcefff] [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000040000000-0x000000007fffffff] [ 0.000000] DMA32 empty [ 0.000000] Normal empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000040000000-0x000000004007ffff] [ 0.000000] node 0: [mem 0x0000000040080000-0x000000007fffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x000000007fffffff] [ 0.000000] cma: Reserved 128 MiB at 0x0000000076c00000 on node -1 [ 0.000000] psci: probing for conduit method from DT. [ 0.000000] psci: PSCIv1.1 detected in firmware. @Gunjan Gupta If I was to raise a PR to update this in the three sunxi64 configs (legacy, current, edge) would that get merged? or are there concerns about changing this? I think setting to the same as Debian is a safe option, and obviously resolves the issue.

Thanks @Gunjan Gupta that looks promising because we can potentially just bump it up for the sunxi kernels to resolve the issues without impacting anyone else I wonder if distros tweak this setting too, seems like an obvious one to bump up.