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
<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]
<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
<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.]