ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
<steev> seems plausible
<qzed> although I'm not sure if that's the end of it...
<qzed> I fear that there might me more services involved, like uefisecapp calling to storesec or something to actually access the database
<qzed> I think it should be possible to register some hooks for those services, so we can figure out when these functions get called
_alice has joined #aarch64-laptops
robher has joined #aarch64-laptops
<steev> qzed: do you have to manually edit the wiki for the surface pro x repo, or is there a git repo for it?
<qzed> I usually manually edit it but there's a git link
<qzed> .wiki.git should work for all github wiki things, but I'm not sure if everyone can access it
<qzed> or only owners/contributers
<steev> it's fine, i forked i'm just trying to figure it all out :D figured i'd do similar for the thinkpad
<qzed> nice
<steev> ah
<steev> you can clone it, or i can
<steev> that works for me, i'll try to work on that over the weekend, if i can find the time
amstan has quit [Quit: Reconnecting]
amstan has joined #aarch64-laptops
shawnguo has quit []
mani_s has quit [Quit: ZNC 1.7.2 - https://znc.in]
vkoul has quit [Quit: ZNC 1.7.2 - https://znc.in]
srinik has quit [Quit: ZNC - http://znc.in]
mani_s has joined #aarch64-laptops
srinik has joined #aarch64-laptops
vkoul has joined #aarch64-laptops
derzahl has joined #aarch64-laptops
dianders has joined #aarch64-laptops
robclark has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
pundir has joined #aarch64-laptops
Lucanis has quit [Read error: Connection reset by peer]
Lucanis has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
steev has joined #aarch64-laptops
bamse has joined #aarch64-laptops
bamse is now known as Guest5185
jhovold has joined #aarch64-laptops
jhovold has quit [Quit: WeeChat 3.4.1]
jbowen has joined #aarch64-laptops
gwolf has joined #aarch64-laptops
flowriser has joined #aarch64-laptops
rfs613 has joined #aarch64-laptops
leezu has joined #aarch64-laptops
Guest5185 is now known as bamse
Evaia63 has joined #aarch64-laptops
Evaia63 has quit [Quit: Hack the Gibson]
Evaia63 has joined #aarch64-laptops
systwi has quit [Server closed connection]
systwi has joined #aarch64-laptops
ndec has quit [Server closed connection]
ndec has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<clover[m]> <bamse> "and the new files are expected..." <- Is this something else I could make a PKGBUILD for?
tomf has quit [Server closed connection]
tomf has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
<steev> clover[m]: eventually the distros themselves would just get it because they'll be in the linux-firmware repo
<clover[m]> That would be great. My hope is for the project to be upstreamed as much as possible
SallyAhaj has quit [Quit: SallyAhaj]
falk689_ has quit [Remote host closed the connection]
falk689 has joined #aarch64-laptops
jhovold has quit [Ping timeout: 480 seconds]
<qzed> re uefi vars: I think my theory with the stubs is false (looks like TZ cannot itself initiate calls to the os-driver)
<qzed> and also the uefi var service depends on a rpmb (replay protected memory block) service, which looks like it must be provided by the driver
<qzed> so I'm once again stuck at "where the hell does the Pro X store its data"
<qzed> I guess on the flex that's again in UFS
<qzed> looking at the .inf diff between flex and pro x, that might be done via storsec.mbn, but I can't see any service thing associated with that
<steev> yeah, the flex has ufs
<qzed> just out of curiosity: can you spot some sort of uefi key/value store on there?
<steev> i can look later, the battery is dead and i forgot to plug it in heh
<qzed> no worries
<qzed> just trying to figure out what I'm even looking for
<steev> i know that it's very similar to the c630's setup
<steev> /dev/sde9: PARTLABEL="UEFI_BS_NV" PARTUUID="507c059a-726f-028d-6e7e-2aeaedc74a2e"
<steev> maybe that?
<qzed> yeah, that kinda sounds like it
<qzed> thanks
<steev> s/3/9/
<qzed> oh nice, thanks!
<steev> that's the c630, not the flex, i'll grab the flex once its had a bit more juice
<qzed> hmm okay, that file seems to be all zeros
<steev> i may have just broken it
<steev> oh, i didn't
<steev> qzed: same url but c630 subdir has all of the sde partitions (and sde itself as a whole) which will take about 30 more minutes to upload since it's ~4GB in size
<qzed> awesome, thanks again!
<qzed> the partiton name you posted matches with a config file I've found from a partition dump via the efi shell: https://github.com/linux-surface/surface-pro-x/issues/37#issuecomment-1186312710
<qzed> (still no clue where those uefi partitions are stored, i currently assume they're extracted to ramfs, or where the secure partitions are located on the spx)
<qzed> there are UEFI_BS_NS_NV, UEFI_RT_S_NV, UEFI_RT_NS_NV partitions
<qzed> NV I guess means non-volatile, BS boot services, and RS runtime services
<qzed> S/NS could be secure/not secure? no clue...
<qzed> *RT means runtime
<qzed> but based on that it kinda looks like the modem stuff isn't stored via storsec
<qzed> which I guess would make it possible that uefivars can be read without a kernel-driver rpmb callback?
SallyAhaj has joined #aarch64-laptops
<steev> the modem stuff is on sdf
<steev> sdd has "ddr" and "cdt"
<qzed> ah so those are different devices? I always thought it's a single device and a bunch of partitions
<steev> i'm not entirely sure, bios just sees 1 device, but it definitely shows up as a bunch of different devices
<steev> sdd claims to be 128MiB, sdf claims to be 1.5GB
<steev> qzed: in 10 minutes, all of them aside from the actual os "drive" will be up (so sdb, c, d, e and f)
<qzed> nice, thanks!
<steev> blkid output of them all
<qzed> sde12 looks like it's the TZ/qsee os
<qzed> one big elf thing
<qzed> kinda interesting that they just put that on a partition like that
<qzed> if it's really the real thing
<qzed> sde14: hyp... is that the EL3 hypervisor?
<qzed> okay, looks like sde15 also has storsec.mbn... so might not be a surface specific part after all :/
<steev> if that actually is the hypervisor on the c630, that would be incredibly frustrating because they don't expose it
<steev> qzed: flex is going up in the flex subdir, https://paste.debian.net/1247449/ for its blkid output
<steev> qzed: the thinkpad is probably closer to the spx, since it also has tis drive on nvme, and i don't see anything else in blkid output
<qzed> yeah, I guess they have one solution for devices with UFS and another for NVME
<qzed> and thanks, yet again xD
<steev> it's not very difficult to run dd if=blah of=blah; scp * :P