pixdrift

It starts pretty close to 0, but not 0 Is this similar to what you see on the Zero3? If you need anything else let me now, I will leave this image running for a while. The fact it doesn't start at the same point each time, definitely looks like a buffer running out. Boot 1. root@orangepizero2:~# dmesg | head -n20 [ 0.883321] async_tx: api initialized (async) [ 0.883341] Key type asymmetric registered [ 0.883354] Asymmetric key parser 'x509' registered [ 0.883511] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 246) [ 0.883939] io scheduler mq-deadline registered [ 0.883958] io scheduler kyber registered [ 0.884056] io scheduler bfq registered [ 0.907712] Serial: 8250/16550 driver, 6 ports, IRQ sharing disabled [ 0.938149] loop: module loaded [ 0.944735] usbcore: registered new interface driver usb-storage [ 0.946043] mousedev: PS/2 mouse device common for all mice [ 0.948220] sun6i-rtc 7000000.rtc: registered as rtc0 [ 0.948294] sun6i-rtc 7000000.rtc: setting system clock to 1970-01-02T00:00:46 UTC (86446) [ 0.949050] i2c_dev: i2c /dev entries driver [ 0.950594] sunxi-wdt 30090a0.watchdog: Watchdog enabled (timeout=16 sec, nowayout=0) [ 0.953963] sdhci: Secure Digital Host Controller Interface driver [ 0.953991] sdhci: Copyright(c) Pierre Ossman [ 0.954060] Synopsys Designware Multimedia Card Interface Driver [ 0.955498] sdhci-pltfm: SDHCI platform and OF driver helper [ 0.957225] ledtrig-cpu: registered to indicate activity on CPUs Boot 2. root@orangepizero2:~# dmesg | head -n20 [ 0.960698] hid: raw HID events driver (C) Jiri Kosina [ 0.960882] usbcore: registered new interface driver usbhid [ 0.960900] usbhid: USB HID core driver [ 0.962997] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available [ 0.977441] NET: Registered PF_INET6 protocol family [ 2.996533] Freeing initrd memory: 17964K [ 3.087943] Segment Routing with IPv6 [ 3.088129] In-situ OAM (IOAM) with IPv6 [ 3.088328] NET: Registered PF_PACKET protocol family [ 3.088657] 8021q: 802.1Q VLAN Support v1.8 [ 3.088806] 9pnet: Installing 9P2000 support [ 3.088980] Key type dns_resolver registered [ 3.105046] registered taskstats version 1 [ 3.105354] Loading compiled-in X.509 certificates [ 3.123670] zswap: loaded using pool zstd/z3fold [ 3.145834] Key type .fscrypt registered [ 3.145864] Key type fscrypt-provisioning registered [ 3.149115] Btrfs loaded, zoned=yes, fsverity=no [ 3.149407] Key type encrypted registered [ 3.149433] AppArmor: AppArmor sha1 policy hashing enabled

A rebuild is quick on my compile setup, and I always like to test with the latest main branch regardless. The testing on the hardware is a little more involved, I will get the details and post them here.

Apologies, I didn't mean to bring up the discussion about overlays again. I agree overlays are the direction we are agreed to go, it is just agreement on implementation that is pending. I am still interested in feedback on the specific section of my branch that I posted as this work to 'move up' hardware configuration into the sun50i-h616.dtsi will also benefit overlays in the future. It's to ensure everything that is SoC level configuration is captured in the sun50i-h616.dtsi rather than being defined and replicated in the board .dts files. If we can agree that this looks beneficial, I will separate it from the 'all enable' PR I was building and raise a new PR.

May as well open old wounds while I am here. I know my patch to 'enable all' as an overlay alternative wasn't well received, but I would like to discuss one of the patches I created in this PR as I think it may add value, specifically the changes to the sun50i-h616.dtsi. https://github.com/armbian/build/compare/main...pixdrift:armbian_build:zero23_enable_all#diff-fd8dde60be0ca66f34e87999a632958889bf41b5ff6b047627ee4d91a7f1e04dR111-R184 These changes are basically to 'move up' all the shared/common config out of the zero2/zero3 board configs so they don't need to be set at the board level and the boards can be pretty close to turning components on with 'okay'. This may not be perfect (need a review of the dtsi changes and feedback), but I wanted the intent to be clear, and to see if others agree with this approach. It also fixes the spi1 pin problem (PH5 -> PH9) in the dtsi patch.. so people don't have to keep working around it (maybe we should just merge this first as something we all agree on?)

This looks pretty interesting @Stephen Graf, sorry I didn't get to test Zero 2 to confirm for you, I did build a fresh image from main though for the test. What was the configuration before you changed it to 19? and how did you land on 19? did you bump it up until it was enough? or was there something more technical driving that decision?

I am not sure why you have quoted me out of context there @Igor but I think this quote poorly represents my intent as the quoted text was part of me providing a response to @MrK regarding overhead of maintaining kernel patches in Armbian. I think your response is both disproportionate and misdirected. I understand the commercial realities of open source and contribute here (as an amateur) by choice.

@MrK I missed your messages earlier and I can see your frustration. The challenge for me personally is my ability to understand what you're proposing in your changes as I am just not at that technical level (a weak mind ), but I wish I was! That absolutely doesn't mean your changes aren't valid (or correct), but I am concerned (as I believe others are) that Armbian may not be the place for these improvements to be added, and they should perhaps be discussed in a kernel dev mailing list etc. and then make their way into Armbian by way of kernel changes? I understand @Gunjan Gupta questions/concerns about changing things (potentially unnecessarily) as I feel Armbian don't want to end up maintaining a kernel patch set very few in the project understand Do you have the details for the mailing lists which deals with the components you're discussing? If not, perhaps someone from the forum can assist with a link and/or suggestion for how to get these patches/changes to the right place. I really value your technical knowledge and experience in this space because I think what you're suggesting will improve the capabilities of the boards we're using, I just want to make sure these contributions are discussed with people responsible for this code upstream so everyone (even outside of Armbian) can benefit, and the changes can be discussed and maintained with like minded developers.

Hi @vice, It's important to mention what build, kernel, configuration for the OrangePi Zero 3 you are using. There are a lot of images available outside of Armbian that may confuse the issue, and the Orange Pi Zero 3 is also in active development so if you are on mainline Armbian build you may not always have the latest changes discussed here. Can you provide some more details about what image you're using?

This is a great suggestion, and a very clean way to implement. If switching to module in the sunx64 kernel config, will the other dependent boards will need changes to support loading the module, or it's safe to assume the will load automatically?

I have it booting and working now by turning off thermal support in kernel (also needed to disable a sun4i multifunction driver that expected the thermal configuration to be there). Board boots, network works.. and doesn't appear to get too hot. I must admit, I am a little surprised because I was under the impression that the thermals for CPU/GPU came directly off the SoC, and as the SoC is the same as the Orange Pi Zero 3 (and other boards if it's common for H616), I was expecting it to work. I will go back to the vendor regarding patching for temperature. In the meantime, what's the best way to have this board specific kernel configuration added to Armbian (ie. the config differs from the base sunxi64 kernel config) until the thermal issue is resolved? Are there any methods for adding it to the board configuration that would be merged if I raised a PR in future for the board? Thanks!

Thanks for your response. As always @Gunjan Gupta you are right, I was meant to say kernel not u-boot. I will rebuild now with thermal off and see how I go.

After booting the vendor image LPI3H_20240110_SD.img from their wiki (https://wiki.sipeed.com/hardware/en/longan/h618/lpi3h/1_intro.html) for comparison, I confirmed they appear to have THERMAL off, likely as it's not currently supported (I will ask them). After installing lm-sensors, there were no results and sensors-detect also failed to find anything root@lpi3h-5396:/# uname -a Linux lpi3h-5396 6.7.0-rc3+ #1 SMP PREEMPT Wed Dec 20 10:17:59 UTC 2023 aarch64 GNU/Linux root@lpi3h-5396:/# sensors No sensors found! Make sure you loaded all the kernel drivers you need. Try sensors-detect to find out which these are. When looking at potentially turning this configuration off in u-boot, I found the kernel config file placed into the FAT partition (for u-boot) suggests Armbian built the configuration with CONFIG_THERMAL=y. # ls -l total 62480 -rwxr-xr-x 1 root root 179 Jan 27 16:46 armbianEnv.txt -rwxr-xr-x 1 root root 1536 Jan 26 20:34 armbian_first_run.txt.template -rwxr-xr-x 1 root root 230454 Jan 26 20:34 boot.bmp -rwxr-xr-x 1 root root 3187 Jan 27 16:31 boot.cmd -rwxr-xr-x 1 root root 3259 Jan 26 20:35 boot.scr -rwxr-xr-x 1 root root 216337 Jan 26 20:33 config-6.7.2-edge-sunxi64 drwxr-xr-x 3 root root 4096 Jan 26 20:34 dtb -rwxr-xr-x 1 root root 23103496 Jan 26 20:33 Image -rwxr-xr-x 1 root root 18400198 Jan 26 20:35 initrd.img-6.7.2-edge-sunxi64 -rwxr-xr-x 1 root root 3594747 Jan 26 20:33 System.map-6.7.2-edge-sunxi64 -rwxr-xr-x 1 root root 18400262 Jan 26 20:36 uInitrd # grep ^CONFIG_THERMAL= config-6.7.2-edge-sunxi64 CONFIG_THERMAL=y Am I right in my thinking that Armbian is using a generic sunxi64 kernel config for the kernel build because the board is in the sunxi64 family? or have I misinterpreted this? This isn't specified in the kernel defconfig I have brought in for the board. I will take a closer look at the build log, just keeping a running log here in case others find the information useful for their own troubleshooting.

Sure, I guess that's down to approach. I have ruled out most of the patches, but wanted to determine if anything else had been added from upstream or that differed from what was there for H61x. Interestingly, the CPU Frequency scaling patch from Sipeed (not sure of full origin) includes more scaling steps in the CPU configuration, not sure if there is worth implementing in H61x as it will impact other boards, but it looks like an improvement over what is there. I went looking for the temperate configuration, not sure if it's related but their kernel configuration has +# CONFIG_THERMAL is not set Couldn't find anything specific to temperature/thermal in their patches, not sure how it's implemented, I thought the temperate output would be coming straight off the SoC? in which case, we would expect it to be implemented and working correctly (even without patches applied), is that correct? Not sure how the temp sensing is implemented in hardware. I plan to clean up (and merge together) many of the patches once the board is booting correctly.

Hello fellow Sunxi forum members, Some may know me from previous Armbian adventures, primarily Orange Pi Zero 3... but I have jumped brands for a change of scenery (but not SoC). When researching H61X based boards for the Zero 2 and Zero 3 development we were doing in another thread, I found the Sipeed LonganPi 3H, which is a relatively new board that took a while to find. My first impressions are that is really well made, and packs a lot in to the Raspberry Pi Zero style profile (although it also has a daughter board). It was shipped quickly in a nice quality hard plastic storage case and.. best of all.. it has two hardware buttons.. so I can reset! (very useful when you are rebooting endlessly). You can find a review of the board here: https://www.cnx-software.com/2023/12/29/sipeed-longan-pi3h-a-raspberry-pi-zero-sized-board-with-gigabit-ethernet-wifi-6-hdmi-and-usb-ports/ There has been some great development on GitHub here (and the documentation on their site is also good) https://github.com/sipeed/LonganPi-3H-SDK https://wiki.sipeed.com/hardware/en/longan/h618/lpi3h/1_intro.html I basically started this thread as I thought I would look outside of the Orange Pi's I had and see if I could get the SDK build working in the Armbian framework. It should be noted that the SDK builds are standalone and use slightly dated uboot and kernel, but I was keen to at least get the builds working in Armbian so I can start iterating and improving. I want it to be very clearly known that I am just migrating the great work from the above Sipeed GitHub repo (their scripts work really cleanly), and will slowly work through issues that I identify as I go. Currently I have migrated all the patches over (named the same as the original repo) until a clean/bootable build is achieved and then I will look at cleaning up the patch structure (although, in all honesty I prefer the numeric patch ordering to what exists currently in the sunxi patching directories.. but that's another discussion). My preliminary porting work to the Armbian build framework can be found here and is configured to only support edge with a wip board configuration for the Longan Pi 3H. https://github.com/pixdrift/armbian_build/tree/longanpi_3h Status: - The Armbian build completely cleanly for both the uboot (held back) and mainline kernel builds for 6.7.2 kernel. - Of the patches from the SDK repository, roughly 10 don't currently apply (not as bad as it sounds) - I have made some minor updates to two patches, and added comments for all problematic/failing patches - Many of the patches are related to CPU Frequency scaling, and I expect these are failing because CPU frequency patches are already in Armbian (I will confirm in future) - The build currently boots a separate boot partition, and that boot partition is using MBR (not GPT) as I had issues with the boot loader locating the GPT partition (haven't looked closely at this) The good news is.. I have the board booting, with 6.7.2 and I get serial output for the boot. The bad news is, it immediately and abruptly decides that the GPU has hit a temperature threshold and shuts down the device (corrupting the FS in the process). On subsequent reboots, fsck is launched to repair the filesystem and GPU hits temperature threshold. On investigation, I don't believe the GPU is actually hot, it's just the configuration has an issue and it's likely reporting a very high temperature value. I will try and confirm this as it may be a patch not applied correctly for GPU? The following is the log from the serial output First boot: =========== U-Boot SPL 2024.01-rc2-armbian (Jan 24 2024 - 11:15:42 +0000) DRAM: 4096 MiB Trying to boot from MMC1 NOTICE: BL31: v2.10.0 (debug):armbian NOTICE: BL31: Built : 10:42:19, Jan 24 2024 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a083600, model: LonganPi 3H INFO: ARM GICv2 driver initialized INFO: Configuring SPC Controller INFO: PMIC: Probing AXP305 on RSB ERROR: RSB: set run-time address: 0x10003 INFO: Could not init RSB: -65539 INFO: BL31: Platform setup done INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for erratum 855873 was applied INFO: BL31: cortex_a53: CPU workaround for erratum 1530924 was applied INFO: PSCI: Suspend is unavailable INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x4a000000 INFO: SPSR = 0x3c9 INFO: Changed devicetree. U-Boot 2024.01-rc2-armbian (Jan 24 2024 - 11:15:42 +0000) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: LonganPi 3H DRAM: 4 GiB Core: 48 devices, 19 uclasses, devicetree: separate WDT: Not starting watchdog@30090a0 MMC: mmc@4020000: 0, mmc@4022000: 1 Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In: serial@5000000 Out: serial@5000000 Err: serial@5000000 Net: eth0: ethernet@5020000 Unknown command 'usb' - try 'help' Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot.scr 3259 bytes read in 1 ms (3.1 MiB/s) ## Executing script at 4fc00000 U-boot loaded from SD Boot script loaded from mmc 129 bytes read in 1 ms (126 KiB/s) 30310 bytes read in 5 ms (5.8 MiB/s) Working FDT set to 4fa00000 Failed to load '/dtb/allwinner/overlay/-fixup.scr' 18400262 bytes read in 762 ms (23 MiB/s) 23103496 bytes read in 957 ms (23 MiB/s) Moving Image from 0x40080000 to 0x40200000, end=41880000 ## Loading init Ramdisk from Legacy Image at 4ff00000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 18400198 Bytes = 17.5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4fa00000 Booting using the fdt blob at 0x4fa00000 Working FDT set to 4fa00000 Loading Ramdisk to 48e73000, end 49fff3c6 ... OK Loading Device Tree to 0000000048e03000, end 0000000048e72fff ... OK Working FDT set to 48e03000 Starting kernel ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. [ 2.498172] thermal thermal_zone0: gpu-thermal: critical temperature reached, shutting down [ 2.506572] reboot: HARDWARE PROTECTION shutdown (Temperature too high) [ 2.519090] reboot: Power down done. Second boot: ============ Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. [ 2.475525] thermal thermal_zone0: gpu-thermal: critical temperature reached, shutting down Begin: Will now [ 2.484056] reboot: HARDWARE PROTECTION shutdown (Temperature too high) check root file system ... fsck from util-linux [ 2.495463] reboot: Power down 2.38.1 Next steps: I am currently running on coffee fumes.. but when I my cognition returns, I plan to work through the remaining patches I have flagged as problematic in series.armbian in my branch. Potentially from there I will reach out to the Sipeed developers if I can't find anything obvious that is causing the above temperature issues . If that fails, I will look to hack up the image to disable the thermal protection code that is shutting the board down so I can boot and get more information about this issue (but this obviously risks the board being damaged). Asking for assistance: If you have any idea what might be causing the temp issue (ie. where to look) drop a message. I am sure I will get to it eventually when I have time, but assistance on where to focus my attention (which module/configuration components) would be a great help. That being said, I haven't looked at any of the currently failing patches so may be a quick fix! If you have one of these boards (even if you aren't a developer) please sign up to the Armbian forums and let me know, it's always great to have other people available for testing

I'd be interested to know if anyone following this thread has a 1.5GB Zero3 for testing? I was planning to buy one for testing, but with such a small price difference between the 1.5GB and 4GB (and even less for the 2GB), I couldn't convince myself to buy it, and not sure why people wouldn't just choose 4GB if given the option? Perhaps 4GB wasn't available at the time the 1.5GB was released? Even the sales statistics on AliExpress suggest most people pay the few dollars extra for the 4GB.

I think this is a really important point to re-iterate. This discussion isn't trying to solve implementation for third party hardware devices with these overlays, this is specifically to support the features that the vendors provide on the boards (and board specific expansions), but in a modular/flexible way. In terms of 'addons' this is limited to the expansion boards which are specific to the hardware such as Orange Pi Zero2/3 expansion board, and the same with the Zero2W expansion board, which is also specific to that hardware. This isn't to bundle overlays for third party devices as @Stephen Graf has mentioned.

For anyone interested in builds of the PR6182 patch set for the menu/overlay changes, I copied up the builds I generated (that also include the mali fix posted in this thread) https://armdev.pixeldrift.net/orangepi/zero3/pr_testing/

Thanks for your response. I think this is where the issue is.. they can't be 'tweaked' because of the potential impact to existing board configurations that share the overlays for the same SoC. Developers are reluctant to change the configuration for the new boards out of concern that it will impact existing boards using the same SoC configuration (this current example with zero2 and zero3 and Bigtreetech demonstrates this) . The concern I have is, that when you create a patch/change for the overlays for a new board using an existing SoC, every board maintainer that has a board using that same SoC needs to re-test to validate the new board changes don't break their implementation. This may be speculation on my part if the process is working for other boards, but the board count is only at 3 or 4 for h616/h618 at this point, when we add Zero2W, Longan Pi3H , MangoPi M-core, Yuzuki Chameleon, Banana Pi M4, I only see the support/testing matrix when making changes exponentially increasing, which will burden far more board maintainers. With board specific overlays, yes it's potentially a large number of files, but the files are relevant to just that board, and they can be modified in isolation without calling back other developers every time a PR is raised. I am not personally concerned about the number of files as they can be organised in directories and follow standard conventions for clarity, and size wise they will amount to kilobytes and compress well. As I mentioned above too, my proposal is to make 'board specific' configurations available as an agreed option for developers in Armbian, not to mandate that every board must be implemented in this way (this can be configured with prefix in the board configuration).

Sorry @MrK I missed this. I am keen to see this patch because it's clear from your previous posts you're far more knowledgeable with the hardware intricacies than I think I could ever hope to be, so I am happy to go along with your suggestions for now :D.. I am just sticking patches together until this thing hopefully works! I think based on my own experience, rather than you forking off my GitHub repository, it would be better to fork from mainline armbian/build (so you don't end up dependent on me): 1. Fork armbian/build so you have your own copy of the main Armbian repo 2. Create a new branch in your fork for the feature/change 3. Share a link to this branch here for collaboration/discussion I am happy to pull changes from there, even if you just add the patch file to the patches.armbian directory in your branch with no other changes. -edit- Just looking at the patch you posted, is the spi-sun6i.c from another patch? or new?

Currently there hasn't been a proposed alternative the solves the issue of board specific implementations of SoCs. There has been a suggestion that this could be done at the SoC level more cleanly, but I have dug through it and so has @Stephen Graf, and there are challenges with this approach (mainly conflicting board implementations and unnecessary options appears to end users) which currently (in my opinion) haven't been addressed by the SoC level overlay proposal. This may change if someone can put a patch together and we can see it working of course. I still argue that having board specific overlays configurations available to Armbian developers (ie. people contributing to the Armbian project) is a fundamentally good (and clean) solution. I honestly don't see a huge increase in developer support burden when supporting this. After the initial creation of a new board configuration in Armbian, these files should be rarely touched or modified. If a zero4 comes out and it's based on the zero3, I just copy the zero3 overlay configuration and update it with zero4 changes and move on. I am not a board maintainer, but I would like to quantify exactly what support effort you are concerned about here @Gunjan Gupta? would you be able to provide examples of the scenarios that would greatly increase the maintenance effort of this approach so I can better understand your concerns? I agree. I put forward the new patch to demonstrate an alternate option, but I am not completely convinced by it either. In honesty, I thought @Gunjan Gupta may accept this as a PR based off our GitHub PR discussion, but I misinterpreted his views (my fault) in the discussion. This patch was developed before I saw his comment. That being said, there is something to be said for the 'out of the box experience' of everything just working, but you're right.. we should probably go the other way and make more things toggled (HDMI was a great example as I rarely use video in my applications of these boards) One thing I did get out of this patching process however was that the DTS files are a bit of a mess. In my view, the configuration for the different SoC components should be done up at the h616.dtsi level, but I still believe the overlays should target specific boards. This is best demonstrated by the changes in my most recent (enable_all) branch. You will see I have moved the configuration for uart5 and ir (as examples) up to the h616.dtsi so the only thing done at the board level (the zero.dtsi because zero2 and zero3 are a special case with shared config here) is the 'status' change. This has pushed me to the conclusion that regardless of what level the overlay configuration targets (SoC or board), there should be essentially no configuration other than 'status = okay' or 'status = disabled' in the overlay for each item except in specific cases where a change of configuration is required such as switching usb otg to host mode. Thanks for joining the conversation @SteeMan and for your Armbian forum moderation efforts. I appreciate this point of view and I completely agree. The things @Stephen Graf does with his boards is completely different to what I do. You then have another example user 'persona' that uses the boards for emulation, or streaming, or NAS. My position is that all our use cases should be treated as first class citizens, and we need to be careful as developers (with the luxury of being able to change what we want) about being opinionated about how we think people should use the hardware, and focus on the user experience to provide all the features a board has to offer easily to the end user. I want to ensure this implementation (and other changes for that matter) avoids the following 1. Questions about why something that looks like it should work, doesn't work (eg. "I enabled this option in overlays, and it still doesn't work") 2. End users needing to 'roll their sleeves up' and write kernel patches or custom patches for Armbian to enable basic features 3. A negative view from new Armbian users when they come to the forum asking for support, and are told to 'implement it yourself if you want it' and leave disillusioned Every new user is potentially a developer/contributor to the project with mentoring, and I think @Stephen Graf and myself are recent examples of this, but that doesn't mean that we want a new board user's first interaction with the community to be a 'just write a dtb overlay' style response as you have mentioned.

After discussion in PR6182, I have written the following patch to enable all these features (except usb otg) by default to remove the need for overlays. https://github.com/pixdrift/armbian_build/tree/zero23_enable_all I have also updated the SPI pin in the h616 dtsi so it specifies PH9 correctly. If you look at the patch, it also cleans up the configuration considerably.. with the philosophy that if everything on the SoC is the same between h616, we should move the configuration up to there, and only have 'status = okay' at the board level to enable/disable the features. I have done that in this implementation. My only concern is SPI, which I have left in the board configuration for now, but I am concerned with inconsistency of these two entries (the lower entry for spi1 is taken from the overlay patch). I feel that the address-cells and size-cells entries should be at the same level in the hierarchy in both and numeric values are specified differently between both. @Stephen Graf I also removed the 'status = okay' at the spidev@0 level from your overlay patch because it didn't seem consistent with any other configurations I could fine (but let me know if it does/doesn't work as it is). &spi0 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>; flash@0 { #address-cells = <1>; #size-cells = <1>; compatible = "jedec,spi-nor"; reg = <0>; spi-max-frequency = <40000000>; }; }; &spi1 { status = "okay"; #address-cells = <0x01>; #size-cells = <0x00>; pinctrl-names = "default"; pinctrl-0 = <&spi1_pins &spi1_cs0_pin>; spidev@0 { compatible = "rohm,dh2228fv"; reg = <0x00>; spi-max-frequency = <0xf4240>; }; }; -edit- So this is probably worth abandoning before raising a new PR, I just read @Gunjan Gupta's post from the PR https://github.com/armbian/build/pull/6182#issuecomment-1903672798

Excellent! thanks for your contribution to the Orange Pi work and registering on the forum to let us know, it's greatly appreciated.

Hi @jokubas.ver, welcome to the forum and thanks for spotting this. As @Gunjan Gupta mentioned it was probably a minor mistake as there was some juggling of these files initially and it looks like people may not have tested this at this point (but great you have!). When you say you've tested, have you tested using Armbian from the official build repo with this flag set to 'okay' or with another build? If it's this build, it will be a PR to resolve it, and I am happy to put raise that or assist you with raising it if you need a hand. Can you let us know which branch you built off and some details of your board version and OS/configuration combination you used for your test? Details of the tests you ran would also be really helpful for others reading this thread and if we need to replicate them when the PR is raised. Thanks again!

@Stephen Graf PR 6182 is now submitted and waiting on review and your testing feedback on Zero3 (no rush ) https://github.com/armbian/build/pull/6182

I am going to pull the 6.1 patches as for zero2 and zero3 they look like dead code (not used by 'current' or 'edge' for these boards) and I don't think it's worth patching the legacy 4 kernel. Will update my branch by pulling the 6.1 patches and raise the PR after testing. -edit- This has been validated now on zero2 + current with the 6.6.12 Boot script loaded from mmc 264 bytes read in 2 ms (128.9 KiB/s) 32009 bytes read in 6 ms (5.1 MiB/s) Working FDT set to 4fa00000 344 bytes read in 5 ms (66.4 KiB/s) Applying kernel provided DT overlay sun50i-orangepizero2-3-i2c3.dtbo 339 bytes read in 5 ms (65.4 KiB/s) Applying kernel provided DT overlay sun50i-orangepizero2-3-ir.dtbo 608 bytes read in 5 ms (118.2 KiB/s) Applying kernel provided DT overlay sun50i-orangepizero2-3-otg-host.dtbo 699 bytes read in 4 ms (169.9 KiB/s) Applying kernel provided DT overlay sun50i-orangepizero2-3-spi1-cs0-spidev.dtbo 644 bytes read in 5 ms (125 KiB/s) Applying kernel provided DT overlay sun50i-orangepizero2-3-uart5.dtbo 620 bytes read in 6 ms (100.6 KiB/s) Applying kernel provided DT fixup script (sun50i-orangepizero2-3-fixup.scr) ## Executing script at 45000000 18377497 bytes read in 761 ms (23 MiB/s) 22964232 bytes read in 953 ms (23 MiB/s) Moving Image from 0x40080000 to 0x40200000, end=41860000 ## Loading init Ramdisk from Legacy Image at 4ff00000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 18377433 Bytes = 17.5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4fa00000 Booting using the fdt blob at 0x4fa00000 Working FDT set to 4fa00000 Loading Ramdisk to 48e79000, end 49fffad9 ... OK Loading Device Tree to 0000000048e08000, end 0000000048e78fff ... OK Working FDT set to 48e08000 Starting kernel ...