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
alpernebbi_ has joined #aarch64-laptops
alpernebbi has quit [Ping timeout: 480 seconds]
ellyq_ has joined #aarch64-laptops
ellyq has quit [Ping timeout: 480 seconds]
tobhe_ has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
checkfoc_us9 has quit []
checkfoc_us9 has joined #aarch64-laptops
telegramgroup_001[m] has joined #aarch64-laptops
<travmurav[m]>
Jens Glathe: as i understood you really need to use the uart and send `\033[H` to trigger the menu
<travmurav[m]>
also don't use in-built efi shell, apparently it causes really weird issues
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
sally has quit [Quit: sally]
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
looked again and yes sutdown -s -t 0 /fw does the trick
gkelly has quit [Remote host closed the connection]
gkelly has joined #aarch64-laptops
<JensGlathe[m]>
now it gives blank screen after exiting EFI stub, let the games begin
<travmurav[m]>
Jens Glathe: earlycon=efifb? :D
<travmurav[m]>
or it kills the display quickly after?
<travmurav[m]>
Jens Glathe: but I wonder if it's actually easier in this case to use normal earlycon and connect to the uart
<travmurav[m]>
so you'd just have earlycon console=ttyMSM0,115200 and on your host picocom -b115200 /dev/ttyUSB0 to connect via that debug microusb
<travmurav[m]>
this assumes crd/devkit dts is used that should have the uart configured properly
<JensGlathe[m]>
need to set this up, yes uart should be in the dtb
<JensGlathe[m]>
it kills the screen after the first line, really early
<travmurav[m]>
yeah in this case it's probably really worth it setting up uart access, it's much easier and reliable to use when you have it :D
alfredo has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
display via type-c doesn't help either
alfredo has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
eh, its answering on a ping but no ssh installed (yet)
sally has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<macc24>
you can compile msm into a module and set it to not load automatically to debug display issues by loading it from ssh and also having logs via ssh
<JensGlathe[m]>
that dt is not sufficient for dp altmode, no USB-A support, no retimers either... ssh only for now, need to do a special hacked image
ektor52 has joined #aarch64-laptops
ektor5 has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
... by installing ssh on the SSD
jglathe_volterra has joined #aarch64-laptops
hightower2 has joined #aarch64-laptops
jglathe_x13s has joined #aarch64-laptops
jglathe_x13s has quit []
srinik has joined #aarch64-laptops
srinik has quit [Ping timeout: 480 seconds]
jhovold has joined #aarch64-laptops
<jhovold>
craftyguy: what kind of camera issues did you see wt the x13s and 6.12-rc?
srinik has joined #aarch64-laptops
<jhovold>
I hit a NULL-deref in camss once on boot, but that's all I've noticed:
<travmurav[m]>
uhhh but why would then loading the pe itself work but the nfail when it tries to parse it again :/
<travmurav[m]>
and not like slbounce does anything with usb devices, it uses simple fs protocol only :/
<maz>
I think we've established by now that the FW is... special.
<travmurav[m]>
yeah...
<travmurav[m]>
that'd be the only explaination from me too xD
<maz>
I think it will be an exercise in finding what can be made to work, and not touch anything.
<travmurav[m]>
though it's annoying since I'm now not sure if some error handling is lacking on my end and some eariler parsing steps have failed silently too
<maz>
if you send me a debug patch, I can apply that and give you the result.
<maz>
JensGlathe[m]: yeah, something like that. though the ITS binding will be substantially different.
<maz>
well, actually not the ITS but the RDs.
<maz>
and we have that already, so it should be good.
<travmurav[m]>
maz: could you tell me what's the last message right before "can't get cert pointers"?
<travmurav[m]>
since I guess there are few dumb possibliities like "asserts are broken"
<travmurav[m]>
but I don't see any other place where an error like this would happen somehow
<JensGlathe[m]>
That dev kit really sounds like a pissed jet engine
<maz>
travmurav[m]: sure thing, let me rebuild the thing.
<maz>
same thing.
<travmurav[m]>
ugh
<maz>
but I have an idea: I have slbounce.efi and tcblaunch.exe on both volumes. wonder if that would confuse things.
<travmurav[m]>
oh might be, I'm actually not sure how simple file system protocol is defined (but it's supposed to read from the same volume as the efi itself afaiu)
<travmurav[m]>
but my impression is that the Read() for the file returns half-garbage...
<travmurav[m]>
and now we re-confirmed that it does it completely silently too...
chrisl has joined #aarch64-laptops
<maz>
travmurav[m]: that's it. if I do "load fs4:\slbounce.efi", no error.
<travmurav[m]>
fun
<travmurav[m]>
well I guess I'd call it 50/50 me not fully understanding uefi and firmware doing dumb stuff xD
<travmurav[m]>
s/and/or
<maz>
I wonder if one could build slbounce embedding tcblaunch.exe.
<maz>
or if that would defeat the validation.
<travmurav[m]>
probably trivial but weird from redistribution standpoint
<travmurav[m]>
well tcblaunch.exe must be as-is since it's signed
<travmurav[m]>
by microsoft
<maz>
oh, of course. I'm not suggesting going down that road for anything else than experimentation.
<travmurav[m]>
and mssecapp tz trustlet (signed by oem) verifies it against the ms keychain
<travmurav[m]>
I wonder if efi shell just passes weird imagehandle to the driver when it's loaded without the disk prefix
<travmurav[m]>
but oh well
hightower2 has quit [Remote host closed the connection]
<travmurav[m]>
seems like avoiding that problem is not too hard so I'd probably avoid breathing at it too much xD
<maz>
:)
chrisl has quit [Ping timeout: 480 seconds]
<macc24>
travmurav: hey have you thought about putting some of dtbhack's functionality into dtbloader?
<travmurav[m]>
macc24: loading overlays - yes-ish
<travmurav[m]>
was considering making a drop-in dir like dtbloader/overlays but wasn't sure on how to nicely handle the load order of them
<travmurav[m]>
(which I guess ideally shouldn't matter but mainline doesn't build symbols)
<travmurav[m]>
otherwise dtbhack only has "code required" kind of fixups for 7c1 which is not that important in the long run
<macc24>
so if dtb would have symbols built-in then load order wouldn't matter?
<Jasper[m]>
<travmurav[m]> "probably trivial but weird..." <- The fact ms is putting up iso's for WoA means it's probably easier to get it either way
<travmurav[m]>
well I guess for 8c3/x1e we don't (yet?) need symbols at all for el2 overlays
<travmurav[m]>
it's also only 7c1 thing where I need to add phandles to existing nodes (which is not possible without symbols)
<Jasper[m]>
Jasper[m]: And maybe if at some point dtbloader gets signed by redhat, they may be able to talk to ms about it
<travmurav[m]>
macc24: but the problem with dtbloader loading overlays would be that it's unconditional, in which case it's better to have like a dedicated boot option in grub/sdboot and have it load a special -el2.dtb (with overlays manually applied in userspace for example), then you can have normal and el2 boot separated
<travmurav[m]>
that is, for slbounce usecase specifically
<travmurav[m]>
overlays are a nice general feature to have
<macc24>
would there be a way to detect if slbounce has already done its thing?
<travmurav[m]>
I have a slightly different "experimental" branch where slbounce itself detects if the overlay was loaded or not
<travmurav[m]>
so i.e. slbounce is always loaded but it bails out and doesn't switch unless the dtb contains a special prop
<travmurav[m]>
so you can unconditionally load slbounce.efi and have two boot options with two dtbs
<travmurav[m]>
(or with overlays but neither grub nor sdboot can load overlays)
<macc24>
there could be overlays that are only applied for booting in el2, probably with filename ending in "-el2"
<macc24>
travmurav[m]: i want to support as many devices as possible so i don't want to hardcode dtbs :/
<travmurav[m]>
well yeah, then ideally we'd extend sd-boot to implement uapi devicetree-overlay prop and grub with something equivalent, then that could just apply overlays on user choice on top of a normal auto-picked board dtb
<travmurav[m]>
as in, this assumes we want user to make a choice of el1/el2
<travmurav[m]>
slbounce is quite complicated to make user friendly in it's current state
<travmurav[m]>
other approach would be to maybe make changes in the kernel to reduce the amount of dtb changes we need
<travmurav[m]>
i.e. hm
<travmurav[m]>
maz: do you know if there is any api in the kernel for a module to know if we started in el2? then msm could know that if zap shader loading failed + we booted in el2 == we can reset the gpu ourselves
<travmurav[m]>
and we drop one of the overlay bits
<travmurav[m]>
the smmuv3 is more complicated in this case I guess
<maz>
it's easy to detect VHE (CurrentEL==EL2).
<travmurav[m]>
and remoteprocs would be evn more complicated then...
<maz>
not easy for anything else as we don't really export that information.
<macc24>
travmurav[m]: i mean... easiest way would be to ignore the dt node if we're running in el2 but devicetree folks would get mad at this
<travmurav[m]>
maz: ah so kernel module could literally just read currentel?
<maz>
and we support having KVM at el2 with the kernel running at EL1.
<macc24>
travmurav[m]: why?
<maz>
travmurav[m]: that would work, but only for a subset of the KVM modes.
<travmurav[m]>
maz: yeah right that's why I wasn't sure, yeah I see that it's only for vhe
<travmurav[m]>
macc24: I'm not sure if for remoteprocs we'd need to rewrite quite a bunch of nodes and i.e. change clock controllers around
<travmurav[m]>
might be needed
<travmurav[m]>
but well I guess it's generally quite an annoying thing
eac has quit [Read error: Connection reset by peer]
<travmurav[m]>
macc24: we can certainly hack something together that would be "good enough", which would be easier with grub and my driver loading patch I guess
<travmurav[m]>
since then we can just script some stuff up in dtbhack and load it on the "el2" option
<travmurav[m]>
so i.e. if you pick "el2" then dtbhack loads -> reads config table to find soc prefix -> updates dtb with overlays -> then slbounce loads
<travmurav[m]>
and if you pick el1 then it just boots as usual, picking the dtb from the config table
<macc24>
travmurav: sdboot has an option for loading devicetree overlays, so there could be a node that would mark whether el2 boot is requested, and if so then el2 overlays could be loaded. i *think* sdboot loads drivers before even showing the boot menu so el2 overlays would need to be loaded when exiting boot services
<travmurav[m]>
I'm afraid sd-boot "supposed to" have it...
<travmurav[m]>
macc24: but yes, that's what it could do with the special slbounce that checks overlay presence on ebs
<travmurav[m]>
which was the original intent: have a boot option that loads the overlay
<travmurav[m]>
but then I guess the problem is picking the correct set of overlays, right
<travmurav[m]>
well not impossible still yeah, by loading real overlays at ebs
<travmurav[m]>
just a bit more hacky from the code standpoint xD
<macc24>
travmurav[m]: it could check compatible string
<travmurav[m]>
macc24: yeah, I meant you can't just use the bootloader overlay property to load correct overlays immediately so your suggestion of loading them at ebs is required
<travmurav[m]>
well in any case, it definitely can be done not too hard assuming we're not looking for a "clean"/"perfect" solution
<macc24>
would be a lot easier if sdboot supported configuring efi drivers per-entry
<macc24>
:/
<travmurav[m]>
yeah
<travmurav[m]>
I guess might be possible to extend blspec for that but that's quite a far reach for blspec scope it feels
<travmurav[m]>
but then again slbounce usecase is not that wide I feel: lack of remoteprocs makes el2 usage only needed by few people who actually rely on it, in which case they can do some manual prep I feel... And if we were to have feature parity with el1 thne we'd not need el1 mode
<macc24>
oh
<macc24>
UKIs could be used for el2 and non-el2 images
<macc24>
with a uki loader that would apply soc-specific overlays, load slbounce
chrisl has joined #aarch64-laptops
<macc24>
I'll need to tinker around with it later today
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
DevKit "angrybox" is up and doing linux-y things
chrisl has joined #aarch64-laptops
f_ has joined #aarch64-laptops
f_ has quit [Remote host closed the connection]
chrisl has quit [Ping timeout: 480 seconds]
<HdkR>
haha, such an angrybox
<JensGlathe[m]>
thats because how it revs when doing something on CPU
<JensGlathe[m]>
well-earned name
f_ has joined #aarch64-laptops
<HdkR>
Interesting, does it not have like any hysteresis?
<JensGlathe[m]>
couldn't detect yet, sounds like its revving up at the slightest load (>2 cores)
<JensGlathe[m]>
like some racing car
<macc24>
sounds like something with no thermal paste
<JensGlathe[m]>
According to @geerlingguy's pics it has all the thermal paste it should need, and then some
<HdkR>
quirky, reminds me of the annoying Intel NUCs that I had on the shelf a couple years ago. Replace it with a new Ryzen thing last year, so much more quiet
<macc24>
JensGlathe[m]: i mean... maybe they forgot to add it lol
<JensGlathe[m]>
yeah, possible. But it is exactly as @geerlingguy described it. noisy.
<JensGlathe[m]>
I will investigate, but not today
<macc24>
huh, i wonder why my slim7x is weirdly warm on front-left side and drawing 13 watts from battery when just running firefox
<HdkR>
13w is barely above idle
<JensGlathe[m]>
is cups acting up? I have that sometimes
<HdkR>
With the screen off I could get down to around 8w, but it doesn't idle very low in Linux
<macc24>
JensGlathe[m]: i don't even have it installed
<HdkR>
The swing of 8w up to >60w under CPU load is pretty wild though
<HdkR>
sadly since I canceled my angrybox I won't be able to see the topend :D
<macc24>
it feels so weird to have a thin and light laptop that almost matches my desktop computer in cpu performance
<HdkR>
It would be even better if I had an ARM desktop that matched my desktop in performance :P
<HdkR>
and offered 128 PCIe lanes if possible...
<HdkR>
Tis a dream
<JensGlathe[m]>
Even worse, QCom canceled most angryboxes
<macc24>
huh, ec code starting at around line 50423 of devkit's dsdt looks eerily similar to what i've seen in slim7x dsdt
<JensGlathe[m]>
what do these Ampere machines cost?
<HdkR>
Yea, I can't even get one now. Although I was hoping the PCIe slot would have been available in them.
<maz>
they have a long history of cancelling the good stuff.
<HdkR>
JensGlathe[m]: Avantek AmpereOne server currently costs $24k
<Jasper[m]>
Newegg was selling ampere boards for 1.5 and 2.5k iirc
<HdkR>
Sadly can't customize it with the A64-37X SKU yet
<Jasper[m]>
But that's US only
<HdkR>
Ampere Altra has bugged PCIe though :/
* macc24
now highly suspects that slim7x and the devkit have the same ec with similar firmware
<JensGlathe[m]>
Out of my range
<macc24>
Jens Glathe: if fan is bothering you there's good news: it can be fixed
<JensGlathe[m]>
yeah, like @fanlesstech is doing it
<JensGlathe[m]>
it is a solvable problem
<macc24>
or that, i was suggesting reverse engineering fan curves
<maz>
macc24: does slim7x have this ucontroller next to the ITE chip?
<macc24>
slim7x boots just fine without fan, i'd imagine that devkit would also
<maz>
indeed, looks different. but the ITE chip is the same.
<macc24>
did you do any updates on the windows ssd?
<macc24>
there might be an ec firmware update somewhere in FileRepository
<maz>
yeah. it started by downloading a whole lot of crap.
<maz>
any particular name to look for?
<macc24>
on slim7x i've seen "alaxec.cap" but it could be any .cap file
<maz>
ITE_ec_devicefirmware8380v290.cap
<macc24>
yeah that sounds about right
chrisl has joined #aarch64-laptops
<macc24>
now that it's known that it's not slim7x-specific how the ec driver should be named :thonk:
<maz>
funny stuff: with -rc3, I het a hard reset of the machine when systemd finds the serial console. the machine boots all the way to userspace, happy as Larry, and then locks up, followed by a reset. as if some watchdog was kicking...
<maz>
s/het/get/
chrisl has quit [Ping timeout: 480 seconds]
<maz>
[ OK ] Found device dev-ttyMSM0.device
<maz>
and that's the last thing she said...
<JensGlathe[m]>
The 2.5G ethernet card does not seem to be reliable
ellyq_ has quit []
ellyq has joined #aarch64-laptops
farchord has joined #aarch64-laptops
<farchord>
Hey everyone! I've been inactive for a while, how's the whole x1e linux experience going?
<JensGlathe[m]>
not bad, not bad
<macc24>
i'm tyipng from x1e laptop and only thing it's missing is sound and lid switch
<minecrell>
(Or just use Johan‘s RC trees as a base)
<macc24>
<minecrell> "maz: you probably need https://..." <- huh i must've never ran into it
chrisl has quit [Ping timeout: 480 seconds]
<tobhe_>
starting a new ubuntu-concept image build now with all the fixes we have accumulated over the weekend...
tobhe_ is now known as tobhe
<JensGlathe[m]>
curious, what's the build time
<tobhe>
all the packages are already built so probably 1 - 2 hours
chrisl has joined #aarch64-laptops
<tobhe>
most of it is livecd-rootfs which builds the layered squashfs files that end up in /casper, the rest is ubuntu-cdimage that turns it into an actual live iso
<tobhe>
all of this has a ton of historical baggage but it is how the actual ubuntu isos have been built since forever
<tobhe>
and pretty tightly integrated with launchpad. We've been working on an easier way to run all of this locally that I'm planning to share soon