Ryzer

Thats the Plan I just wanted to update my fork first in case any problems occured before submitting. Just wanted to check, seeming as I am covering 2 areas (dts patches and drm patches) would you still prefer this to be in a single commit? The original purposing being to add hdmi support for the Pcduino2 and Pcduino3, but evolved due to the drm breakages.

Indeed. Comparing sources between kernel 6.12 and 6.15, I could only spot one difference in the drm_atomic_helper_connector_hdmi_check() function so I have tested applying this via a patch and the build compiled successfully. Testing the build I found that reboot now works and shutdown finishes with just a blank display. If it is indeed the same issue then this patch will likely fix the problem. Based on what I found it may impact certain Rockchip Socs also: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/gpu/drm/display/drm_hdmi_state_helper.c?h=linux-6.15.y&id=0d337b40ca1e532af42516d9e9024baad466319a drv-drm-atomic-helper-null-pointer-fix.patch Thanks Ryzer

The good news is that we get a working display. The bad news is that it creates a new problem. when Either shutting down or rebooting a kernel panic is triggered. After a bit more digging I found the reason that the drm_hdmi_connector_mode_valid patch failed is because the function does not exist under kernel 6.12. I dont know yet if it may be necessary to include it yet or if drm_atomic_helper_connector_hdmi_check needs some further tweaks. Thanks Ryzer

Recreated hdmi patches under kernels 6.12 and kernels 6.15 in pcduino-boards-fixes branch. When attempting to build with current kernel 6.12.30, with drm patches for sun4i_hdmi_enc.c to use drm_hdmi_connector_mode_valid and drm_atomic_helper_connector_hdmi_check fails to compile. when just applying drm_atomic_helper_connector_hdmi_check patch build compilation is successful. Just need to verify this build works. For kernel 6.15, with just the hdmi patches, we get a working HDMI display output:

Hi, Then the only other difference would be that your device has a pin tied to usb0-vbus. The topwise dts does not have the display nodes included in the cubieboard. Now as you are currently kernel 6.1, it is possible to enable the display via overlays or compile a version of the topwise dts that includes the display nodes. So the internal display does not work under 6.1? Are there any kind of errors or does it not appear to intialise at all? Cubieboard nodes (*Note - Nodes other than hdmi and usb related have been removed): /dts-v1/; #include "sun4i-a10.dtsi" #include "sunxi-common-regulators.dtsi" #include <dt-bindings/gpio/gpio.h> / { model = "Cubietech Cubieboard"; compatible = "cubietech,a10-cubieboard", "allwinner,sun4i-a10"; hdmi-connector { compatible = "hdmi-connector"; type = "a"; port { hdmi_con_in: endpoint { remote-endpoint = <&hdmi_out_con>; }; }; }; }; &de { status = "okay"; }; &hdmi { status = "okay"; }; &hdmi_out { hdmi_out_con: endpoint { remote-endpoint = <&hdmi_con_in>; }; }; &reg_usb1_vbus { status = "okay"; }; &reg_usb2_vbus { status = "okay"; }; &usb_otg { dr_mode = "otg"; status = "okay"; }; &usbphy { usb0_id_det-gpios = <&pio 7 4 (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>; /* PH4 */ usb1_vbus-supply = <&reg_usb1_vbus>; usb2_vbus-supply = <&reg_usb2_vbus>; status = "okay"; }; Topwise a721: /dts-v1/; #include "sun4i-a10.dtsi" #include "sunxi-common-regulators.dtsi" #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/input/input.h> #include <dt-bindings/interrupt-controller/irq.h> #include <dt-bindings/pwm/pwm.h> / { model = "Topwise A721"; compatible = "topwise,a721", "allwinner,sun4i-a10"; panel { compatible = "starry,kr070pe2t"; backlight = <&backlight>; power-supply = <&reg_lcd_power>; port { panel_input: endpoint { remote-endpoint = <&tcon0_out_panel>; }; }; }; reg_lcd_power: reg-lcd-power { compatible = "regulator-fixed"; regulator-name = "reg-lcd-power"; gpio = <&pio 7 8 GPIO_ACTIVE_HIGH>; /* PH8 */ enable-active-high; }; }; &de { status = "okay"; }; &reg_usb0_vbus { status = "okay"; }; &reg_usb1_vbus { status = "okay"; }; &reg_usb2_vbus { status = "okay"; }; &tcon0_out { tcon0_out_panel: endpoint@0 { reg = <0>; remote-endpoint = <&panel_input>; }; }; &usb_otg { dr_mode = "otg"; status = "okay"; }; &usb_power_supply { status = "okay"; }; &usbphy { usb0_id_det-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */ usb0_vbus_det-gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */ usb0_vbus-supply = <&reg_usb0_vbus>; usb1_vbus-supply = <&reg_usb1_vbus>; usb2_vbus-supply = <&reg_usb2_vbus>; status = "okay"; }; It is possible to build just uboot using the BUILD_ONLY=uboot option. Again here you could face potential issues as newer uboot might not work well with an old kernel. All the best Ryzer

Most likely USB OTG unless there are any USB related errors in the kernel log. In the case of OTG, there should be auto detection via the ID pin which sets the device role but I have never known this to work. Fortunately it is possible to set the mode manually to host in the device tree. I tend to use the following device tree overlay: /dts-v1/; /plugin/; /{ compatible = "allwinner,sun4i-a10", "allwinner,sun7i-a20"; fragment@0{ target = <&usb_otg>; __overlay__{ dr_mode = "host"; }; }; }; just connect via serial or ssh, once logged in use nano and paste in the text above. Save it as something like sun4i-usb-host.dts. Then run armbian-add-overlay sun4i-usb-host.dts. This automatically compiles the overlay and places it /boot/dtb/overlay-user/ The RAM may just need fine tuning slightly. As far as I know it is not possible to adjust the RAM frequency in uboot once compiled, only check clock rate via sudo cat /sys/kernel/debug/clk/pll-ddr/clk_rate. I might have to try that on my pcDuino2, I didn't think the A10 would be powerful enough to run Octoprint. All the best Ryzer

Right so 1GB - display framebuffer allocation. Can you confirm HDMI works as it been a while since I built an system image with 6.1 kernel. I dont recall display issues, just problems relating to SPI at the time. Anyway kernel 6.1 is no longer supported, even as a legacy kernel. The earliest kernel you can now build with is 6.6. I am suprised that the mirrror archives I have looked at so far do not feature any 6.6 kernel builds for the Cubieboard. Thats not to say it would be impossible to compile with an older kernel but could prove more trouble than what it is worth. I am interest to see what if encounter any stability issues when booting an edge kernel. Interesting, that is the exact same RAM chips used on the pcDuino2 but the additional text enscribed is different. Just to be safe can you run memtester to see if it picks up an errors. For example: sudo memtester 64MB 2. Even without re-compiling the entire system, what we can do is replace the targeted board dts. This should be doable given you already have a serial link, but you will need to catch uboot early on to hault to boot process to get a uboot prompt. Then running setenv ftdfile sun4i-a10-topwise-a721.dts to see if the onboard display works. *update* - upon checking kernel sources the previously mentioned sun4i-drm patches are no longer necessary as the changes appear to have been included in the latest sub revision of kernel 6.12.30 All the best Ryzer

Right, I was thinking what if you try forcing a different mirror via DOWNLOAD_MIRROR: https://docs.armbian.com/Developer-Guide_Build-Switches/#hidden-options-for-advanced-users-default-values-are-marked-bold I cant guarantee this will work though. While A2 cards offer better performance, they are not as well supported. That is still the case to the best of my knowledge. Right one of the caveats I did find with getting HDMI working was the likelihood of increased taints so I think this patch is also required: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c?h=v6.14.11&id=ae048fc4f96d716a2ef326bd6e894694057c078c It is a possibility that either the RAM could be faulty or just unstable and need fine tuning. The problem is that really old system images tend to be less picky about RAM issues and will still try to boot. Normally I would say try installing memtester but that seems to detect failures in the most recent kernel yet my 6.6 build found no memory issues. Besides the originally Android image, have you tested with one of the archived images? More importantly what exactly are the RAM chips used on the board? Can you confirm the actual RAM capacity? From my experience, my second pcduino2 board with the Skhynix RAM had these sorts of problems. Sorry I cant be of more help Ryzer

In that case I would strongly recommend purchasing an A1 rated SD card before trying anything else. If you are getting MMC related errors these are definitely related to the SD card rather than RAM. Once you have done this then we can look into DRAM config if need be. Trying to enable the display post build is kinda tricky. If it was just a matter of adding the HDMI display nodes, then yes that is normally possible however the display driver needs a slight patch in order to work. Now if you had kernel headers installed you could try to build the driver however another current problem means that custom loaded modules seem to not load/unload properly. Seeming as you are using the pre-built Cubieboard images, it already has the display nodes in place but not the recent patches to sun4i-drm. Looking again at the build log you provided earlier it looks like something is blocking the download of bookworm distro which is why it is failing. what happens if you trying ping apt.armbian.com? Given that this issue happens with bookworm, I wonder if it will also happen if trying build with Ubuntu Noble instead. I am currently working on formally including the display patches on my latest development branch so please bear with me. Best of luck Ryzer

That's completely understandable. Given how long the A10 and A20 have been around, I wouldn't expect recent kernels to be thoroughly tested on them. Even from my perspective HDMI is more of a nice-to-have rather than a priority. I realize I might be an exception in this, but I prefer trying to fix issues myself rather than relying on someone else to do it. The only real barrier is my own lack of knowledge. That said, I believe I’ve firmly gotten to grips with device trees now. I acknowledge that I still have some way to go before I can confidently dig into driver development myself. I really appreciate the effort from you and others in making the build system so easy to use. Thanks to that, I’m able to apply my own fixes where needed with relatively minimal technical knowledge of the intricacies of Linux. I actually noticed the change today while browsing kernel.org. Exactly what I had in mind.

@Igor I can only guess that something has changed within the drm framework somewhere between kernel 6.6 and 6.12. After a bit of digging I did find the patch mentioned in my previous post, which I can confirm does restore HDMI functionality albiet with what appear to be minor errors. Taken from Pcduino3: ryan@pcduino3:~$ sudo dmesg | grep drm [sudo] password for ryan: [ 1.000426] sun4i-drm display-engine: bound 1e00000.display-frontend (ops 0xc0caec14) [ 1.000666] sun4i-drm display-engine: bound 1e20000.display-frontend (ops 0xc0caec14) [ 1.001260] sun4i-drm display-engine: bound 1e60000.display-backend (ops 0xc0cae380) [ 1.001797] sun4i-drm display-engine: bound 1e40000.display-backend (ops 0xc0cae380) [ 1.002745] sun4i-drm display-engine: No panel or bridge found... RGB output disabled [ 1.002787] sun4i-drm display-engine: bound 1c0c000.lcd-controller (ops 0xc0cac870) [ 1.003623] sun4i-drm display-engine: No panel or bridge found... RGB output disabled [ 1.003671] sun4i-drm display-engine: bound 1c0d000.lcd-controller (ops 0xc0cac870) [ 1.005703] sun4i-drm display-engine: bound 1c16000.hdmi (ops 0xc0caf610) [ 1.007882] [drm] Initialized sun4i-drm 1.0.0 for display-engine on minor 0 [ 1.068719] sun4i-drm display-engine: [drm] *ERROR* Unsupported infoframe type: 131 [ 1.068755] sun4i-drm display-engine: [drm] *ERROR* Unsupported infoframe type: 129 [ 1.126922] sun4i-drm display-engine: [drm] fb0: sun4i-drmdrmfb frame buffer device [ 4.022304] [drm] Initialized simpledrm 1.0.0 for 7e000000.framebuffer on minor 1 [ 4.150136] simple-framebuffer 7e000000.framebuffer: [drm] fb1: simpledrmdrmfb frame buffer device [ 4.537321] [drm] Initialized lima 1.1.0 for 1c40000.gpu on minor 2 [ 8.416996] systemd[1]: Starting modprobe@drm.service - Load Kernel Module drm... [ 8.783119] systemd[1]: modprobe@drm.service: Deactivated successfully. [ 8.785117] systemd[1]: Finished modprobe@drm.service - Load Kernel Module drm. kernel 6.14 already has the changes adopted so does not need to be patched. I appreciate that boards like the pcduino2 are over a decade old now and not likely to achive the same attention as something like the orange pi zero.

That is worrying, I wonder if there could potentially be issues with the RAM, which could either be faulty or clocked higher than a level it is stable at. Reffering back to the fex you provide earlier it suggest a dram value of 384, so you may have to the def_config file to include the line CONFIG_DRAM_CLK=384. Is the card just class 10 rated or is it an A1 SD card? https://docs.armbian.com/User-Guide_Getting-Started/ Strange it should auto login on first boot. What it should be request is to set a new root password then confirming that password. Could you please provide a screen shot of the login screen you are greeted with. Alternatively it may be possible to set the root password external to get around this issue. Please see: https://docs.armbian.com/User-Guide_Autoconfig/ Strange never encoutered that before, have you tried pulling the latest version of armbian build to see if it fixes it? Unfortunately I have not had a lot of luck in trying to get WSL2 to work so I have stuck with virtual box. Worth a shot with the pre-built images, but I dont believe the Cubieboard is in a much better state. best of luck Ryzer

Ok that is a promising start at least. Are the 'BUG: bad page state messages' every boot or occasionally? The route cause will probably be difficult to find, possibly a deep route kernel or hardware issue. I tend to find that sometimes I will get the bad page state messages and then on another occassion get no kind of faults. You shouldnt need to enter any credientials on first boot, that only applies to setup over network connection. Once you have been able to login and if wireless works then you can install memtester to see if that picks up an errors. not a problem, looking forward to hearing your progress Ryzer

Hi pcduino2user, Nice to see a fellow Pcduino user, I guess not many people interested in over a decade old hardware at this point. I try my best, I am by no means an expert, most of my current changes are just corrections to the device tree. Anyway, there appear to breaking changes in kernel 6.12 which breaks hdmi output. The intial patches for adding the hdmi display nodes are in my pcduino2-and-3-improvements branch however they are for much older kernel versions so need to be re-created, something I plan to do within the coming week. Additional the display driver needs a minor tweak. I currently have a userpatch derived from: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20241130-hdmi-mode-valid-v5-10-742644ec3b1f@linaro.org/ Thanks Ryzer

Right to clarify what I described earlier was the patch creation process, where you would modify an existing file or if the file does not exist you would create in the relevant. After running for a bit the build process will pause. At this point you would need to open a new tab and navigate to cache/sources/linux-kernel-worktree/6.12__sunxi__armhf/arch/arm/boot/dts/allwinner. Here you would need to amend the sun4i-a10-topwise-a721.dts. According to the dts it already has the panel node so the on board display should at least work unless the driver is broken or device tree bindings have changed. Unfortunately I havent worked with panels so cannot provide much further assistance for other than confirming that an entry exist in the simple panel driver. sudo modinfo panel-simple | grep starry [sudo] password for ryan: alias: of:N*T*Cstarry,kr070pe2tC* alias: of:N*T*Cstarry,kr070pe2t ryan@pcduino2-1:~$ Normally to get hdmi to work you simply have to enable the hdmi nodes plus create a hdmi connector node. I have attached the patch that I use on my pcduino2, applying the same alterations to the dts of the topwise's dts should work. I have had issues with hdmi display in 6.12 which I found a work around for but not perfect as we have to modify the hdmi driver. From What I can tell the problem is related to atomic check function: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20241130-hdmi-mode-valid-v5-10-742644ec3b1f@linaro.org/ It may be fixed in kernel 6.14 but I havent tested it yet. save the changes in your text editor and exit. Return to the tab running the build script, hit enter and it will generate a preview of the changes and ask if you are happy with the changes or not. type 'y' to accept. Luckily the build process will helpfully walk you through these steps. Once the build process has finished go to output/patch/. and rename the newly generated patch something useful so that you remember its purpose. Then move it into patches or userpatches. Which is up to you but personally, I prefer to have my patches in userpatches unless it is something I plan to merge in future. whenever you run git pull to fetch the latest version of armbian build, the patch directory is likely to be updated whereas userpatches is not affected. A caveat with userpatches is that full directory structure is not pre-existing so you have to manually create it, mirroring the patches directory. Also note that userpatches are applied after patches in the patch directory. Did you clone Armbian build directly or are you work off your own fork? Now what i tend to do is rerun the build process to check that the patch was applied successful. So rerun ./compile.sh BOARD=topwise-A721 (Replace with the name used in your config file) BRANCH=current RELEASE=bookworm kernel-patch. if successful it should appear in the list of patches and if applied under usepatches it will helpful be the last entry on the list. Unless you have any further patches to apply you can then go on to running a full build. I am suprised no one has yet done a video on the patching process yet Have you attempted disassembling the tablet to check for any solder pads present which could be the serial console? If there is then it may be possible to hook up a usb to serial converter. This could at least be a solid indicator to confirm that the device is at least booting. best of luck Ryzer pcduino2-hdmi-enable.patch

All Armbian board configurations files live in build/config/board/ Besides the Pcduino2 Cubieboard and OlinuXino-lime board, I don't know what other A10 boards still have some level of support. After that the next step would probably be to confirm that it works with uboot. Here you have another config file and dts. For any tweaks to uboot you will need to pass uboot-patch when running compile.sh. Note that when you do this you will need to open a new tab and navigate to cache/sources/u-boot-worktree/ Similiarly for the kernel you would navigate to cache/sources/kernel/ currently 6.12 is "current" while 6.14 is "edge" Hope this helps Ryzer

My mistake I was suggesting based on prior comments found on the Orange Pi Zero3 thread but after reviewing again it looks like the port part of the overlay is no longer necessary either so as Kris777 suggested just the interface name should hopefully now suffice. According to wiki, the main i2c interface should be i2c3: https://linux-sunxi.org/Xunlong_Orange_Pi_Zero2

HI, I dont believe it is necessary to recreate the Topwise A721 dts as it should already be included in the kernel sources used. What most likely needs to be done as a minimum is config file so that the Armbian build system recognizes the board and knows how to handle it. Admittedly I have never added a board so I can only speculate. A problem you may face is that the internal LCD may no longer work with the latest kernels. best of luck Ryzer

oh right, then maybe there is a few things you can help me with in future as I still getting to grips with my esp32. Don't worry it look difficult at first but gets easier. Now I believe I know what the problem, on the overlays line modify it to i2c0-pi and i2c1-pi. This appears to be a common problem with armbian-config overlay functional. My own A10 and A20 systems also has this problem as well.

Hi Yordan, Are you sure you have correctly enabled the i2c overlay on your board? what is the output of cat /boot/armbianEnv.txt? If something is showing up even with nothing apparently connected they your are likely targeting a different bus. It is possible what you are seeing is the address of the internal pmic although this normal shows up as UU. Best of luck Ryzer

A bit later than planned but finally got round to a system rebuild with 6.12.23 but still encounter the exact same issues as before. Loading a simple "hello_world" module intially appears to load successfully but if trying to removing it we then still get: ~/exp-drivers/hello_world$ sudo rmmod hello rmmod: ERROR: ../libkmod/libkmod-module.c:856 kmod_module_remove_module() could not remove 'hello': Resource temporarily unavailable rmmod: ERROR: could not remove module hello: Resource temporarily unavailable Attempting to call lsmod still spams a load of syslog messages and if we then try to call it again it just hangs. Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 403.890953] Internal error: Oops: 5 [#1] SMP THUMB2 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.312451] Process lsmod (pid: 1638, stack limit = 0x9d250a51) Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.325587] Stack: (0xf0dade00 to 0xf0dae000) Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.337169] de00: c16067b0 00000000 00000000 ffffffff c4103000 e2b03f90 6830fe88 e2b03f90 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.352658] de20: 00000400 c9854d70 00000000 bfa9e044 c9854d88 f0dadeb0 bfa9e044 c0309b0b Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.368148] de40: 00000000 00000000 f0dade98 c9854d98 00000001 c9f81000 2e9f8000 c9918300 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.383626] de60: c4043dc0 00000000 f0dadf80 c3126840 00000000 00000400 00000001 c0b217c4 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.399058] de80: c03522a5 c0309e59 00000400 00000001 01aafca0 00000400 00000001 00000000 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.414440] dea0: f0dade90 00000400 00000001 00000000 c3126840 00000000 00000000 00000000 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.429741] dec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000400 e2b03f90 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.445005] dee0: 00000400 c3126840 c9191400 01aafca0 f0dadf80 c02e61d5 00001a55 c4304068 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.460249] df00: c4304068 00000000 00000000 00000000 ffefe2c0 ef32c434 00000000 e2b03f90 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.475507] df20: b6e79fff f0dadfb0 01ab00a4 00000817 c9191400 00000255 c9918300 c0aca39f Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.490740] df40: 00000000 c0aca39f 00000000 00000000 00000000 e2b03f90 00000000 c3126840 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.506009] df60: c3126840 00000000 00000000 c01002a0 c9191400 00000003 00000000 c02e6a09 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.521213] df80: 00000000 00000000 c01002a0 e2b03f90 be93e100 01aae2e0 000005e8 b6bc5888 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.536430] dfa0: 00000003 c0100061 01aae2e0 000005e8 00000003 01aafca0 00000400 00000001 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.551603] dfc0: 01aae2e0 000005e8 b6bc5888 00000003 0000000a be93e3b4 00000000 00000000 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.566780] dfe0: 00000003 be93e2e0 b6b6037b b6ad9656 40070030 00000003 00000000 00000000 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.581942] Call trace: Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.581955] m_show from seq_read_iter+0xd3/0x37c Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.603084] seq_read_iter from seq_read+0xa5/0xcc Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.614746] seq_read from vfs_read+0x79/0x21c Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.626005] vfs_read from ksys_read+0x45/0x9c Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.637120] ksys_read from ret_fast_syscall+0x1/0x5c Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.648813] Exception stack(0xf0dadfa8 to 0xf0dadff0) Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.660406] dfa0: 01aae2e0 000005e8 00000003 01aafca0 00000400 00000001 Message from syslogd@pcduino2-1 at May 24 00:02:33 ... kernel:[ 404.67Segmentation fault Here is what lsmod looks like before trying to load a custom module and going haywire: Module Size Used by aes_arm_bs 20480 2 crypto_simd 12288 1 aes_arm_bs aes_arm 12288 3 aes_arm_bs ccm 16384 6 sunrpc 360448 1 rtl8xxxu 167936 0 mac80211 667648 1 rtl8xxxu axp20x_adc 16384 0 sun4i_gpadc_iio 12288 0 cfg80211 618496 2 mac80211,rtl8xxxu industrialio 61440 2 sun4i_gpadc_iio,axp20x_adc sun4i_ts 12288 0 rfkill 20480 3 cfg80211 libarc4 12288 1 mac80211 sunxi_cedrus 40960 0 v4l2_mem2mem 16384 1 sunxi_cedrus videobuf2_dma_contig 16384 1 sunxi_cedrus videobuf2_memops 16384 1 videobuf2_dma_contig videobuf2_v4l2 16384 2 sunxi_cedrus,v4l2_mem2mem videobuf2_common 45056 5 sunxi_cedrus,videobuf2_dma_contig,videobuf2_memops,v4l2_mem2mem,videobuf2_v4l2 videodev 188416 3 sunxi_cedrus,v4l2_mem2mem,videobuf2_v4l2 mc 36864 5 sunxi_cedrus,videobuf2_common,videodev,v4l2_mem2mem,videobuf2_v4l2 cpufreq_dt 16384 0 evdev 16384 1 uio_pdrv_genirq 16384 0 uio 16384 1 uio_pdrv_genirq zram 24576 2 zsmalloc 16384 1 zram binfmt_misc 20480 1 dm_mod 98304 0 autofs4 36864 2 ext4 606208 2 mbcache 12288 1 ext4 jbd2 102400 1 ext4 pinctrl_axp209 12288 0 lima 49152 0 gpu_sched 36864 1 lima drm_shmem_helper 16384 1 lima sun4i_gpadc 12288 0 sunxi 12288 0 phy_generic 16384 2 sunxi display_connector 16384 0 gpio_keys 16384 0 uas 20480 0 icplus 12288 1 Maybe it would be a safer bet to build again with 6.6 for the time being or try with 6.14 and hope for the best?

Hi Lucas, In the /boot/armbianEnv.txt where you have the line "overlays=sun8i-h3-spi-spidev, you do not need the sun8i-h3 bit. I think it is a problem with how the current version of armbian-config adds overlays. Even though the actually name of the overlay would be sun8i-h3-spi-spidev.dtbo, the armbianEnv.txt only needs the interface name which in this case is spi-spidev. To the best of my knowledge there is no general spi-sunxi module, only spi-sun4i and spi-sun6i. The H3 is compatible with the spi-sun6i driver.

What SD card are you using? I don't believe the A20 is up to the task of running a modern desktop. It could still be a power issue if indeed no LEDs are on at all. Does the device turn off happen randomly or when the Banana Pi M1 power down when under high load? I'd advise getting a USB to Serial adapter to get a better idea of what is happening on the board. Best of luck Ryzer

Thanks for the update, I will create a fresh build this weekend. The only downside is that 6.6.x is now considered legacy. mue473, have you had a chance to test with the latest 6.12.x or higher for any module loading related issues? cheers Ryzer

Right will give it another go. Turns out adjusting the CMA is not straightforward in the case of the A10 or A20. The Video Engine can only access the first 256mb of memory, which is addressed via a DMA pool in the respective dtsi files. Anything higher than the default 96mb causes it become dissociated from the DMA pool. i suspect that's what lead to my earlier crashes.