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)
derzahl has joined #aarch64-laptops
derzahl has quit [Ping timeout: 480 seconds]
derzahl has joined #aarch64-laptops
echanude has joined #aarch64-laptops
echanude has quit [Ping timeout: 480 seconds]
derzahl has quit [Ping timeout: 480 seconds]
Mathew has joined #aarch64-laptops
root has joined #aarch64-laptops
root is now known as Guest2192
<Guest2192>
I was able to order x13s from USA
Guest2192 is now known as akaWolf0
mcbridematt has quit [Ping timeout: 480 seconds]
mcbridematt has joined #aarch64-laptops
Mathew has quit [Ping timeout: 480 seconds]
<steev>
nice
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
rfs613 has quit [Ping timeout: 480 seconds]
<jhovold>
steev: that's good that you were able to confirm that it was indeed the nvme
<steev>
yeah... that's something :)
<jhovold>
steev: did I understands you correctly, that you have never gotten linux-next to boot on your machine?
<steev>
but i have only been able to get it to do that twice....
<steev>
not since like... before thanksgiving in the US
<steev>
so nov in the 20s
<steev>
actaully, i'm not sure now
<jhovold>
perhaps something has changed in the nvme subsystem which only affects your controller
<steev>
i know not in a long time
<jhovold>
which controller do you have?
<steev>
that's possible
<steev>
uhh
<steev>
am630
<steev>
0002:01:00.0 Non-Volatile memory controller: Shenzhen Unionmemory Information System Ltd. AM630 PCIe 4.0 x4 NVMe SSD Controller (rev 03)
<jhovold>
so that's different from the one I have:
<jhovold>
there's 90 commits to drivers/nvme since 6.1, I'll take a closer look
<steev>
derp, i didn't even think to look through those
<steev>
that said... i'm to bed
<jhovold>
sleep well!
<steev>
clover[m]: ^^ (might wanna add the 2 different controllers listed to the wiki - perhaps check what you have as well) - init you might want to check yours?
<steev>
jhovold: also my frustrations above were... rebooting and using the exact same commands... well it would just immediate punt to black, despite getting that one boot where i got the pic
<jhovold>
steev: not sure what happened there, could it be that the msm drm driver was included in the initramfs as a module?
<jhovold>
steev: doesn't exactly explain why it would only mess up the fb ocassionally, but still...
<jhovold>
steev: if you can just prevent the display from turning off, you could try sprinkling some printks in nvme_probe() and see how far it gets
<jhovold>
you saw the "pci function" message and never got the "allocated %lld MiB host memory buffer.\n" in nvme_setup_host_mem()
iivanov has joined #aarch64-laptops
Caterpillar has joined #aarch64-laptops
<Caterpillar>
I have been away 10 days. Any updates concerning the X13s?
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
SSJ_GZ has joined #aarch64-laptops
<juergh>
steev, not sure if it's related but I had display blanking issues as well. turns out I had to set REGULATOR_GPIO=y but I still get the occasional blank at boot so something seems racy.
<init>
jhovold: steev: I built numerous configs and did a lot of try in the past 24h and I experience the same exact problem as steev, with the same nvme controller. I'm pretty sure it's related to that because my setup has dm-crypt and I get some relief before the screen goes blank, mapper fails to find any volume.
<init>
we might have found the difference between BY and BX
init-x13s has quit [Remote host closed the connection]
janrinze has quit [Ping timeout: 480 seconds]
janrinze has joined #aarch64-laptops
<jhovold>
init: ok, thanks. I've had time to look much at the nvme changes yet, but I'll try to do so
<jhovold>
*haven't had
init2 has joined #aarch64-laptops
<jhovold>
init: we really should figure out why your display goes even after making sure regulator core doesn't turn the supplies off, but do have a setup were you can run some quick test? How many seconds do you have before the screen goes blank?
<jhovold>
init: there isn't anything in particular that stands out from a quick look at the nvme changes. We should try to confirm if the it is the first admin command that times out. The default timeout is 60 seconds so I guess your screen goes off before you see any error message. The timeout can be lowered temporarily, though.
<init2>
depending on your availability, (it's 8h48 am here), ill be available from 9h30 to 11h30 for any test you want me to run or try
rfs613 has joined #aarch64-laptops
<init2>
the display turning black is quite precise and repeatable
<init2>
always at the same moment.
<jhovold>
init2: sounds good. How many seconds do you get roughly?
<ajhalaney[m]>
Can I get a recap on the "how to prevent the screen from blanking in general on boot failures bit?" I've experienced similar in the past and would like to know how to further debug. Usually I'm dead in the water with a backlit black screen (I think that's what's being discussed between steev/init/jhovold above)
<init2>
i'm tempted to build a arch bootable key without nvme and try it.
<init2>
jhovold: as soon as i can try i'll start a little timer from uefi to blank screen and report back
<init2>
~15-20 minutes from now
<jhovold>
init2: sure, no stress. just figured you maybe remembered if it was 30 seconds or 5.
<jhovold>
ajhalaney[m]: you can hack regulator core to stop disabling seemingly unused regulators and possibly also make sure the DRM isn't being loaded in case that messes up the framebuffer
<jhovold>
ajhalaney[m]: alternatively, you should be able to make sure all display deps are in the initramfs, but that doesn't seem to work currently. possibly due to the missing GPU, haven't had time to investigate
rfs613 has quit [Quit: restart]
rfs613 has joined #aarch64-laptops
<ajhalaney[m]>
cool. ive got a few meetings today so ill try your branch as well if i dont have to participate much. I too have the nvme device steev has and have seen similar problems trying to run trees
<jhovold>
sounds good, I'll post a new next branch in a bit
<init2>
let's all go back to IDE...
<jhovold>
steev: init2: I'm pretty sure your display turns off because the MSM DRM driver is being probed. Confirmed that it has that effect here.
<init2>
jhovold: what should I do first then, rebuild without DRM MSM?
<jhovold>
init2: heh, yeah, that should work fine! Then you need to patch regulator core (or mark regulators always-on) and you should be good
<init2>
ok ill do that now and report back.
init2 has quit [Remote host closed the connection]
echanude has joined #aarch64-laptops
<init>
i'm having repeatable progress
<jhovold>
init: seeing any nvme command timeout?
<init>
I'll try to report as clearly as I can.
<init>
1- As expected. the screen timeout is exactly 30s every single time. 2- Adding the suggested always-on directive to the 4 regulators and rebuildint the dtb / re-copying it to boot does not stop this behaviour. I don't know the way to validate that my changes are taken in account, but if I make Image dtbs only the dtb gets compiled, so it does not seems theres a problem with that. 3- I've noticed that on my working 6.1-rc7, if
<init>
don't enter my dm-crypt password and let it hang on the prompt, I get the exact same behavior, the screen ends up going black forever. If I do enter my password, the boot sequence continues and the blackening problem does not happen during that session again. 4- It's unclear if opting our msm drm has any effect on the whole problem. 5- with the next build, my boot sequence hangs at /dev/mapper waiting for an nvme device to app
<init>
ar, until I hit 30s then the screen goes black. So I would conclude that, there's no new "problem" with drm/screen blackening that wasn't there before, it was just hard to see as the boot process didn't hang before the magic hapenned. Now that we have this suposedly nvme hang, we all get a behavior that seems new, but likely existed before.
<jhovold>
init: still seems you have regulator turning off, i'd patch regulator core for that
<jhovold>
init: I took a closer look at the MSM DRM driver mess, and it can be summarised as depedency hell. For example, due to te enabled DP alt mode support you need the USB phys in initramfs, etc. But there's still circular dependency that prevents it from being usable in initramfs. Disabling that mess of a driver is the way to go for now.
<jhovold>
init: i'll prepare custom config that can be used for this, gimme a few minutes to prepare a new branch
<init>
just to be clear, no matter if I build the kernel with MSM DRM or not, or no matter if i'm on 6.1-rc7 or -next. if I let the dm-crypt prompt hang, or if nvme does not get detected, I get the exact same black screen at the exact same time.
<init>
this patch you're working on will allow us to see the nvme problems
<init>
which is great
<init>
am I right?
<jhovold>
init: yes, I hope so. I'll try to prevent the display from turning off, but I'll also lower the nvme command timout so thaht it would fire before your screen goes black if that's the issue
<init>
amazing
<init>
sorry if I sound like an imbecile, but when I debug thing I like to exclude as many variable as possible.
<init>
keeps my sanity
<jhovold>
sounds like the right approach
<jhovold>
init: steev: I've pushed two new branches based on next-20221215
<jhovold>
The broken thermal patches have been removed from linux-next and I've fixed a deadlock issue regulator core
<jhovold>
The debug branch has a few instrumentation patches which should allow you to have a working display in the rescue shell
<jhovold>
It also lowers the nvme admin command timeout so that you don't have to wait a whole minute if that what's happening with your controller
<jhovold>
Just checkout the debug branch and run make johan_defconfig
<steev>
will give it a whirl as soon as i have a chance, but init might get to it first :)
<malvi[m]1>
How is the Snapdragon 7c HP X2?
<malvi[m]1>
Are there any ongoing projects (?) on it right now? Was getting it for ~360$ hence
<malvi[m]1>
I know this might not be the right place to ask, I apologize in advance
<gwolf>
malvi[m]1: Sounds like the right place :-)
<gwolf>
I understand the Snapdragon 7xx are strictly less than the 8xx -- And given I've often seen prices for (used) laptops with the Snapdragon 855 (i.e. the iC630) around US$300, I think $360 for the HP might be a *bit* expensive
<gwolf>
But then again, I have no idea as to the rest of the hardware this computer has!
<danielt>
HP X2 is well supported upstream (and it can boot from its internal SD card slot so you can easily dual boot it too)
<malvi[m]1>
I think it originally retailed for 599, it's this tablet - HP x2 11 Detachable Keyboard and Wireless Wi-Fi, Bluetooth Rechargeable USI Certified Pen, 11-inch Tablet PC (Silver , 8GB LPDDR4x-2133 SDRAM/128 GB eMMC, Chrome OS/4G LTE/B&O Audio/FPR) 11-da0017QU https://amzn.eu/d/1v6usyy
<gwolf>
I don't know if there are many models of this machine, but https://support.hp.com/vn-en/document/c05997501 says it's a Snapdragon 835... the only down point I see is that it has 4GB RAM, a bit low
<gwolf>
for me at least
<malvi[m]1>
gwolf: I wish I could get a secondhand one of these, India doesn't have good enough secondhand marketplaces
<gwolf>
malvi[m]1: I understand your pain point, I'm in Mexico and we are in a similar situation
<malvi[m]1>
Very fun times these are
<gwolf>
But the specs for the machine you present looks quite decent!
<malvi[m]1>
Customs took away a few devices I was receiving from an OEM to work on them, AOSP ports
<init>
building wip/sc8280xp-next-20221215-debug with make johan_defconfig
<danielt>
IIRC in terms of computer performance HP X2 and Yoga C630 are pretty close.
<malvi[m]1>
Imports aren't fun
<malvi[m]1>
gwolf: Is it worth the price though? I might actually use it as a daily device for a while, since I'm at university, and I personally think with the keyboard and the stylus it is a pretty good deal i guess
<gwolf>
I am very happy with my C630, it did become my main laptop.
<malvi[m]1>
That is pretty nice!
<gwolf>
But depends on the use case -- it is (as expected) on the slow side when you do CPU-intensive stuff (i.e. compiling, video editing...)
<malvi[m]1>
Not really, never really worked on a Chromebook so it'll mostly be light document editing and note taking at best
<malvi[m]1>
And YouTube and a few PDFs at best
<gwolf>
well, make it into a real Linux machine 😉
<gwolf>
I've never used ChromeOS
<malvi[m]1>
gwolf: Okay!
<malvi[m]1>
gwolf: That's what I want to try out
<danielt>
How much do you "want to try it out"! AFAIK HP X2 is almost unique for being, Arm *and* great upstream support *and* having an internal SD card slot. That means its fun to hack on *and* you can play Android games whilst watching TV.
<danielt>
If you don't care about the SD card slot then Lenovo Duet 5 is interesting (and sometimes cheaper than HP X2) but to play with alternative OS you have to boot from a USB dongle so you don't get to "feel" the tablet form factor properly when running the alternative OS.
<javierm>
danielt: also the HP X2 is the only qcom based machine that allows Linux to run on EL2, so can support KVM
<javierm>
which I think is a huge advatange over others like the X13s
<danielt>
javierm: Just HP X2... I thought all the recent QCom/Chromebooks had access to EL2.
<danielt>
javierm: I was very annoyed that X13s boots in EL1 (esp. given Windows Hyper-V works OK on the platform).
<danielt>
javierm: No EL2 is the think I hate most about my X13s :-(
<malvi[m]1>
<danielt> "How much do you "want to try..." <- That sounds amazing
<malvi[m]1>
<danielt> "If you don't care about the SD..." <- That isn't available in India I think
<danielt>
You can't do both at the same time... but with an internal SD card slot dual booting is non-destructive.
<javierm>
danielt: right, I meant the HP X2 in particular over other non-Chromebook machines
<malvi[m]1>
Thank you so much for your inputs gwolf danielt :D
<malvi[m]1>
javierm you too :3
<gwolf>
danielt: Right, dual-booting is non-destructive. However, if you want to make Linux your primary OS, you will want to host it on a decent-throughput storage. SD cards are notoriously slow (and unreliable, but that's a different point)
<danielt>
gwolf: I found performance with a modern A2 card is pretty good... but, yes, its is definitely not as fast as the internal storage.
<danielt>
To be honest the only performance testing I did was a kernel compile (where SD+7cx on HP X2 was enough to score a draw with eMMC+SD850 on Yoga C630)
* danielt
goes to double check Yoga 630 specs... maybe wrong about eMMC
<steev>
The yoga c630 (NOT the Chromebook version) does not use eMMC, but ufs
<steev>
jhovold: however it's just kinda sitting... there now
<danielt>
Thanks... in that case SD+7cx and UFS+SD850 ended up pretty much the same kernel compile times... and what else should we care about ;-)
<init>
bootin..
<jhovold>
steev: finally! :)
<init>
screen does not turn black, but I have 3 curious messages
<jhovold>
steev: do get a console?
<jhovold>
as in rescue shell?
<steev>
jhovold: no, it's literally sitting there where i'm at now
<init>
don't mind the crypto error, I added back dm-* modules. it's just because it does not find any nvme drive.
<steev>
mine finds the device here, using the debug config but it still gets stuck
<malvi[m]1>
<danielt> "Thanks... in that case SD+7cx..." <- so finally what would you suggest? if I just wanted to use it as a tablet, lugging around, taking notes and such - it should be a good pick, shouldn't it? O.o
<steev>
with just adding "verbose boot_delay=10000" to the defaults of "root=UUID=<uuid> {pd,clk}_ignore_unused it does attempt to boot, but then the lack of various other things system expects...
<jhovold>
steev: init: so steev's nvme appears to be probed correctly but something still hangs, while init doesn't seem to have probed pcie at all. Most odd...
<jhovold>
init: do you have pcie-qcom and deps in your initramfs?
<steev>
does appear so
<steev>
seems kinda odd that network time sync would have an unlimited timeout. systemd is weird
<jhovold>
i have the follwing explicitly added to my initramfs: phy_qcom_edp leds_qcom_lpg pwm_bl i2c_hid_of i2c_qcom_geni nvme phy_qcom_qmp_pcie pcie_qcom
<jhovold>
then maybe mkinitcpio pulls in some more
<jhovold>
init: can you double check that you did not forget the nvme module?
<init>
i literally copy pasted the line you put on irc
<init>
yeah its there
<jhovold>
init: try adding nvme_core as well if for some reason that isn't pulled in
<jhovold>
init: i trimmed my config pretty heavily to keep build times down and disabled the device mapper so won't be able to use that config in your setup without first enabling it.
<jhovold>
steev: init: perhaps the could be other deps like that which your systems rely on. I'm running a pretty lean setup here.
<steev>
well, there's an easy way to test that too
<init>
im running a minimal arch linux install. for the sake of eliminating all obscure behavior
<init>
except for dm-crypt
<init>
because im an idiot
<init>
hahaha
<jhovold>
init: arch here too, but i skipped dm
<init>
because you are a clever man
<steev>
once we have proper wifi and audio, i plan to encrypt my rootfs, but for now, it's still too early
<init>
i like being forced to unlock my stuff everytime something fails.
<jhovold>
heh
<init>
looks like usb a600000.usb stays pending. or i don't know what it means
<init>
damn I have to go. will be out for the next 24h.
<init>
ill read the backlog
<init>
thanks again for the work on that
<jhovold>
init: yeah, the combo phy isn't in the initramfs
<jhovold>
maybe something more
<steev>
kicking off another build here to test something, but i need to run for about an hour as well, i'll be back
<jhovold>
init: np
echanude has quit [Quit: WeeChat 3.6]
hexdump01 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #aarch64-laptops
<hexdump0815>
malvi[m]1: danielt: gwolf: i think all aarch64 chromebooks will give you el2 and allow you to use kvm and nearly all of them have very good mainline support due to google pushing the soc vendors to mainline their code for the chromebooks
<hexdump0815>
besides the qcom 7c there are also nice mt8183 ones just slightly slower and mt8173 and rk3399 ones a bit older, but still quite nice
<hexdump0815>
malvi[m]1: in case the newer image does not work, maybe try the older one as well - i think this is what that x2 user tried and got working
<malvi[m]1>
I still need to purchase the Chromebook xD that's true, the mainline support and all. But what I've seen are reviewers basically trashing the device because it's "not powerful enough"
<malvi[m]1>
I have two choices at this point, either save up for a better laptop, or get myself a tablet to run around with.
<steev>
jhovold: so this is kinda weird - it definitely sees the device, but it still times out finding it... because it's looking for a different uuid?
<bluerise>
are there any interesting current arm chromebooks with a rockchip or qcom?
iivanov has quit [Quit: Leaving...]
<steev>
ah, it's failing on the swap partition for some reason
laine has quit [Read error: Connection reset by peer]
laine has joined #aarch64-laptops
<hexdump0815>
bluerise: rockchip only was rk3399, so a bit older meanwhile, qcom would be 7c gen 1 or 2 and maybe gen 3 around the corner for next year i guess, also good mediatek mt8183 and most interesting mt8195 for its performance and a bit mt8192, but both are still being upstreamed to mainline right now
<hexdump0815>
for mediatek there seems to be mt8186 around the corner for next year which should be at about 7c gen 1 level maybe, so slightly better than mt8183
<steev>
jhovold: interesting... i added zswap settings - will get a diff of the config here shortly, and i can reliably hit the thing we were hitting before
<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)
Evaia6310 has joined #aarch64-laptops
krzk4 has joined #aarch64-laptops
rfs613- has joined #aarch64-laptops
jbowen_ has joined #aarch64-laptops
jbowen has quit [Ping timeout: 480 seconds]
jbowen_ has quit []
jbowen_ has joined #aarch64-laptops
Evaia6310 is now known as Evaia631
rfs613 has quit [resistance.oftc.net larich.oftc.net]
krzk has quit [resistance.oftc.net larich.oftc.net]
Evaia631 has quit [resistance.oftc.net larich.oftc.net]
vkoul has quit [resistance.oftc.net larich.oftc.net]
jbowen_ has quit [resistance.oftc.net larich.oftc.net]
krzk4 is now known as krzk
krzk is now known as Guest2402
krzk has joined #aarch64-laptops
jbowen_ has joined #aarch64-laptops
vkoul has joined #aarch64-laptops
rfs613 has joined #aarch64-laptops
rfs613 has quit [Ping timeout: 492 seconds]
vkoul has quit [Ping timeout: 482 seconds]
krzk has quit [Ping timeout: 482 seconds]
vkoul has joined #aarch64-laptops
SSJ_GZ has quit [Ping timeout: 480 seconds]
<steev>
aha, i realize what it was - if i rootwait, it stops at the previous screen, if i do not, it does the bit where it looks like it's booting but then times out; though, wtf, i commented out the swap line, and systemd is now looking for /dev/nvme0n1p6 (which is what the swap partition was); i'm guessing this is something to do with the suspend/resume and i need to modify the initramfs to tell it no resume
<akaWolf0>
when it will arrive, I guess I can help at least testing something
<steev>
It already has arrived, and works mostly okay, there’s still stuff that isn’t there quite yet (audio, gpu, touchscreen - touchscreen works but you gotta bind it manually/run the command in rc.local
<steev>
Wi-Fi works but it’s a hack, while we wait for proper firmware/driver support for proper firmware
<akaWolf0>
audio/gpu is something big and requires a lot of work?
<ajhalaney[m]>
I get stuck here fairly consistently and have yet to get jhovold config to boot with debug or not steev . Frustrating been chasing my tail all day on it
<ajhalaney[m]>
(hopefully matrix pics stuff shows up to irc as links)
<steev>
it does
<steev>
ajhalaney[m]: you have the am630?
<steev>
nvme controller
<akaWolf0>
steev: what kind of work required in audio/video subsystems?
<steev>
so, audio just requires the dts bits, and ucm2 bits submitted upstream, we have them, but, currently something somewhere isn't correct
<steev>
video... i dunno, maybe just adding dts bits to know about the venus device?
<akaWolf0>
venus is doing what? hw decoder?
<ajhalaney[m]>
steev: yeah i do (had to double check again)
<steev>
yeah, video hw decoder/encoder
<steev>
unless by video you meant gpu, in which case... i'm not sure what's missing, and i need to revisit it again again, but we're dealign with some other weirdness on next currently
<akaWolf0>
steev: can you give me a link to datasheets which you are using
<steev>
i'm not
<steev>
oh, and bluetooth
<akaWolf0>
hm? how is it? :) where is description of registers and so on?
<steev>
acpi tables, and asking people who do have access to the datasheets (which isn't me) - i just cosplay as a kernel dev
<steev>
fwiw, the bluetooth stuff was....
<steev>
15:38:13 <steev> comparing to the c630, pins for pinmux, cts, rts-tx and rx
<steev>
15:39:10 <bamse> that would be gpio121, gpio122, gpio123 and gpio124
<steev>
15:39:20 <bamse> and gpio133 is "bt enable"
<steev>
i haven't attempted to get it going at all though
<akaWolf0>
I should get mine laptop by 8th January
<akaWolf0>
my final goal is to use it as every-day all-purpose laptop
<HdkR>
steev: Only cosplay as a kernel dev, not yet a full kernel dev? :P
<ajhalaney[m]>
steev: jhovold if yall need me to test anything else (eventually ill look at it more on my own but im about fed up for the day lol) lemme know. I've got family I'm hosting thru the weekend but can prolly find some time or if not then next week
<ajhalaney[m]>
steev too modest about his dev status lol
<akaWolf0>
ajhalaney[m]: yeah I guess, but it was regarding his access to datasheets
<akaWolf0>
btw matrix bridge somehow works at IRC server side?
<selmer443[m]>
I’m cosplaying as a kernel tester, don’t feel bad steev
<steev>
no idea, i'm just an irc user, not an op
<akaWolf0>
but how do you make changes to drivers without datasheets?
<akaWolf0>
I guess from ACPI tables you can figure out only device tree
<steev>
poke and prod til you get something that works
<HdkR>
It's a shame since these devices need more people poking and prodding
<steev>
nothing is stopping you, except that pesky FEX work :P
<akaWolf0>
these devices needs open documentation :)
<HdkR>
steev: Nothing is stopping you, except that pesky Kali work :P
<HdkR>
Sadly I abhore low level debugging like this. I get demotivated after a couple hours of poking and then stop working for the entire day ¯\_(ツ)_/¯
<steev>
did you not read my outburst last night? :P
<steev>
i'm not demotivated, just frustrated that multiple boots have different outcomes with no changes
<HdkR>
:D
<HdkR>
Some hardware insanity thrown in for good measure
<bamse>
ajhalaney[m]: what kernel version is that nvme issue?