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> qcom_tee_uefisecapp firmware:tee-uefisecapp: qctee_uefi_set_variable: uefisecapp error: 0x80000007
<jhovold> on the sc8280xp crd
<jhovold> steev: efivar -pn 882f8c2b-9646-435f-8de5-f208ff80c1bd-RTCInfo
<steev> it's the same uuid, give me one moment
<jhovold> { 65 2c d8 50 00 00 01 00 00 00 00 00 }
<jhovold> where 65 2c d8 50 is the LE offset from the GPS epoch
<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?
<kettenis> OpenBSD now uses 315964800
flokli has quit [Quit: WeeChat 3.7.1]
<jhovold> #define RTC_TIMESTAMP_BEGIN_GPS 315964800LL /* 1980-01-06 00:00:00 */
<jhovold> kettenis: ^
flokli has joined #aarch64-laptops
<kettenis> cool, thanks; then at least our implementations agree
iivanov has quit [Quit: Leaving...]
iivanov has joined #aarch64-laptops
echanude has joined #aarch64-laptops
<qzed> jhovold, steev: the latest iteration is at https://github.com/linux-surface/kernel/commits/spx/next-20230123, I'd submit it later if you don't have any further comments on it
<qzed> I've added the module_exit() stuff back in since the other series should now make that a viable option
<qzed> but I've kept subsys_initcall(), not sure if I should change that as well
<jhovold> qzed: i think that if we allow building it as a module you should probably drop susbsys_init as well
<qzed> okay
<jhovold> I'm planning on sending a couple more fixes for the probe deferal to work
<qzed> nice
<jhovold> in the rtc driver i'm probe deferring indefinitly if efivars is not yet available
<jhovold> but for this to work reliably we need a device to be registered along with the efivars
<qzed> hmm, yeah
<jhovold> and we do for the generic implementation, just not for the custom ones, so I was planning on moving that to efivars_register()
<qzed> makes sense
<jhovold> it will not give us fancy device link support, but it should work
<jhovold> qzed, ardb: it seems you should not worry too much about set_var() not working on the crd and c630
<jhovold> the crd "should" work as it use the same storage as the x13s iiuc, maybe just some old fw
<jhovold> c630 may be a different story, where the fw doesn't own the storage device
<jhovold> with the rtc series and the uefi patches, you would at least be able to read out the time until there's a solution to that
<ardb> jhovold: i have been using the c630 for years without this, so i'll manage :-)
<jhovold> :)
<juergh> huh? does battery status reporting on the x13s depend on userspace?
<juergh> ubuntu@ubuntu:~$ cat /sys/class/power_supply/qcom-battmgr-bat/manufacturer
<juergh> cat: /sys/class/power_supply/qcom-battmgr-bat/manufacturer: No such device
<juergh> but:
<juergh> debian@x13s:~$ cat /sys/class/power_supply/qcom-battmgr-bat/manufacturer
<juergh> SMP
<juergh> with the same kernel
<juergh> presumably same fw as well
<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]
falk689 has joined #aarch64-laptops
<jenneron[m]> this is not good
hexdump0815 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #aarch64-laptops
<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 ;-)
<clover[m]> O I think I've noticed that. Its kinda rare
<steev> the only time mine drops them seems to be when i.... fat thumb the touchpad and move the cursor elsewhere on the screen
echanude has quit [Ping timeout: 480 seconds]
<bamse> jenneron[m]: what are you trying to get working in your initramfs?
<jenneron[m]> bamse: when adsp firmware is loading from rootfs booted from USB, i get I/O errors
<jenneron[m]> so i need either this to be fixed or adsp in initramfs
<bamse> jenneron[m]: it sounds more like your getty is trying to run on a tty that you don't have...
<jenneron[m]> nope
<jenneron[m]> if i remove adsp firmware this rootfs boots fine