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)
<qzed>
steev: so efivars work with the new series?
<steev>
lets not be hasty here
<steev>
i haven't tested that part yet
<qzed>
alright :D
<steev>
i just assumed i screwed up and dropped the patches instead of reverting them :( so i gotta redo, which isn't difficult, just been busy with work
falk689 has quit [Remote host closed the connection]
falk689 has joined #aarch64-laptops
<steev>
attempt incoming
<steev>
my efivars folder is empty
bluerise has joined #aarch64-laptops
bluerise_ has quit [Ping timeout: 480 seconds]
<qzed>
Did you build in qseecom or build it as module?
<steev>
apparently neither :D
<steev>
this time with it built in
<steev>
i do see them now :D
<qzed>
nice, thanks for testing
<jenneron[m]>
bamse: assuming i didn't mess up userspace (it may be wrong), this part of DSDT may be responsible for modem https://dpaste.com/6MTPHCLQM, but i don't know how to read PMIC GPIOs there
falk689 has quit [Remote host closed the connection]
falk689 has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
alfredo has joined #aarch64-laptops
<jenneron[m]>
bamse: also, when I have adsp firmware placed, I get I/O errors when trying to boot from USB. it might be related to glink
<jenneron[m]>
without adsp firmware it is fine
<jhovold>
steev: I get that too occasionally when hitting the MSM DRM late "probe" deferral. It seems to recover but the error messages are annoying.
<jhovold>
The driver needs to be fixed, and until then you can load the panel driver before the DRM driver to avoid it.
<steev>
i'm not too worried, if it's a known issue eventually it'll be fixed :)
<steev>
the display worked fine as you noted
<jhovold>
steev, qzed: do you know if you have any older qcom latops which use UEFI to store the RTC offset?
<steev>
i have a flex 5g and a c630
<jhovold>
it sounded like you've got qzed's driver working on a number of older machines
<ardb>
i'm using it on c630 but the updates don't persist, unfortunately
<ardb>
this could be related to the use of ResetSystem() vs PSCI reset
<jhovold>
just curious whether my assumption that the name and format of that RTCInfo variable hasn't changed
<ardb>
although i don't remember what i have been using on mine
<ardb>
i suppose setting the RTC involves updating the RTCInfo variable?
<jhovold>
ardb: interesting, writing variables doesn't seem to work on the sc8280xp reference design either
<ardb>
jhovold: is EFI ResetSystem() disabled on those?
<jhovold>
right, the first four bytes hold an offset from the GPS (!) time epoch
<ardb>
of course :-)
<jhovold>
well, it hangs when trying to reset/poweroff as I mentioned the other dat
<jhovold>
day
<ardb>
ah indeed
<steev>
jhovold: i haven't tried v2 on them yet, but v1 i have on there, yeah
<ardb>
likely, the SetVariable() calls just update the in-memory copy of the varstore
<ardb>
which gets written out when ResetSystem() is called
<ardb>
this is how it works on the RaspberryPi EDK2 port as well
<jhovold>
ardb: right, on the CRD I actually see the firmware returning EFI_DEVICE_ERROR though. It's just a debug statment in qzed's v1
<jhovold>
which you neeed to enable to see it
<jhovold>
perhaps it's just some variables / namespaces that are write protected, but using that qcom GUID fails
<jhovold>
steev: do you see that RTCInfo variable on either of those machines?
<steev>
jhovold: give me a bit
iivanov has joined #aarch64-laptops
<steev>
jhovold: yes
<steev>
on the c630
<jhovold>
steev: thanks, does it seem to be 12 bytes with an 4 byte offset at the start? Same GUID?
<jhovold>
ardb, qzed: same error from the fw when trying to set BootOrder:
<jhovold>
steev: thanks! So it seems you should be able to get the RTC to work with my series and using the UEFI for storage
<jhovold>
well, apart from the fact that you would still not be able to save the time from Linux if the variables are read-only as ardb mentioned...
<jhovold>
just have to run windows (or the firmware setup) occassionly to update the time in case of drift. ;)
<steev>
Heh
<steev>
Eventually maybe we will be able to write them?
<steev>
But yeah
<jhovold>
steev: yeah, maybe qzed can figure out what is missing if it's at all possible
<jhovold>
steev: do you also get an error when trying to set variables on the c630?
<jhovold>
e.g. if you change that dev_dbg in qctee_uefi_set_variable() to dev_err, do see the firmware returning an error on set?
<jhovold>
such as when trying to change the BoorOrder
<jhovold>
For example, efibootmgr -o 0, returns an error here and the above error is logged if changed to dev_err()
<jhovold>
As ardb mentioned, the efivarfs idea of the content is still updated, but only persists until next boot. (This seems like a bug efivarfs.)
<steev>
yeah it does
<steev>
well, i haven't tried v2 just yet
<steev>
but it did with v1
<steev>
and that's what i'm currently on, i need to give my c630 next tree some love before i can test it again
<jhovold>
steev: did you try changing that dev_dbg() to dev_err() so we know if the error comes directly from the fw?
<steev>
i have not, but i will
<jhovold>
thanks!
matthias_bgg has quit [Quit: Leaving]
<qzed>
hmm, I don't have any idea why this might fail
<qzed>
on the SPX I just tried creating a new variable, that worked persistently
<qzed>
I'll give it a try with the boot order later
<jhovold>
qzed: creating new or modifying seems to work on the x13s, but neither works on the crd
<jhovold>
which is a bit concerning given that the firmware on those should be farily closely related
<jhovold>
the firmware on the crd I have is quite old though, but still.
<qzed>
might be it requires the RpmbOsService, which is as far as I can tell for writing to some host-accessible rpmb block from the TZ/app side
<qzed>
I thought it should fail with QSEECOM_RESULT_INCOMPLETE or QSEECOM_RESULT_BLOCKED_ON_LISTENER
<qzed>
if that's the case
<qzed>
both of which should emit a bit warning
<qzed>
but maybe there's some registration for that necessary, I don't really know how that is supposed to be implemented
<jhovold>
qzed: yeah, that does not sound like something which is easy to figure out. perhaps we can try to ask qcom for details.
<jhovold>
another difference is that I'm booting from UFS instead of NVMe on the CRD, but not sure that's relevant. I have no idea where those vars are stored.
jelly has quit [Remote host closed the connection]
<jhovold>
qzed: but at least windows is able to mess up my boot order the few times I've tried booting it, so it should be doable somehow. ;)
<ardb>
jhovold: would be good to check if it persists even when you unload/reload efivarfs
<jhovold>
ardb: it seems you're right, neither unmounting nor unmounting and unloading restores the original value. Only rebooting does that.
<jhovold>
so it seems the firmware caches the new value, but returns an error as it failed to actually store it?
svarbanov has quit [Remote host closed the connection]
jelly has joined #aarch64-laptops
svarbanov has joined #aarch64-laptops
alfredo has quit [Quit: alfredo]
<ardb>
jhovold: i'd assume the values are written back when ResetSystem() is called
<jhovold>
ardb: but storing variables work on the X13s which do not use ResetSystem() either
<ardb>
jhovold: x13s is nvme, right?
<jhovold>
correct
<ardb>
is there any emmc or ufs being exposed to the OS on those machines?
<jhovold>
only on the reference design (crd), not on the x13s
<ardb>
ok so the flash is exclusively owned by the firmware on the x13s
<ardb>
which means the variable stores can be carried out immediately
<ardb>
if it is shared with the os, some tricks are needed to do the arbitration
<ardb>
caching and deferring until resetsystem is one such trick
<jhovold>
ok, i guess the question then would be why the fw returns an error when caching
<ardb>
yes that is surprising
<jhovold>
and you're not using ResetSystem() on the c630 either?
<ardb>
nope
<ardb>
i turned everything off in RT_PROP_TABLE iirc
<ardb>
but i'd have to double check what i did exactly tbh
<kettenis>
ah, that is where the funny 10 years + 1 week is coming from!
<kettenis>
(difference between GPS epoch and Unix epoch)
<kettenis>
that's a sane but at the same time annoying choice
<kettenis>
what is the plan to handle leap seconds on the Linux side?
<jhovold>
kettenis: heh, I just ignored that for now... :)
<jhovold>
not sure if the UEFI bothers with it either
<jhovold>
UEFI fw
<kettenis>
that is probably the sane thing to do
<kettenis>
would be good if different OSes would ignore the leap secons in the same way
<kettenis>
what is the offset in seconds you're using now?
<bamse>
juergh: it requires you to run the pd-mapper service in userspace
<bamse>
juergh: pd-mapper is involved in the process of making the battery driver know when the firmware is booted...and yes it's not nice to have that dependency
shoragan has quit [Read error: Network is unreachable]
shoragan has joined #aarch64-laptops
<mani_s>
jhovold, efibootmgr returns "EFI variables are not supported on this system"
<mani_s>
dmesg log shows that efivars is registered
<mani_s>
also, "Remapping and enabling EFI services"
<qzed>
mani_s: you're using the qseecom patches and have that enabled?
<mani_s>
qzed, yes
<qzed>
built-in or module?
<mani_s>
forgot to mention that this is seen on SC8280XP CRD
<mani_s>
qzed, module
<qzed>
ah, does efivarfs show anything?
<qzed>
afaik the CRD doesn't allow setting variables, but that should return a different error I think
<qzed>
building it as module could cause efivarfs to not load, so that might be an issue
<qzed>
if reading via efivarfs works, then it's unfortunately some firmware thing
<qzed>
meaning if reading works but writing (e.g. via efibootmgr) doesn't
<mani_s>
qzed, i have efivars and uefisecapp loaded
<mani_s>
qzed, efivar command doesn't show any variables
<qzed>
so I assume ls -al /sys/firmware/efi/efivars also shows empty?
<mani_s>
right
<qzed>
can you try remounting efivarfs?
<mani_s>
ok
<mani_s>
qzed, efivars was not mounted >.<
<mani_s>
now i can see the variables
<qzed>
I guess that makes sense
<qzed>
if you build it as module and it gets loaded late, systemd (or whatever) might already have tried mounting efivarfs and that failed because at that time efivars were not supported
<juergh>
bamse, ah thanks for that info
alfredo has joined #aarch64-laptops
<mani_s>
qzed, okay, thanks for the help!
<mani_s>
and thanks for the patches too :)
<mani_s>
jhovold, qzed looks like I can set variables on my CRD as well
<mani_s>
atleast the variable i created persists across reboots
<qzed>
huh, interesting... any errors/warnings in the log?
<mani_s>
qzed, no errors/warnings
alfredo has quit [Read error: Connection reset by peer]
<mani_s>
looks like it works
<mani_s>
although i couldn't test by booting a different boot manager other than windows
<qzed>
neat
<steev>
mani_s: what firmware are you on? perhaps your firmware is newer than jhovold's and that's why it works for you and not him?
<jhovold>
mani_s: that's great news, thanks for testing. I guess it should just be the firmware version then.
<jhovold>
the fact that you boot using nvme shouldn't matter if the the fw use a separate flash for storage
<jhovold>
or my crd is just broken. :)
iivanov has quit [Quit: Leaving...]
<jenneron[m]>
bamse: is it going to be changed? I'm still looking how to implement it in initramfs
<jenneron[m]>
actually the I/O problem may be not because of glink, but because of adsp itself
falk689 has quit [Remote host closed the connection]
<rfs613>
for those with x13s, has anyone noticed the keyboard occasionally dropping characters? Not seeing it myself, only my left mouse button seems to sometimes miss clicks.
<rfs613>
there's some speculation on forums that it might be i2c bus beign flooded by queries from soemthing. Vague, I know ;-)