FS#73231 - [linux] Installer doesn't detect the internal eMMC drive
Attached to Project:
Arch Linux
Opened by trapanator (trapanator) - Sunday, 02 January 2022, 15:16 GMT
Last edited by Toolybird (Toolybird) - Monday, 09 October 2023, 20:31 GMT
Opened by trapanator (trapanator) - Sunday, 02 January 2022, 15:16 GMT
Last edited by Toolybird (Toolybird) - Monday, 09 October 2023, 20:31 GMT
|
Details
Description:
I have a baytrail device (Minix Z64). I can boot it with Archlinux installer (adding `acpi=off` on the grub menu to be able to boot it). But when I am in the shell, I cannot see the internal eMMC drive. I tried to load these kernel modules (with modprobe): * mmc_block * sdhci * sdhci_acpi Still I cannot see the internal eMMC. Maybe I forgot other module? Additional info: * Installer, december version |
This task depends upon
I think that there's something missing...
dmesg.txt (47.4 KiB)
https://github.com/rhboot/efivar/commit/f0d3ed17ef3b2bbdfdff4dde12ec0a82d1ccdd33
ACPI is used to discover and configure hardware components. I would not be surprised if setting acpi=off is the reason for your issue. Is there some other option you could try to get the system to boot?
Are there another alternatives?
https://wiki.ubuntu.com/DebuggingACPI#Debugging_procedure
If "acpi=off" allows the system to boot, try to isolate the ACPI issue with the following boot parameters
Try booting with "acpi=ht"
This disables all of ACPI except just enough to enable Hyper Threading. If acpi=off works and acpi=ht fails, then the issue is in the ACPI table parsing code itself, or perhaps the SMP code.
Try booting with "pci=noacpi"
This disables ACPI for IRQ routing and PCI scanning.
Try booting with "acpi=noirq"
This disables ACPI for IRQ routing.
Try booting with "pnpacpi=off"
This disables the ACPI component of the Linux Plug and Play code.
Try booting with "noapic"
Disables the IO-APIC for IRQ routing or PCI scanning.
Try booting with "nolapic"
Disables the local APIC.
But lsblk doesn't show the eMMC device;
But (again) lsmod now lists "mmc_block", "sdhci" and "sdhci_acpi" (before it didn't with acpi=off!)
And now? I should wait for the patch?
I am currently evaluating what can be done here, as there has not been a release for efivar since 2018 and upstream does not respond (https://github.com/rhboot/efivar/issues/137). Backporting seems a bit risky as there are three years of commits and the commit in question does not apply cleanly. Another (also potentlially risky) option would be to bump to some commit in the list of recent commits.
My assumption is, that other downstream distributions use some specific commit or heavily patch the sources to make this work.
Tried with OpenSuse Leap 15.3, it can install on it.
lsmod-opensuse.log (6.1 KiB)
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk1 179:0 0 29,1G 0 disk
├─mmcblk1p1 179:1 0 512M 0 part /boot/efi
├─mmcblk1p2 179:2 0 26,6G 0 part /
└─mmcblk1p3 179:3 0 2G 0 part [SWAP]
mmcblk1boot0 179:8 0 4M 1 disk
mmcblk1boot1 179:16 0 4M 1 disk
lsmod-archlinux.log (5.5 KiB)
root@archiso ~ # lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 657.4M 1 loop /run/archiso/airootfs
sda 8:0 1 14.4G 0 disk
├─sda1 8:1 1 735M 0 part /run/archiso/bootmnt
└─sda2 8:2 1 77M 0 part
Can you see whether loading that module helps?
Could you provide some more details on the controller (e.g. lspci?).
Hm, it's a bit hard to compare the opensuse kernel (5.3.x) to the one used in archiso (5.16.4).
There can be many reasons for why they behave differently (e.g. buggy driver).
If you want, I can try with a recent linux distro. Fedora 35 is ok?
lspci-vvv-archlinux.log (5.2 KiB)
Linux version 5.17.0-0.rc0.20220112gitdaadb3bd0e8d.63.fc36.x86_64 (mockbuild@bkernel01.iad2.fedoraproject.org) (gcc (GCC) 11.2.1 20211203 (Red Hat 11.2.1-7), GNU ld version 2.37-22.fc36) #1 SMP PREEMPT Wed Jan 12 18:54:57 UTC 2022
I'm attaching all logs.
The live of Fedora Rawhide sees the eMMC drive, as you can see in the lsblk-fedora-rawhide.log
lsblk-fedora-rawhide.log (0.6 KiB)
lsmod-fedroa-rawhide.log (3.9 KiB)
lspci-fedora-rawhide.log (0.7 KiB)
lspci-vvv-fedora-rawhide.log (5.3 KiB)
> WARNING: CPU: 0 PID: 132 at include/linux/msi.h:262 __pci_enable_msi_range+0x422/0x570
If you are feeling brave you could try the Fedora kernel with Arch Linux (and rebuild the initramfs), that would rule out user spaces issues.
Could you try booting Fedora with `nolapic`? Maybe that is causing the breakage.
The problem with Archlinux iso is that during boot the screen is black and I cannot see anything, furthermore it reboots at any point during booting...
it uses grub as bootloader.
https://drive.google.com/file/d/1OUh8xe9rMDaVae7kn3hcSNO7RU-L-LYc/view?usp=sharing
blank screen then it reboots.
No problem at all, it installs on eMMC correctly.
Is there any way to *disable* framebuffer, KMS, whatever graphic mode after grub boot screen?
on the other distributions as start would help.
On slackware 15 I'm attaching the config.gz. These are rows with "grep BAY":
CONFIG_BAYCOM_SER_FDX=m
CONFIG_BAYCOM_SER_HDX=m
CONFIG_BAYCOM_PAR=m
CONFIG_I2C_DESIGNWARE_BAYTRAIL=y
CONFIG_PINCTRL_BAYTRAIL=y
CONFIG_SND_SOC_SOF_BAYTRAIL=m
zcat /proc/config.gz > config.txt
module_blacklist=pinctrl-cherryview,pinctrl-lynxpoint,pinctrl-alderlake,pinctrl-broxton,pinctrl-cannonlake,pinctrl-cedarfork,pinctrl-denverton,pinctrl-elkhartlake,pinctrl-emmitsburg,pinctrl-geminilake,pinctrl-icelake,pinctrl-jasperlake,pinctrl-lakefield,pinctrl-lewisburg,pinctrl-sunrisepoint,pinctrl-tigerlake
Then only the basic pinctrl-intel.ko is used.