robclark changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Chrome OS Trogdor Devices - Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630 - Lenovo ThinkPad X13s - and various other snapdragon laptops) - https://oftc.irclog.whitequark.org/aarch64-laptops
baozich has joined #aarch64-laptops
baozich has quit [Remote host closed the connection]
rz has quit [Remote host closed the connection]
jgowdy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rz has joined #aarch64-laptops
Lucanis has quit [Ping timeout: 480 seconds]
jgowdy has joined #aarch64-laptops
<dgilmore>
looking at jhovold's git repo, the commit with -------------------- linux-next -------------------- does that indicate that everything before is lined up for linux-next? and everything after is in progress work?
rz has quit [Remote host closed the connection]
rz has joined #aarch64-laptops
ellyq_ has joined #aarch64-laptops
ellyq has quit [Ping timeout: 480 seconds]
ellyq_ has quit []
ellyq has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
Lucanis has joined #aarch64-laptops
<steev>
i believe so
altacus has joined #aarch64-laptops
altacus_ has quit [Ping timeout: 480 seconds]
jhugo_ has joined #aarch64-laptops
ndec has quit [Ping timeout: 480 seconds]
ndec has joined #aarch64-laptops
jhugo has quit [Ping timeout: 480 seconds]
jglathe_volterra has quit [Remote host closed the connection]
jglathe_volterra has joined #aarch64-laptops
jgowdy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<leezu>
Hi, I noticed v6.8 series stops reporting battery charge information on sc7180. Ie. the information about what percentage of charge the battery has went missing. v6.7.12 still works fine. Will test v6.9-rc2. Please let me know if you're aware of a fix / existing issue report
<leezu>
Or maybe I'm missing a new CONFIG.
<travmurav[m]>
leezu: on a chromebook?
<leezu>
Yes, sc7180 trogdor lazor
<travmurav[m]>
iirc this is handled by the EC on those
<leezu>
So on 6.8, dmesg lists the following error:
<leezu>
[ 0.762752] sbs-battery 12-000b: error -EINVAL: Failed to register power supply
<leezu>
[ 0.769468] sbs-battery: probe of 12-000b failed with error -22
<leezu>
Whereas, on 6.7, [ 0.642097] sbs-battery 12-000b: sbs-battery: battery gas gauge device registered
<leezu>
[ 0.674969] sbs-battery 12-000b: I2C adapter does not support I2C_FUNC_SMBUS_READ_BLOCK_DATA.
<cenunix[m]>
here would be the neater output without the 3000 [ffmpeg/video] lines being repeated
<robclark>
travmurav[m]: still no dice on slbounce+x13s .. here is my startup.nsh, maybe I'm not operating dtbhack properly? I assume I need to first load the symbols then the "main" dtbo...
<robclark>
it doesn't get far enough to load fbcon so not sure exactly where it dies, but it eventually resets
<travmurav[m]>
robclark: yeah this looks correct, I assume it doesn't complain when installing the dtb?
<robclark>
it doesn't seem to.. and earlycon=efi says it is taking dtb from config table
<travmurav[m]>
very weird...
<travmurav[m]>
is earlycon=efifb keep_bootcon not enough to see where it dies?
<robclark>
lets try keep_bootcon
<robclark>
brb
<travmurav[m]>
inb4 in cmd-db
<robclark>
well, / vs \ confusion in dtbhack cmdline.. but fixing that didn't get further
<travmurav[m]>
ugh
<travmurav[m]>
robclark: I guess it's in linux-mode with the dtb in the right place?
<robclark>
IIRC it is in linux mode.. but for "normal" boots I use dtb= on kernel cmdline
<travmurav[m]>
robclark: could you confirm that if you run dtbhack by hand (or maybe add a pause in the startup script?) that it says "The DTB configuration table was installed!"
<travmurav[m]>
just to confirm it doesn't bail out after failing something and leaving the old config table from the firmware
<robclark>
yeah, last boot I commented out the last line, which is how I realized the \ issue.. when I fixed that it did say something to the effect of "The DTB configuration table was installed"
<travmurav[m]>
yeah so it loaded the new dtb correctly at least, and didn't fail when applying the overlays
<robclark>
last line (or maybe 2nd to last) is the "exit boot services" bit.. I don't see anything after that
<robclark>
nope.. didn't see anything more after the EBS msg from efi stub
<travmurav[m]>
very weird
<travmurav[m]>
hm
<travmurav[m]>
have you tried running sltest.efi?
<travmurav[m]>
should see a green line on top of the screen
<travmurav[m]>
sltest.efi tcblaunch.exe
<robclark>
yeah, sltest works
<robclark>
so pretty sure slbounce itself is working
<travmurav[m]>
interesting...
<travmurav[m]>
but linux never prints anything with earlycon=efifb...
<robclark>
nope.. any extra cmdline to get it to be more verbose?
* travmurav[m]
is puzzled
<travmurav[m]>
I think linux should be happy printing all the dmesg right after the ebs message
<travmurav[m]>
so if it doesn't then it sounds very sad, especially given slbounce runs exactly inside ebs
<travmurav[m]>
so the fact that there is no earlycon at all, worries me a bit
<robclark>
hmm
<travmurav[m]>
can you sanity-check if it prints stuff when you don't load slbounce but only dtbhack? the kernel should crash but that would be a fun datapoint I guess
<robclark>
well, let me re-test sltest.. when I had tried it, it was from earlier build of slbounc
<travmurav[m]>
it definitely should print on the screen
<robclark>
ok, I can try that too
<travmurav[m]>
robclark: any chance you've updated the firmware in the meanwhile? maybe they broke it? xD
<robclark>
it was a while back when I sltest'd.. but I think I updated fw beforehand.. I've not installed any recent fw update
<travmurav[m]>
right
<robclark>
ok, without loading slbounce I do get msgs after EBS, so confirms something going sideways at EBS.. but I do still get the green line with sltest
<travmurav[m]>
weird
<travmurav[m]>
but yeah I guess I'd blame the switch to el2 sadly
todi has joined #aarch64-laptops
<travmurav[m]>
though not exactly sure where in/after the switch would it die
<travmurav[m]>
probably after if sltest works
<travmurav[m]>
I'm "trying my best" reloading the EL1 cpu state into EL2 after taking over but it's very possible that I initialize some cpu registers wrong and it somehow goes sideways in an UB way
<robclark>
oh, hmm, but md5sum of sltest and slbounce don't match that in my build dir.. maybe I only copied over the new dtbhack.efi.. (but I think that was all that changed?)
<travmurav[m]>
so it works for me, for some other people but not for you(???)
<travmurav[m]>
I didn't do many changes to slbounce I think but it might be worth trying the new one if you have a very old one
<travmurav[m]>
the changes since the last tag/prebuilts should only be in dtbhack though so if you have v3 then it's a bit sad that it dies
hexdump01 has quit []
<robclark>
oh, replacing slbounce.efi and it gets further.. it eventually dies, but this gives me something to poke around with
hexdump0815 has joined #aarch64-laptops
<travmurav[m]>
\o/
<travmurav[m]>
does it panic visibly on the screen?
<travmurav[m]>
and is it cmd-db xD
<robclark>
I don't see a panic before it goes black screen.. when it reboots I'll check journal, maybe it got far enough to log something
<travmurav[m]>
hm I guess cmd-db would be early enough
<travmurav[m]>
and no one on 8c3 complained about it
<robclark>
ok.. I can grab that patch and see if I get further
<travmurav[m]>
robclark: crash with that happens very early fwiw
<travmurav[m]>
would be visible in earlycon efifb I htink
<travmurav[m]>
at least it was for me always
<travmurav[m]>
but probably worth having anyway, yeah
<robclark>
it does seem to get far enough to find sda... last thing I see before screen goes black is something about sync_state
<travmurav[m]>
hm
<robclark>
(that is with the cmd-db patch)
<travmurav[m]>
sounds similar to the crash we had due to iommu...
<travmurav[m]>
what kernel is this?
<robclark>
anyways I can continue poking around and trying to figure out where it dies
<robclark>
jhovold's 6.9-rc2 with my random WIP on top
<robclark>
(and now the cmd-db patch)
<travmurav[m]>
hm this should have the iommu, I wonder if there is some kernel config for smmuv3
<robclark>
let me double check
<travmurav[m]>
the problem was that linux couldn't have two different iommu drivers at the same time iirc, which was (started to be?) fixed since 6.8
<travmurav[m]>
and iirc there are still few places (even in msm?) where it gets upset with two iommus
<travmurav[m]>
jglathe_volterra spent a while poking at it
<robclark>
I do have v3 enabled
<robclark>
hmm
<travmurav[m]>
something about bus_ops iirc
<robclark>
hmm.. fbcon is loading, but it could be getting about to the point where it tries to bring up the gpu and setup the private smmu<->msm interface
<jglathe_volterra>
travmurav[m], robclark: I get only this: Apr 06 20:45:10 sdbox2 kernel: fb0: Framebuffer is not in virtual address space.
<jglathe_volterra>
Comes up regardless, though
<jglathe_volterra>
6.8.2
<cenunix[m]>
did venus firmware get any updates or anything special I have to do besides using 6.9-rc2 and have the firmware?
jglathe_ has joined #aarch64-laptops
jhovold has quit [Ping timeout: 480 seconds]
jglathe_sdbox2 has quit [Ping timeout: 480 seconds]
ellyq has quit []
<steev>
jenneron[m]: you can, or you can send it to the ML and I can reply there with it, if preferred
ellyq has joined #aarch64-laptops
<robclark>
travmurav[m]: one of the things I notice booting with slbounce, is `sync_state() pending due to 1c20000.pcie` which I don't see with "normal" EL1 boot.. seems like there is at least one other pci1c10000.pcie which is ok.. not sure why one of them wouldn't probe.. seems like the one that does probe is 0004:00:00.0 (which is _not_ the one with nvme.. ). I noticed the msgs about sda is actually about my usb-c thumb drive
<robclark>
which I'm using for esp, so I guess the issue is rootfs not found. Although not sure why probe-defer dependencies would be different with el2 boot. Or what is different on volterra (maybe nvme hooked up to different pcie?)
<steev>
robclark: the other one is the wwan maybe?
<robclark>
wwan is 0006:00:00.0 (no idea if that one probed.. or if the id's are stable).. lspci says:
<robclark>
probably need some modules that load from disk rather than initrd.. but not sure what about this would be different btwn slbounce boot vs "normal" boot.. other than the injected dependency on smmu-v3
<robclark>
(which.. things scroll too fast to tell if it has probed.. so that could be an issue?)
<robclark>
hmm, pcie@1c10000 does use smmu-v3 .. which hints that it probed
<jglathe_volterra>
0002:01:00:0 is always the port for nvme
<jglathe_volterra>
also on x13s
<jglathe_volterra>
0004 is pcie3, which is WWAN
<robclark>
hmm, it could be as dumb as modules missing from initrd.. but not really sure _what_
<robclark>
I guess if I knew why some pcie probe but others don't, I'd know what the issue is
<jglathe_volterra>
doesn't exist on Volterra (or something), so if the iommu-map is wrong there , I would only find out if I boot with EL2 on X13s (which I haven't done yet)
<robclark>
hmm, status="disabled"??
<robclark>
oh, overridden in sc8280xp-lenovo-thinkpad-x13s.dts
<jglathe_volterra>
yep
<jglathe_volterra>
but the iommu-map may be wrong (for whatever reason
<robclark>
hmm, is that configured by fw?
* robclark
really wishes x13s had console-ramoops like chromebooks
<robclark>
I guess I could hack up something with rootfs on usb-c so I could boot to console to see full dmesg.. ugg..
<jglathe_volterra>
no, its in sc8280xp.dtsi, 0x40000 for pcie3a, 0x50000 for pcie3b
<jglathe_volterra>
since ath11k_pci is on pcie4, 0x60000 there seems to be working nicely... or something
<jglathe_volterra>
its working here. I guess I will need to boot EL2 on the X13s to find out more
altacus has joined #aarch64-laptops
altacus_ has quit [Ping timeout: 480 seconds]
altacus_ has joined #aarch64-laptops
altacus has quit [Ping timeout: 480 seconds]
<wiley[m]>
any point to something like power-profiles-daemon on the x13s and/or is there anything that should be tuned for better battery life?
paddymahoney has quit [Remote host closed the connection]