Dave

Hello to everyone Trying to use armbian on RockPi 4C plus. Got kernel OOPS. Kernel crushes in different moments: mostly during systemd units starting or just after boot finished. Backtraces are different (no common). Faulty images: 1) From the https://www.armbian.com/rockpi4/ For Model C+ here: https://redirect.armbian.com/rockpi-4cplus https://mirrors.dotsrc.org/armbian-dl/rockpi-4cplus/archive/ Armbian_22.11.1_Rockpi-4cplus_bullseye_current_5.15.80_minimal.img 2) Built by myself Armbian_22.11.2_Rockpi-4cplus_bullseye_current_5.15.84_minimal.img Armbian_23.02.0-trunk_Rockpi-4cplus_bullseye_edge_6.1.8_minimal.img Armbian_23.02.0-trunk_Rockpi-4cplus_bullseye_edge_6.1.9_minimal.img Armbian_23.02.0-trunk_Rockpi-4cplus_bullseye_edge_6.1.10_minimal.img My image build script for the edge (6.1.x): #!/bin/bash BOARD_NAME_PARAM="rockpi-4cplus" LINUX_DISTRO_PARAM="bullseye" LOG_FILE="_armbian_build_${BOARD_NAME_PARAM}.log" BRANCH_VALUE="edge" log() { local currtime=`date +"%Y/%m/%d %H:%M:%S"` echo "$currtime: $*" echo "$currtime: $*" >> $LOG_FILE } log "$0 begin" ARMBIAN_BUILD_OPTIONS="\ BOARD=$BOARD_NAME_PARAM \ BRANCH=$BRANCH_VALUE \ FULL_DESKTOP=no \ BUILD_DESKTOP=no \ BUILD_MINIMAL=yes \ INSTALL_HEADERS=no \ KERNEL_ONLY=no \ KERNEL_CONFIGURE=no \ RELEASE=$LINUX_DISTRO_PARAM \ COMPRESS_OUTPUTIMAGE=\"sha,img,xz\" \ " log "ARMBIAN_BUILD_OPTIONS=$ARMBIAN_BUILD_OPTIONS" log log "====================================" log "Armbian build - starting ..." log "====================================" sudo ./compile.sh $ARMBIAN_BUILD_OPTIONS armbian_compile_result=$? if [ $armbian_compile_result -eq 0 ]; then log "====================================" log "Armbian build finished: SUCCESS" log "====================================" else log "====================================" log "Armbian build failed: ERROR" log "====================================" fi log "$0 end" exit 0 All the faulty images have common thing in /boot/armbianEnv.txt fdtfile=rockchip/rk3399-rock-pi-4c-plus.dtb As I found out there are 2 dtbs referring to rockpi 4cplus: /boot/dtb-6.1.10-rockchip64/rockchip/rk3399-rock-4c-plus.dtb /boot/dtb-6.1.10-rockchip64/rockchip/rk3399-rock-pi-4c-plus.dtb Vanilla kernel https://github.com/torvalds/linux/tree/master/arch/arm64/boot/dts/rockchip has rk3399-rock-4c-plus dts https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts and does not have rk3399-rock-pi-4c-plus I've changed /boot/armbianEnv.txt in the following way fdtfile=rockchip/rk3399-rock-4c-plus.dtb WIth rk3399-rock-4c-plus.dtb my RockPi 4C plus board boots fine and does not hang. I believe there is a mistake in dtb files. Why there are 2 dtbs /boot/dtb/rockchip/rk3399-rock-4c-plus.dtb /boot/dtb/rockchip/rk3399-rock-pi-4c-plus.dtb ?

I've built new image from the trunk (23.02) The issue is fixed now. Boot partiton now has correct type "b (W95 FAT32)" compatible for both RPi3 and RPi4. The image boots fine - checked on RPi3B plus and RPi4 fdisk -l Armbian_23.02.0-trunk_Rpi4b_jammy_edge_6.1.10_minimal.img Disk Armbian_23.02.0-trunk_Rpi4b_jammy_edge_6.1.10_minimal.img: 2.62 GiB, 2810183680 bytes, 5488640 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x50838be0 Device Boot Start End Sectors Size Id Type Armbian_23.02.0-trunk_Rpi4b_jammy_edge_6.1.10_minimal.img1 8192 532479 524288 256M b W95 FAT32 Armbian_23.02.0-trunk_Rpi4b_jammy_edge_6.1.10_minimal.img2 532480 5488639 4956160 2.4G 83 Linux

1) I've made a typo in my original post - my bad: for Armbian_22.08.7 I've mentioned incorrect image file name Armbian_22.08.1_Rpi4b_jammy_current_5.15.61.img Correct piece of text should be: -------------------------------- I've faced the issue: Armbian_22.08.7 official image (Armbian_22.08.7_Rpi4b_jammy_current_5.15.74_minimal.img) failed to boot on RPi3B plus. -------------------------------- 2) About your statement: "The Raspberry Pi 3B/3B+ isn't a supported board. The images are menth to be used on Raspberry Pi4 and 400 only. That you can make it work on the 3B+ is just a bonus." Official Armbian page for for RPi: https://www.armbian.com/rpi4b Please check out "Compatible" list: 3A 3B 3B+ 4 and etc So RPi 3 family models are officially supported 3) There is no technical reason for Armbian RPi distro not to work on RPi3 boards It has all required components: Kernel, device tree, firmware. The main reason is just incorrect changes for image build procedure which sets wrong boot partition type. And I can repeat: Armbian images up to version 22.08.1 inclusively were correct (bootable both on RPi3 and RPi4). Mistake was introduced into image build procedure somewhere between versions 22.08.1 and 22.08.7 By the way "ef" (EFI) partition is the same FAT32 partition just with different partition type code: https://en.wikipedia.org/wiki/EFI_system_partition Manually changing just boot partition type to "c" (FAT32) make image bootable on both RPi3 and RPi4 4) There is a huge amount of RPi3 boards in the field: no reason to limit Armbian usage area without any strong cause.

Hello everybody. I've faced the issue: Armbian_22.08.7 official image (Armbian_22.08.1_Rpi4b_jammy_current_5.15.61.img) failed to boot on RPi3B plus. The same image boots fine on RPi 4B Could not get serial console output (output is empty) Older official image Armbian_22.08.1_Rpi4b_jammy_current_5.15.61.img boots on Rpi3B plus just fine. As I've found out the reason is incorrect boot partition type set for the image. Armbian_22.08.1 (boots fine) boot partition type is "c" (W95 FAT32 LBA) Armbian_22.08.7 (doesn't boot) boot partition type is "ef" (EFI) After manually changing boot partiton type to "c" (W95 FAT32 LBA) for the image Armbian_22.08.7_Rpi4b_jammy_current_5.15.74_minimal.img it begins to boot Please check fdisk output ===================== "Good" image: $ fdisk -l Armbian_22.08.1_Rpi4b_jammy_current_5.15.61.img Disk Armbian_22.08.1_Rpi4b_jammy_current_5.15.61.img: 3 GiB, 3196059648 bytes, 6242304 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x79597c7b Device Boot Start End Sectors Size Id Type Armbian_22.08.1_Rpi4b_jammy_current_5.15.61.img1 8192 532479 524288 256M c W95 FAT32 (LBA) Armbian_22.08.1_Rpi4b_jammy_current_5.15.61.img2 532480 6242303 5709824 2,7G 83 Linux ===================== "Bad" image: $ fdisk -l Armbian_22.08.7_Rpi4b_jammy_current_5.15.74_minimal.img Disk Armbian_22.08.7_Rpi4b_jammy_current_5.15.74_minimal.img: 2,5 GiB, 2680160256 bytes, 5234688 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x1d7b3f1b Device Boot Start End Sectors Size Id Type Armbian_22.08.7_Rpi4b_jammy_current_5.15.74_minimal.img1 8192 532479 524288 256M ef EFI (FAT-12/16/32) Armbian_22.08.7_Rpi4b_jammy_current_5.15.74_minimal.img2 532480 5234687 4702208 2,2G 83 Linux ===================== The same story is for manual build from the repo (Armbian 22.08.11) Image build is fine. Image doesn't boot on RPi3Bplus Boots fine on RPi4 Manual compile command is: #!/bin/bash BOARD_NAME_PARAM="rpi4b" LINUX_DISTRO_PARAM="jammy" ARMBIAN_BUILD_OPTIONS="\ BOARD=$BOARD_NAME_PARAM \ BRANCH=current \ FULL_DESKTOP=no \ BUILD_DESKTOP=no \ BUILD_MINIMAL=yes \ INSTALL_HEADERS=no \ KERNEL_ONLY=no \ KERNEL_CONFIGURE=no \ RELEASE=$LINUX_DISTRO_PARAM \ COMPRESS_OUTPUTIMAGE=\"sha,img,xz\" \ ARMBIAN_CACHE_ROOTFS_PATH=/mnt/armbian-cache/rootfs \ ARMBIAN_CACHE_TOOLCHAIN_PATH=/mnt/armbian-cache/toolchain \ " sudo ./compile.sh $ARMBIAN_BUILD_OPTIONS --------------------------- As example - please check out notice from https://github.com/pftf/RPi3 Create an SD card (or USB drive if you plan to use USB Boot) in MBR mode with a single partition of type 0x0c (FAT32 LBA) or 0x0e (FAT16 LBA). Then format this partition to FAT32. Note: Do not try to use GPT for the partition scheme or 0xef (EFI System Partition) for the type, as these are unsupported by the CPU-embedded bootloader.