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
bluerise_ has joined #aarch64-laptops
bluerise has quit [Ping timeout: 480 seconds]
mrkajetanp has quit [Ping timeout: 480 seconds]
<HdkR>
Am I a derp. I thought the UEFI was supposed to just find boot options in ESP/EFI/<folder>/?
<HdkR>
Since I can't get EFI Shell working on this thing, just trying to get the loader to show up in the UEFI as a boot option
DanielSchfer[m] has joined #aarch64-laptops
<DanielSchfer[m]>
<HdkR> "Am I a derp. I thought the..." <- It is, maybe try renaming it BOOTAA64.EFI
<HdkR>
full path should be something like `EFI/debian/BOOTAA64.efi`?
ellyq_ has joined #aarch64-laptops
<HdkR>
Oh hey, got a "Welcome to grub" before it explodes. Progress
ellyq has quit [Ping timeout: 480 seconds]
<steev>
progress is good!
tobhe has joined #aarch64-laptops
tobhe_ has quit [Ping timeout: 480 seconds]
thevar1able__ has joined #aarch64-laptops
thevar1able has quit [Read error: Connection reset by peer]
thevar1able__ is now known as thevar1able
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<HdkR>
Ripped the drive from my Yoga 7x and put it on the T14s and it does the same thing.
<HdkR>
That's terrible
<HdkR>
Feels like grub is crashing but I have no idea why
enyalios has joined #aarch64-laptops
enyalios_ has quit [Ping timeout: 480 seconds]
<HdkR>
Might explain why this Debian image on my USB drive worked on the Yoga but not the T14s actually
<HdkR>
Cursed device
<steev>
odd
<HdkR>
I'll blame Lenovo until proven otherwise :P
martiert_work has quit [Quit: WeeChat 4.4.1]
martiert has joined #aarch64-laptops
<steev>
time to use gummiboot!
jhovold has joined #aarch64-laptops
srinik has joined #aarch64-laptops
srinik has quit [Ping timeout: 480 seconds]
SpieringsAE has joined #aarch64-laptops
thevar1able__ has joined #aarch64-laptops
maud has joined #aarch64-laptops
thevar1able has quit [Read error: Connection reset by peer]
<HdkR>
konradybcio: BIOS is on latest according to Windows Update and Lenovo's support website
<HdkR>
1.31 or something
<HdkR>
and of course Windows update didn't have anymore firmwares for me
<HdkR>
I assume 120hz and 64GB config hasn't been a well tested target
<HdkR>
:)
mrkajetanp has joined #aarch64-laptops
alfredo has quit [Quit: alfredo]
<konradybcio>
lenovo site mentions "Self-healing BIOS", interesting
<konradybcio>
also HdkR secure boot? any lenovo secure features turned on?
<HdkR>
konradybcio: secure boot disabled. Didn't see a self-healing bios option on the device
<konradybcio>
HdkR: and just to make sure, you didn't get any funky internal software on windows? lenovo shipped that once to a guy with a new x13s and he shared it on twitter..
<HdkR>
lol, no
<HdkR>
I ran Windows update until it had nothing left and then repartitioned a new drive
<HdkR>
tried multiple grub builds. The one from Fedora, the one from Debian, my legacy debian one which I use on the Yoga 7x, and the Debian x13s net installer grub. All fail
<HdkR>
The debian image slapped on to a USB device also works on the Yoga 7x. So it really just seems like something about this 120hz and 64GB configuration on the T14s freaks it out
ellyq has quit []
ellyq has joined #aarch64-laptops
<HdkR>
Screen is actually lower resolution than Yoga 7x, so I can only assume the 64GB is the deal breaker
<JensGlathe[m]>
try to bot EFI shell foran interim step?
<HdkR>
EFI shell works
<HdkR>
But I don't know how to use it apart from bcfg controls
<JensGlathe[m]>
On my X14 I don't have kb with grub bootloader
<JensGlathe[m]>
is it possible to load grubaa64.efi from the shell?
<HdkR>
Maybe can use a chainloader command or something, but typing there is the absolute worst
<JensGlathe[m]>
when there is a working command it could end up in startup.nsh, so...
<HdkR>
I'll file that under not knowing how to use efi shell
<konradybcio>
HdkR: you can boot linux directly from efi shell
PeterRobinson[m] has quit [Quit: Bridge terminating on SIGTERM]
fomos[m] has quit [Quit: Bridge terminating on SIGTERM]
travmurav[m] has quit [Quit: Bridge terminating on SIGTERM]
JasonMontleon[m] has quit [Quit: Bridge terminating on SIGTERM]
WeetHet[m] has quit [Quit: Bridge terminating on SIGTERM]
anonymix007[m] has quit [Quit: Bridge terminating on SIGTERM]
KieranBingham[m] has quit [Quit: Bridge terminating on SIGTERM]
Nios34[m] has quit [Quit: Bridge terminating on SIGTERM]
\[m] has quit [Quit: Bridge terminating on SIGTERM]
FarchordSteveCossette[m] has quit [Quit: Bridge terminating on SIGTERM]
JosDehaes[m] has quit [Quit: Bridge terminating on SIGTERM]
TSIN[m] has quit [Quit: Bridge terminating on SIGTERM]
MrCatfood[m] has quit [Quit: Bridge terminating on SIGTERM]
lollaritits[m] has quit [Quit: Bridge terminating on SIGTERM]
z3ntu has quit []
DanielSchfer[m] has quit [Quit: Bridge terminating on SIGTERM]
clover[m] has quit [Quit: Bridge terminating on SIGTERM]
freekurt[m] has quit [Quit: Bridge terminating on SIGTERM]
amstan has quit [Quit: Bridge terminating on SIGTERM]
eliaselias[m] has quit [Remote host closed the connection]
Segfault[m] has quit [Read error: Connection reset by peer]
danielt has quit [Read error: Connection reset by peer]
Jasper[m] has quit [Write error: connection closed]
JensGlathe[m] has quit [Read error: Connection reset by peer]
LoganLeland[m] has quit [Write error: connection closed]
jenneron[m] has quit [Read error: Connection reset by peer]
Molyuu[m] has quit [Read error: Connection reset by peer]
colemickens has quit [Read error: Connection reset by peer]
thenightman97[m] has quit [Remote host closed the connection]
kuruczgy[m] has quit [Read error: Connection reset by peer]
konradybcio has quit [Remote host closed the connection]
nirik has quit [Remote host closed the connection]
mrkajetanp has quit [Ping timeout: 480 seconds]
anonymix007[m] has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
ellyq_ has joined #aarch64-laptops
ellyq has quit [Ping timeout: 480 seconds]
craftyguy has quit [Remote host closed the connection]
cyrinux has quit []
cyrinux has joined #aarch64-laptops
craftyguy has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
ellyq_ has quit [Ping timeout: 480 seconds]
ellyq has joined #aarch64-laptops
<whiskey9>
konr ubuntu.(Sunday.Hr09.Q3)::
<whiskey9>
"/usr/local/cosit/bin/census"
<whiskey9>
contain => silent_and_nobody;
<whiskey9>
ubuntu.(Sunday.Hr09.Q3)::
<whiskey9>
"/usr/local/cosit/bin/census"
<whiskey9>
contain => silent_and_nobody;
<whiskey9>
konradybcio: Holy cats. I didn't realize you could exec the kernel from the uefi shell. Thank you! I was wedged on getting grub to do anything but fail. (xps 9345, 64GB RAM)
<robclark>
hmm so two data points that 64GB+grub==bad?
<whiskey9>
Possibly. I'd try pulling a stick of RAM, but...
<whiskey9>
I *did* manage to work with systemd-boot, but I didn't finish up messing with it (and actually try to exec a kernel)
<HdkR>
Seeing if I can do anything with efi shell now
<whiskey9>
Heh, actually booting the kernel, the screen going blank, and it rebooting feels like HUGE progress to me! Ha!
<robclark>
abelvesa: btw, let me know if there are any things you want me to try as far as getting 3rd usb-c dp working on 7x.. I'm actually using my laptop to get work done so can't reboot whenever but you you give me a list of things to try when I do get to the point where I can reboot, I can. (Either way, having 2 of the 3 dp working is a defn improvement)
<HdkR>
EFI shell booted the kernel and the screen went blank as well. Need to rip a rootfs off my other drive to see if it is really doing anything
travmurav[m] has joined #aarch64-laptops
<travmurav[m]>
no earlycon=efifb?
<HdkR>
I'll add it to my launch options
<travmurav[m]>
I believe efifb is very reliable to get at least some early logs from the kernel on the screen, so you know it tried to boot
<travmurav[m]>
later you don't want to have it though since it's slow
<whiskey9>
Nice. I've been using slow motion video on my phone to watch some of the stuff the flies by too quick.
\[m] has joined #aarch64-laptops
<\[m]>
dev kit sent a mail
<\[m]>
>Thank you for your order of the Snapdragon Development Kit for Windows (C8380-12C-MP-32G). We are confirming that your order will ship later in September. Qualcomm Technologies would also like to inform you about an important update to your product.
JensGlathe[m] has joined #aarch64-laptops
<JensGlathe[m]>
hopefully it still has a dp or minidp
<HdkR>
I assume all three USB4 ports can do DP still
<HdkR>
Definitely booting Linux, got a bunch of logs out to efifb
<HdkR>
Think I need to rip some firmwares from the Windows partition, but lets see if logs actually got written
<HdkR>
What's the firmware folder for T14s? qcom/x1e80100/LENOVO/21N1?
konradybcio has joined #aarch64-laptops
<konradybcio>
yes
<HdkR>
Still a black screen once efifb is handed over
<HdkR>
With firmwares copied from Windows partition
Eighth_Doctor has joined #aarch64-laptops
dcavalca has joined #aarch64-laptops
Jasper[m] has joined #aarch64-laptops
DanielSchfer[m] has joined #aarch64-laptops
JosDehaes[m] has joined #aarch64-laptops
kuruczgy[m] has joined #aarch64-laptops
z3ntu has joined #aarch64-laptops
<HdkR>
oh, some error messages roughly 60 seconds in
<HdkR>
gpu hw init failed: -22
<HdkR>
-22 initializing firmware
<JensGlathe[m]>
60 secs is usally nvme
<konradybcio>
are you running Johan's or Abel's branch?
<HdkR>
Johan's
<konradybcio>
okay, either of them is fine
<konradybcio>
torvalds may still have issues.. but we're working on that..
ellyq has quit []
ellyq has joined #aarch64-laptops
<robclark>
HdkR: for gpu, only the qcdxkmsuc8380.mbn.xz is different from yoga
<HdkR>
Good to know, I guess signed with a different key?
mrkajetanp has joined #aarch64-laptops
<robclark>
yeah, I think so
<HdkR>
Is this going to be the case that this display isn't known so it breaks late in boot? I saw some crinkly cursor in the upper left for a bit before it vanished
<konradybcio>
HdkR: your userspace may refuse to show anything if gpu fails to load
<HdkR>
I would hope i3wm understands what to do if msm is breaking
<HdkR>
I'll disable msm in the kernel and try again
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
<\[m]>
tv
<robclark>
HdkR: if it isn't an oled panel, then panel-edp should _probably_ work (modulo the WARN_ON() splat if it doesn't recognize the panel)
<HdkR>
robclark: It's the 120hz OLED
<robclark>
ok, then for oled panel-edp might work by accident
<robclark>
I have a suspicion that we'll need a different dtb for t14s with oled
<robclark>
you could try copying my patch for 7x oled as a starting point
<robclark>
all the other oleds seem to work with the same samsung panel driver
<anonymix007[m]>
> different dtb for t14s with oled
<anonymix007[m]>
That's kinda bad. Is there at least something that could be used to automatically differentiate them?
srinik has quit [Ping timeout: 480 seconds]
<travmurav[m]>
this seems like not a completely popular opinion, but this is the exact reason why my dtbloader is built around running code to dynamically patch dtb it loads :^)
<Jasper[m]>
New (8 core) x1p sku's got announced today
<travmurav[m]>
\o/ maybe soon we get to 4 core cros skus that I could maybe afford
<robclark>
travmurav[m]: hopefully it has different id's to match on for dtbloader.. I think the differences are more than you'd want to manage with dtb overlay
<anonymix007[m]>
IDs are probably the same though. Hmmm, can it maybe read EDID in EFI?
<travmurav[m]>
anonymix007: I don't like that you put device detection into sd-boot since this means at least a) one can't use the db outside of sd-boot, b) there is no place to handle quirks (see message above)
<travmurav[m]>
but well
<travmurav[m]>
in the end
<travmurav[m]>
as long as there is anything that can kick those people to provide generic images that work
<robclark>
anonymix007[m]: no, the problem is the power up sequence of the panel is different.. but I'd expect it to be a different SKU with different CHID's
<HdkR>
Disabling msm didn't solve anything
<HdkR>
Nightmare laptop
<anonymix007[m]>
robclark: isn't it already powered up by the firmware? There's only one way to know for sure if SKU is going to be any different
<robclark>
probably but there are enough edge cases that you can't really count on that (like what if you don't load the .ko's until after "unused" regulators are disabled
<robclark>
but lets see the CHID's first and then worry about it
<robclark>
worst case, I guess dtbloader has to learn how to read acpi tables to pick the right dtb :-P
<robclark>
anonymix007[m]: also, depending on which panel, you want a different panel driver to be loaded (and various other differences in dtb).. I don't think dtbloader wants to learn to be enough of a display driver to read edid before ExitBootServices
<anonymix007[m]>
travmurav :
<anonymix007[m]>
a) not really, it can be used anywhere as long as the parser can handle an additional section in the text files. Can you maybe add it to your dtbloader repo?
<anonymix007[m]>
b) do you have any suggestions on how to implement quirks?
<anonymix007[m]>
robclark: apparently, there are EFI_EDID_*_PROTOCOL protocols. Not sure whether firmware on T14s actually implements any of them though
<robclark>
hmm, possible
alfredo has quit [Quit: alfredo]
exeat has quit [Quit: rcirc on GNU Emacs 29.4]
<travmurav[m]>
anonymix007: I don't understand what you mean by additional section but afaiu your proposal is limited to systemd stub
<travmurav[m]>
if you want to handle per-specific-device quirks like mac address detection, you have to run code on that device
srinik has joined #aarch64-laptops
<anonymix007[m]>
travmurav: do other UKI stubs exist?
<travmurav[m]>
no idea
<travmurav[m]>
but what if I don't want to use UKI or, for example, don't want to run Linux at all?
clover[m] has joined #aarch64-laptops
<clover[m]>
Is a wwan option available nowadays?
<anonymix007[m]>
travmurav: If you don't want to use UKI, you can't use automatic dtb selection which is built into UKI. It's quite simple
<travmurav[m]>
well
<travmurav[m]>
so this is what I don't like
<HdkR>
clover[m]: T14s has a wwan option. Make sure to select it since Lenovo decided not to populate the wwan m.2 if you don't select the option
<travmurav[m]>
doesn't matter the proposal is invalid, only that /I/ don't like it
<anonymix007[m]>
travmurav: Not sure how non-Linux OS would work though. Is there some kind of EFI stub on *BSD?
<travmurav[m]>
my original goal was to a) provide retrofit ebbr-like environment for OS that doesn't want to handle quirks, and make it drop-in enough for those who are willing to carry it
<robclark>
tbh I prefer something separate from sd-boot, so the system looks like EBBR
<travmurav[m]>
so it wouldn't matter really how the OS works, as long as it follows EBBR and reads uefi configuation table to get dtb
<anonymix007[m]>
It is built into sd-stub which can be used without sd-boot though
<clover[m]>
Steev are you getting a t14s?
<anonymix007[m]>
travmurav: in such case I'd expect even *BSD to work. One would probably put to use whatever bootloader it wants into UKI's .linux section
<anonymix007[m]>
The main issue with dtbloader I see is that it has to be installed as a driver and has hardcoded search paths. This makes it complicated to install (not just "boot from USB and it works")
<anonymix007[m]>
a requires having DTBs on the ESP partition
<travmurav[m]>
dunno, the pmOS images we generate with dtbloader do "just boot from usb and work"
<anonymix007[m]>
> Alternatively, some bootloaders such as systemd-boot provide driver boot directory.
<anonymix007[m]>
Are these images using sd-boot?
<travmurav[m]>
yes
alpernebbi has quit [Ping timeout: 480 seconds]
alpernebbi has joined #aarch64-laptops
clover[m] has quit [Remote host closed the connection]
kuruczgy[m] has quit [Remote host closed the connection]
JensGlathe[m] has quit [Remote host closed the connection]
travmurav[m] has quit [Remote host closed the connection]
konradybcio has quit [Remote host closed the connection]
anonymix007[m] has quit [Remote host closed the connection]
z3ntu has quit [Remote host closed the connection]
Jasper[m] has quit [Remote host closed the connection]
Eighth_Doctor has quit [Remote host closed the connection]
DanielSchfer[m] has quit [Remote host closed the connection]
JosDehaes[m] has quit [Remote host closed the connection]
dcavalca has quit [Remote host closed the connection]
<HdkR>
robclark: Looks like your patch modified to work for t14s didn't change behaviour
<steev>
clover: Not unless someone sponsors it for me (or wait til December/January when my bonus comes)
<steev>
I want it for teh 64GB of ram, moreso than the performance gains, the X13s is quite handy enough for my needs
clover[m] has joined #aarch64-laptops
Eighth_Doctor has joined #aarch64-laptops
dcavalca has joined #aarch64-laptops
JensGlathe[m] has joined #aarch64-laptops
Jasper[m] has joined #aarch64-laptops
DanielSchfer[m] has joined #aarch64-laptops
konradybcio has joined #aarch64-laptops
kuruczgy[m] has joined #aarch64-laptops
\[m] has joined #aarch64-laptops
travmurav[m] has joined #aarch64-laptops
<steev>
but the good news there is, by that time, all the T14s peeps should have all the kinks worked out ;)
<craftyguy>
hey that's my strategy :P
<HdkR>
Alternatively, I'm planning on using this laptop as a frisbee
<craftyguy>
a t14s frisbee?
<robclark>
HdkR: I guess upload an acpi dump and maybe someone who knows how to read it can figure out what is different from the "normal" t14s?
<JensGlathe[m]>
regarding different configs, they are quite common. Is this reflected in those dmi(?) ids dtbload is using? Otherwise could variations like panels or different WWAN /WLAN cards be loaded / probed via overlay?
<robclark>
I assume/hope the it will be reflected in the CHIDs
<steev>
HdkR: i always accept hardware donations ;)
<konradybcio>
HdkR: would you be willing to recompile and print-bomb grub?
<HdkR>
Last time I tried recompiling grub it didn't work at all. This is why I ripped grub from some old AF debian installer
<Jasper[m]>
Have you tried ripping grub from some new af distro installer
<Jasper[m]>
preferably one that isn't 5 years old by default
<Jasper[m]>
(I think there were a couple of updates recently that made booting nicer in general, no idea if that's included with the image you downloaded)
<JensGlathe[m]>
more like new af UEFI BIOS not tested for other than EFI Shell / Windows 11
<HdkR>
Jasper[m]: I tried the most recent Debian and Fedora images and it was even worse
<JensGlathe[m]>
Had my issue on he HP X14 with the kb not working in grub, current Ubuntu grub 2.12
<Jasper[m]>
rip
jhovold has quit [Ping timeout: 480 seconds]
<steev>
testing or newer debian is grub 2.12 which is, afaik, the latest grub (aside from git) - i don't see much that would affect anything in grub, though they did add an fdtdump command recently