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)
<bamse> that sucks, sorry to hear that
<leezu> hexdump0815: Re cp513-2h It's also available at acerrecertified.com for 454$ They previously sold the Lazor cp513-1h there for 180$ and it was like new.
<steev> akawolf[m]: maybe try leaving it plugged in overnight and then try and boot it?
<akawolf[m]> steev, when it plugged in, it continuisly does bootloop and I can't even turn it off
<steev> try pressing and holding the power button for 20 seconds
miracolix has joined #aarch64-laptops
<akawolf[m]> steev, doesnt help, still bootloop
<steev> Does it turn back on if you keep it closed when you plug it in?
<akawolf[m]> yes
<leezu> hexdump0815: Regarding the 12/23 message and config, thank you for the reminder. I just compared and have a few questions: 1) you're compiling with Os instead of O2, how much of a difference does it make? 2) you enabled EXPERT mode, why? 3) I previously used VA_BITS=48 but you have VA_BITS=39? 4) You're missing the zswap options
<leezu> https://docs.kernel.org/admin-guide/mm/zswap.html 5) QCOM_FASTRPC may be required for using the DSP?
<steev> akawolf[m]: can you enter the bios by hitting enter when it says that?
<steev> Unplugged
<akawolf[m]> steev, nope, it doesnt turn on when unplugged, and doesnt charging when plugged in
<steev> The battery should be be drained, it should be around 30%; so if you plug it in, and it turns on, when you try to go into bios, it just turns off?
<steev> Should not be*
<akawolf[m]> it doesn't turn on
<steev> You said earlier that it turns on when you plug it in and it goes until it says hit enter
<akawolf[m]> when unplugged I mean
<steev> Right, I’m saying plug it in, and then try to go into bios this time
<akawolf[m]> yes, that's correct, whe it plugged in it doesnt respond to any keypresses: I've tried Enter, F1, F10
<steev> I think the f keys are disabled by default, you have to hit fn
<steev> So, hold the fn button and mash f2
<steev> After plugging it in
<steev> When the person brought it to you there, did they take it with them on the plane or was it in the cargo?
<akawolf[m]> nope, it doesnt respond to Fn + F1, F2, F10
<steev> And probably a stupid question, but since I swap them Willy-nilly, are you using the ac adapter that came with it? Or a different one
<steev> Iirc, it’s f2 or f12 on the thinkpad.
<akawolf[m]> she said it was with her in her purse
<steev> Maybe it’s f10 though
<akawolf[m]> f10 doesnt work neither
<akawolf[m]> I'm using original one adapter
<steev> Right, I’m saying I thought it was f12
<steev> But I’m not at home to check
<akawolf[m]> Fn+F12 doesn't work
<akawolf[m]> I guess it's failed before BIOS started
<rfs613> F12 (with Fn if necessary) for temporary startup device
<rfs613> F11 for recovery
<rfs613> F10 for diagnostics
<rfs613> F9 display regulator info
<rfs613> F5 show asset information
<rfs613> F1 enter BIOS setup
<rfs613> if you press ENTER when the Lenovo banner is up, it displays those choices.
<rfs613> that's x13s with BIOS N3HET74W (1.46)
<rfs613> if those don't work, i'm afraid something is quite broken...
xroumegue has quit [Ping timeout: 480 seconds]
xroumegue has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<steev> yeah, i would probably try mashing enter
<steev> also, huh, TIL about the diagnostics
<akawolf[m]> no, Enter doesn't work
<akawolf[m]> don't know what can be broke laptop like so. does someone try to put charging in a second USB-C port?
<akawolf[m]> can it broke the device in such way or there is protection?
<steev> you can plug into either port, but i'm pretty sure you shouldn't plug into both
janrinze has quit [Quit: Leaving.]
janrinze has joined #aarch64-laptops
<akawolf[m]> I never tried to put the charging cable in anything besides those one marked with charging symbol
<akawolf[m]> but if you say it can't broke the device, I have no idea what happened with that laptop
<steev> i plug it into whichever one i happen to land it into
<akawolf[m]> yeah I see :)
<steev> maybe let it sit for a while off?
<akawolf[m]> yep, it will be off for the night, tomorrow I will contact with argentinian support and if they can't do repair (I guess there is needed hardware one) there is no much choice -- we will manage to bring it back to US...
tobru_ has joined #aarch64-laptops
tobru has quit [Remote host closed the connection]
miracolix has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
iivanov_ has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
Las[m] has joined #aarch64-laptops
<qzed> biggest reordering is done, but still need to address all the style issues and I've probably been missing a couple more things
<qzed> I've essentially changed the structure so that we now have a qcom tee device and a proper device link for ordering between that and the SCM device
<qzed> the uefisecapp device is now a child device under the tee device
<qzed> and the rtc could be added as child device as well
<jhovold> qzed: no, the rtc lives on the spmi bus. We just need the uefi secapp for the store store an offset
<qzed> ah, okay
<jhovold> you'd still have the problem with efivarfs that I mentioned the other day though
<jhovold> it expects efivars to be available before module init
<jhovold> and devicelink additions doesn't really solve that bit
<qzed> I thought using subsys_initcall should fix that?
<qzed> the device link was due to Krzysztof Kozlowski's request
<jhovold> right, that is currently needed. so the device link's doesn't buy us that much
<qzed> he wanted me to ensure proper ordering
<qzed> which I guess would also be a bit of an issue for the rtc thing?
<jhovold> yeah, I saw that part of the discussion. not sure it's that relevant here (no pm etc)
<qzed> yeah
<qzed> I mean it's also mostly to make sure the drivers don't get removed
<qzed> or if they do, in the correct order
<jhovold> yeah, and perhaps it can speed up subsys init probing a fraction too
<jhovold> problem is that efivars doesn't pin your driver anyway
<qzed> yeah
<qzed> so I'm thinking about how the rtc would hook into this
<jhovold> efi is just supposed to be there, or at least that has been the assumption so far
<qzed> at the moment, I've added a struct qctee_device which is used for all scm calls
<jhovold> i'm currently calling efivars from the driver
<jhovold> we have a few drivers doing that already (e.g. to stora a MAC address)
<qzed> ah, so the rtc only uses efivars and doesn't use the scm calls?
<jhovold> right
<qzed> ah neat, I thought we might need to hook it up to the scm call mechanism, but that does save us that headache
<jhovold> it seem later qcom firmware will use a different interface (perhaps using op-tee)
<jhovold> but it doesn't give us any device links
<qzed> yeah, I believe Srinivas mentioned that, so I'm pretty unsure about what names to choose (e.g. qcom_tee or something like that could be conflicting)
<jhovold> so short term, perhaps just using syscall init and always compile is needed as it gives us something that matches the current assumptions
<ndec> it's not really op-tee. but smc-invoke. qcom moved away from qseecom driver to smc-invoke (and along that moved a bunch of their code from kernel to user space)
<ndec> smc-invoke is out of tree, and can be re-implemented as a driver in drivers/tee/
<qzed> so I should probable name that thing qseecom instead of qcom_tee
<qzed> jhovold: I assume we want to set .suppress_bind_attrs=true as well?
<jhovold> yeah, possibly, I had that in the first version of the patch I sent you, but then figured, if someone unloads their efivars driver they get what they deserve
<qzed> heh, I guess that also makes sense
<jhovold> as far as I could tell, everything will behave nicely and you simply don't get store a new rtc time while the the driver is unloaded
<qzed> right
<ndec> qzed: yes, naming that after the original downstream driver seems better. when I saw qcom-tee , I immediately thought about drivers/tee..
<qzed> ndec: when I initially chose the name I was a bit confused about what Qualcomm's name for that was...
<qzed> IIRC it was called tee, TrEE, and qseecom, all different in different places and all seemingly referred to the same thing
<qzed> so thanks for clearing that up
<ndec> we can't blame anyone for finding qcom naming confusing :)
<ndec> in the past qseecom was the only driver for TEE. it is a large an un-upstreamable piece of code. few years ago they introduce smc-invoke, which is a thin driver that has a user space counter part which does more or less the same thing as qseecom.
<ndec> during the transition which is done over several years, the SoCs support both qseecom and smc invoke, *but* if a secure app is 'launched' by qseecom you must use the qseecom driver to communicate with it. which is the case of the uefisecapp (launched before the kernel starts)
<qzed> ah, thanks for that info
<ndec> most recent SoC (i think as of this year for mobile chipsets) have deprecated qseecom completely. compute chipset are lagging a bit behind, but at point (8cx gen 3+NN) will need a newer driver.
<qzed> okay, so then we could choose qcom,qseecom as base compatible? with qcom,tee or something else then for the new one
<qzed> jhovold, steev: I'm pushing my changes to https://github.com/linux-surface/kernel/tree/spx/next-20230117, I've removed the module_exit stuff and switched tristate to bool
<ndec> for smc invoke srini has shown it can be implemented in drivers/tee/ but we are discussing with qcom people to get them to agree that this is a good solution.
<qzed> nice
<ndec> I am sure qcom is already working on the next rewrite of that driver too :)
echanude has quit [Quit: WeeChat 3.6]
echanude has joined #aarch64-laptops
djakov has quit [Remote host closed the connection]
iivanov_ has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
djakov has joined #aarch64-laptops
miracolix has joined #aarch64-laptops
tobru_ has quit [Ping timeout: 480 seconds]
alexeymin has quit [Quit: No Ping reply in 180 seconds.]
alexeymin has joined #aarch64-laptops
snuckls_ has joined #aarch64-laptops
miracolix has quit [Ping timeout: 480 seconds]
Lucanis0 has quit []
Lucanis has joined #aarch64-laptops
hexdump0815 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #aarch64-laptops
<hexdump0815> leezu: maybe i gave the wrong link as all the options you mention are actually in already - https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/config.cbq-6.1.1-stb-cbq
<hexdump0815> leezu: these are the options required (most probably a few of them are not really required) on top of defconfig to make it work on trogdor for me: https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/misc.cbq/options/additional-options-special.cfg
<hexdump0815> leezu: zswap and other nice optional options i have in another repo which i'm merging in into the config
<hexdump0815> leezu: btw. i'm always surprised how cheap arm chromebooks seem to be in the us compared to european prices :)
<steev> qzed: i can give that a whirl when i'm done testing the testing i'm currently doing
<qzed> thanks!
<qzed> here's an updated version:
<qzed> I think this should be ready for v2
<qzed> jhovold: ^
<qzed> steev: a small heads-up: config the vars have changed and you'll need to update the DT
<steev> i noticed :) also a question; should we select EFIVARSFS too? if enabling the secapp?
<steev> i guess technically you don't *need* to, but seems kinda pointless without?
<qzed> yeah
<steev> or would selecting it force it to be y?
<qzed> although... some kernel stuff could access vars without efivarfs... so I'd let the maintainers decide that
<qzed> hmm, you're right about that I think
<steev> but you're the maintainer
<qzed> since it's built in
<steev> M:Maximilian Luz <luzmaximilian@gmail.com> right there, clear as day :P
<qzed> heh, I'm delegating that to other maintainers then
<steev> oh, did you ever figure out the display going kaput?
<qzed> not really... switched to 17 and with that it's random if it works or not... which it already was before
<steev> fair enough
laine_ has joined #aarch64-laptops
laine has quit [Ping timeout: 480 seconds]
laine_ has quit [Ping timeout: 480 seconds]
snuckls_ has quit [Remote host closed the connection]
derzahl has joined #aarch64-laptops
<derzahl> ey goys! not really a laptop but anyone know of theres (non-android) linux running on these buggers? https://www.amazon.com/NEW-Microsoft-Surface-128GB-Unlocked/dp/B08JTDPRM1
<steev> maybe check if postmarketOS supports it?