chromebook_trogdor: status: wormdingler (lenovo chromeboot duet 3)

vulpes2 commented 7 months ago

Noticed there wasn't a devcie-specific issue for wormdingler, so I thought I'd open one to keep info in the correct place.

Software setup

kernel: 6.4.16 (based on config from v6.1.51)
distro: Debian sid
mesa: 23.2.1 (from the Debian sid repo)
window protocol: wayland
desktop environment: gnome

Working

Wi-Fi (including WPA3-SAE and 802.11w) and Bluetooth
Built-in display (orientation, brightness controls)
Energy: battery status, dpms, suspend/resume
IIO sensors: gyroscope (auto-screen orientation, udev rule required). Link is for krane but the rule should work the same.
Trackpad: works well, libinput quirk required to configure pressure correctly just like krane.
USB: USB host, PD charging, display out (no audio)
Touchscreen: works out of the box, orientation is correct and follows screen rotation on GNOME
Graphics: OpenGL works out of the box with freedreno, performance is noticeably better than mali
Audio: speakers and mics seem okay

Needs work

Will investigate in these when I have more time.

Hardware video decoding/encoding: venus firmware is loaded, tested decoding with mpv --hwdec=v4l2m2m-copy, it's extremely choppy and unusable
Pen digitizer: cannot test, this device will only work with USI2 pen which I don't have
Audio: ucm config needs to be modified to remove the nonexistent headset and mic. dt might also need tweaks to fix the flood of ASoC: error at __soc_pcm_hw_params on MultiMedia2: -22 messages.

Broken

Cameras: CSI cameras, no mainline support for the subsystem.

Notes

IIO sensors require iio-sensor-proxy to be installed and running for them to work with GNOME.
Hardware compositing work out of the box with chromium and firefox once they are running natively on Wayland.

vulpes2 commented 7 months ago

Unfortunately starting from kernel 6.5 the display has stopped working, the device will only boot to a blank screen. Tested two config files, one was from the existing v6.1.51, one was config.cbq-6.6.0-stb-cbq, both gave the same results. Power management seems to be working as the power button does turn the backlight on and off, but there is simply nothing displayed on the screen. From what I can tell a homebrew SuzyQ should give me access to the AP serial console, don't know when I'll get to it but that's probably the next step for troubleshooting.

hexdump0815 commented 7 months ago

@vulpes2 - thanks a lot for creating thise separate gh issue for wormdingler, i have now also linked it in the trogdor readme: https://github.com/hexdump0815/imagebuilder/commit/ee9e71bb13dac378f9292a22aa5b8beefbab30ba

for debugging blank screen problems this might be helpful: https://github.com/hexdump0815/imagebuilder/issues/61#issuecomment-1843374506 ... did you try v6.6 already? if not: maybe its fixed there and in general it is a very good target as it is a lts kernel, so it will get fixes for the next three years

in case you would prefer to buy something suzyqable like: there seems to be someone selling working devices now on ebay - see the link at the end of https://github.com/hexdump0815/linux-mainline-on-arm-chromebooks ... i have no relation to this, just read on irc that it seems to work

vulpes2 commented 7 months ago

Both 6.5 and 6.6 boot to a blank screen, I'll try the script trick you mentioned and see if I can get some logs. It's really a shame because I was really hoping 6.6 would work out of the box, since it's a nice LTS release.

In terms of SuzyQ, I do actually have the breakout board, just haven't gotten around to putting it together yet. It's inevitable that I'll get frustrated enough and decide to put it together, it's just a matter of time basically.

vulpes2 commented 7 months ago

Added the below snippet to rc.local to get some logs, and I got a completely normal boot sequence with no additional error messages on v6.5.13. Since there were a lot of renames in the dts, I tried using the dt from 6.4 with kernel 6.5 too, and nothing seems to have changed. I'm out of ideas at this point, even getting a serial console to the soc won't help me, will stick to v6.4 for now. It would be great if anyone can provide some more hints on how to debug this further.

if [ ! -f /marker ]; then
    dmesg > /dmesg.txt
    touch /marker
    shutdown -h now
fi

hexdump0815 commented 7 months ago

@vulpes2 - if you have a working and a non working version, then git bisect should lead to the breaking commit - it is a bit painful (due to having to compile and install multiple kernels) and requires a bit of discipline (to always install the proper kernel each time, as the kernel version will jump around a bit between last, new and various -rcx versions during bisecting) but it helped me to find the root cause of problems quite a few times already ... if you do that, then do it on a usb device, so that you can easily revert to a working kernel via dd on another machine - for the emmc case otherwise this would be of interest: https://github.com/hexdump0815/imagebuilder/blob/main/doc/test-booting-a-kernel-on-chromebooks.txt ... good luck

btw. when you mention suzyq breakout board above, do you mean the google servoe board or some self built variant?

vulpes2 commented 7 months ago

Yeah, that's what I have been doing, building the kernel and flashing the kpart image to a flashdrive so there will be a working copy on the emmc at all times. I've previously tried to bisect a kernel issue on a different board and it was extremely painful due to the amount of manual work involved, even with the image building & flashing process completely scripted, so I'm pretty hesitant to try that again.

About the suzyq thing, I have one of these generic breakout boards to build a cable with, not a fancy servo board unfortunately.

vulpes2 commented 6 months ago

An update on the display situation, I tried bisecting the kernel source and found the root cause, the dsi bridge is powered on too late so panel init is failing. I'm not much of a developer so my ability to troubleshoot this kind of stuff is very limited, but I did come up with a hack that can reliably mitigate this issue for now. The patch and more details can be found in the upstream bug report: https://gitlab.freedesktop.org/drm/msm/-/issues/47

By the way, I did end up putting together a debug cable, having access to the AP serial console is super helpful for debugging, but I'm not sure how I can unlock ccd without reinstalling ChromeOS.

vulpes2 commented 6 months ago

A proper fix has been suggested and it has been tested. Will try to get it upstreamed and backported to linux-stable.

hexdump0815 commented 6 months ago

i usually do a ccd open and setting the gbb flags to 0x19 as a first thing before using a chromebook with linux ... it might be required to backup (maybe dd) your current system, restore chromeos, ccd open and then restore linux again ... maybe searching the web for "sh1mmer" might bring up an option to boot and ccd open your device from usb :) ... it at least helped me to ccd open and usb-boot enable a krane with broken emmc which would otherwise only be useable as a paperweight or doorstop ...

vulpes2 commented 6 months ago

Unfortunately there's no leaked RMA shim for trogdor so that's a dead end. I'll leave it as is for now and reinstall ChromeOS at some point to fix it.

hexdump0815 commented 6 months ago

@vulpes2 - i think wormdingler is based on strongbad (see: https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/ - and strongbad somehow seems to be some variant of trogdor - don't ask me about the logic behind all this naming :) )

update: the recovery image name of wormdingler seems to tell the same story

WesleyVanNeck commented 5 months ago

@hexdump0815 can you make a updated kernel build for chromebook trogdor i cant do it my self

hexdump0815 commented 5 months ago

@FrostNovaHD - i have no time to build new kernels right now - but it is not that complicated to build one yourself and it can be done easily on the device itself - see: https://github.com/hexdump0815/imagebuilder/blob/main/doc/building-own-kernels.md

WesleyVanNeck commented 4 months ago

@FrostNovaHD - i have no time to build new kernels right now - but it is not that complicated to build one yourself and it can be done easily on the device itself - see: https://github.com/hexdump0815/imagebuilder/blob/main/doc/building-own-kernels.md

When do we get new bootable img for trogador

vulpes2 commented 4 months ago

You do not need a new bootable image, you can simply build the kernel and install it on top of the existing image. I may post an updated kernel image at some point, no promises though.

XxTHKxX commented 3 weeks ago

Heya, just hopping on to the party here. The last bootable image for trogdor is kernel 6.1, uh. can I get some hand holding to get the device to a good stable new kernel/image? ((i just got the chromebook like 2 days ago so I've got not much experience with it's hardwares, I know a bit of linux and such but not much)). Dev mode is enabled, and a test boot of the last bootable sd images is successful, just wanted to be a bit more up to date

LukIsHere commented 3 weeks ago

the latest avaliable kernel is here (6.6.23) you just need to follow this guide it is really simple just do it step by step @XxTHKxX

XxTHKxX commented 3 weeks ago

the latest avaliable kernel is here (6.6.23) you just need to follow this guide it is really simple just do it step by step @XxTHKxX

Uh, if I may ask, is there a way for me to edit the cmdline for this kernel (without rebuilding it completely at least)? I'd like to reenable ipv6 support on the kernel, as part of my network requires the usage of ipv6 in order to connect to their service

XxTHKxX commented 3 weeks ago

Okay so I tried to build and install the latest kernel based on instruction on building-your-own-kernel and the corresponding readme file for my device, but seems like even after installing the new kernel via dd if=/boot/vmlinux.kpart-6.6.23-stb-cbq+ of=/dev/mmcblk0p1 The booted image still use the old kernel, any suggestion?

LukIsHere commented 3 weeks ago

Uh, if I may ask, is there a way for me to edit the cmdline for this kernel

afaik no without building it at least once. it isn't very complicated process as long as u just copy comand one by one and modifying one file

if depthcharge-tools are added to the images it should be possible

for my device, but seems like even after installing the new kernel via dd if=/boot/vmlinux.kpart-6.6.23-stb-cbq+ of=/dev/mmcblk0p1 The booted image still use the old kernel, any suggestion?

try running lsblk and checking if ur emmc aint called mmcblk1 instead of mmcblk0 if that's the case the command shoud be

dd if=/boot/vmlinux.kpart-6.6.23-stb-cbq+ of=/dev/mmcblk1p1

@XxTHKxX

XxTHKxX commented 3 weeks ago

Uh, if I may ask, is there a way for me to edit the cmdline for this kernel afaik no without building it at least once. it isn't very complicated process as long as u just copy comand one by one and modifying one file

if depthcharge-tools are added to the images it should be possible

for my device, but seems like even after installing the new kernel via dd if=/boot/vmlinux.kpart-6.6.23-stb-cbq+ of=/dev/mmcblk0p1 The booted image still use the old kernel, any suggestion? try running lsblk and checking if ur emmc aint called mmcblk1 instead of mmcblk0 if that's the case the command shoud be
dd if=/boot/vmlinux.kpart-6.6.23-stb-cbq+ of=/dev/mmcblk1p1
@XxTHKxX

I feel like an idiot after looking at the mmc device name, how the heck did i missed something so obvious. After fixing the device name from 0 to 1, the new kernel is booted up, and the new cmdline provided worked perfectly. Thank you so much for pointing me in the right direction!

LukIsHere commented 3 weeks ago

no problem actually don't blame urself on previous/older devices i used it always used to be 0 that's why the guide assumes it should be 0 but yeah in newer ones it for some reason is 1

hexdump0815 / imagebuilder