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 <den...@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 <ekulta...@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 <den...@ausil.us> wrote: > >> > >> On Tue, Dec 12, 2023 at 10:01 PM Luke Short <ekulta...@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/zuidvuomjf8gm...@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/zuidvuomjf8gm...@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-le...@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-le...@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-le...@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
