MobileRead Forums - View Single Post

enthdegree · 11-04-2024, 07:52 PM

Thanks for the encouragement, elinkster

A few technical questions about the Clara BW, possibly relevant to any new device. I'd be grateful for any help:

Has anyone successfully compiled its kernel? I got the kernel source from here and pulled /proc/config.gz from my Clara BW. However `make ARCH=arm CROSS_COMPILE=~/[the toolchain dir]/bin/arm-kobo-linux-gnueabihf-` fails in two cases I tried:
- koxtoolchain nickel env fails at some #preprocessor term in the ARM assembly... not a good sign.
- gcc-linaro-4.9.4-2017.01 gets past that part, but apparently I don't have all the needed compile-time variables: when compiling drivers/devfreq/helio-dvfsrc-opp.c it can't find the header helio-dvfsrc.h (in the same directory) because it's referenced in angle brackets. If I hand edit that file to quotes it starts failing for the same reason for headers in /drivers/misc/mediatek. I'm not informed enough with the build process to know where these vars should be set.
In spite of not getting the whole kernel to build, I did manage to compile just the module uhid.ko with `make [...] modules`. But then `insmod uhid.ko` via koreader terminal fails with "device or resource busy." Further, I notice the Clara BW's kernel config already has CONFIG_UHID=y anyway, so it seems like this whole kernel & module build is unnecessary?

To investigate further I have to wait, my device came with backlight defects and I'm getting it replaced.

Edit: ah, just now getting up to speed. This Mediatek SOC signed boot situation is unfortunate: https://www.mobileread.com/forums/sh...d.php?t=363175 . Some words & dump on the same or similar SOC here: https://www.reddit.com/r/kindle/comm...th_generation/ .
Given the similarity I wonder if some work on the paperwhite 5 is not applicable: https://kb.taktpraha.cz/projects/kindlepw5 . The Clara's UART pads are obvious, see here: https://guide-images.cdn.ifixit.com/...MldedEWXk.huge. I wonder if there is anything to be learned during early boot. I don't know what the other 4 pads below the Clara's UART are.

Has anyone learned what exactly fusing these Download pads on the Clara Color PCB does? (presumably the BW has the same pads). I wonder if connecting them during a reboot forces it into MediaTek BROM mode. If that's the case, then I wonder if anything useful can be learned through https://github.com/bkerler/mtkclient, (in particular I'd like to see if the device has any efuses set). Maybe by some miracle a MediaTek bypass implemented in mtkclient will unlock the bootloader. Another slim but obvious first line of attack would be the proprietary chimeratool. At any rate running a new kernel is far more involved than anything I want to do on the device, for now.

11-04-2024, 07:52 PM	#4
enthdegree Member Posts: 19 Karma: 10 Join Date: Jun 2014 Device: none	Thanks for the encouragement, elinkster A few technical questions about the Clara BW, possibly relevant to any new device. I'd be grateful for any help: Has anyone successfully compiled its kernel? I got the kernel source from here and pulled /proc/config.gz from my Clara BW. However `make ARCH=arm CROSS_COMPILE=~/[the toolchain dir]/bin/arm-kobo-linux-gnueabihf-` fails in two cases I tried: koxtoolchain nickel env fails at some #preprocessor term in the ARM assembly... not a good sign. gcc-linaro-4.9.4-2017.01 gets past that part, but apparently I don't have all the needed compile-time variables: when compiling drivers/devfreq/helio-dvfsrc-opp.c it can't find the header helio-dvfsrc.h (in the same directory) because it's referenced in angle brackets. If I hand edit that file to quotes it starts failing for the same reason for headers in /drivers/misc/mediatek. I'm not informed enough with the build process to know where these vars should be set. In spite of not getting the whole kernel to build, I did manage to compile just the module uhid.ko with `make [...] modules`. But then `insmod uhid.ko` via koreader terminal fails with "device or resource busy." Further, I notice the Clara BW's kernel config already has CONFIG_UHID=y anyway, so it seems like this whole kernel & module build is unnecessary? To investigate further I have to wait, my device came with backlight defects and I'm getting it replaced. Edit: ah, just now getting up to speed. This Mediatek SOC signed boot situation is unfortunate: https://www.mobileread.com/forums/sh...d.php?t=363175 . Some words & dump on the same or similar SOC here: https://www.reddit.com/r/kindle/comm...th_generation/ . Given the similarity I wonder if some work on the paperwhite 5 is not applicable: https://kb.taktpraha.cz/projects/kindlepw5 . The Clara's UART pads are obvious, see here: https://guide-images.cdn.ifixit.com/...MldedEWXk.huge. I wonder if there is anything to be learned during early boot. I don't know what the other 4 pads below the Clara's UART are. Has anyone learned what exactly fusing these Download pads on the Clara Color PCB does? (presumably the BW has the same pads). I wonder if connecting them during a reboot forces it into MediaTek BROM mode. If that's the case, then I wonder if anything useful can be learned through https://github.com/bkerler/mtkclient, (in particular I'd like to see if the device has any efuses set). Maybe by some miracle a MediaTek bypass implemented in mtkclient will unlock the bootloader. Another slim but obvious first line of attack would be the proprietary chimeratool. At any rate running a new kernel is far more involved than anything I want to do on the device, for now. Last edited by enthdegree; 11-05-2024 at 02:02 AM.