Hey folks,
I was able to test flashing the raw image directly onto my internal drive. I had to reset the BIOS and then re-enable Linux support and disable UEFI secure boot again. Now the boot entry for Fedora shows up for the internal drive. However, it just boots into the GRUB recovery shell. Here are the latest commands I am using to setup the raw image:
```
```
Dennis, thank you so much for helping to test out Fedora as well as your follow-up to help fix the battery status. I downloaded the Rawhide build available as soon as your email came in: Fedora-Workstation-Live-osb-Rawhide-20231216.n.0.aarch64.iso . I tested on both of my USB-C ports with a NVMe (native USB-C) and SATA (with a USB-A to USB-C adapter) external drive and used Fedora Writer to flash the ISO. I modified the boot arguments to include "arm64.nopauth
clk_ignore_unused pd_ignore_unused modprobe.blacklist=qcom_q6v5_pas" and removed the "quiet" flags (there appear to be two in the Rawhide builds for some reason). I see the boot messages below and then it switches to a blank screen for a few seconds before the laptop reboots:"""
Booting a command list
EFI stub: Decompressing Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services...
_
"""
At least with the raw image flashed to an external drive using my steps above, I see more kernel/boot information after this part and it does not reboot. Using the ISO, it just instantly goes blank and then reboots shortly after that.
I would be inclined to say that maybe the latest BIOS broke something or that my newer X13s could be a slight hardware variant. However, I am able to boot, install, and use Armbian with no problems at all. I cross-referenced their kernel modules and configurations (along with various other sources) to come up with my "ultimate" configuration from my first e-mail thread.
I am at a complete loss. Fedora seems to work on the X13s for everyone except me.
Sincerely,
Luke Short
On Sun, Dec 17, 2023 at 3:47 PM Dennis Gilmore <dennis@xxxxxxxx> wrote:
to get pd-mapper to work you need to remove
/etc/modprobe.d/anaconda-denylist.conf and regenerate the initrd. you
can modprobe qcom_q6v5_pas and then start pd-mapper to get battery
reporting working without a reboot
On Sat, Dec 16, 2023 at 4:17 PM Dennis Gilmore <dennis@xxxxxxxx> wrote:
>
> Hi Luke,
>
> Using today's rawhide Workstation Live iso image I was able to boot
> and install to the NVMe drive. I added to the bootargs "arm64.nopauth
> clk_ignore_unused pd_ignore_unused modprobe.blacklist=qcom_q6v5_pas"
> post install I also had to add "arm64.nopauth clk_ignore_unused
> pd_ignore_unused" and fix up grub after logging in t make it
> permanent. there seems to be a bug in anaconda not carrying over boot
> arguments to the installed system. With that I was able to boot and
> log in. there is extra steps to get the touchscreen, 5g modem and
> bluetooth working. additionally pd-mapper needs to be installed and
> running for power management and a some other things to work
> correctly, right now it looks like something has changed in 6.7 kernel
> from 6.6 that is stopping pd-mapper from running.
>
> Dennis
>
>
> On Wed, Dec 13, 2023 at 3:46 PM Luke Short <ekultails@xxxxxxxxx> wrote:
> >
> > Hey folks,
> >
> > Germano - thank you so much for putting that wiki together. It has been really helpful and insightful. It sucks to hear that the laptop does not support virtualization. I would definitely use it if it was possible. Even with just troubleshooting my black screen issue, I have noticed the battery dying very quickly. Hopefully that can at least be addressed one day. Kind of defeats the purpose of an Arm laptop, right?
> >
> > Dennis - thank you for the suggestions! I have not recently run into issues with USB itself. A few tests I did last week resulted in the root file system UUID not being found and another test led to the USB drive powering off (the RGB lights would flicker for a second and then turn off). Thankfully, that is not something I am seeing with my latest configuration settings. For whatever it is worth, I am currently using an external NVMe drive connected via USB-C. I have tried swapping out the internal drive that has Windows installed for another NVMe drive but the BIOS seems to cache the old boot entries and does not detect the new internal drive. It is unbootable.
> >
> > I have taken your suggestions and that all seems to simplify my configuration. However, I still encounter a black screen.
> >
> > New steps taken so far:
> > * Only testing with Fedora 39 Workstation (GNOME desktop environment) for consistency in tests.
> > * Using only "arm64.nopauth clk_ignore_unused pd_ignore_unused rd.driver.blacklist=msm" for boot arguments.
> > * Removed the firmware file that was known to cause USB boot issues.
> > * Appended the "modprobe.blacklist=qcom_q6v5_pas" boot argument.
> > * Built the initramfs with only the "qtr" kernel module: `add_drivers+=" qrtr "`
> > * Updated Fedora 39 to the latest stable. This bumped the Linux kernel from 6.5.6 to 6.5.4 and the qcom-firmware up to 20231111-1.fc39.
> > * In Windows 11, using Windows Updates and the Lenovo control panel, I installed all available BIOS and hardware updates (it has been a few months since I last updated).
> > * Using only "arm64.nopauth clk_ignore_unused pd_ignore_unused rd.blacklist=msm modprobe.blacklist=msm initcall_blacklist=regulator_init_complete" for boot arguments.
> > * This was suggested in the wiki to deal with a blank screen during boot.
> > * The workaround resulted in the root file system not being found. Dracut showed a bunch of errors related to that after about a minute.
> >
> > These are the logs shown on my screen before it goes black (it takes 10-15 seconds to go black and then it stays black). Even appending the "iommu.passthrough=0 iommu.strict=0" boot arguments still leads to the two IOMMU errors.
> >
> > ```
> > [ OK ] Started plymouth-start.service - Show Plymouth Boot Screen.
> > [ OK ] Started systemd-ask-password-plymouth.service - Forward Password Requests to Plymouth Directory Watch.
> > [ OK ] Reached target paths.target - Path Units.
> > [ OK ] Reached target basic.target - Basic System.
> > [ 12.<TIME_STAMP>] geni_se_qup 8c0000.geniqup: deferred probe timeout, ignoring dependency
> > [ 12.<TIME_STAMP>] geni_se_qup 9c0000.geniqup: deferred probe timeout, ignoring dependency
> > [ 12.<TIME_STAMP>] geni_se_qup ac0000.geniqup: deferred probe timeout, ignoring dependency
> > [ 12.<TIME_STAMP>] arm-smmu: 3da000.iommu: deferred probe pending
> > [ 12.<TIME_STAMP>] arm-smmu: probe of 3da000.iommu failed with error -110
> > [ 12.<TIME_STAMP>] platform 15000000.iomu: deferred probe pending
> > [ 12.<TIME_STAMP>] platform 33c0000.pinctrl: deferred probe pending
> > [ 12.<TIME_STAMP>] platform firmware:scm: deferred probe pending
> > [ 12.<TIME_STAMP>] platform 1c00000.pcie: deferred probe pending
> > [ 12.<TIME_STAMP>] platform regulator-edp-bl: deferred probe pending
> > [ 12.<TIME_STAMP>] platform 1c10000.pcie: deferred probe pending
> > [ 12.<TIME_STAMP>] platform regulator-misc-3p3: deferred probe pending
> > [ 12.<TIME_STAMP>] platform regulator-wlan: deferred probe pending
> > [ 12.<TIME_STAMP>] platform 1c20000: deferred probe pending
> > [ 12.<TIME_STAMP>] platform regulator-wwan: deferred probe pending
> > [ 12.<TIME_STAMP>] platform 988000.serial: deferred probe pending
> > [ 12.<TIME_STAMP>] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to 1b3000000.remoteproc
> > [ 12.<TIME_STAMP>] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to af000000.clock-controller
> > [ 12.<TIME_STAMP>] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to aec5a00.phy
> > [ 12.<TIME_STAMP>] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to ae000000.display-subsystem
> > [ 12.<TIME_STAMP>] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to 30000000.remoteproc
> > [ 12.<TIME_STAMP>] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to 3d900000.clock-controller
> > [ 12.<TIME_STAMP>] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to 894000.i2c
> > [ 12.<TIME_STAMP>] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to 988000.serial
> > [ 12.<TIME_STAMP>] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to 990000.i2c
> > ```
> >
> > Anything else I should try or log files I can look at? I appreciate your time!
> >
> > Sincerely,
> > Luke Short
> >
> > On Wed, Dec 13, 2023 at 8:40 AM Dennis Gilmore <dennis@xxxxxxxx> wrote:
> >>
> >> On Tue, Dec 12, 2023 at 10:01 PM Luke Short <ekultails@xxxxxxxxx> wrote:
> >> >
> >> > Hey folks,
> >> >
> >> > I recently purchased the X13s Qualcomm Arm laptop. I am very excited to try Linux on it! I'd like to use Fedora to align with what I use for work. The [Fedora Wiki](https://fedoraproject.org/wiki/Thinkpad_X13s) page appears to be out-of-date for this laptop and I would be happy to help update it once I get it working on my end.
> >> >
> >> > From what I've read online, Linux support for it is good these days with many users reporting success with Arch Linux, Debian (Armbian, specifically), Ubuntu, and even Fedora running on it. However, I am having issues with Fedora and always end up with a black screen once the GPU gets loaded. I have tested with Fedora 39 (fully updated with the latest firmware and Linux 6.6) and Rawhide/40 (Linux 6.7.0-rc4 currently). Both GNOME (Workstation) and Xfce (Spin) desktop builds have been tested (I can never actually get that far to see them, though).
> >> >
> >> > From my research, these are all of the steps required to get the laptop to even boot (kernel modules are missing from the initramfs and additional boot arguments are needed).
> >> >
> >> > ```
> >> > $ export DEVICE=sda
> >> > $ sudo -E mount -t btrfs -o subvol=root /dev/${DEVICE}3 /mnt
> >> > $ sudo -E mount -t btrfs -o subvol=home /dev/${DEVICE}3 /mnt/home
> >> > $ sudo -E mount -t ext4 /dev/${DEVICE}2 /mnt/boot
> >> > $ sudo -E mount -t vfat /dev/${DEVICE}1 /mnt/boot/efi
> >> > $ sudo mount -t proc none /mnt/proc
> >> > $ sudo mount --rbind /dev /mnt/dev
> >> > $ sudo mount --rbind /sys /mnt/sys
> >> > $ sudo mkdir -p /mnt/run/systemd/resolve/
> >> > $ echo "nameserver 8.8.8.8" | sudo tee /mnt/run/systemd/resolve/stub-resolv.conf
> >> > $ sudo nano /mnt/etc/dracut.conf.d/20_thinkpad-x13s.conf
> >> > force_drivers+=" nvme phy_qcom_qmp_pcie i2c_hid_of i2c_qcom_geni leds_qcom_lpg pwm_bl qrtr pmic_glink_altmode gpio_sbu_mux phy_qcom_qmp_combo panel-edp msm phy_qcom_edp i2c_hid_of i2c_qcom_geni qcom_q6v5_pas usb_storage uas "
> >> > $ sudo chroot /mnt dracut --regenerate-all --force
> >> > $ sudo nano /mnt/etc/default/grub
> >> > GRUB_CMDLINE_LINUX="efi=noruntime clk_ignore_unused pd_ignore_unused arm64.nopauth iommu.passthrough=0 iommu.strict=0 pcie_aspm.policy=powersupersave console=tty1 splash plymouth.ignore-serial-consoles loglevel=3"
> >>
> >> I am using " clk_ignore_unused pd_ignore_unused arm64.nopauth" as the
> >> bootargs. I had to add rd.driver.blacklist=msm for 6.5 kernels. I also
> >> only made sure that qrtr ended up in the initramfs by using add_driver
> >> in a config. If booting from usb you have to make sure to follwo waht
> >> is documented in
> >> https://fedoraproject.org/wiki/Thinkpad_X13s#Rawhide_hacking. I have
> >> only tried booting with the firmware removed.
> >>
> >> Dennis
> >>
> >> > GRUB_DEFAULT_DTB="dtb/qcom/sc8280xp-lenovo-thinkpad-x13s.dtb"
> >> > $ sudo chroot /mnt grub2-mkconfig -o /boot/grub2/grub.cfg
> >> > $ sudo sync
> >> > ```
> >> >
> >> > Vanilla/upstream Fedora Arm raw image builds do not even boot without these tweaks. With these tweaks, I can boot to the GRUB menu and eventually see the Plymouth boot screen which shows the Fedora logo and then a loading spinner. When it switches to a graphical environment, the screen flashes and goes blank. I also seem to be unable to switch to a TTY console which could be due to the F keys not working properly.
> >> >
> >> > There is a kernel thread [here](https://lore.kernel.org/all/ZUidVUomjf8GMzrG@xxxxxxxxxxxxxxxxxxxx/T/) that explains how to get the stable Fedora 39 working. I did all of the steps but the same thing happened: the screen ends up being black once the system is fully booted up. I have tested using USB and the internal drive. The USB, despite historically being unreliable, has been more reliable in my testing. I believe those issues with low power voltage for USB devices have been fixed.
> >> >
> >> > Does anyone have any advice on how to get graphics working so I can get to the desktop environment? I feel so close to a solution but I seem to be missing a piece of the puzzle here. Thank you for any insight you may have!
> >> >
> >> > Research references:
> >> > - [Thinkpad X13s - Fedora Project Wiki](https://fedoraproject.org/wiki/Thinkpad_X13s)
> >> > - [ThinkPad X13s - Gentoo wiki](https://wiki.gentoo.org/wiki/ThinkPad_X13s)
> >> > - [External display on the x13s?](https://lore.kernel.org/all/ZUidVUomjf8GMzrG@xxxxxxxxxxxxxxxxxxxx/T/)
> >> > - [HCL:ThinkpadX13s - openSUSE Wiki](https://en.opensuse.org/HCL:ThinkpadX13s)
> >> >
> >> > Sincerely,
> >> > Luke Short
> >> > --
> >> > _______________________________________________
> >> > arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx
> >> > To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx
> >> > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> > List Archives: https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx
> >> > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
> >> --
> >> _______________________________________________
> >> arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx
> >> To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx
> >> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives: https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx
> >> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
