No keyboard available at bootloader

[roiredxsoto]

Scenario:

• USB stick with Haiku hrev54886 ISO burned with Etcher, plugged to USB 3.0 port
• Computer: Ryzen 5 1600, Radeon RX560, chipset B450, no hard drives, BIOS in full UEFI mode, BIOS USB set to back compatibility
• Keyboard (XBows mechanical)-Mouse plugged to USB KM switch plugged to an USB 3.0 port on the Mobo.
• PC boots with the USB stick but fails to enter desktop because I forgot about the need of "fail-safe graphics".

Issue:

As this pc is set as full UEFI, in order to blacklist the graphics driver I have to press SPACEBAR (not SHIFT key) to trigger the bootloader menu and mark the Safe Graphics mode. This is impossible to get done. Bootloader does not respond to keyboard input.

I said SPACEBAR and SHIFT because I forgot that it was set to full UEFI, so I did use both.

I tried the process:

• with the default setup as stated in the Scenario part
• with the keyboard plugged into one of the USB 2.0 ports
• with a plain microsoft keyboard plugged to the switch
• with the plain microsoft keyboard plugged to the USB 2.0 port

In any case Bootloader seems to bypass keypresses thus making it impossible to activate any safe mode resulting in never reaching the desktop.

Circunvent:

In order to get to the desktop I booted the pc with another working Haiku USB stick and modified the

/boot/home/config/settings/kernel/drivers/kernel

file blacklisting there the graphics driver in order to get hrev54886 to boot.

With this "trick", the USB stick with the hrev54886 Haiku boots to desktop and allows to install Haiku onto an external USB disk, which I did without issues.

Re-Issue:

(New Scenario) Same as initial Scenario, changing the USB stick with Haiku hrev54886 ISO, with the newly installed USB HD.

The system boots and stops at the bootloader menu where have to select the state to be able to continue with the booting process. Then again, no keyboard input at the bootloader menu.

Mounting the drive on a working Haiku USB stick shows that no syslog is available, the /boot/system/var/log folder only holds the file es1370.log.

Weirdo Ghosting:

This only happened with hrev54886 USB stick that holds a clean new image of Haiku hrev54886 burned with etcher doing what I said before. That same clean image, used as "Install from" in the Haiku installer, used from an old working Haiku USB stick, resulted in a working install on the external USB drive without keyboard issues, with the setup as stated in the initial Scenario.

This is the first time that any Haiku ISO on an USB stick does this on any of the HW I use. I still keep that USB stick with that image, so if you need me to do any test, let me know. Regards, RR

[beaglejoe]

Bootloader does not respond to keyboard input.

I have been experiencing this on an Intel® NUC Kit NUC8i5BEH

It seems to be related to this commit:

​https://git.haiku-os.org/haiku/commit/?id=9adc70887e06e23975eeea6e62b3d8921ef2b1a1

[waddlesplash]

Did you confirm that using an EFI loader from the commit before that does not have the problem, and with that commit the problem occurs?

[beaglejoe]

Yes,
hrev54759 works
hrev54762 does not

I have commented out the code from the commit

[​​https://git.haiku-os.org/haiku/commit/?id=9adc70887e06e23975eeea6e62b3d8921ef2b1a1]

and built with head at 2021 Jan 28 14:30 GMT and it works.

[waddlesplash]

Revert proposed: ​https://review.haiku-os.org/c/haiku/+/3696

[beaglejoe]

Looking a little further into this, I restored the code to head revision.
Verified problem.

In: src\system\boot\platform\efi\console.cpp (approx Line 237)

if (graphics) {
		status = consoleControl->SetMode(consoleControl,
			EfiConsoleControlScreenGraphics);

it looks like the call to set EfiConsoleControlScreenGraphics disables the keyboard ??

I added a call to immediately put it back. ie:

		status = consoleControl->SetMode(consoleControl,
			EfiConsoleControlScreenText);

Which restored keyboard function. This seems odd as the Console already seemed to be in graphics mode with working keyboard. Maybe because it was already in graphics mode ? Is there a GetMode() ??

[kallisti5]

@beaglejoe could you grab a copy of the bootloader logs with the console-control guid enabled? I'd like to at least understand the error cases before we completely revert.

The console-control stuff is non-standard and for older Apple hardware which starts in a graphical framebuffer mode instead of a standard EFI text mode.

It's possible the NUC (and some other devices) present the non-standard hook incorrectly and implement it incorrectly (or at least out-of-alignment with how Apple uses it)

Since the code is there to better support older Intel Apple devices, but is also non-standard... i'll 100% +2 it's removal if we can at least confirm this is what's going on.

[kallisti5]

Here is systemd's EFI loader using it:

​https://github.com/systemd/systemd/blob/main/src/boot/efi/graphics.c

Here's the story behind it: ​https://titanwolf.org/Network/Articles/Article?AID=9a12968d-0e6c-4350-9504-e9dc4c429b0d#gsc.tab=0

Given @beaglejoe's test above, it appears I might be using it wrong and we should just always "set text mode" and leave it alone.

[beaglejoe]

@kallista5 where do I find the bootloader logs?

[waddlesplash]

They should be written to serial out, if you have access to that, or via the debug menu there is a "View bootloader log" option (which may however be inaccessible if you have no keyboard...)

[kallisti5]

@beaglejoe ok lets try this as a fix.

Revert your code, and delete 1 line for me:

diff --git a/src/system/boot/platform/efi/console.cpp b/src/system/boot/platform/efi/console.cpp
index 5747436632..f9cc627d88 100644
--- a/src/system/boot/platform/efi/console.cpp
+++ b/src/system/boot/platform/efi/console.cpp
@@ -249,7 +249,6 @@ console_control(bool graphics)
 status_t
 console_init(void)
 {
-       console_control(true);
        update_screen_size();
        console_hide_cursor();
        console_clear_screen();

[beaglejoe]

@kallista5

Yes that works. In an earlier test, I had changed the removed line to

console_control(false);

That also works.

@waddlesplash
I can view the boot log on screen (when keyboard works) but I am not sure if that is from current boot or last boot. Also, is there any way to save it to file. (no serial port)

[kallisti5]

​https://review.haiku-os.org/c/haiku/+/3685 was submitted to fix issues like these, but also maintain the Apple EFI support.

summary: I shouldn't have been trying to use things that are non-standard beyond doing the "bare minimum"

[pulkomandy]

Merged in hrev54932.

[beaglejoe]

I tried this again with head. No keyboard. I was mistaken in comment 13 about console_control(false)

With that line removed as originally proposed in comment 12 by @kallista5, the keyboard works.

My apologies for the early erroneous report.

[tqh]

Noticed that this also caused keyboard on my machines to not work even with newer change. I thought it was something else, since I have commented out one of the places, but it was called twice.

I think we need to remove this until you first detect that it is an old Mac before applying this quirk.

[waddlesplash]

Fixed for real in hrev54940.