ChanServ 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
etehtsea has quit [Read error: Connection reset by peer]
etehtsea has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
etehtsea has quit [Read error: Connection reset by peer]
<Grabunhold_>
i will need some time until I find the time to test it (as I said, I'm on stock fedora, so will need an hour or so to compile a kernel with the patch, configure the bootloader and whatnot), but will certainly do!
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
Lucanis_ has quit [Read error: Connection reset by peer]
<GurneyBuchanan[m]>
The next goal is to get bootable live images (if possible) from Rawhide - does anyone have any knowledge on how to approach that?
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<deathmist>
GurneyBuchanan[m]: since systemd-boot seems to be used one option would be to integrate https://github.com/TravMurav/dtbloader but currently it assumes dtb files to exist in a few specific dirs (see src/main.c) and would also start briefly and do nothing on other EFI devices if it's included in a generic aarch64 iso
<travmurav[m]>
JFYI for distros dtbloader should be compiled with make ABORT_IF_UNSUPPORTED=1 ... so sd-boot ignores the error when dtbloader couldn't detect what device it runs on
<GurneyBuchanan[m]>
That's SLICK! Ok - that seems worth considering - and we have the developer right here to help (great work @tru
<GurneyBuchanan[m]>
s/@tru/travmurav )!/
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
mcbridematt has quit [Ping timeout: 480 seconds]
enyalios_ has quit [Remote host closed the connection]
enyalios has joined #aarch64-laptops
mcbridematt has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
Melody91_ has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
Melody91 has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
<GurneyBuchanan[m]>
I've been attempting to use https://copr.fedorainfracloud.org/coprs/radical1/snapdragon-x-elite/ aka a rebuild of qcom-firmware-extract to extract the firmware but it is firing an error that no Bitlocker volume has been defined - I suspect this is because I am booting off of a USB drive at the moment. If anyone has any advice on how to pass a path to qcom-firmware-extract, let me know!
chrisl has quit [Ping timeout: 480 seconds]
<GurneyBuchanan[m]>
<deathmist> "Gurney Buchanan: since systemd-..." <- Random: but curious - how do x86 systems handle this issue (whereas aarch64 systems do not)?
JesusGod-Pope666-Info has joined #aarch64-laptops
<anthony25>
X86 (beside maybe some exceptions) doesn't use DTS, the hw discovery is done through acpi
<GurneyBuchanan[m]>
<anthony25> "X86 (beside maybe some exception..." <- Oh that's intriguing - and I'm guessing aarch64 either doesn't implement acpi or doesn't have a shim for it yet?
<robclark>
no, linux does not have support for how ACPI works on these laptops (namely, PEP)
<GurneyBuchanan[m]>
* Oh that's intriguing - and I'm guessing aarch64 either doesn't implement acpi or doesn't have a shim for it yet?
<GurneyBuchanan[m]>
Btw thanks for the info - I'm learning (as quickly as I can)!
<GurneyBuchanan[m]>
I'm guessing this is a case where Qualcomm really should be the ones publishing support for the Snapdragon X Elite PEP into Linux but they aren't?
<robclark>
QC had patches posted for all the core SoC (as well as the CRD reference design) before the first devices shipped
<robclark>
but based on devicetree
<GurneyBuchanan[m]>
Ahhhhh understood!
<GurneyBuchanan[m]>
* Ahhhhh understood! So just a different choice in implementation detail for device enablement!
<robclark>
it's still an open question if we should try to support ACPI.. but as more laptops come out, it might be hard to scale without
jglathe_volterra has quit [Remote host closed the connection]
<robclark>
Support for ACPI PEP would be, I think, hard... and a lot of the way drivers are wired up and connected to each other is based on of/dt
<anthony25>
But even if you have a device tree, you need a way to pass it to the kernel (it doesn't know which dtb to load), so either the bootloader does it, or you need something like dtbloader to detect which device it is, and load the associated dtb
<GurneyBuchanan[m]>
Gotcha, so that leaves us in need of something more like https://github.com/TravMurav/dtbloader if we want to ship a generic aarch64 image that can boot on devices ranging from an RPI to a snapdragon laptop and presumably some upcoming mediatek laptops and the Nvidia DGX Spark?
<GurneyBuchanan[m]>
You beat me to it!
<GurneyBuchanan[m]>
Is there appetite for this to be added to the bootloader itself?
<robclark>
idk if dtbloader would work on r-pi (does r-pi have uefi/dmi?) but presumably it would work on other windows arm laptops in the future (providing that the rest of the SoC were supported upstream... not sure what the odds of that would be for nv+mtk)
<anthony25>
rpi I think uses uboot, which takes care of the devicetree no?
<robclark>
ahh, yeah, probably
<dgilmore>
there is a tianocore build for rpi, that does ACPI
<dgilmore>
but generally people use u-boot and it provides a fdt
<steev>
rpi does not use uboot (by default) unless you're talking about fedora specific
<dgilmore>
in my experience using raspbian or fedora its used u-boot
<GurneyBuchanan[m]>
Ok, that's interesting, so we would have to have either two aarch64 images (most likely)?
<GurneyBuchanan[m]>
Does anyone know how ubuntu currently handles it?
<dgilmore>
though i treat rasbian as a appliance. I have a few machines in my pidp-8 pidp-10 and pidp-11's and emonpi where I do not use Fedora
<steev>
raspbian (assuming you mean raspberrypiOS now as they call it), just uses their start* firmwares that the gpu boot and does the equivalent of u-boot, but as far as i know, are not a fork of u-boot or barebox
<anthony25>
ubuntu has a script in grub to detect the x1 devices
krei-se has joined #aarch64-laptops
<GurneyBuchanan[m]>
I'm missing my "neat" emoji - but that's a pretty interesting solution - is that roughly analagous to (but less generic than) dtbloader?
<robclark>
in theory something like dtbloader could be used everywhere, but just be a no-op if there is already a dtb table installed or if it doesn't recognize the device dmi
<anthony25>
steev: ha ok, I didn't remember how it worked there. My point was more to say: the bootloader is specific to the device (or limited to a set of devices) and take care of the devicetree, instead of a generic bootloader situation
<steev>
anthony25: you can force it to use u-boot... by naming u-boot what it thinks the kernel is, and then u-boot->u-boot efi implementation->efi bootings
<steev>
i am, unfortunately, familiar with pi devices :P
<GurneyBuchanan[m]>
Intriguing... so we could consider dtb-loader as a generic solutions for the aarch images... hrm
<GurneyBuchanan[m]>
How would I go about integrating it and trying it locally on my system?
<GurneyBuchanan[m]>
GurneyBuchanan[m]: YOLO (I shall try it now before my next meeing)
gwolf has quit [Read error: Connection reset by peer]
<steev>
we stan technical issues causing us to miss our next meetings!
<GurneyBuchanan[m]>
I'm a Red Hatter so I can feign that it is work-related
gwolf has joined #aarch64-laptops
<GurneyBuchanan[m]>
* is work-related!
Lucanis has quit [Ping timeout: 480 seconds]
<anonymix007[m]>
Gurney Buchanan: systemd-stub can automatically select DTBs as well and it should work even on RPi (assuming there is an EFI environment, though I heard that the U-Boot implements enough of it to work), so booting with UKIs is an alternative option.
<GurneyBuchanan[m]>
INTERESTING - though what is a UKI (I'm unfamiliar with the TLA)!
<GurneyBuchanan[m]>
<GurneyBuchanan[m]> "YOLO (I shall try it now..." <- Update: I am struggling to reach EFI, adding the suggested entry (https://www.irccloud.com/pastebin/3VkgXYIb/) now!
chrisl has joined #aarch64-laptops
jglathe_volterra has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
xroumegue has joined #aarch64-laptops
hgblob has joined #aarch64-laptops
<hgblob>
hi guys, I talked to some of you at Connect last week, about my honor magic book art 14 snapdragon
<hgblob>
it seems a UFS phy is missing
<hgblob>
I'm using @abelvesa 's tree
<hgblob>
the netbsd guys have ufs running, but they basically ignore the phy
<hwpplayer1>
I'm about to write a low level system tool/game for snapdragon x elite on windows
<hwpplayer1>
Planning
<hwpplayer1>
I want to touch all features of the device
<hwpplayer1>
A device that I can buy easily in Turkey
<GurneyBuchanan[m]>
<GurneyBuchanan[m]> "Update: I am struggling to reach..." <- I have yet to discover a way to get into the EFI (I've tried this entry as well with no luck unfortunately) - I'm open to any other suggestions! travmurav might know!
<steev>
GurneyBuchanan[m]: btw, just an fyi, using matrix features makes it hard to read things for irc users
<GurneyBuchanan[m]>
Oh, thanks for the heads up! I didn't realize that! I'm happy to join on IRC instead!
<steev>
you don't need to join irc, its bridged, just something to keep in mind :D
<steev>
(i'm responding to you from irc)
<GurneyBuchanan[m]>
Sounds good, I'm guessing those include threads?
<GurneyBuchanan[m]>
Do replies or emoji reactions cause any issues?
<jglathe_volterra>
No threads, no nested replies.
<steev>
oh, using my shell entry - a) you probably need the correct uuid for your efi partition, but more importantly, you need the efi shell
<steev>
it's not something that comes from qcom in the bios or anything
<steev>
i put mine in there by, well, mounting the efi partition, and creating the shell directory and copying the executable in there
<GurneyBuchanan[m]>
Sounds good, I will avoid those!
<GurneyBuchanan[m]>
Oh okay! Any tips on how to find that EFI shell?
<GurneyBuchanan[m]>
I'm mostly trying to prove out that dtb loader could work and then I will try the same image on a raspberry pi to make sure we don't break anything!
<GurneyBuchanan[m]>
Thanks for sharing, y'all! Stepping away from the keyboard for a bit and I will likely resume tinkering tomorrow!
<GurneyBuchanan[m]>
Now that it is at least consistently booting, I'm hoping to try to find a path for us to get a bootable live image from the Fedora build system!
<steev>
that would be awesome to see!
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hgblob has quit [Quit: Konversation terminated!]
enyalios_ has joined #aarch64-laptops
enyalios has quit [Ping timeout: 480 seconds]
hgblob has joined #aarch64-laptops
hgblob has quit [Quit: Konversation terminated!]
jhovold has quit [Ping timeout: 480 seconds]
kalebris_ has joined #aarch64-laptops
kalebris has quit [Ping timeout: 480 seconds]
kalebris_ is now known as kalebris
<deathmist>
GurneyBuchanan[m]: you shouldn't need efi shell for dtbloader with systemd-boot anyway, just place the built .efi in /EFI/systemd/drivers/ of ESP as it briefly mentions
chrisl has joined #aarch64-laptops
hwpplayer1 has quit [Remote host closed the connection]
chrisl has quit [Ping timeout: 480 seconds]
ahoneybun[m] has joined #aarch64-laptops
<ahoneybun[m]>
Has anyone been able to boot a live disk of NixOS on the Thinkpad X13s yet?
mbuhl has quit [Remote host closed the connection]