search

hexdump0815 / imagebuilder

velvet os - simple script framework to build ubuntu 22.04 lts jammy (in older versions also 20.04 lts focal) and debian 12 bookworm (in older versions also 11 bullseye) bootable usb / sd card images for some arm and intel devices - lots of prebuilt images as well
GNU General Public License v3.0
315 stars 46 forks source link

chromebook_kukui: status: fennel (lenovo chromebook flex 3 - mt8183 version) #58

Open hexdump0815 opened 2 years ago

hexdump0815 commented 2 years ago

notes on fennel running 5.18.1:

here is list of working and non working features on the mt8183 version of the lenovo chromebook flex 3 (fennel). i just had a short moment to do a test boot and the system tested was the sku6 version.

working

untested

broken

installation

coming soon

problems

none so far

Pawlicker commented 2 years ago

Hi, I have one of these laptops on hand. I can confirm sound doesn't work, but I can help make it work if there's anything you need help with. It boots at least on mine.

Edit: how did you get sleep mode working? I'm noticing sleep mode on mine is not causing the LED to go out or the screen like on Chrome OS.

Edit 2: So after installing ubuntu-mate-desktop sleep mode works in MATE. I think XFCE for some reason doesn't like sleep mode on this device.

hexdump0815 commented 2 years ago

sorry - i'm mostly offline right now, but will be back in a few days

regarding audio, you might check if you have a sku6 version as well (cat /proc/device-tree/model) and if this is the case then maybe try to change the matching line in rc.local (https://github.com/hexdump0815/imagebuilder/blob/main/systems/chromebook_kukui/rc-local-additions.txt#L27) to your model string ... sku6 and fennel14 should have the exact same audio hardware and it should work, but one never knows ...

if you have another sku version or if it still does not work then this might give some ideas about how to debug it: https://github.com/hexdump0815/imagebuilder/issues/54

regarding the sleep issue i'll have to check later - it worked for me, but everything is possible to break again or for certain systems :)

Pawlicker commented 2 years ago

Changing the model string to sku6 and fennel did in fact fix it and audio now works. I'm still having sleep issues, when the laptop is in sleep mode for "too" long it seems to have issues with the SD card seemingly being unmounted. I'll see if I can determine why that's the case.

hexdump0815 commented 2 years ago

how is the sd card connected: as mmc (i.e. /dev/mmcblkx) or as usb (i.e. /dev/sdx)? if it is usb it reminds me a bit on what seems to be the case on trogdor chromebooks: if run from emmc it seems to work, if run from usb sleep does not work properly as the usb sleep handling does not seem to be clean ... most of the mediatek chromebook mainline code is coming from mediatek/google chromeos developers and i guess running a system from usb and then even trying to suspend it might be outside of their testing scope ...

you might try s2idle mode: https://github.com/hexdump0815/imagebuilder/blob/main/systems/chromebook_kukui/rc-local-additions.txt#L1-L2 - it should be enough to keep the system alive over night on these systems in case running from emmc is not an option for you

Pawlicker commented 2 years ago

It's definitely connected as /dev/sda while the onboard storage is stored on mmcblk. I'm not sure it's a good idea to transfer the OS over to the MMC or how I would do it on these newer Chromebooks. It also seems to only happen after a few hours and not right away, and well Chromebooks do not run the OS from USB.

Even changing that s2idle only keeps it at the deep version and worse; I get permission denied issuing the command itself as root.

hexdump0815 commented 2 years ago

this "permission denied" with s2idle sounds very strange - this should simply work ... what does "cat /sys/power/mem_sleep" say for you? are you using the latest images with the latest 5.18.1 kernel? i just tested it on my kappa system (running off emmc) and there suspend/resume works perfectly fine even for hours in deep mode

regarding installing onto emmc i would recommend to carefully read all of https://github.com/hexdump0815/linux-mainline-on-arm-chromebooks to get the basic ideas ... on the 64bit arm chromebooks which are all using the default and installed depthcharge bootloader the installation to emmc is quite riskless as chromeos can easily be reinstalled from a downloaded google recovery image for the corresponding device if desired - there is no rom flashing etc. required like for intel chromebooks with the efi firmware

i'm always using https://github.com/hexdump0815/imagebuilder/blob/main/info/generic/install-to-emmc-with-luks-full-disk-encryption.txt as base to copy and paste the steps whenever i setup to emmc from one of the images - the doc needs to be rewritten and is hard to read as there is a lot of other not chromebook relevant information mixed in (efi, u-boot), but it has proven to work well many times and will even give you an encrypted root disk, which i think is a very good idea for a portable device

good luck and best wishes - hexdump

Pawlicker commented 2 years ago

I'll mess with trying an eMMC install some later, I've been somewhat busy the past week. I noticed in dmesg there was a second or two before the SD card was remounted when I left the laptop closed overnight for testing purposes with no apps open and it took a little longer for the login box to come up. This was marked with some write/read errors right before it's remounted.

I found another minor GPU bug with color corruption. I'll take a screenshot of it later and see if it shows up there. I might file a freedesktop bug and whatnot.

hexdump0815 commented 2 years ago

@Pawlicker - i have adjusted the audio module loading in /etc/rc.local now so that it should work for fennel (and a lot of other systems) out of the box for future images - https://github.com/hexdump0815/imagebuilder/commit/fbb7823bb1e637dabfb24d44467531ff1668d1f1

deiol commented 2 years ago

I've got a Lenovo Flex 3 and from the ChromeOS shell, /proc/device-tree/model outputs "Google fennel sku7 board." Interestingly, when booting to VelvetOS, /proc/device-tree/model outputs "Google fennel14 sku0 board." I haven't gotten sound to work yet, dmesg shows mt8183_da7219 mt8183-sound: ASoC: failed to instantiate card -6 and the output device is "Dummy Output." Modifying rc.local to load mt8183-mt6358-ts3a227-max98357 resolves the "failed to instantiate card" error in dmesg, but I still get Dummy Output. I will update if I make any progress.

hexdump0815 commented 2 years ago

@deiol - that wrong sku version is a bit confusing as the kernel image includes all possible dtb files and the bootloader should pick the right one - maybe some naming got mixed up in the dtb files ...

regarding audio: the first point to achieve is to get some device showing up with "cat /proc/asound/cards" and it looks like you got to that point already - correct? if that is there you'll need to create a proper ucm file based on the chromeos ucm file - for that the following links should give some information on how to move on with this:

let me know in case more help is required ... in case you get it working a pull request with the working ucm files would be very nice, so that i can add it to the tree ( https://github.com/hexdump0815/imagebuilder/tree/main/systems/chromebook_kukui/extra-files/usr/share/alsa/ucm2 and https://github.com/hexdump0815/imagebuilder/blob/main/systems/chromebook_kukui/rc-local-additions.txt#L30-L74 )

good luck and best wishes - hexdump

deiol commented 2 years ago

@hexdump0815 thank you for the informative post! I've solved the wrong sku version and submitted a pull request on your linux-mainline-mediatek-mt81xx-kernel repo.

After fixing that and updating rc.local to account for the new sku, I'm getting output when I cat /proc/asound/cards. Still no audio though, so I'll look into creating a ucm file. I'll submit a pull request if I get it working.

hexdump0815 commented 2 years ago

@deiol - cool - thanks a lot - i have put your pull request on my todo list - this is indeed a much better way to get the list of the dtb's and i'll also apply to it quite a few more kernels and in other places ... you already tested it exactly in the way you submitted it in the pr - right?

looking forward to you getting your sound working - good luck!

deiol commented 2 years ago

Correct, I tested building the kernel exactly as I submitted in the PR (multiple times now) with success.

I got sound working, your UCM file mt8183_mt6358_ts3a227_max98357.conf worked however I had to rename it to mt8183_mt6358_t.conf, I've submitted a PR. I'll note that the default volume was VERY loud. I'm still looking into a few other oddities;

In case folks come across this thread in the future, note the ALSA/UCM/PulseAudio hacking doc recently moved; https://github.com/hexdump0815/imagebuilder/blob/main/doc/alsa-ucm-pulseaudio-hacking.txt

hexdump0815 commented 2 years ago

@deiol - thanks a lot for the update and the pr's - i hope to find the coming weekend or the days after a bit more time to have a closer look at this ... the headphone jack switching needs some extra effort i think if its possible with mainline and regular alsa/ucm right now at all, but at some point we'll get that going too ... thanks for the hint with the moved docs

thanks a lot and best wishes - hexdump

hexdump0815 commented 2 years ago

@deiol - fyi: your pr's are merged now - thanks a lot for your contribution ... i took out the (as i think unused) "-F" option from the mkimage cmd and replaced the shortened ucm conf file with a symlink to the long filename which should work as well i think ... i think it depends on the ucm version (depending on the distribution used) if the long filename can be used or a short one is required

best wishes - hexdump