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> because i can take johan's defconfig, and get to a point where it kinda does... something - but if i enable zram (see my mention to him of a diff) i get the same thing as ajhalaney[m]
<steev> 15:56:29 <steev> jhovold: https://paste.debian.net/hidden/45630642/ is a diff of yours to what i added to try to get the swap partition recognized (about to just comment it out)
<bamse> no idea what might be wrong there
<steev> adding those options, i end up with what andrew sees, without them, i end up with the screenshot i posted above
<steev> and if we add drm_msm back in... then we just get a black screen and can't see any of the above :D
<steev> basically... next is being next
<akaWolf0> steev: so you think drivers for x13s are ready in mainline?
<akaWolf0> only DTS parts needs work?
<steev> no
<steev> there's still a lot of work to go on both, but it's *usable* - it's my daily driver for work... and i work on a linux distribution
<HdkR> I'm waiting for it to be my daily driver for work as well :D
<akaWolf0> what kind of work needs to be done at drivers side?
<HdkR> GPU needs to get up and running :)
<akaWolf0> someone updates the table here? https://github.com/ironrobin/archiso-x13s/wiki/Feature-Support
<steev> that would be clover[m] (aka ironrobin)
<steev> bamse: what nvme controller do you have btw? those of us having issues seem to have an am360
<steev> 630?
<akaWolf0> IIURC linux-x13s
<akaWolf0> in the table should be changed to mainline?
<steev> i believe he means my kernel there
<steev> or maybe that's the arch package
<akaWolf0> yeah, I guess it's about your kernel which is used in arch package. but I mean does it in mainline, drivers you are working at?
<akaWolf0> cpufreq, cpuidle, System suspend, Primary display
<steev> cpufreq yes, cpuidle... yes? suspend/primary display i think are technically still not in yet
<bamse> steev: is this the answer you're looking for: "Subsystem: Silicon Motion, Inc. Device 2267"?
<steev> blrgh
<steev> that's probably the same as johan. also you should run `update-pciids` :P
<steev> the good news is, you won't run into the issues we do :P
<bamse> but this is a new problem?
<steev> yes
<steev> but it seems specific to 21BX and not 21BY, and all you devs have 21BY and all us.... consumers.. have 21BX
<steev> maybe we could ask mark for what the actual differences are between 21BY and 21BX? because audio also seems to work fine on BY but not BX
<bamse> due to hardware differences? or the usual issue of just getting the ucm files etc in order?
<HdkR> All four of mine are 21BX, confirmed
<akaWolf0> btw is there significant difference amongst x13s versions?
<bamse> steev: allow me to bring some joy with my 21BX0008US
<bamse> steev: sounds like i should avoid the latest kernel then ;)
<steev> heh
<steev> well, the ucm2 files should be fine (though i had to create my own symlink because srinik symlinks teh BY not BX by default, but that's a minor detail i could probably fix up in my packaging of it)... which i should probably push
<steev> https://git.linaro.org/people/srinivas.kandagatla/alsa-ucm-conf.git/log/?h=x13s is the ucm2 files, and i think his dts patches haven't been merged in just yet, but you'd know far better than i would ;)
<steev> oh, i did push them
<akaWolf0> I order 21BXCTO1WW
<steev> https://salsa.debian.org/steev/alsa-ucm-conf for the debian types (but like i said, i should fix the package)
<steev> i'm assuming that version has touch screen and wwan/
<bamse> wwan is the shit
<akaWolf0> my version is w/o touch and wan (I dont use it) but with 400 nits screen and 32gb/1tb
<akaWolf0> bamse: yeah anyway you always have phone with you and can share wi-fi :)
<bamse> akaWolf0: i thought so too, but with builtin wwan you don't drain the battery on your phone
<bamse> well, it's even better than that...you don't need do anything to stay connected:)
<akaWolf0> bamse: I've noticed that screen consume much more energy then wi-fi+cellular, and you dont need one more sim-card, so for me choice is obvivious :)
<bamse> akaWolf0: 2nd sim card costs too much...but i think 4 lines was $5 more than 3 lines...
<bamse> a month that is
<akaWolf0> bamse: haha I'm russian now live in Argentina, so everything here is different. it was very hard to find a way to bring laptop here, I paid $290 for delivery from USA w/o box
<bamse> i'm hoping we'll be able to get all the pieces together for you
<akaWolf0> ah thanks I was ready that it isn't ready yet for everyday use, so I'll try to help too :)
<bamse> akaWolf0: i've been using mine as my primary workstation since june...
<akaWolf0> bamse: what about watching movies?
<bamse> i've not seen any attempts at bringing in venus support, so that would be cpu-decoding only
<bamse> that said, the venus version in sc8280xp seems quite similar to other platforms already supported
<akaWolf0> guess sw decoding much more resource consuming
<bamse> yes
<akaWolf0> how do you compare venus? by ACPI table?
<bamse> steev: okay, so on my dev-x13s i've now hit an issue twice where the nvme is detected but it says enabling and then i end up in ramdisk console...
<bamse> akaWolf0: the datasheet..
<akaWolf0> bamse: but steev said there is no datasheet in public
<bamse> although that doesn't cover any differences in the firmware interface
<bamse> he's correct
<akaWolf0> do you have access?
<bamse> yes
<akaWolf0> good news :)
<bamse> steev: got it to boot a few times, but my display didn't work...and as you say, one you have a kernel that doesn't boot...it really doesn't boot, no matter how many times you try
<steev> yeah :/
<bamse> steev: but you don't get the timeout from nvme right? just that the root device wasn't found?
<steev> i'm not even sure if the root device isn't found because it SEES the partitions
<bamse> i mean, there used to be a message from pcie that nvme timed out
<steev> at least, it sees them if zram isn't enabled in the kernel config
<bamse> have you tried reverting e7b813b32a42 ("efi: random: refresh non-volatile random seed when RNG is initialized") ?
<steev> i have not
<bamse> do that...mine has booted 5 times straight since i removed that
<bamse> with that patch i got a kernel panic really early, when the kernel tried to process scheduled_work at addres 0x0
<bamse> just took some work to get the system to a state where i could look further up in the dmesg ;)
<steev> will try
<steev> you sir, are a gentleman and a scholar
<steev> it boots here with that reverted
<HdkR> \o/
<steev> no input devices but that's probably unrelated
<bamse> i think it might be that the set_variable function in the efi struct is NULL...in that case the reverted patch would just jump into hyperspace, just like the callstack said it did...
<steev> well that is fun
<steev> ardb: ^^ any possible insights on what we might do so that can be kept?
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<steev> bamse: so here's another question... why the hell doesn't BY show the same issue?
<bamse> steev: i don't believe that to be the case
<bamse> well...that's not entirely true...because i don't see this problem on the crd either
<bamse> steev: i will have to get back to you on that then...but first some sleep, and i need to wrap this other thing that i should have been doing tonight...
<bamse> good night
<steev> appreciate your looking into this though! night!
<steev> oh, looked at the patch... and yeah, i was right - nov 22 :) i said somewher ein the 20s in november
<steev> also, sleep would be nice... but i have new neighbors who have a 1 yr old with *very* healthy lungs
<steev> jhovold: whenever you're around - as bamse found, the breakage is from e7b813b32a42
<steev> i was hoping those i2c patches might help with the touchscreen issue, but sadly the problem is elsewhere
<jhovold> steev: bamse: that's great news! Still need to determine why it only affects some people's machines (and not the CRD either)
<jhovold> bamse: did you use my branch which has qzed efivar support in it? If not that may explain your NULL deref
<jhovold> bamse: steev: and perhaps the firmware on my machine isn't as sensitive about clearing that variable. A couple of hypothesis to confirm.
<ardb> bamse: thanks for the report
iivanov has joined #aarch64-laptops
<jhovold> bamse: ardb: steev: so that new efivar access is just broken as it should not be done unconditionally
<jhovold> that said, we need firmware to provide an rt_prop table with that service bit cleared
<jhovold> for some reason, my machine (and the crd) does not look up when trying to access the nonsupported service
Guest2402 has quit [Quit: The Lounge - https://thelounge.chat]
thelounge17 has joined #aarch64-laptops
thelounge17 is now known as krzk
krzk has quit []
SSJ_GZ has joined #aarch64-laptops
krzk has joined #aarch64-laptops
krzk is now known as Guest2449
Guest2449 has quit []
thelounge55 has joined #aarch64-laptops
thelounge55 is now known as krzk
init1 has joined #aarch64-laptops
init has quit [Ping timeout: 480 seconds]
<jhovold> ardb: bamse: steev: sent a fix here
<jhovold> the difference in behaviour probably comes down to us using different firmware
<jhovold> mine claims to support setting variables but the call itself returns EFI_UNSUPPORTED
<jhovold> same on both the x13s and CRD
<steev> oh nice
<jhovold> based on the report from bamse above, later firmware has likely cleared both the service bit and callback pointer, which triggers a NULL deref during boot, with semi random consequences
<steev> i am, afaik, on the latest bios, but not sure
<jhovold> in case the status bit isn't alreadt cleared we need another hack for that until the firmware can be fixed
<jhovold> steev: it's clearly time for me to update the firmware too. Haven't had time to risk any downtime so far, but hopefully things will slow down a bit now
<steev> it's all good :)
<steev> i'm just excited to be able to boot -next again
<steev> but, now it's 3:30am, and i need some sleep ;)
<jhovold> goodnight
<akaWolf0> what is UEFI implementation in x13s?
Vectorboost has joined #aarch64-laptops
Vectorboost has quit [Quit: Leaving]
iivanov_ has joined #aarch64-laptops
Vectorboost has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
Vectorboost has quit [Quit: Leaving]
Vectorboost has joined #aarch64-laptops
SSJ_GZ has quit [Ping timeout: 480 seconds]
SSJ_GZ has joined #aarch64-laptops
Vectorboost has quit [Quit: Leaving]
Vectorboost has joined #aarch64-laptops
<qzed> jhovold: steev: fwiw I believe returning EFI_UNSUPPORTED was/still is (?) the standard behavior on most QC devices, but would be nice to see them finally not advertising those features if they're broken
Vectorboost has quit [Quit: Leaving]
Vectorboost has joined #aarch64-laptops
Vectorboost has quit []
Vectorboost has joined #aarch64-laptops
<jhovold> qzed: yeah, hopefully the set-variable bit is cleared now too, but i've added a sanity check just in case so that the RNG seed regression doesn't trigger
<jhovold> bamse: steev: init1: I've just pushed a new branch based on today's -next:
<jhovold> It has the fix for the EFI RNG regression and the sanity check mentioned above. Let me know if it triggers or if the services are corrrectly described now. Otherwise you'll see something like:
<jhovold> efi: [Firmware Bug]: Runtime services mask contains unsupported services (0x3fff)
<jhovold> when booting.
<jhovold> I also finally sorted out all the display dependencies and have documented all the modules that are needed in the initramfs for a functional rescue shell (without hacking regulator core).
<jhovold> The list is impressive (?):
<jhovold> MODULES=(i2c_hid_of i2c_qcom_geni leds_qcom_lpg pwm_bl qrtr pmic_glink_altmode gpio_sbu_mux phy_qcom_qmp_combo panel-edp msm phy_qcom_edp nvme phy_qcom_qmp_pcie pcie_qcom)
<jhovold> Note that the above order avoids triggering the MSM DRM probe deferal issue (due to the driver not looking up the panel until component bind)
Vectorboost has quit [Quit: Leaving]
<jhovold> Oh, and I include DM_CRYPT in johan_defconfig for init1 :)
laine_ has joined #aarch64-laptops
laine has quit [Remote host closed the connection]
iivanov_ has quit [Ping timeout: 480 seconds]
Vectorboost has joined #aarch64-laptops
<Caterpillar> is anyone else with a X13s experiencing data and time loss when booting Linux?
<Caterpillar> sorry, not data, I meant date
<jhovold> Caterpillar: rtc support is underway, until then you need to use ntp
<Caterpillar> jhovold: thank you
rfs613- is now known as rfs613
Vectorboost has quit [Ping timeout: 480 seconds]
<ajhalaney[m]> jhovold: I took that patch for a spin and added my TB on list, things boot sane now, thanks! Also, I took that whole branch for a ride and I don't see the warning "Runtime services mask contains unsupported services" that you added... in case you were interested in that data point :)
<jhovold> ajhalaney[m]: ah, perfect. thanks for confirming!
Vectorboost has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
iivanov_ has joined #aarch64-laptops
iivanov has quit [Read error: Connection reset by peer]
alpernebbi has quit [Ping timeout: 480 seconds]
alpernebbi has joined #aarch64-laptops
<init1> jhovold: sick. fethcing it.
<init1> fetching
<init1> thanks
init-x13s has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
iivanov_ has quit [Read error: Connection reset by peer]
init-x13s has quit [Remote host closed the connection]
init-x13s has joined #aarch64-laptops
<init-x13s> [initnull@stargazer ~]$ uname -a Linux stargazer 6.1.0-next-20221216-49469-ga4844378eb0e-dirty #15 SMP PREEMPT Fri Dec 16 14:41:26 EST 2022 aarch64 GNU/Linux
<init-x13s> weee
<init-x13s> I had to add CONFIG_NLS_ASCII back
<init-x13s> and for now I don<t have battery status, and all my crits are at +110C
<init-x13s> but it boots!
init-x13s has quit [Remote host closed the connection]
iivanov has quit [Quit: Leaving...]
<steev> jhovold: adding my confirmation as well :) additionally, confirming that with that list of modules, don't see the probe deferral mess in dmesg anymore
Vectorboost has quit [Remote host closed the connection]
<akaWolf0> steev: do you know which UEFI implementation in x13s?
<steev> i do not, but i'd assume tianocore based
akaWolf0 has quit [resistance.oftc.net reticulum.oftc.net]
kettenis has quit [resistance.oftc.net reticulum.oftc.net]
Caterpillar has quit [resistance.oftc.net reticulum.oftc.net]
Cyrinux has quit [resistance.oftc.net reticulum.oftc.net]
hexdump01 has quit [resistance.oftc.net reticulum.oftc.net]
janrinze has quit [resistance.oftc.net reticulum.oftc.net]
jhovold has quit [resistance.oftc.net reticulum.oftc.net]
martijnbraam1 has quit [resistance.oftc.net reticulum.oftc.net]
frytaped has quit [resistance.oftc.net reticulum.oftc.net]
clover[m] has quit [resistance.oftc.net reticulum.oftc.net]
AlexMarty[m] has quit [resistance.oftc.net reticulum.oftc.net]
robertmader[m] has quit [resistance.oftc.net reticulum.oftc.net]
mothenjoyer69 has quit [resistance.oftc.net reticulum.oftc.net]
steevdave[m] has quit [resistance.oftc.net reticulum.oftc.net]
JoshuaAshton has quit [resistance.oftc.net reticulum.oftc.net]
maz has quit [resistance.oftc.net reticulum.oftc.net]
kbingham has quit [resistance.oftc.net reticulum.oftc.net]
macc24 has quit [resistance.oftc.net reticulum.oftc.net]
xnox has quit [resistance.oftc.net reticulum.oftc.net]
suihkulokki has quit [resistance.oftc.net reticulum.oftc.net]
Libre___ has quit [resistance.oftc.net reticulum.oftc.net]
agraf has quit [resistance.oftc.net reticulum.oftc.net]
javierm has quit [resistance.oftc.net reticulum.oftc.net]
alpernebbi has quit [resistance.oftc.net reticulum.oftc.net]
bluerise has quit [resistance.oftc.net reticulum.oftc.net]
djakov has quit [resistance.oftc.net reticulum.oftc.net]
jelly has quit [resistance.oftc.net reticulum.oftc.net]
minecrell has quit [resistance.oftc.net reticulum.oftc.net]
fevv8[m] has quit [resistance.oftc.net reticulum.oftc.net]
jonasbits has quit [resistance.oftc.net reticulum.oftc.net]
ajhalaney[m] has quit [resistance.oftc.net reticulum.oftc.net]
HdkR has quit [resistance.oftc.net reticulum.oftc.net]
xypron has quit [resistance.oftc.net reticulum.oftc.net]
qzed has quit [resistance.oftc.net reticulum.oftc.net]
mahmoudajawad[m] has quit [resistance.oftc.net reticulum.oftc.net]
tomeu has quit [resistance.oftc.net reticulum.oftc.net]
szclsya[m] has quit [resistance.oftc.net reticulum.oftc.net]
harvests[m] has quit [resistance.oftc.net reticulum.oftc.net]
davidebeatrici[m] has quit [resistance.oftc.net reticulum.oftc.net]
danielt has quit [resistance.oftc.net reticulum.oftc.net]
Dylanger has quit [resistance.oftc.net reticulum.oftc.net]
travmurav[m] has quit [resistance.oftc.net reticulum.oftc.net]
go4godvin has quit [resistance.oftc.net reticulum.oftc.net]
Sobek[m] has quit [resistance.oftc.net reticulum.oftc.net]
alexeymin has quit [resistance.oftc.net reticulum.oftc.net]
calebccff has quit [resistance.oftc.net reticulum.oftc.net]
abelvesa has quit [resistance.oftc.net reticulum.oftc.net]
SSJ_GZ has quit [resistance.oftc.net reticulum.oftc.net]
pbsds0 has quit [resistance.oftc.net reticulum.oftc.net]
xroumegue has quit [resistance.oftc.net reticulum.oftc.net]
malvi[m]1 has quit [resistance.oftc.net reticulum.oftc.net]
Prawn[m] has quit [resistance.oftc.net reticulum.oftc.net]
flokli has quit [resistance.oftc.net reticulum.oftc.net]
selmer443[m] has quit [resistance.oftc.net reticulum.oftc.net]
EricCurtin[m] has quit [resistance.oftc.net reticulum.oftc.net]
juergh has quit [resistance.oftc.net reticulum.oftc.net]
Esmil has quit [resistance.oftc.net reticulum.oftc.net]
Lucy[m] has quit [resistance.oftc.net reticulum.oftc.net]
ungeskriptet[m] has quit [resistance.oftc.net reticulum.oftc.net]
luxio_39[m] has quit [resistance.oftc.net reticulum.oftc.net]
shoragan has quit [resistance.oftc.net reticulum.oftc.net]
NomadNaomie[m] has quit [resistance.oftc.net reticulum.oftc.net]
harvestz[m] has quit [resistance.oftc.net reticulum.oftc.net]
jenneron[m] has quit [resistance.oftc.net reticulum.oftc.net]
Leandro[m] has quit [resistance.oftc.net reticulum.oftc.net]
cmeerw[m] has quit [resistance.oftc.net reticulum.oftc.net]
wiizzard has quit [resistance.oftc.net reticulum.oftc.net]
quinine has quit [resistance.oftc.net reticulum.oftc.net]
Manis[m] has quit [resistance.oftc.net reticulum.oftc.net]
abelvesa has joined #aarch64-laptops
danielt has joined #aarch64-laptops
alexeymin has joined #aarch64-laptops
Sobek[m] has joined #aarch64-laptops
Dylanger has joined #aarch64-laptops
xypron has joined #aarch64-laptops
go4godvin has joined #aarch64-laptops
szclsya[m] has joined #aarch64-laptops
davidebeatrici[m] has joined #aarch64-laptops
qzed has joined #aarch64-laptops
mahmoudajawad[m] has joined #aarch64-laptops
ajhalaney[m] has joined #aarch64-laptops
fevv8[m] has joined #aarch64-laptops
jonasbits has joined #aarch64-laptops
harvests[m] has joined #aarch64-laptops
HdkR has joined #aarch64-laptops
travmurav[m] has joined #aarch64-laptops
calebccff has joined #aarch64-laptops
bluerise has joined #aarch64-laptops
jelly has joined #aarch64-laptops
djakov has joined #aarch64-laptops
alpernebbi has joined #aarch64-laptops
minecrell has joined #aarch64-laptops
tomeu has joined #aarch64-laptops
Esmil has joined #aarch64-laptops
EricCurtin[m] has joined #aarch64-laptops
flokli has joined #aarch64-laptops
xroumegue has joined #aarch64-laptops
pbsds0 has joined #aarch64-laptops
juergh has joined #aarch64-laptops
malvi[m]1 has joined #aarch64-laptops
Lucy[m] has joined #aarch64-laptops
selmer443[m] has joined #aarch64-laptops
jenneron[m] has joined #aarch64-laptops
Prawn[m] has joined #aarch64-laptops
NomadNaomie[m] has joined #aarch64-laptops
luxio_39[m] has joined #aarch64-laptops
ungeskriptet[m] has joined #aarch64-laptops
shoragan has joined #aarch64-laptops
harvestz[m] has joined #aarch64-laptops
Leandro[m] has joined #aarch64-laptops
cmeerw[m] has joined #aarch64-laptops
quinine has joined #aarch64-laptops
SSJ_GZ has joined #aarch64-laptops
wiizzard has joined #aarch64-laptops
Manis[m] has joined #aarch64-laptops
frytaped has joined #aarch64-laptops
mothenjoyer69 has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
janrinze has joined #aarch64-laptops
maz has joined #aarch64-laptops
robertmader[m] has joined #aarch64-laptops
AlexMarty[m] has joined #aarch64-laptops
steevdave[m] has joined #aarch64-laptops
kbingham has joined #aarch64-laptops
macc24 has joined #aarch64-laptops
JoshuaAshton has joined #aarch64-laptops
xnox has joined #aarch64-laptops
agraf has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
suihkulokki has joined #aarch64-laptops
martijnbraam1 has joined #aarch64-laptops
javierm has joined #aarch64-laptops
clover[m] has joined #aarch64-laptops
Libre___ has joined #aarch64-laptops
Caterpillar has joined #aarch64-laptops
akaWolf0 has joined #aarch64-laptops
kettenis has joined #aarch64-laptops
Cyrinux has joined #aarch64-laptops
wiizzard has quit [Ping timeout: 481 seconds]
Leandro[m] has quit [Ping timeout: 481 seconds]
Lucy[m] has quit [Ping timeout: 481 seconds]
AlexMarty[m] has quit [Ping timeout: 483 seconds]
ungeskriptet[m] has quit [Ping timeout: 480 seconds]
harvestz[m] has quit [Ping timeout: 480 seconds]
luxio_39[m] has quit [Ping timeout: 480 seconds]
mothenjoyer69 has quit [Ping timeout: 480 seconds]
fevv8[m] has quit [Ping timeout: 480 seconds]
travmurav[m] has quit [Ping timeout: 480 seconds]
Prawn[m] has quit [Ping timeout: 480 seconds]
go4godvin has quit [Ping timeout: 480 seconds]
EricCurtin[m] has quit [Ping timeout: 480 seconds]
selmer443[m] has quit [Ping timeout: 480 seconds]
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)
<akaWolf0> need do add x13s to the topic? :)
<Caterpillar> :-)
AlexMarty[m] has joined #aarch64-laptops
<bamse> jhovold: i didn't use your branch, i booted linux-next...
<bamse> jhovold: and this was reproduced with really old firmware
SSJ_GZ has quit [Ping timeout: 480 seconds]