notes on image 210725-02 on snow

[pbgapski]

First of all, thanks @hexdump0815 for the images. They pretty much match what I wanted.

In this ticket I will write some notes about its usage on snow. This is not an issue report per se, maybe more of a quick journal, mixed with a few questions.

I started following the procedure to disable the firmware write-protect by removing the ring, and adjusting the gbb flags to 0x19. Thanks for the detailed procedure. In my case it did not work at first: I had to reopen the chromebook and clean the contacts with a small brush, and then I was able to disable wp.

I flashed the image to both sd card and usb drive, but neither would boot. After ctrl+u, USB would give a grave beep and boot to chos. SD would as well but without the beep. In case that matters, the USB was 8Gb, the SD was 16Gb.

I had to run 'cgpt repair' on the SD card, and then it booted just fine.

I tried both rev4 and rev5, but the touchpad was not functional. It works fine on chos. I am not sure if it was expected to work, but I would be grateful for tips on things I can try to make it work.

I have not tried the sound tweaks yet.

Next I would like to replace chos on the emmc. I have done this before with archlinux, but I have been hit by the loss of gbb flags, and that was the main drive to disable wp and tweak gbb flags now.

I have seen some comments about emmc suppport for the U3, and before I flash the emmc, please comment on the procedure and possible tweaks if you have the time.

[hexdump0815]

hi @pbgapski - sorry for the late response, but i was mostly offline for a few days. which image did you use exactly and which tool did you use to write it to sd/usb on which os? i usually test the images at least once quickly before uploading them, so they should work - but maybe i'll double check in case you tell me which one it was. i'm not 100% sure off mind if booting from usb works on snow - if then only from one of the usb ports and not from the other.

the touchpad should actually work fine on both rev4 and rev5 - i tested both. maybe the actual hardware varies between different machines? can you maybe post the dmesg from both chromeos and the imagebuilder image somewhere to see which drivers are used and/or which error messages come up?

flashing the emmc is easy on chromebooks as the boot firmware is in the other flash and the native initial bootloader of the chromebook is used. the only thing to keep in mind is to do all the wanted gbb flag settings etc. before overwriting chromeos, as this only works from chromeos and cannot be done (at least not easily) afterwards - worst case its always possible to boot the image from sd card again or to restore chromeos via restore image.

good luck and best wishes - hexdump

[pbgapski]

hi @pbgapski - sorry for the late response, but i was mostly offline for a few days. which image did you use exactly and which tool did you use to write it to sd/usb on which os? i usually test the images at least once quickly before uploading them, so they should work - but maybe i'll double check in case you tell me which one it was. i'm not 100% sure off mind if booting from usb works on snow - if then only from one of the usb ports and not from the other.

Never mind the small delay in the response, and thanks for taking the time to respond.

The image I used was
https://github.com/hexdump0815/imagebuilder/releases/download/210725-02/chromebook_snow-armv7l-bullseye.img.gz

It was written as follows:
zcat chromebook_snow-armv7l-bullseye.img.gz | dd of=/dev/sdX; sync
to both USB and SD card. The OS was debian bullseye on amd64.

On snow, boot is not supposed to work on the USB3 port as far as I know.

the touchpad should actually work fine on both rev4 and rev5 - i tested both. maybe the actual hardware varies between different machines? can you maybe post the dmesg from both chromeos and the imagebuilder image somewhere to see which drivers are used and/or which error messages come up?

I must mention that I had two of those chromebooks: one of them got a failed TPM, and the other a reddish screen, so I switched the display from one to the other to have a working machine, so I may need a custom dtb. I do not believe it is a hw problem, since the touchpad works on chos. The one I am using is 04.2013, while the other is 09.2014 on the label.

I will get both dmesg and post in the next few hours.

[pbgapski]

dmesg-chos.log

dmesg from chromeos

[    0.783860] atmel_mxt_ts 1-004b: Family ID: 130 Variant ID: 35 Major.Minor.Build: 2.0.AA
[    0.783870] atmel_mxt_ts 1-004b: Matrix X Size: 24 Matrix Y Size: 14 Object Num: 23
[    0.784792] atmel_mxt_ts 1-004b: T9 Config: XSIZE 2039, YSIZE 1359, XLINE 19, YLINE 11
[    0.784892] input: Atmel maXTouch Touchpad as /devices/12c70000.i2c/i2c-1/1-004b/input/input1
[    0.786886] atmel_mxt_ts 1-004b: Status: 80 Config Checksum: f0c268
[    0.786898] atmel_mxt_ts 1-004b: Status: 00 Config Checksum: f0c268
[    0.796463] atmel_mxt_ts 1-004b: Status: 00 Config Checksum: f0c268

[pbgapski]

dmesg-hex.log

dmesg from https://github.com/hexdump0815/imagebuilder/releases/download/210725-02/chromebook_snow-armv7l-bullseye.img.gz

[pbgapski]

Sound works fine with rev4 dtb

[hexdump0815]

it looks like different touchpads are used in different snow chromebooks - mine is:

[    0.833861] input: Cypress APA Trackpad (cyapa) as /devices/platform/soc/12c70000.i2c/i2c-1/1-0067/input/input0

and works perfectly fine. in theory yours should work as well as the driver for it is included in the kernel as well (CONFIG_TOUCHSCREEN_ATMEL_MXT=y) - maybe some slight incompatibility? i have just built a new v5.15 kernel for snow, maybe you can give it a try: https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/releases/tag/5.15.12-stb-cbe%2B ... just unpack both files from /, run "update-initramfs -c -k 5.15.12-stb-cbe+" and create a new entry for it in /boot/extlinux/extlinux.conf - maybe it works better :)

[hexdump0815]

btw. i just downloaded the image you used again, wrote it to an sd card and it boots and works fine for me - so it was maybe a problem with your sd card then i guess ...

[pbgapski]

it looks like different touchpads are used in different snow chromebooks - mine is:

[    0.833861] input: Cypress APA Trackpad (cyapa) as /devices/platform/soc/12c70000.i2c/i2c-1/1-0067/input/input0

and works perfectly fine. in theory yours should work as well as the driver for it is included in the kernel as well (CONFIG_TOUCHSCREEN_ATMEL_MXT=y) - maybe some slight incompatibility? i have just built a new v5.15 kernel for snow, maybe you can give it a try: https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/releases/tag/5.15.12-stb-cbe%2B ... just unpack both files from /, run "update-initramfs -c -k 5.15.12-stb-cbe+" and create a new entry for it in /boot/extlinux/extlinux.conf - maybe it works better :)

Thanks, I am downloading the new kernel to give it a try. If the touchpad does not work I will try some tweaks as it seems to be an issue with my device.

[pbgapski]

btw. i just downloaded the image you used again, wrote it to an sd card and it boots and works fine for me - so it was maybe a problem with your sd card then i guess ...

Or maybe some mistake on my part. In any case is good to know the image is working fine.

Thanks for the feedback.

[pbgapski]

dmesg-5.15.12.log

The 5.15.12-stb-cbe+ kernel booted fine. But still no luck with the touchpad. I will read about how to mess with the dtb as a last try.

[pbgapski]

this may be the solution to my touchpad issue: https://archlinuxarm.org/forum/viewtopic.php?f=47&t=13801

I may have mixed the rev4 board with the rev5 touchpad when using the parts from my two snow chromebooks

[hexdump0815]

looks like there is a solution in sight - two actually: either changing the hardware or the dtb :)

good luck - hexdump

[pbgapski]

I followed the "changing dtb" path as it seemed more interesting. This is my first dtb hack :-)

After reading about device trees, dtc and such, and a few iterations, the touchpad seems to be working.

The steps are as follows, executed in the chomebook itself:
dtc -I fs -O dts -o snow-hack.dts /proc/device-tree/
then edit the snow-hack.dts just created.

After that:
dtc -I dts -O dtb -o snow-hack.dtb snow-hack.dts
cp snow-hack.dtb /boot/dtb-5.15.12-stb-cbe+/exynos5250-snow-hack.dtb
and edit extlinux.conf to point the kernel to the above dtb.

The change in the dts was the following:
trackpad@67 { reg = <0x67>; compatible = "cypress,cyapa";
to
trackpad@4b { reg = <0x4b>; compatible = "atmel,maxtouch";

[pbgapski]

Upon further inspection, the cursor moves but the buttons are not working. Maybe the interrupt is wrong? It seems a few more iterations will be required ;-)

[jenneron]

@pbgapski hexdump0815/linux-mainline-and-mali-generic-stable-kernel#6

[hexdump0815]

@jenneron - thanks a lot ... @pbgapski - it usually is better and less error prone to edit the dts files in the kernel sources and rebuild the dtbs from them instead of decompiling the dtb and editing the resulting dts file as required changes might be distributed across different regions of the file - the decompiling is handy if there is no source for it or for very simple changes

[pbgapski]

@jenneron - thanks a lot ... @pbgapski - it usually is better and less error prone to edit the dts files in the kernel sources and rebuild the dtbs from them instead of decompiling the dtb and editing the resulting dts file as required changes might be distributed across different regions of the file - the decompiling is handy if there is no source for it or for very simple changes

@hexdump0815 yes, sure you are right. I tried that path as I had never done it before and it allowed for faster iteration cycles. It was interesting but far from elegant.

[pbgapski]

@pbgapski hexdump0815/linux-mainline-and-mali-generic-stable-kernel#6

@jenneron thanks for the commit. If possible, please attach the new dtb so I can give it a try before the long kernel build.

[jenneron]

before the long kernel build.

@pbgapski you don't need to do that, just checkout to needed version, apply patch and do ARCH=arm make dtbs.

please attach the new dtb

It's quite risky to run any binaries shared like this, but here you go as you asked.

snow-5.15.10-touchpad-dtbs.zip

[pbgapski]

@pbgapski you don't need to do that, just checkout to needed version, apply patch and do ARCH=arm make dtbs.

@jenneron thanks for the tip

It's quite risky to run any binaries shared like this, but here you go as you asked.

you are right of course

snow-5.15.10-touchpad-dtbs.zip

thanks for the dtb

@hexdump0815 this patched dtb fixes the touchpad issues on my snow chromebook

[hexdump0815]

thanks for reporting that it works - will just have to double check that it still works well with the other touchpad before fully enabling it

[pbgapski]

Following the test with the dtb provided by @jenneron, I am moving to the kernel compile.

This is based on the notes at https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/faa7e00b0806e2f75e45ed4630c843dca4adb1f2/readme.cbe.

Here I will write only what I had to modify. The kernel used was mainline tarball 5.15.14. Platform is debian bullseye on amd64 arch, and the goal is to cross compile to armhf.

line 21: removed email stuff from new touchpad patch

(bullseye-amd64-snow)root@bul:/compile/doc/stable# git diff
diff --git a/misc.cbe/patches/fix-atmel-touchpad.patch b/misc.cbe/patches/fix-atmel-touchpad.patch
index 87523a0..c328562 100644
--- a/misc.cbe/patches/fix-atmel-touchpad.patch
+++ b/misc.cbe/patches/fix-atmel-touchpad.patch
@@ -1,18 +1,3 @@
-from: https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/issues/6
-
-From 170fa62ecc113a44cf33591c7b38643eaf457c55 Mon Sep 17 00:00:00 2001
-From: Anton Bambura <jenneron@protonmail.com>
-Date: Wed, 5 Jan 2022 16:13:53 +0200
-Subject: [PATCH] ARM: dts: exynos: snow: add atmel mxt touchpad
-
-Add Atmel mXT touchpad (like peach chromebooks) as it is used in
-some revisions (probably rev5 only).
-
-Signed-off-by: Anton Bambura <jenneron@protonmail.com>
----
- arch/arm/boot/dts/exynos5250-snow-common.dtsi | 15 +++++++++++++++
- 1 file changed, 15 insertions(+)
-
 diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
 index c952a6151..83c1a3a4e 100644
 --- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
(bullseye-amd64-snow)root@bul:/compile/doc/stable# 

Apply patch:
patch -p1 < /compile/doc/stable/misc.cbe/patches/fix-atmel-touchpad.patch

Install required packages in chroot:
apt install build-essential git gcc-arm-linux-gnueabihf flex bison libssl-dev bc kmod rsync

[pbgapski]

30: make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf- olddefconfig
31: make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf- -j 2 zImage dtbs modules
41: make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf- -j 2 modules_install
54: make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf- -j 2 headers_install INSTALL_HDR_PATH=/usr

[pbgapski]

Everything moved to internal emmc and working fine.

Notes: do not forget to set "legacy_boot" flag on internal boot partition and label the root partition as "rootpart"

[hexdump0815]

@pbgapski - that sounds good

i usually change the label of the partitions on emmc to something like rootemmc and bootemmc and adjust the fstab accordingly in order to still be able to cleanly boot from sd card in case i want/need to (otherwise there would be multiple partitions with the same label in this case)

[pbgapski]

i usually change the label of the partitions on emmc to something like rootemmc and bootemmc and adjust the fstab accordingly in order to still be able to cleanly boot from sd card in case i want/need to (otherwise there would be multiple partitions with the same label in this case)

Since you mention it, I did try that, and the boot failed in the initramfs as the cmdline was coded with "root=LABEL=rootpart".

I even tried a uEnv.txt file in /boot, but the solution was way simpler. Once I fixed the cmdline in extlinux.conf, everything worked :-)

[pbgapski]

As a sidenote, I had never used extlinux before. I was used to grub on desktops and u-boot on SOCs.

@hexdump0815 I did enjoy your solution with u-boot and extlinux. Very flexible and easy to customize.

[hexdump0815]

@pbgapski - happy to hear that you have it working well now ... yes the extlinux.conf needs to be adjusted as well - i forgot about that one ... i also like the extlinux approach as it is so much simpler than grub :)