RPI4 w/ 21:9 monitor and 3440x1440 resolution hangs on boot

I'm stumped with a problem and would appreciate any pointers for troubleshooting.

I got my RPI to start booting in 3440x1440 with the following /boot/msdos/config.txt:
Code:
[all]
arm_64bit=1
dtparam=audio=on,i2c_arm=on,spi=on
dtoverlay=mmc
dtoverlay=disable-bt
device_tree_address=0x4000
kernel=u-boot.bin

[pi4]
max_framebuffer_width=3440
max_framebuffer_height=1440
hdmi_force_hotplug=1
hdmi_group=2
hdmi_mode=87
hdmi_cvt=3440 1440 30 7 0 0 0
framebuffer_width=3440
framebuffer_height=1440

Unfortunately, once the kernel starts to boot, I get the following printout on screen and the system then hangs (transcribed):
Code:
Booting [/boot/kernel/kernel].
Using DTB provided by EFI at 0x7ef0000.
EFI framebuffer information:
addr, size    0x3d7de000, 0x12e5800
Dimensions    3440 x1440
stride        3440
masks         0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000

Removing
Code:
max_framebuffer_width=3440
max_framebuffer_height=1440
makes the system boot, but I'm stuck on a 1920 times something resolution; switching to 3440x1440 after initialization does not work.

I even tried adding
Code:
hdmi_enable_4kp60=1
instead; this appears to also switch into 3440x1400 upon display initialization. However, boot still gets stuck after above message.

I tried adding
Code:
efi_max_resolution=3440x1440
screen.width=3440
screen.height=1440
to /boot/loader.conf but with no effect.

Not sure, whether this is relevant - firmware was updated recently, as I'm booting from USB SSD (this wouldn't work otherwise). Running on FreeBSD 13.0 p5.
 
Thanks, unfortunately, that doesn't fix it.

The thread you linked to seems to describe a slightly different problem set, if I read this right. I do get the desired resolution upon device initialization. The u-boot loader lists details and hands the baton off to the loader in the right resolution.

Finally, once the actual kernel starts loading, it just stops and... goes out for lunch? I suspect it's a FreeBSD and not a hardware issue. Then again, this might be an issue with the device tree blob or god knows what. This embedded boot stuff is not my strength at all.

I dread that my only possible way to troubleshooting might be hooking up a serial line and debugging the kernel. Or maybe I should start putting some printfs into a custom kernel in an attempt to figure out what's going on.
 
From what I gather on the internet, yes. One person that reported success (yes, I know, this isn't statistically significant and it's unfortunately in German but Google Translate does a reasonable job):


and another one:
though this one blames newer firmware for breaking a previously working setup...

I found the relevant parts where the loader halts; it's somewhere in stand/efi/loader/bootinfo.c. I've added in a bunch of printfs and am now recompiling to figure out where it stops.
 
I have now cleared loader from the list of culprits. After enabling VERBOSE_SYSINIT and not getting any further output after loader, I'm now digging into the CPU and memory initialization.

What better way to start the day than picking through some kernel code...
 
And nothing. The culprit is likely somewhere in sys/arm64/arm64/machdep_boot.c, but short of connecting a serial line and debugging the kernel, I probably won't be able to troubleshoot this, I guess. Adding printfs doesn't work at this stage - system is not sufficiently initialized at this point in time.

I'm wondering what possibly could go wrong here, just because the resolution is higher? Anyone got 4k working with FreeBSD 13 on an RPI4?
 
Back
Top