10:01 p.m.
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
7:52 a.m.
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_...
9:40 a.m.
On Tue, Dec 12, 2023 at 10:01 PM Luke Short <ekultails(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to arm-leave(a)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
3:46 p.m.
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(a)ausil.us> wrote:
On Tue, Dec 12, 2023 at 10:01 PM Luke Short
<ekultails(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to arm-leave(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to arm-leave(a)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
4:17 p.m.
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(a)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.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(a)ausil.us> wrote:
>>
>> On Tue, Dec 12, 2023 at 10:01 PM Luke Short <ekultails(a)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(a)lists.fedoraproject.org
>> > To unsubscribe send an email to arm-leave(a)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(a)lists.fedoraproject.org
>> To unsubscribe send an email to arm-leave(a)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
4:47 p.m.
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(a)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(a)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.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(a)ausil.us> wrote:
> >>
> >> On Tue, Dec 12, 2023 at 10:01 PM Luke Short <ekultails(a)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(a)lists.fedoraproject.org
> >> > To unsubscribe send an email to arm-leave(a)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(a)lists.fedoraproject.org
> >> To unsubscribe send an email to arm-leave(a)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
12:16 a.m.
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(a)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(a)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(a)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.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(a)ausil.us>
wrote:
> >>
> >> On Tue, Dec 12, 2023 at 10:01 PM Luke Short <ekultails(a)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(a)lists.fedoraproject.org
> >> > To unsubscribe send an email to arm-leave(a)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(a)lists.fedoraproject.org
> >> To unsubscribe send an email to arm-leave(a)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
12:26 p.m.
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(a)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 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(a)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(a)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(a)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.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(a)ausil.us>
wrote:
>> > >>
>> > >> On Tue, Dec 12, 2023 at 10:01 PM Luke Short
<ekultails(a)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(a)lists.fedoraproject.org
>> > >> > To unsubscribe send an email to
arm-leave(a)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(a)lists.fedoraproject.org
>> > >> To unsubscribe send an email to arm-leave(a)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
8:33 a.m.
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.
9:20 a.m.
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....
1:02 p.m.
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(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to arm-leave(a)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
109
days inactive
171
days old
10 comments
3 participants
participants (3)
-
Dennis Gilmore -
Germano Massullo -
Luke Short