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>
display is staying blank?
<qzed>
yeah, gotta head off now, problem for tomorrow to solve
<steev>
i saw that here too with the gpu testing on the x13s; one it, it seems like the iommu is deferring
<qzed>
hmm, might be something to that. In contrast to the usual display-stays-black problems it rebooted at some point
<qzed>
after some time
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
Lucanis0 has joined #aarch64-laptops
Lucanis has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
matthias_bgg has quit [Quit: Leaving]
<jhovold>
ardb: i belive the broken reset service has been reported to Lenovo even the problem seems to come from the firmware they get from Qualcomm
<ardb>
jhovold: that does not surprise me at all tbh
<jhovold>
ardb: I believe they clear the corresponding bit in the RT_PROP table in recent revisions so that the temporary hack we carry is no longer needed. I guess you can still call that papering over though.
<qzed>
ardb: say I would want to paper over those... I assume I can hack in that RUN flag somehow?
<qzed>
I'd kinda like to know: If the page is in memory, would ResetSystem() work?
<ardb>
qzed: probably
<qzed>
cheers
<ardb>
what i'd like to try is calling SetVirtualAddressMap() with a 1:1 mapping of the RUN regions
<ardb>
instead of avoiding it entirely on these systems
<ardb>
i suspect that this would work around both issues
<qzed>
ah, nice
<ardb>
on x86, they also leave the boot data regions mapped until after SetVirtualAddressMap() returns
<ardb>
and i would not be surprised if it is the exact same AMI firmware code that is broken
<qzed>
so if I understand correctly that could make novamap unnecessary?
<ardb>
it is already unnecessary as it is the default
<ardb>
so we would devirate from this new default by calling SVAM()
<qzed>
ah, neat
<ardb>
but with a 1:1 mapping
<ardb>
(we already create the 1:1 mapping in the EFI memory map, we just don't install it)
<ardb>
i'll try to cook something up later today
<qzed>
nice, thanks
<ardb>
in the mean time, whoever has time and access, please provide the dmidecode output of the affected systems/
<qzed>
I can get one for the SPX once I get home
<ardb>
cheers
srinik has quit [Killed (NickServ (Too many failed password attempts.))]
iivanov has quit [Remote host closed the connection]
tobru has joined #aarch64-laptops
<HdkR>
steev: No one needed internet anyway? :P
<steev>
heh
<steev>
that was meant for someone else :P
<clover[m]>
lol
<qzed>
jhovold: re UEFI var stuff: do you happen to know if it's possible to turn that into a proper TEE driver?
<qzed>
one issue with v1 is that it doesn't really reflect the probe ordering wrt scm
<qzed>
so my plan was to add a device and driver for the tee and app-interface part, then another for the uefi app thing
<qzed>
but as far as I can tell the interface is incompatible with the one that the kernel tee driver infrastructure expects (with UUIDs and such)
<akawolf[m]>
did you guys had a problems with x13s like it's boot loop endlessly when put a power cable? just got mine x13s and it doesnt work...
<akawolf[m]>
and I can't even stop bootloop
<bamse>
akawolf[m]: around "bios" or after that?
<akawolf[m]>
bamse, it show Lenovo logo with «to interrupt press Enter» and after that restarts
<bamse>
akawolf[m]: and works fine if you don't have the power cable connected?
<akawolf[m]>
bamse, no, it doesnt work et all if power isn't connected
<bamse>
sounds like it's broken...
<akawolf[m]>
bamse, yeah, looks like so, but it's brand new
<bamse>
i had problems with the early firmware that it sometimes wouldn't turn on when i connected power cable and hit the power button...but that seems to have been resolved in firmware upgrades
<akawolf[m]>
what a shame, they bring me broken laptop from China to USA and from USA to Argentina