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>
[ 8.636873] fb0: switching to msm from EFI VGA
<steev>
no deferred devices, remote procs are up :D
<steev>
qzed: some weird messages in my dmesg output, it claims it can't load the a680 firmware (i copied yours into place) - and it also says it couldn't power up the gpu but i have the rendering nodes and such, and i'm in sway so... somehow it's running?
<steev>
oddly, it's -13 which is access denied?
<steev>
qzed: also appears that i do have more usb devices now -previously it was 4 now i have 6
<steev>
bamse: so with 5.19.0-rc4 and that patch and so forth, there's still the weird cursor lag when e.g. downloading but it's nowhere near what it used to be
<bamse>
steev: we need to try to figure out what's causing that slowdown...
<bamse>
time to get some sleep, got even more patches to review & apply tomorrow
<steev>
i pulled in "a few" of qzed's patches re: a680 support, and pulled in his a680 fw too, and it does seem to load it, then the gpu says -13 and then... it works?
<steev>
bamse: for what it's worth, even though CPU0 is stuck at around 30-40%, it IS going through all the states in policy0, it's not stuck at 1.7GHz now
srinik has quit [Killed (NickServ (Too many failed password attempts.))]
srinik has joined #aarch64-laptops
systwi has joined #aarch64-laptops
djakov_ has quit [Remote host closed the connection]
djakov has joined #aarch64-laptops
<bamse>
steev: that's good
leezu_ is now known as leezu
<leezu>
I'm able to connect the problematic Lazor to other APs, such as a hotspot by my phone.
<leezu>
Interestingly the touchpad stopped working / is disabled (?) on that second Lazor which does not have issues with the AP. Please also let me know if you have ideas how to debug that. Both devices run kernel 5.17.15
falk689 has joined #aarch64-laptops
<steev>
leezu: they have the same sku?
<robclark>
macc24: why is "GPU reclocking == ?" for duet5? It should work for all the qc chromebooks
<robclark>
same with kvm
<robclark>
(I'd expect external display to also work.. but don't have a good way to test that atm)
<steev>
i don't have a good way to test external display either :( aside from maybe plugging in the apple dongle that has an hdmi output on it, but does that count?
<leezu>
steev: Both are "Machine model: Google Lazor (rev3 - 8)" with Acer's Model Number N20Q4. Is that what you mean with SKU, or where can I find it?
<steev>
yeah, that's what i had in mind - alas, i don't have a lazor so i can't be super helpful. and lenovo still hasn't even shipped my x13s
<steev>
bamse: the flex5g does seem to just "die" on me here - not sure if it's trying to suspend and just doesn't wake up, or what, but can't ping it, and while the power is on the display doesn't wake up, and unfortunately `sudo journalctl -b -1` doesn't show any sort of errors that would have caused it
<steev>
the backlight is *not* on, sorry, i thought it was but that's just bad angles of the sun/window reflecting just so
<robclark>
leezu: iirc the sku is printed on the label on the back.. but if depthcharge is picking the same dtb for both that should be fine (I'm assuming you are using the normal approach to building boot img which packs all the dtb's and lets depthcharge pick.. appended dtb or only packing a single dtb could result in using the incorrect dtb for the device)
<macc24>
robclark: wh-
<macc24>
why were you looking at cadmium ,_,
<robclark>
someone was asking about installing linux on a lazor ;-)
<robclark>
and I was being helpful
<macc24>
and it's because no one bothered to update it
<macc24>
i'm planning on updating it so soc-specific and device-specific parts are separated
<robclark>
makes sense
<macc24>
leezu: can you share depthcharge log from both problematic and 'normal' lazors?
<macc24>
it's in path that looks something like /sys/firmware/coreboot/log
<robclark>
so, I have some vague memories from the early days of lazor bringup.. that there was a trackpad fw update to fix an issue with EM interference with wifi antennas (?).. but AFAIU if you've booted CrOS at least once on the device it should have installed the fw update. (And that might have only been applicable for early revisions of the device)
<leezu>
macc24: /sys/firmware/log?
<macc24>
leezu: maybe, i don't remember
<leezu>
This wifi issue just started. I was able to connect to the AP from both lazors previously..
<macc24>
robclark: oh and about external display, a pinephone dock dongle thingy refused to work for me on lazor
<leezu>
I did notice that ChromeOS would also fail to connect to the AP, but that's on yet another lazor
<steev>
robclark: so, interestingly, without your patch, i don't *reliably* get video output, but with your patch, i get the -13 error but video comes up reliably?
<leezu>
But on the second the touchpad stopped working
<leezu>
robclark: I'm only including sc7180-trogdor-lazor-r3.dtb
<macc24>
they're running bit different versions of qtiseclib, whatever that is,
<leezu>
robclark: is the firmware update you are referring to reflected by the firmware number in the depthcharge log? The devices run different firmware: Firmware version: B2-C:0 RO_B:0.0.11/4d655eab RW_B:0.5.100/cr50_v2.94_mp.51-e4a2d932d7 and B2-C:0 RO_B:0.0.11/4d655eab RW_A:0.5.93/cr50_v2.94_mp.40-77ed078988
vsp has joined #aarch64-laptops
<robclark>
IIRC the tp fw isn't part of coreboot.. it is something kernel or userspace downloads to tp
<steev>
robclark: i lied... with your patch i don't either... i dunno what is going on, today it's not wanting to give me video, this is vweird
<robclark>
but could be that depthcharge fw matters
<robclark>
steev: idk.. one thing I noticed from your dmesg is that you are using the _ignore_unused things.. not sure if that is still recommended, maybe it is still needed on the windows things
<steev>
clk_ignore is, according to bamse, and will be for quite some time
<robclark>
I don't see any stuck clks, etc, so I guess it is fine
<robclark>
the dmesg you posted, looks like things are working anyways
<leezu>
robclark: Do you know from where kernel / userspace takes the firmware? Are they part of linux-firmware
<robclark>
I don't remember.. probably not linux-firmware, iirc it is the sort of thing that requires device specific tuning.. but I wasn't involved in that directly, I just remember the bug go by..
<robclark>
but like I've said, if you've booted CrOS at least once I think you should be good
<robclark>
(and probably production devices were delivered with the correct tp fw already flashed)
<robclark>
the different depthcharge version is more likely difference
<robclark>
if you can boot a CrOS image from usb, I think you can update depthcharge fw with: /usr/sbin/chromeos-firmwareupdate -m recovery
<robclark>
macc24: ^^ could also be relevant to you if you have old fw.. somewhere along the way there were some TCPC fw updates for external display issues
<leezu>
Is it possible to boot the CrOS recovery image from USB and not recover the system but rather get a live session?
<robclark>
hmm, I don't *think* so.. but the recovery process will afaiu give you the fw updates.. maybe dianders knows if there is an easier way to update fw from linux.. I guess in theory it should be possible to build your own depthcharge but not sure how to flash it from linux distro
<macc24>
robclark: thanks!
<macc24>
leezu: chroot?
<dianders>
Not that easy to build your own firmware without going the whole hog and un-write-protecting. If RO firmware is google signed I don't think you can do an RW update that's dev signed
<dianders>
...but it wouldn't be hard to get the firmware updater out of a recovery image by just mounting it and grabbing the recovery binary
<leezu>
So it's a static binary?
<dianders>
Last I checked it was a shellball
<leezu>
So if I get a copy of /usr/sbin/chromeos-firmwareupdate it comes with everything needed, including the firmware?
<dianders>
Yeah
<dianders>
I think you run it with "--mode=recovery" maybe? It should have a --help
<dianders>
I think perhaps that won't do an update of your security chip if that matters to you (the security chip also is what provides CCD). That one you'd get from /opt/google/cr50/firmware/ and update it with "gsctool -a ${FIRMWARE}"
<leezu>
./chromeos-firmwareupdate --manifest shows me bios-lazor.ro-13577-388-0.rw-13577-459-0.bin and ec-lazor.ro-2-0-6492.rw-2-0-6519.bin. Where can I see the versions I'm currently running?
<dianders>
If you're booted with chrome OS `crossystem fwid`
<leezu>
I copied the file over from chrome os. But I think ./chromeos-firmwareupdate -V shows the current version
<dianders>
Maybe "grep 13577 /sys/firmware/log" would work?
<leezu>
(Nevermind about -V. It only shows the included versions)
<leezu>
The grep returns: "S - OEM_IMAGE_VERSION_STRING=ChromeOS_13577.459.0"
<dianders>
Not sure how to get EC version. If you have serial console then `version` on the EC console. If you have Chrome OS running then `ectool version` works
<robclark>
dianders: two different lazors, same rev+sku but different fw versions.. one wifi works on, the other touchpad works on
<dianders>
Try a different serial console.
<dianders>
Really, the trackpad? That's pretty odd. And you're sure it's not a HW problem?
<leezu>
There are 3 consoles: 'Cr50 - Shell' which is read-only. 'Cr50 - AP' which is connected to Linux (ttyS0) and 'Cr50 - EC' which provided above output
<dianders>
leezu: odd. Ah, I guess the EC and "Cr50 - Shell" are somehow swapped. I forgot that EC shell is usually read only...
<dianders>
leezu: In any case, I wouldn't expect AP or EC BIOS to affect the trackpad. Seems super weird to me that it would be broken. No messages in the log relating to this?
<leezu>
Re problem: I currently have 3 lazors. One with ChromeOS and 2 that essentially run the same Debian (copied via dd). On one of the Debian lazors, I can no longer connect to my AP and see "chan info: invalid frequency 0 (idx 41 out of bounds)" in dmesg. It worked before and it still works on the other Debian lazor. On the second Debian lazor the trackpad stopped working, which
<leezu>
may be a hardware issue. I'm not sure. Interestingly the ChromeOS Lazor is also unable to connect to the Wifi AP
<leezu>
I haven't looked much into the trackpad issue yet. Do you have a keyword in mind that may show up in the logs related to trackpad?
<robclark>
dmesg | grep Touchpad
<dianders>
leezu: Looks like maybe `dmesg | grep 7-0015` or `dmesg | grep elan` or `i2cdetect -y -a -r 7`
<robclark>
[ 3.946610] input: Elan Touchpad as /devices/platform/soc@0/ac0000.geniqup/a84000.i2c/i2c-7/7-0015/input/input9
<dianders>
I guess the elan touchpad also has firmware on it that can be updated by Chrome OS, but I'm not quite as familiar with those updates.
<leezu>
Both debian lazors run the same elan firmware: [ 0.683155] elan_i2c 7-0015: Elan Touchpad: Module ID: 0x00d8, Firmware: 0x0003, Sample: 0x0008, IAP: 0x0001
<leezu>
The one with broken touchpad also shows: [ 4659.874249] elan_i2c 7-0015: invalid report id data (0)
<dianders>
Seems like the broken touchpad one worked well enough to probe if you see that?
<dianders>
Does `evtest` show any data on the touchpad on the broken one?
<leezu>
It does
<leezu>
I noticed before that the touchpad would be disabled if I rotate the screen and operate the device in tablet mode
<leezu>
(I'm not in tablet mode now)
<leezu>
Further, on the lazor with the "broken" touchpad, I notice that the screen will come up as flipped all the time, unless I mask iio-sensor-proxy
<leezu>
(Since 2-3 days.. Previously there was no issue)
<robclark>
so, umm.. one warning (for folks who have multiple lazors), don't stack them on top of each other, it will fool the sensor that figures out if the lid is open
<robclark>
(no permanent damage or anything.. but if lid sensor is involved it can cause confusion)
<leezu>
It's possible that the issues started after having them stacked. But now they are not stacked.. Is there some state to reset?
<robclark>
I don't think so.. the issue is just that the magnets line up when they are stacked on top of each other.. I've never had problems after unstacking
<dianders>
Sure seems like somehow the EC is confused about the state. I guess `evtest` and looking at `cros_ec_buttons` might tell you something?
<leezu>
What do you mean with looking at `cros_ec_buttons`?
<dianders>
If I open the lid I instead see `Event code 0 (SW_LID) state 0`
<robclark>
does chromeos-install work on non-test images, ie. if leezu booted his CrOS lazor could he use that to make a bootable usb image that he could boot on the other lazors?
<dianders>
Yes chromeos-install works on non-test images, but I don't _think_ you can install from eMMC to USB. I could be wrong though.
<robclark>
hmmm, I've done the other direction a bunch of times, so just assumed eMMC->USB would work.. but I guess I've never tried it
<leezu>
Can I dd the CrOS /dev/mmcblk1 to an USB disk?
<leezu>
(Issuing the dd from a linux live usb)
<leezu>
Ideally I'd like to shrink the partitions after copying to the USB disk and then use a USB stick, but that's optional and I haven't tried
<dianders>
I'd expect the DD to work with a sufficiently big USB disk
<robclark>
maybe? Assuming the usb disk was bigger than emmc.. I'd try chromeos-install first
<leezu>
On evtest cros_ec_buttons, it shows "Event code 1 (SW_TABLET_MODE) state 1"
<leezu>
So indeed, EC is confused about the tablet mode and kept it on
<dianders>
Are there magnets nearby the board?
<leezu>
No
<robclark>
you didn't forget to switch off your at-home MRI machine? :-P
<leezu>
Let me check :D
<leezu>
It's off
<robclark>
:-P
<dianders>
Hrm. In general magnets would be what I'd expect would mess it up most. IIRC there are often also accelerometers in the lid and base and the EC might calculate the angle between them to help figure things out.
<leezu>
Would booting the device with CrOS do any help? Is it possible to get the sensor values that EC considers for deciding the tablet state?
<dianders>
Yeah, the "ectool" on a Chrome OS image can poke at the EC a bunch. If you also fully open CCD you can probably make the EC console writeable over UART but that might wipe your device...
<leezu>
Ok. I think the first step is to update the EC firmware on this lazor, as it does have the older one
<leezu>
S - OEM_IMAGE_VERSION_STRING=ChromeOS_13577.388.0
<leezu>
S - OEM_IMAGE_VERSION_STRING=ChromeOS_13577.388.0
<dianders>
I'm a little surprised that the keyboard works. Isn't that also disabled by tablet mode?
<leezu>
It should be, yes. But not on this lazor anymore..
<dianders>
(?)
<dianders>
In any case, I'm going to disappear for a little bit. If you can update the kernel on this device, I suppose you could always hack the kernel to just ignore the tablet mode switch from the EC. ;-)
<steev>
bamse: is i2c1 on the flex5g supposed to be the touchscreen?
systwi_ has joined #aarch64-laptops
jhovold has quit [Ping timeout: 480 seconds]
systwi has quit [Ping timeout: 480 seconds]
systwi has joined #aarch64-laptops
systwi_ has quit [Ping timeout: 480 seconds]
iivanov has quit [Remote host closed the connection]