c0rnelius

I suspect the issue is the version of U-Boot currently on the eMMC. When the board boots, if U-Boot is found on the eMMC, that is what will be used to do the initial boot. If an SDCARD is detected with a viable OS, it will then attempt to load it. It may be that the version of U-Boot "BSP?" on the eMMC is not compatible with Armbian and needs to be dd'd off. I just flashed this to SD to test. Came up fine. ____ ____ _ __ __ ____ ____ | __ )| _ \(_) | \/ |___ \/ ___| | _ \| |_) | | | |\/| | __) \___ \ | |_) | __/| | | | | |/ __/ ___) | |____/|_| |_| |_| |_|_____|____/ Welcome to Armbian 24.5.3 Bookworm with Linux 6.6.36-current-meson64 System load: 10% Up time: 1 min Memory usage: 4% of 3.69G IP: CPU temp: 37°C Usage of /: 4% of 29G [ Menu-driven system configuration (beta): sudo apt update && sudo apt install armbian-config ]

Your welcome.

I used gnome-disk-utility `gnome-disks`.

It came right up. patrick@10.0.0.XXX's password: ____ _ ____ _ ____ | _ \ __ _ ___ _ __ | |__ ___ _ __ _ __ _ _ | _ \(_) | ___| | |_) / _` / __| '_ \| '_ \ / _ \ '__| '__| | | | | |_) | | |___ \ | _ < (_| \__ \ |_) | |_) | __/ | | | | |_| | | __/| | ___) | |_| \_\__,_|___/ .__/|_.__/ \___|_| |_| \__, | |_| |_| |____/ |_| |___/ Welcome to Armbian_community 24.8.0-trunk.369 Bookworm with Linux 6.6.39-current-bcm2712 No end-user support: untested automated build System load: 8% Up time: 1 min Memory usage: 5% of 3.89G IP: 10.0.0.XXX CPU temp: 47°C Usage of /: 4% of 29G patrick@rpi5b:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS mmcblk0 179:0 0 29.7G 0 disk ├─mmcblk0p1 179:1 0 256M 0 part /boot/firmware └─mmcblk0p2 179:2 0 29.2G 0 part /var/log.hdd / zram0 253:0 0 1.9G 0 disk [SWAP] zram1 253:1 0 50M 0 disk /var/log zram2 253:2 0 0B 0 disk nvme0n1 259:0 0 238.5G 0 disk ├─nvme0n1p1 259:1 0 508M 0 part └─nvme0n1p2 259:2 0 238G 0 part I suggest you try another PSU. These units don't fair well under powered. If you are using a PSU to SPEC and still having issues try using a quality SDCARD.

Which img did you try? For usb boot, try adding usb_max_current_enable=1 to the config.txt file.

https://github.com/raspberrypi/libcamera https://github.com/raspberrypi/picamera2 Ubuntu Noble already has this available; sudo apt install python3-libcamera

I've only worked with the BPI-M4-ZERO. My personally opinion on the h616/8 line up is that the focus should be on stable and not LTS. Little to none of the official mainline patches are being back ported and the patches being used currently in LTS are kind of hack-a-noodle patches. For example: https://lore.kernel.org/linux-arm-kernel/CA+E=qVeMnQNrT8tNnHBnCL2Efy3VjbRAYQGMXstziCThRsiBDw@mail.gmail.com/T/ https://lore.kernel.org/linux-arm-kernel/20240419071450.7aiheeoyq35yjoo7@vireshk-i7/T/ The ones being currently used in Armbian I believe are either RFC's or taken from OPI. The thermal patch above is already in 6.9.y. But with that said, if you have any questions feel free to hit me up and if I can, I'll help.

Try disabling wireless completely using the config.txt: dtoverlay=disable-wifi-pi5 If you don't need bluetooth disable that to: dtoverlay=disable-bt-pi5 Not enabling it in nmtui is not enough, the module is still active 'firmware is still getting loaded' and can't find a country code.

`modprobe i2c-dev` or add it to /etc/modules and reboot.

Its a bug. You need to make sure the wireless country code is set, even when its not being used.

New imgs are now available. 6.6.30-current-meson64 https://www.armbian.com/bananapicm4io/

I'll see if I can get those release imgs updated to something more recent and inquire about the breakage.

Damn. That's not good. Sorry to hear that.

Hmm. It appears ur still on 6.6.16-current-meson64 which does not include the fix.

This has already been fixed upstream and backported to 6.6.y LTS. https://lore.kernel.org/lkml/20240322164525.2617508-1-christianshewitt@gmail.com/ My suggestion is to update the kernel. If you don't wanna update you may just be able to blacklist the driver, which was what I did until it was fixed. It comes down to what is required by Klipper in your case.

I suggest looking over the overlays available; https://github.com/BPI-SINOVOIP/pi-linux/tree/pi-6.1-sunxi/arch/arm64/boot/dts/allwinner/overlay They may or maynot need to be edited as BSP VS MAINLINE usually isn't identical.

Using overlays on the PI whilst on Armbian should be no different than doing so on RaspiOS. https://www.raspberrypi.com/documentation/computers/config_txt.html#overlay_prefix If you don't know how to use them I suggest you use google or check the foundation docs.

Try disabling it with an overlay. /dts-v1/; /plugin/; / { fragment@0 { target = <&mbus>; __overlay__ { status = "disabled"; }; }; }; If that doesn't work, set the wrong compat string. /dts-v1/; /plugin/; / { fragment@0 { target = <&mbus>; __overlay__ { compatible = "allwinner,sun8i-h3-mbus"; }; }; }; Use the `armbian-add-overlay` to compile and add the overlay. NOTE: The overlay(s) may not work because of how the current DTS is setup, which is why I suggested blacklisting the driver. The driver in question is: sun8i-a33-mbus https://lore.kernel.org/linux-arm-kernel/a48923b7-12f9-808e-1171-49b826bd5f1c@samsung.com/T/#ma00a3e07248dc7fb2d300b7c9c409f69ffa64c14

Try adding a delay and see if that corrects the DRAM detection. https://github.com/armbian/build/blob/main/patch/u-boot/v2024.01/board_bananapim4zero/006-sunxi-restore-modified-memory.patch#L149

Kali is in a lot of ways a polished SID with all of their own custom bits added. It can be debootstrap'd just like Debian, Devuan and Ubuntu. I did find some services didn't work on boot; 'ssh avahi bluetooth ntp'. But there could be some option they have I'm not aware of to allow those services to start out of the box. Creating a custom service to start those does the trick though. I would think adding this as an option could be doable, but the question then becomes who wants to handle the support required to maintain it?

Try adding it this way. extraargs=swiotlb=0

Add this to your cmdline. swiotlb=0 https://github.com/raspberrypi/linux/commit/3e0065d1cb5bd58e35e0c7722ffe6303dfe0364f

The 6.6.y kernel for reasons I have yet to figure out reads the MEM wrong. 6.7 and up is not affected by this. Nor is 6.1 to 6.5. I would have thought after so many REVS this would have been resolved, but I have yet to see it come up as a topic of discussion. This in my experience is also not PLATFORM specific. It happens on all my boards regardless of SoC and PLATFORM.

I suspect it has to do with the devfreq driver for the MBUS/DRAM controller. https://lore.kernel.org/linux-arm-kernel/a48923b7-12f9-808e-1171-49b826bd5f1c@samsung.com/T/#ma00a3e07248dc7fb2d300b7c9c409f69ffa64c14 In my personal experience this introduces instability into the a64/h5. You could try blacklisting the driver and see if it solves the issue. I personally remove the entry from the DTS and create an overlay to add it back if for some reason I need it. The main issue you reported `Kernel panics with headless boot` in my mind points to it being the driver.

My guess would be this patch; https://github.com/armbian/build/blob/main/patch/u-boot/v2022.10/meson64-boot-usb-nvme-scsi-first.patch But if its a spin up HDD, it could be PREBOOT and it isn't able to spin up the drive in time and halting the boot process.