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:
<jhovold> never seen it before, but can't say for sure whether it's a new issue or not, haven't been able to reproduce it
<maz> so the ubuntu build of Grub is able to correctly boot a kernel on the devkit as long as you don't interact with the command-line.
<maz> and that includes booting at EL2.
<JensGlathe[m]> yeah, good to know. But I actually selected the boot entry, and it came up. Which dt do you use?
<maz> I've added the DT that was on the list to the CD image, with a hacked up grub.cfg to pick it up.
<maz> for me, just booting the default setup resulted in an empty DT, which of course didn't go anywhere.
<JensGlathe[m]> list? CD image?
<maz> that image
<maz> that series.
<maz> now I need to know where the SMMUv3 is, because PCI is dead without it.
<JensGlathe[m]> must be in the patchwork for slbounce (dtbhack).
<JensGlathe[m]> that series is what I'm using too. but no display with it
<maz> ah, of course! thanks for the hint!
<maz> I'm "lucky" that I don't care about the display. all I want is a serial console.
paddymahoney has quit [Ping timeout: 480 seconds]
<JensGlathe[m]> Huh. It worked on first boot (without display), only I didn't have ssh installed. So... not everything is bad
<JensGlathe[m]> running 24.04 tho
<maz> ah, fair enough. guess I went the bleeding edge way!
<travmurav[m]> maz: https://github.com/TravMurav/slbounce/blob/main/dtbo/x1e-el2.dtso but I assume you saw it already
<travmurav[m]> the offset into the sids matches the pcie number usually fwiw
<maz> travmurav[m]: yes, JensGlathe[m] pointed me to it -- going to slap that into a monolithic DT.
<travmurav[m]> maz: later might be worth preparing a series like this maybe https://lore.kernel.org/linux-arm-msm/20231219-topic-8280_smmuv3-v2-2-c67bd3226687@linaro.org/
<maz> and then I can resurect the ITS
<maz> indeed, that'd be the plan.
<JensGlathe[m]> on sc8280xp, I have smmuv3 and ITS (MSI-parent) for it
srinik has quit [Ping timeout: 480 seconds]
<maz> travmurav[m]: BTW, does this ring any bell:
<maz> Can't get cert pointers
<maz> Failed to prepare data for Secure-Launch: 2
<travmurav[m]> ugh sounds like PE parsing failed
<maz> I get this if I have two USB devices plugged in.
<travmurav[m]> don't think I ever saw it tho
<maz> (one containing slbounce, and another one containing the ubuntu install)
<travmurav[m]> ughhh I wonder if something dumb happens like falinig memory allocation
<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"?
<JensGlathe[m]> @maz there is more to it (on sc8280xp):every pcie port has an iomu-map https://github.com/jglathe/linux_ms_dev_kit/blob/jg/ubuntu-el2-blackrock-v6.12-rc3/arch/arm64/boot/dts/qcom/sc8280xp.dtsi#L1756
<travmurav[m]> oh
<travmurav[m]> yeah this is vvery weird
<maz> JensGlathe[m]: yes, I'm familiar with the setup (I wrote part of the binding ;-)
<travmurav[m]> I guess the file doesn't get loaded fully/correctly then or something
<travmurav[m]> since I suppose the start of the PE is correct but not the end of it
paddymahoney has joined #aarch64-laptops
<travmurav[m]> maz: I'd appreciate if you try this and see if it reports the error more clearly: https://github.com/TravMurav/slbounce/tree/check-loaded-file
<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
<macc24> maz: i don't think so
<macc24> those 2 bga chips on top are retimers
<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
<macc24> * with a patched kernel
chrisl has joined #aarch64-laptops
<minecrell> maz: you probably need https://lore.kernel.org/linux-arm-msm/20241009145110.16847-1-johan+linaro@kernel.org/ if you want reliable serial on the RCs
<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
chrisl has quit [Ping timeout: 480 seconds]
<kuruczgy[m]> Steve Cossette [Farchord]: Things still missing that would be nice to have and I haven't seen much progress on... (full message at <https://matrix.org/oftc/media/v1/media/download/ATgmNl-_WxomVasLrCH9uQIzUed8Qoyn1y4c3x5Nii6_HW9K7IjTxFbAOA_H-1fUZFRdlDFS2dYAjadhlAq-SohCeS82lBkAAG1hdHJpeC5vcmcvWGZYT1d5ZUhnWWVLRXJJWGJoakhCWFR5>)
chrisl has joined #aarch64-laptops
alexlanzano has joined #aarch64-laptops
jhovold has quit [Ping timeout: 480 seconds]
<tobhe> new image is up
<tobhe> JensGlathe[m]: I think my estimate was pretty on point actually
<steev> tobhe: being able to do it locally would be awesome
<farchord> <kuruczgy[m]> "Steve Cossette [Farchord..." <- > <@kuruczgy:matrix.org> Steve Cossette [Farchord]: Things still missing that would be nice to have and I haven't seen much progress on... (full message at <https://matrix.org/oftc/media/v1/media/download/AV6FLfU7okXdF2BT-z0dryGm7Yh_AICDEBEPAsxhnPCwLAMEyh8GiTbge46-NlD3CfEdxVIkER3DPkkewR43_v9CeS9BUKAgAG1hdHJpeC5vcmcvR1dtSGxudEROUnhCU0lCWmhaVEtYSUFD>)
ellyq_ has joined #aarch64-laptops
ellyq has quit [Ping timeout: 480 seconds]