robclark changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Chrome OS Trogdor Devices - Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630 - Lenovo ThinkPad X13s - and various other snapdragon laptops) - https://oftc.irclog.whitequark.org/aarch64-laptops
AlexMarty[m] has joined #aarch64-laptops
<Dantheman825[m]>
okay, now it's just stuck on rtkit-daemon.service
<steev>
Or is that tangential to the Microsoft stuff
<travmurav[m]>
steev: seems like this targets UEFI, and our problem is "a level above"
<travmurav[m]>
as in, the uefi runs in EL1 and afaiu this issue is in the uefi image itself, so I guess it's just loading malicious uefi code. one would still need to do the magic handshake with qhee/mssecapp to get el2
enick_663 is now known as qzed
<travmurav[m]>
to reword - we already disable uefi secure boot in most cases to even boot our grub/etc so one could just replace our grub with some nasty thing and patch uefi from there
<travmurav[m]>
funnily, I think this also means that windows is "more safe" on arm devices that use secure-launch since it doesn't need to rely on the uefi root of trust, and instead uses the vendor-locked one
<travmurav[m]>
at least for the secure-launch path
<travmurav[m]>
and I guess it still doesn't help if the efi runtime services were corrupted, idk how much privileges windows gives when calling into them
martiert has quit [Quit: WeeChat 4.1.1]
abelvesa has quit []
abelvesa has joined #aarch64-laptops
abelvesa has quit []
abelvesa has joined #aarch64-laptops
abelvesa has quit []
abelvesa has joined #aarch64-laptops
abelvesa has quit []
abelvesa has joined #aarch64-laptops
abelvesa has quit []
abelvesa has joined #aarch64-laptops
abelvesa has quit []
abelvesa has joined #aarch64-laptops
abelvesa has quit []
abelvesa has joined #aarch64-laptops
abelvesa is now known as Guest9258
Guest9258 has quit []
abelvesa has joined #aarch64-laptops
abelvesa has quit []
abelvesa has joined #aarch64-laptops
sporos11[m] has joined #aarch64-laptops
<Jasper[m]>
<travmurav[m]> "as in, the uefi runs in EL1..." <- Had time to look at the certs thing yet?
nscnt[m] has joined #aarch64-laptops
ema_ has quit []
ema has joined #aarch64-laptops
martiert has joined #aarch64-laptops
xnox1 has quit []
xnox has joined #aarch64-laptops
<travmurav[m]>
Jasper: I occasionally take looks at this mess but don't have any news for now
<ajhalaney[m]>
Jasper: lemme know if you have any luck, I was playing around with trying to boot the fedora raw image off a USB stick last night with no success so far despite all the usual suspects (clk_ignore_unused, pd_ignore_unused, arm64.nopauth, make sure something loads a dtb, etc). Hard to tell what's going on during boot with the laptop, makes me appreciate a proper serial so much more.
<steev>
ajhalaney[m]: just solder on a serial port like calebccff did with his c630 /s
<ajhalaney[m]>
:D
<calebccff>
this is the only right way to do aarch64 bringup
<Jasper[m]>
calebccff: Is this one of those without secure boot?
<Jasper[m]>
The qualcomm one
<calebccff>
Jasper[m]: yeah, the bootloader is a total mess. You can't access any boot device selection screen, but pressing F5 will attempt to boot from USB. If you poke around in EFI shell you'll find that there is a boot device menu app you can run, they just never hooked it up
<steev>
oh that's fancy
<calebccff>
it's sc7180 WoA, with UFS (no clue where/how to figure out what the DT should look like for that)
<calebccff>
it also has the Qualcomm BDS menu left in
<calebccff>
you can enable PXE booting, somehow, maybe it supports some USB ethernet thing
<calebccff>
it also has the mass storage mode settings but it crashes if you try and enable it :(
* calebccff
would very much like to run U-Boot on it
<Jasper[m]>
Where'd you get it from?
<steev>
dang it
<steev>
the dock i got for mac doesn't work with the thinkpad :( the usb ports are slightly too close together
<steev>
i could probably do something silly like use usb-c cables
rz_ has joined #aarch64-laptops
rz has quit [Ping timeout: 480 seconds]
<_[m]1>
the side dock like htat?
<_[m]1>
<ajhalaney[m]> "Jasper: lemme know if you have..." <- for debian, somehow just creating a efi partition and putting the .dtb in there makes the installer boot 🤷
<_[m]1>
I was lazy so fde on lvm 1 partition and it kept that /EFI
<_[m]1>
fckng magic this stuff
<zdykstra>
if you want to do direct EFI booting, e.g. make a UKI bundle and add an EFI entry pointing to it, what's the right way to load the relevant DTB on boot?
<ajhalaney[m]>
fancy work you did there calebccff
<ajhalaney[m]>
zdykstra: my (untested) understanding is that if you update the firmware and turn the "Linux Boot" option on it will try and install sc8280xp-lenovo-thinkpad-x13s.dtb from the ESP into the UEFI tables... which then the efi stub should pull out and run along ok. I have just been using grub's devicetree stuff or telling the stub to pull it with the kernel command line "dtb=" option up till now
<zdykstra>
how lock-step does that file have to be to the kernel version? Exactly, I assume?
<ajhalaney[m]>
with all the work done upstream the idea is that if you adhere to dt-bindings upstream, your devicetree should continue to work (i.e. they make sure that old bindings are still supported in drivers). Now in practice... dunno how well that can be said, I always tie the two together and dump a new one for each kernel :)
<zdykstra>
Good to know - thank you
<zdykstra>
My goal is to get Void and ZFSBootMenu working on the x13s, but I'm very new to Arm systems
<zdykstra>
we'll see how well the hardware works with kexec - that can be a real pain point on x86_64