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" 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@hovoldconsulting.com/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@hovoldconsulting.com/T/) - [HCL:ThinkpadX13s - openSUSE Wiki](https://en.opensuse.org/HCL:ThinkpadX13s)
Sincerely, Luke Short
Il 13/12/23 05:01, Luke Short ha scritto:
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.
Hello I am the author of the page. It is obsolete because I ended up selling the X13s, because I was tired of the uncertainty that was surrounding the virtualization support development, the power management etc.
A short timeline of my disingagement (note the years that passes) https://twitter.com/search?q=x13s%20from%3AGermanoMassullo&src=typed_que...
On Tue, Dec 12, 2023 at 10:01 PM Luke Short ekultails@gmail.com 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@hovoldconsulting.com/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@hovoldconsulting.com/T/) - [HCL:ThinkpadX13s - openSUSE Wiki](https://en.opensuse.org/HCL:ThinkpadX13s) Sincerely, Luke Short -- _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
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@ausil.us wrote:
On Tue, Dec 12, 2023 at 10:01 PM Luke Short ekultails@gmail.com 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 withoutthese 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@hovoldconsulting.com/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@hovoldconsulting.com/T/)
- [HCL:ThinkpadX13s - openSUSE Wiki](
https://en.opensuse.org/HCL:ThinkpadX13s)
Sincerely, Luke Short -- _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
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@gmail.com 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.i2cAnything 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@ausil.us wrote:
On Tue, Dec 12, 2023 at 10:01 PM Luke Short ekultails@gmail.com 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@hovoldconsulting.com/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@hovoldconsulting.com/T/) - [HCL:ThinkpadX13s - openSUSE Wiki](https://en.opensuse.org/HCL:ThinkpadX13s) Sincerely, Luke Short -- _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue-- _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
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@ausil.us 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@gmail.com 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.i2cAnything 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@ausil.us wrote:
On Tue, Dec 12, 2023 at 10:01 PM Luke Short ekultails@gmail.com 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@hovoldconsulting.com/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@hovoldconsulting.com/T/) - [HCL:ThinkpadX13s - openSUSE Wiki](https://en.opensuse.org/HCL:ThinkpadX13s) Sincerely, Luke Short -- _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue-- _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
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:
```
$ 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 mv /mnt/lib/firmware/qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn.xz /root/ $ sudo nano /mnt/etc/dracut.conf.d/20_thinkpad-x13s.conf add_drivers+=" qrtr " $ sudo chroot /mnt dracut --regenerate-all --force $ sudo nano /mnt/etc/default/grub GRUB_CMDLINE_LINUX="arm64.nopauth clk_ignore_unused pd_ignore_unused rd.driver.blacklist=msm" GRUB_DEFAULT_DTB="dtb/qcom/sc8280xp-lenovo-thinkpad-x13s.dtb" $ sudo chroot /mnt grub2-mkconfig -o /boot/grub2/grub.cfg $ sudo sync
```
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@ausil.us 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@ausil.us 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@gmail.com 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 screenduring 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 - ForwardPassword 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 appreciateyour time!
Sincerely, Luke Short
On Wed, Dec 13, 2023 at 8:40 AM Dennis Gilmore dennis@ausil.us
wrote:
On Tue, Dec 12, 2023 at 10:01 PM Luke Short ekultails@gmail.com
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 bootwithout 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@hovoldconsulting.com/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@hovoldconsulting.com/T/)
- [HCL:ThinkpadX13s - openSUSE Wiki](
https://en.opensuse.org/HCL:ThinkpadX13s)
Sincerely, Luke Short -- _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
Do not reply to spam, report it:
It kind of sounds like you have not enabled linux booting in UEFI and put the dtb into the root of the ESP partition on the NVMe drive. when booting the liveiso adding "devicetree /dtb/qcom/sc8280xp-lenovo-thinkpad-x13s.dtb" on its own line with the kernel and initrd should let things get up then you can make sure that the dtb is copied into the right place. you do need to tell UEFI that you are booting linux.
Dennis
On Mon, Dec 18, 2023 at 12:16 AM Luke Short ekultails@gmail.com wrote:
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:
$ 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 mv /mnt/lib/firmware/qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn.xz /root/ $ sudo nano /mnt/etc/dracut.conf.d/20_thinkpad-x13s.conf add_drivers+=" qrtr " $ sudo chroot /mnt dracut --regenerate-all --force $ sudo nano /mnt/etc/default/grub GRUB_CMDLINE_LINUX="arm64.nopauth clk_ignore_unused pd_ignore_unused rd.driver.blacklist=msm" GRUB_DEFAULT_DTB="dtb/qcom/sc8280xp-lenovo-thinkpad-x13s.dtb" $ sudo chroot /mnt grub2-mkconfig -o /boot/grub2/grub.cfg $ sudo syncDennis, 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@ausil.us 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@ausil.us 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@gmail.com 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.i2cAnything 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@ausil.us wrote:
On Tue, Dec 12, 2023 at 10:01 PM Luke Short ekultails@gmail.com 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@hovoldconsulting.com/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@hovoldconsulting.com/T/) - [HCL:ThinkpadX13s - openSUSE Wiki](https://en.opensuse.org/HCL:ThinkpadX13s) Sincerely, Luke Short -- _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue-- _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Il 13/12/23 22:46, Luke Short ha scritto:
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?
That's a long story and one of the main reasons why I sold the X13s. But the most import one is that most of people involved in the effort of developing Linux support are not responsive or under NDA, so a X13s could not do much to contribute as a tester.
I also can't help but notice that Fedora for Apple Silicon has just been released https://fedoramagazine.org/introducing-fedora-asahi-remix-39/ so we have an Apple ARM machine with a better support than a Thinkpad Qualcomm ARM based one....
Hey folks,
I wanted to give a final update on this.
Following Dennis's suggestion to put the DTB on the EFI partition of the internal NVMe drive fixed issue number 1 for me. Issue number 2 was that my Intel Optane NVMe drive in my external USB-C enclosure was not working with Fedora on the X13s (but it works on x86 computers I have). I swapped it out for a Silicon Power NVMe drive and now it works! The GNOME desktop environment loads up with the latest Fedora Workstation 40/Rawhide builds. No more black screen!
I've also been trying out the Fedora Asahi Remix on my MacBook Pro and, yes, I must say it is a much smoother experience than the Lenovo Thinkpad X13s so far. I thought the lack of the latest OpenGL and no Vulkan would be a deal breaker but most apps work great.
Sincerely, Luke Short
On Tue, Dec 19, 2023 at 8:21 AM Germano Massullo germano.massullo@gmail.com wrote:
I also can't help but notice that Fedora for Apple Silicon has just been released https://fedoramagazine.org/introducing-fedora-asahi-remix-39/ so we have an Apple ARM machine with a better support than a Thinkpad Qualcomm ARM based one.... -- _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-
Dennis Gilmore -
Germano Massullo -
Luke Short