Bug 1180799

Summary: No keyboard input available in installer or during boot on RPi4
Product: [openSUSE] openSUSE Tumbleweed Reporter: Ang <dillon.ang.h>
Component: KernelAssignee: openSUSE Kernel Bugs <kernel-bugs>
Status: RESOLVED DUPLICATE QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: fvogt, nsaenzjulienne, tiwai
Version: Current   
Target Milestone: ---   
Hardware: aarch64   
OS: openSUSE Tumbleweed   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Ang 2021-01-12 03:57:19 UTC
Hello,

After I updated my system from Tumbleweed AArch64 snapshot 20201218 to snapshot 20210108, I noticed that there appears to be a problem with kernel-default-5.10.4-1.1. It may be related to the kernel module for the VL805 chip that handles USB on the Raspberry Pi 4. This issue does not affect the Raspberry Pi 3 which still appear to run normally.

This problem can be seen in a few different ways. When booting the system from the installation DVD, I have keyboard input in GRUB, but as soon as the system starts booting into the installer, my keyboard and mouse goes dead. It will boot all the way to the screen where it asks you to accept the license agreement (including downloading what it needs to update the installer), but you cannot use either the mouse or keyboard. You also are unable to interact with the system during the boot process using the keyboard (to switch from the splash to a verbose mode). Because of this, you cannot actually install Tumbleweed 20210108 on the Raspberry Pi 4 from the USB.

I tested this on a Raspberry Pi 4 4GB that boots entirely from a USB drive (no SD card), I installed 20201218, then I did a zypper dup to 20210108. While you can interact with the system using the keyboard during GRUB, during the boot process, it stalls completely, and the system times out and goes into a recovery prompt (since it can no longer see the USB drive it is booting from). You cannot type anything here since all USB devices appear to be dead.

I also tested this on the same Raspberry Pi 4 4GB with an SD card. I installed 20201218 using the USB drive, then I did a zypper dup to 20210108. This time, it will boot up until the prompt to enter a password to unlock encrypted drives (I use LUKS on my home partition to encrypt it), but you are unable to enter a password to unlock the drive since the system does not respond to the keyboard. You are also unable to interact with the system using the keyboard during the boot process (you can switch between the splash and verbose mode with the keyboard).

The workaround was to boot the system up using kernel-default-5.9.14-1, since it was previously installed when I installed 20201218. When I did this, the system worked as expected both when booted from USB and when booted from an SD card.

I've seen this behavior previously when I ran the Debian AArch64 and Ubuntu AArch64 installer. You can interact with the system during GRUB, but as soon as the installer starts, you lose any ability to use USB devices. It appears also related to the VL805 chip the Raspberry Pi 4 uses since I was able to boot and run through the installation for both of these on the Raspberry Pi 3.
Comment 1 Ang 2021-01-12 04:05:29 UTC
Just want to clarify that I am running the latest stable version of the Raspberry Pi 4 EEPROM 2020-12-11 and the latest stable firmware for the VL805 chip. These were installed using Raspberry Pi OS 64-bit and rpi-eeprom-update.

Also, on the system with the SD card, you cannot switch between the splash and verbose mode with the keyboard during boot since it does not accept USB keyboard inputs.

Let me know what other information I may be able to provide.
Comment 2 Fabian Vogt 2021-01-12 08:47:54 UTC
Related to bug 1180336?
Comment 3 Nicolas Patricio Saenz Julienne 2021-01-14 09:40:18 UTC
Hi Ang, sorry for the inconvenience, and thanks for taking the time to do a write-up of the issue. We're aware of it and it's fixed. USB should work on the next Tumbleweed release (or whenever the relevant kernel version is picked up).

*** This bug has been marked as a duplicate of bug 1180336 ***