Why would you do that? Not sure what you’re trying to do by doing this.
Because we’ve already confirmed this specific u-boot is known working and stable, versus the latest in CI. I’m trying to control variables as much as possible, and since the board has never booted with the fixed CI, I can’t say for certain it’s 100% fixed.
This is not the MMC access LED. It’s a heartbeat LED to indicate Linux has started and is operating correctly.
Which raises a question: why is it showing heartbeat when it most definitely is not operating? If it was actually executing, there should be output on the HDMI and I should also see activity on the MMC data lines. It should be attempting root mount; it does not. It just falls flat on it’s face.
And just to be extra certain, I have a stack of other boards for testing the generic kernel builds. RPi3, RPi4, Pine A64-LTS, and a Radxa ROCK 3C. (So bcm, Allwinner A64, and RK3566.) Every one of them is able to run the exact same kernel just fine from the same build process when fed the correct DTBs. I also double checked, and their configuration for 6.1.42 checks out.
It’s best to grab the working kernel and initramfs from our CI images and then try to boot it manually using the script. If it doesn’t boot, the script is bad. If the script does boot, then your custom kernel/initramfs is bad.
Except that is exactly what I am saying: the kernel and initramfs from Libre’s CI images are not working.
I specifically grabbed 2023-05-03-raspbian-bullseye-arm64-lite, loop mounted it, copied the complete kernel including System.map to a good u-boot SD, and that kernel produces the exact same behavior.
When I write that exact image, as-is with no changes at all, it behaves exactly the same. The only difference is it finds grub, executes kernel load, and then I get a solid cyan or purple screen and everything is locked solid with no heartbeat. On both boards. Sometimes - but not consistently - it will get through the EFI stubs post-kernel and go to a solid yellow screen, still locked solid.
And obviously, with the official image doing largely the same, it’s not simply a kernel issue.
So, I had to set aside another project to swipe the FT232 off it (which I’ve been putting off because that project is a real pain to get back to a manageable state.) Which was illuminating in that I’ve been correct. It’s not reaching operating state.
no sdio debug board detected
BL2 Built : 15:21:18, Aug 28 2019. gxl g1bf2b53 - luan.yuan@droid15-sz
set vcck to 1120 mv
set vddee to 1000 mv
Board ID = 3
CPU clk: 1200MHz
DDR scramble enabled
DDR3 chl: Rank0+1 @ 912MHz
bist_test rank: 0 1a 03 31 27 13 3b 17 00 2f 2b 14 43 18 01 2f 29 13 40 19 02 3S
AddrBus test pass!
Load fip header from SD, src: 0x0000c200, des: 0x01400000, size: 0x00004000, pa0
New fip structure!
Load bl30 from SD, src: 0x00010200, des: 0x013c0000, size: 0x0000d600, part: 0
Load bl31 from SD, src: 0x00020200, des: 0x05100000, size: 0x0001b800, part: 0
Load bl33 from SD, src: 0x0003c200, des: 0x01000000, size: 0x00086a00, part: 0
NOTICE: BL31: v1.3(release):c3714b49be
NOTICE: BL31: Built : 09:23:36, Jun 20 2023. gxl bl-3.5.0 gc3714b49be - jenkinh
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services...
[BL31]: tee size: 0
usual dmesg stuff
[ 4.095407] mmc1: new ultra high speed SDR104 SDXC card at address 5048
[ 4.097131] mmcblk1: mmc1:5048 SD64G 58.0 GiB
[ 4.103959] mmcblk1: p1 p2
Starting version 247.3-7+deb11u2
[ 4.183012] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[ 4.332592] usb 1-1: New USB device found, idVendor=05e3, idProduct=0610, bc8
[ 4.335226] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 4.342497] usb 1-1: Product: USB2.0 Hub
[ 4.403144] hub 1-1:1.0: USB hub found
[ 4.403558] hub 1-1:1.0: 4 ports detected
[ 4.415441] mmc0: Card stuck being busy! __mmc_poll_for_busy
[ 4.516508] meson-vrtc c81000a8.rtc: registered as rtc0
[ 4.516584] meson-vrtc c81000a8.rtc: setting system clock to 1970-01-01T00:0)
So post EFI, the HDMI is falling down. Every time, even though it’s a well known MacroSilicon. And as soon as it hits the RTC, dead lock.
And then, Alpine? Alpine’s been booting just fine with
booti this whole time aside from a minor DTB issue! I actually had successful bring-up with both 2022-07 and latest u-boot several days ago, except the HDMI output is breaking as soon as the kernel starts booting. So I had a working config that was crashing for a wholly unrelated reason (busybox config mistake on my part.)
The adapter I’m using can also be ruled out; it’s a MacroSilicon MS2109. Is it great? Hell no. But it’s functional and cheap and I’m not admitting how many I own or have misplaced.
So at this point, we can accurately say the following:
- Alpine Linux 3.18.2 with
linux-lts is able to boot the kernel successfully, but HDMI fails immediately, and the boot fails early due to a distro issue I caused
- Raspbian (Libre) 2023-05 does NOT boot successfully; HDMI fails either before or immediately after EFI stub, and then dies fully when the RTC is intialized. Occurs on both boards.
- Raspbian (Libre) 2023-05 also intermittently locks up attempting to execute EFI stubs which reproduced with multiple SD cards
- Kernel 6.1.40 (Raspbian) does not have functioning HDMI output, and never makes it past RTC
- Kernel 6.1.42 (Alpine) does not have functioning HDMI output, but is able to make it past RTC
- Both show identical results with u-boot 2022-07 or latest CI
So the question really is: why is HDMI breaking here, and why is the Raspbian image dying at RTC or before?