I've tried booting Banana Pi M2 Ultra with LibreELEC-R40.arm-12.2.0-bananapi-m2u.img.gz on a microsd card but it stucks at very first step:
Stock Android image on the e-mmc and stock Ubuntu image on another SD card boots fine on the same device.
I've tried booting Banana Pi M2 Ultra with LibreELEC-R40.arm-12.2.0-bananapi-m2u.img.gz on a microsd card but it stucks at very first step:
Stock Android image on the e-mmc and stock Ubuntu image on another SD card boots fine on the same device.
After this I've tried the older LibreELEC-R40.arm-12.0.2-bananapi-m2u.img.gz image and it proceeds further, shows Libreelec picture
U-Boot 2024.01 (Jan 19 2025 - 21:37:00 +0000) Allwinner Technology
CPU: Allwinner R40 (SUN8I 1701)
Model: Banana Pi BPI-M2-Ultra
DRAM: 2 GiB
Core: 59 devices, 21 uclasses, devicetree: separate
WDT: Not starting watchdog@1c20c90
MMC: mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
In: serial@1c28000
Out: serial@1c28000
Err: serial@1c28000
Net: No ethernet found.
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
1: LibreELEC
Retrieving file: /KERNEL
append: boot=UUID=1901-3650 disk=UUID=1b00dc9a-0bd6-4bdf-a943-108ad6b52376 quiet console=ttyS0,115200 console=tty1
Retrieving file: /sun8i-r40-bananapi-m2-ultra.dtb
Kernel image @ 0x42000000 [ 0x000000 - 0x9d77d0 ]
## Flattened Device Tree blob at 43000000
Booting using the fdt blob at 0x43000000
Working FDT set to 43000000
Loading Device Tree to 49ff3000, end 49fff62c ... OK
Working FDT set to 49ff3000
Starting kernel ...
[ 0.001943] /cpus/cpu@0 missing clock-frequency property
[ 0.002014] /cpus/cpu@1 missing clock-frequency property
[ 0.002051] /cpus/cpu@2 missing clock-frequency property
[ 0.002087] /cpus/cpu@3 missing clock-frequency property
[ 0.559168] sun4i-pinctrl 1c20800.pinctrl: request() failed for pin 198
[ 0.565856] sun4i-pinctrl 1c20800.pinctrl: pin-198 (1c28c00.serial) status -517
[ 0.573179] sun4i-pinctrl 1c20800.pinctrl: could not request pin 198 (PG6) from group PG6 on device 1c20800.pinctrl
[ 0.583741] dw-apb-uart 1c28c00.serial: Error applying setting, reverse things back
[ 1.415535] sun4i-pinctrl 1c20800.pinctrl: request() failed for pin 202
[ 1.422369] sun4i-pinctrl 1c20800.pinctrl: pin-202 (1c20800.pinctrl:202) status -517
[ 1.434034] sun4i-pinctrl 1c20800.pinctrl: request() failed for pin 192
[ 1.440839] sun4i-pinctrl 1c20800.pinctrl: pin-192 (1c10000.mmc) status -517
[ 1.448081] sun4i-pinctrl 1c20800.pinctrl: could not request pin 192 (PG0) from group PG0 on device 1c20800.pinctrl
[ 1.458825] sunxi-mmc 1c10000.mmc: Error applying setting, reverse things back
..........
Display More
After that I've had other problems but that's probably unrelated to issue above
I had 12.0.2 running on a BananaPi-M2 Berry and tried the update procedure from within LibreElec console. Screen went black and further no boot.
So I flashed the 12.2.0 and that does not boot. So tried the 12.0.2-bananapi-m2u image and that does not boot either.
So I tried 2020-04-19-raspbian-jessie-bpi-m2u-sd-emmc.img and that does boot.
Any ideas?
I flashed the LibreELEC-R40.arm-12.2-nightly-20251008-fd9623b-bananapi-m2u.img.gz but still no green led activity
I wonder if I am using the correct image?
Has it something to do with 32/64 bit?
If neither LE or Armbian images for the board boot, it's either bad hardware or something in common boot code that both distros share. Do you have a UART cable that can be attached to show early boot output?
Yes, I'll hook things up to see what happens. Strange thing is that an old respbian does boot...
What is the setting for the debugport, I tried 115200 8N1 but only garbage comes out
Tried other serial adapter. Now get the message:
U-Boot SPL 2025.07 (Oct 12 2025 - 20:27:55 +0000)
DRAM 1024 Mib
Trying to boot from MMC1
And that's the end.
When I start from the raspbian-jessie I get a different startup.
First:
[294]HELLO BPI! BOOT0 is starting!
it ends with:
[600]Jump to secend boot
then
U-Boot 2014.07 (April 19 2020 - 14:29:12) Allwinner Technology
and then continues
Ok, so there is some issue with mainline U-Boot. R40 is so rare that nobody raised issue before. I guess some bisecting is in order...
If I can help, please say so.
The strange thing is that I had 12.0.2 running on the BPi and then I decided to update...
I shouldn't have done that.. But talking afterwards is always easy..
And I tried to install 12.0.2 and that does not start either..
puzzled...
I tried 10.0.4 and that boots and starts.
I'll try 11.0.6 next
I tried 11.0.6 and that works.
I tried 12.0.2 and that works too.
I was misinterpreting that the green led should show activity when the system starts, but that is not the case.
At least not with LibreElec. With Raspbian it does.
I found the issue, but I'm not sure how to solve it yet. It's extremely weird. U-Boot is not built correctly, that much is obvious. However, reason why is curious. If I put .git folder into source folder, then it builds correctly. It seems that some tool require git metadata to decide something. I have to find which tool causes that.
This is second weird build bug that I'm researching in last week or so...
Years ago I heard someone say that with computers everything would be easier.....
I hit the same hang with LibreELEC 12.2.1 on a Banana Pi M2 Ultra (R40) and tracked it down with the serial console and FEL. Serial output, then nothing:
The same image boots fine with the U-Boot 2024.01 from 12.0.2.
Cause: U-Boot 2025.07 contains commit 358d1cc232c3 ("spl: Align FDT load address"), so the SPL now puts the device tree at the end of U-Boot proper rounded up to 8 bytes. U-Boot proper (OF_SEPARATE) still looks for it exactly at _end, which 2025.07 doesn't align. In the 12.2.1 build for this board U-Boot is 367164 bytes (4 more than a multiple of 8), so U-Boot proper finds no device tree and hangs before its serial console starts. That's why nothing at all is printed after the SPL. 2024.01 isn't affected (its U-Boot is 359920 bytes and its SPL doesn't round). Whether a board is hit depends on its U-Boot size, so other 32-bit Allwinner boards may or may not be affected.
Verified over FEL: LibreELEC's own 12.2.1 U-Boot boots when the device tree is placed exactly at _end, and hangs with no output when it's placed 4 bytes higher (where the 2025.07 SPL puts it).
Fix: upstream fixed it in commit 8b0ebe054bb3 ("arm: Update linker scripts to ensure appended device tree is aligned", in U-Boot v2026.04 and later). LibreELEC master already uses U-Boot 2026.10, which works on my board. For 12.2 the backport is two lines in the linker scripts (. = ALIGN(8); before _end). With it, a real SD boot of 12.2.1 works. I've opened a GitHub issue with the patch: https://github.com/LibreELEC/LibreELEC.tv/issues/11966
Workaround until then: write the 12.2.1 image to the SD card, then replace its bootloader with the one from the 12.0.2 image (both have the first partition at 4 MiB, the bootloader area is 8 KiB to 4 MiB). On Linux, with the card as /dev/sdX (check with lsblk!):
gunzip -c LibreELEC-R40.arm-12.0.2-bananapi-m2u.img.gz | dd of=uboot-12.0.2.bin bs=1k skip=8 count=4088
sudo dd if=uboot-12.0.2.bin of=/dev/sdX bs=1k seek=8 conv=fsync
That's what my board runs now (12.2.1, from eMMC, with U-Boot 2024.01).
Thanks for the information. I noticed this issue but was unable to find the cause for it after spending quite some time on it.
In any case, 12.x version won't have any future update, so any M2U user will have to wait on LE13 or use this workaround.