koutheir Posted September 22 Share Posted September 22 (edited) I downloaded and flashed the three images of Armbian 24.8.1 (Noble GNOME, Ubuntu 22.04 Jammy and Debian 12 Bookworm) on the Banana Pi M7, connected to the computer via serial console. The three images are these: Armbian_24.8.1_Bananapim7_noble_vendor_6.1.75_gnome-kisak_desktop.img Armbian_24.8.1_Bananapim7_jammy_vendor_6.1.75_kde-neon-kisak_desktop.img Armbian_24.8.1_Bananapim7_bookworm_vendor_6.1.75_cinnamon-backported-mesa_desktop.img For each image, I booted and logged the board output. The board fails to successfully boot and instead gets stuck in a boot loop. I then mounted the armbi_root partition and edited the file armbi_root/boot/armbianEnv.txt to set verbosity=7, in the hope of getting more useful information from the kernel. I retried booting the board, and I observed the same boot loop, but this time with more kernel logs. The serial outputs of the failed boots are here: Armbian 24.8.1 Noble GNOME: noble.log (see attached files) Armbian 24.8.1 Ubuntu 22.04 Jammy: jammy.log (see attached files) Armbian 24.8.1 Debian 12 Bookworm: bookworm.log (see attached files) I’m not sure why the kernel decides to reboot everytime, but I’m sharing the information in case it is useful to someone. (see original post) noble.log jammy.log bookworm.log Edited September 22 by koutheir Attached files locally instead of linking them. 0 Quote Link to comment Share on other sites More sharing options...
royk Posted September 22 Share Posted September 22 Your logs are not visible without logging in at the forum of banana-pi 0 Quote Link to comment Share on other sites More sharing options...
koutheir Posted September 22 Author Share Posted September 22 16 minutes ago, royk said: Your logs are not visible without logging in at the forum of banana-pi I'm sorry, I didn't realize that. I edited the post in order to attach the files directly instead of linking them. 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted September 22 Share Posted September 22 How I did testing: 1. Download https://dl.armbian.com/bananapim7/Bookworm_vendor_minimal 2. Flash and boot (by using USB Imager - try that perhaps) 3. Boot logs: https://paste.armbian.com/vucakunoko Next: testing the same image just to make sure: https://dl.armbian.com/bananapim7/Noble_vendor_gnome-kisak Armbian_24.8.1_Bananapim7_noble_vendor_6.1.75_gnome-kisak_desktop.img Boot logs: https://paste.armbian.com/jobavuqeza My PSU is lab, no PD. Problem is 100% not on our side. 0 Quote Link to comment Share on other sites More sharing options...
koutheir Posted September 23 Author Share Posted September 23 I downloaded and flashed both images, then I set verbosity=7, then I booted each on the board. I'm powering the board using a USB-C 30W power supply. I don't know of another way to power the board. Both images failed to boot on my board, and I attached the serial console logs for reference. Armbian_24.8.1_Bananapim7_bookworm_vendor_6.1.75_minimal.log Armbian_24.8.1_Bananapim7_noble_vendor_6.1.75_gnome-kisak_desktop.log 0 Quote Link to comment Share on other sites More sharing options...
koutheir Posted September 23 Author Share Posted September 23 (edited) As I mentioned here, the Armbian unofficial 24.5.0 provided in the Banana Pi M7 documentation boots fine and works as expected, provided that the package linux-dtb-legacy-rk35xx does not get upgraded. For some reason, the version 24.5.0-trunk of that package works fine, but upgrading it to version 24.5.1 breaks the boot process. For the moment, I placed an apt hold on that package, in order to avoid upgrading it by mistake. Upgrading all other packages does not cause boot problems. I'm trying to analyze the situation, so I captured the serial console output of that image booting before upgrading linux-dtb-legacy-rk35xx (so version 24.5.0-trunk) and after the upgrade (so version 24.5.1). Of course, the second boot fails, but I captured all u-boot and kernel logs. I removed the kernel timestamps in order to make the comparison easier. I then sorted the log files (yes, alphabetic sort), and looked for the lines that are different. I noticed that the u-boot log is almost the same. The differences are in the kernel logs. Here are the log lines that are emitted only during the broken boot process: OF: graph: no port node found in /i2c@feab0000/fusb302@22 OF: graph: no port node found in /i2c@feab0000/fusb302@22/connector OF: graph: no port node found in /i2c@feab0000/fusb302@22/connector OF: graph: no port node found in /i2c@feab0000/fusb302@22/connector ... rk-pcie fe180000.pcie: PCIe Linking... LTSSM is 0x2 And here are the lines that are different (- is for the working boot, and + is for the broken boot): -RKNPU fdab0000.npu: pvtm=834 +RKNPU fdab0000.npu: pvtm=835 ... -cpu cpu4: pvtm=1707 +cpu cpu4: pvtm=1704 ... -dwmmc_rockchip fe2c0000.mmc: DW MMC controller at irq 92,32 bit host data width,256 deep fifo +dwmmc_rockchip fe2c0000.mmc: DW MMC controller at irq 91,32 bit host data width,256 deep fifo ... -dwmmc_rockchip fe2c0000.mmc: Successfully tuned phase to 8 +dwmmc_rockchip fe2c0000.mmc: Successfully tuned phase to 13 ... -feb90000.serial: ttyS6 at MMIO 0xfeb90000 (irq = 104, base_baud = 1500000) is a 16550A +feb90000.serial: ttyS6 at MMIO 0xfeb90000 (irq = 103, base_baud = 1500000) is a 16550A ... -pcieport 0002:20:00.0: PME: Signaling with IRQ 192 +pcieport 0002:20:00.0: PME: Signaling with IRQ 191 ... -pcieport 0004:40:00.0: PME: Signaling with IRQ 150 +pcieport 0004:40:00.0: PME: Signaling with IRQ 149 ... -xhci-hcd xhci-hcd.7.auto: irq 139, io mem 0xfcd00000 +xhci-hcd xhci-hcd.7.auto: irq 138, io mem 0xfcd00000 ... -xhci-hcd xhci-hcd.8.auto: irq 140, io mem 0xfc400000 +xhci-hcd xhci-hcd.8.auto: irq 139, io mem 0xfc400000 And, for completeness, here are the log lines that only appear in the working kernel: EXT4-fs (mmcblk1p2): mounted filesystem with writeback data mode. Opts: (null) EXT4-fs (mmcblk1p2): re-mounted. Opts: commit=600,errors=remount-ro ... NET: Registered protocol family 10 ... Segment Routing with IPv6 ... fuse: init (API version 7.32) ... rk-pcie fe150000.pcie: PCIe Link Fail ... rk-pcie fe150000.pcie: PCIe Linking... LTSSM is 0x1 rk-pcie fe150000.pcie: failed to initialize host ... rockchip-pinctrl pinctrl: could not request pin 116 (gpio3-20) from group usbc1-int on device rockchip-pinctrl rockchip-pinctrl pinctrl: pin gpio3-20 already requested by fe2b0000.spi; cannot claim for 3-0022 rockchip-pinctrl pinctrl: pin-116 (3-0022) status -22 ... spi-nor spi5.0: unrecognized JEDEC id bytes: ff ff ff ff ff ff spi-nor: probe of spi5.0 failed with error -2 ... typec_fusb302 3-0022: Error applying setting, reverse things back typec_fusb302: probe of 3-0022 failed with error -22 ... systemd[1]: ... I still don't know what is going wrong after upgrading linux-dtb-legacy-rk35xx, but I hope this small comparison gives someone a better idea, in order to help me solve this issue. For reference: # uname -a Linux banana-pi-m7-aarch64-1 5.10.160-legacy-rk35xx #1 SMP Wed May 15 03:04:45 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux # lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.4 LTS Release: 22.04 Codename: jammy # armbian-config reports: # - Armbian 24.5.1 stable # - Ubuntu jammy based Armbian for the ArmSoM Sige7 # - SoC runs between 408 and 2256 MHz using ondemand governor. Edited September 23 by koutheir 0 Quote Link to comment Share on other sites More sharing options...
Solution koutheir Posted September 23 Author Solution Share Posted September 23 I found and fixed the problem, and of course, it is the PSU. TL;DR: use a USB-C PD 2.0 power supply that can provide 35W for a single USB-C port. I bought the Banana Pi M7 from this Amazon page, and the seller provides a power supply, with the board, that can only provide up to 20W of power. Even though the board specification says "Power Input: USB Type-C PD 2.0, 9V/2A, 12V/2A, 15V/2A", which implies that the board can require up to 30W of power. This caused most official images (Armbian and otherwise) to fail to boot. I happened to have a USB-C charger that can provide 35W of power, so I tried that instead, and it basically solved the whole problem. I tried multiple Armbian official images and they work as expected. Thank you for your help! I hope this helps someone. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.