Opened 15 months ago
Last modified 3 months ago
#18561 new bug
Haiku fails to boot on steam deck
| Reported by: | nephele | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | R1/beta6 |
| Component: | System/Boot Loader/EFI | Version: | R1/Development |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
The screen just stays blank on attempting to boot Haiku, on a hunch from tqh I'd commented out serial_enable and serial_init in serial.cpp of the efi loader, but the result stayed the same.
This was tested with hrev57221
Attachments (2)
Change History (14)
comment:1 by , 15 months ago
comment:2 by , 15 months ago
Can boot from USB with rEFInd then haiku_loader.efi . After trying different options (safe mode, vesa), it's still hanging on graphics boot screen...
by , 15 months ago
| Attachment: | Capture d'écran 2023-08-21 003441.png added |
|---|
Haiku fails to load on Steam deck after Haiku boot menu
comment:3 by , 4 months ago
Tried hrev57877 on Steam Deck LCD with firmware F7A0131, using USB drive connected to USB C hub as a boot device. Haiku loader works for me if I comment out serial_init and serial_enable calls, otherwise it's stuck on black screen. This also seems to be a regression since Haiku loader from beta4 image works without any workarounds. Haiku still won't boot though (neither the beta4 nor hrev57877), it's just stuck on gray icons without any syslog output. By default it will boot to garbled boot splash like here, but setting video mode to 800x1280 fixes the boot splash
comment:4 by , 4 months ago
beta4 will have disabled syslog serial out by default so that may be the difference there. It seems odd that those calls cause it to get stuck, though.
Stuck on gray icons probably means a bootloader to kernel transition problem. Did you try disabling SMP?
comment:5 by , 4 months ago
Yes I tried the safe mode options already. After disabling more serial_ calls (here and here), I did some printf/machine shutdown call debugging and found that it gets to the kernel start routine and that changing this line to false fixes the kernel freeze on the following dprint. After disabling sdhci and radeon_hd accelerant it can boot to desktop.
comment:6 by , 4 months ago
I guess the Steam Deck just does not even have the standard x86 serial out port internally, or it's somehow disabled so we just stall on it.
comment:7 by , 4 months ago
Ultimately release builds should not be using serial out by default, so I would have expected beta4 to work here. If it doesn't, that's a bug we need to fix.
comment:8 by , 4 months ago
For reference, here's the change that disables serial out by default. Is this not sufficient to prevent stalls? (Is there some way to detect a lack of the default serial line that we are missing?)
comment:9 by , 4 months ago
Seems like it's not enough. Loader still would stall on another serial_enable() line in arch_start.cpp (commenting out serial_init or serial_disable is not needed in the end). Also the workaround in kernel is still needed.
comment:10 by , 4 months ago
| Milestone: | Unscheduled → R1/beta5 |
|---|
OK, it looks like that last call should be disabled on release builds then, and possibly all of serial_enable in the bootloader.
comment:11 by , 4 months ago
It appears FreeBSD just has limits for how long they will loop in the output routines before giving up. I guess we should do likewise.
comment:12 by , 3 months ago
| Milestone: | R1/beta5 → R1/beta6 |
|---|
The calls are disabled in the beta5 branch. Larger refactors to handle serial lines not working properly can be done later.
On a bit more investigation: the boot loader does load if i put it on the esp of the nvme, but not on the thumb stick. If loaded it however cannot see the disk anymore.
I'll try this again with a usb-c flash drive to see if that improves matters over the usb-c to usb-a cable i've been using.