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



## cmoerz (Dec 9, 2021)

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:

```
[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):

```
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

```
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

```
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

```
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.


----------



## bakul (Dec 9, 2021)

From https://forums.raspberrypi.com/viewtopic.php?t=248037
add `hdmi_pixel_freq_limit=400000000`. The RPF folks are quite helpful but you have to report a problem you see while running Raspbian! Mainly because that is what they know.


----------



## cmoerz (Dec 9, 2021)

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.


----------



## bakul (Dec 9, 2021)

Does this resolution work with Raspbian?


----------



## cmoerz (Dec 9, 2021)

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):






						Raspberry Pi 4 und Ultra Wide Monitor... - Deutsches Raspberry Pi Forum
					

Liebe Foristen,  habe eine dringliche Frage zur Behebung eines Fehlers. Deswegen will ich gleich zur Sache kommen. Und zwar geht es um einen Raspberry pi 4 und einen IIYAMA ProLite XUB3493WQSU-B1 mit der Auflösung 3440x1440 also 21:9. Habe schon etliche…




					forum-raspberrypi.de
				




and another one:





						No HDMI Output - RPI4 4GB - MSI Ultrawide MAGCQ341 ( 3440x1440@60Hz ) - Raspberry Pi Forums
					






					forums.raspberrypi.com
				



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.


----------



## cmoerz (Dec 11, 2021)

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...


----------



## cmoerz (Dec 11, 2021)

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?


----------

