PaperWhite 1 Kernel Build Walkthrough

[NiLuJe]

lab126's Makefile being wonky does vaguely ring a bell, so I'd chalk that one up to the lab126 patches not being fool-proof .

[bulsa]

After disabling neon in drivers/video/mxc/mxc_epdc_fb.c and taking quite some missing #defines (this source code release stinks imho...) from https://github.com/koreader/koreader...mxcfb-kindle.h (NiLuJe, where did you get them from??), it now compiles sucessfully, however I have no idea if it works .

[NiLuJe]

@bulsa: Amazon's source code packages. Unlike Kobo's, their mxcfb headers are actually usually fairly sane . Might have lucked out on the exact version I chose at the time though ;p.

Note that this version of the header is fairly strongly aimed at userland, some stuff has been renamed, and it's generally an agglomeration of a couple of different versions of the header in order to cover all the 5.x range of FW & devices.

[bulsa]

I used Kindle_src_5.4.4.2_2323310003.tar.gz/gplrelease/linux-2.6.31.tar.gz. There the defines you marked PW2 are missing, but the kernel driver is using most of them...

[NiLuJe]

That's because 5.4.4.2 is a PW1 kernel, and those are definitely Carta/PW2 things .

[bulsa]

The process of building those source packages has to be very interesting, when apparently the drivers dont match the header version...

[finitelife]

tl;dr - I will be maintaining the original post with up to date progress. It will always result in the kernel and modules getting compiled. So far the Kernel will probably brick your device. The modules however, should work just fine (they insmod fine).

So after a bit of searching...

I found the front light header in the uboot source (uboot/include/linux/frontlight.h).
I found an ?earlier/compatible? version of the hall sensor header (yoshime_hall.h)

I have updated the original post with the fixes in place. I also added the depmod fix and switched from perl to sed.

I am actively pursuing fixes to the FB_MXC_EINK_PANEL problem currently. I'd like to blame the dev environment, but so far everything has been Amazon oversight. Fingers crossed, coffee at the ready.

In enabling the hall sensor, I noticed HALL_MISC_DEV_NAME and HALL_DEV_MINOR. Not sure what the values should be. Any help there would be appreciated. Here's the output of 'cat /proc/devices':

Character devices:
1 mem
4 /dev/vc/0
4 tty
5 /dev/tty
5 /dev/console
5 /dev/ptmx
7 vcs
10 misc
13 input
29 fb
89 i2c
108 ppp
128 ptm
136 pts
180 usb
188 ttyUSB
189 usb_device
207 ttymxc
252 mwan
253 pmic
254 rtc

Block devices:
259 blkext
7 loop
179 mmc

@bulsa:
Shoot... it makes sense that the 3G would be using the OTG. Also, the config has USB driver for GSM and CDMA modems enabled (CONFIG_USB_SERIAL_OPTION=m), so it appears likely. I may end up having to go ttl->bt for some semblance of periphery. Albeit a cool hack, I'd rather completely discount the OTG before I solder on a level shifter, serial bt module, and likely cut a hole in my case. Another idea... the Wifi-only PW1... does it not have the modem, or did they just not put a sim in it? Anyways, here's my lsusb- hopefully it will shed some light:
lsusb -t

Bus 001 Device 001: ID 1d6b:0002
Bus 001 Device 002: ID 1949:9001

I'm very familiar with linux and development, just not the low level hardware and drivers. So if you need me to run a specific command on the kindle, lay it on me. ANY AND ALL ASSISTANCE WELCOME.

I noticed that unionfs on the kindle is broken. You can mount just fine, but when you access the rw/union directory, it locks up. So using this process I patched in and compiled AuFS-standalone+utils. I'm playing with it right now. Hopefully it will make optware a simple process (cram/squashfs, no need to bind new directories).

If anyone wants to discuss opkg/optware/cramfs/aufs, please PM me. I should have a release this week.

[finitelife]

Brainwave...

To configure for PW1 WiFi:

make ARCH=arm imx50_yoshime_defconfig

To configure for PW1 3G:

make ARCH=arm imx50_yoshime3_defconfig

Original post updated.

[lyssdod]

Great work!

Some time ago I also wanted to try this idea (https://www.mobileread.com/forums/sho...d.php?t=242506), but I had to pause it for a while because of lots of stuff at work.

Glad to see someone got it working

I have K4NT, will try to build some modules on it using your manual.

[knc1]

Originally Posted by finitelife

- - - -

In enabling the hall sensor, I noticed HALL_MISC_DEV_NAME and HALL_DEV_MINOR. Not sure what the values should be. Any help there would be appreciated.

Here's the output of 'cat /proc/devices':

- - - -

1* Not shown in /proc/devices
2* Reasonable, otherwise there would be *DEV_NAME, *DEV_MAJOR and *DEV_MINOR
3* I expect its on the I2C bus

Hmm...
There is a Linux utility for scanning the I2C bus -
You will most likely have to cross-build it for ARM and run it on a live device.

It is part of the utility set XXX (damn't forgot the name) -
If you can't find it - remind me to look for it in about 14 hours.

[finitelife]

i2c-utils didn't reveal much

i2cdetect -l

i2c-0 i2c mxc_i2c I2C adapter
i2c-1 i2c mxc_i2c I2C adapter
i2c-2 i2c mxc_i2c I2C adapter

i dmesg'd hall and i2c, even tried 'echo 1 > /sys/devices/system/yoshime_hall/yoshime_hall0/hall_debug'. nothing yet. Still, having some fun with magnets right now.

[bulsa]

Originally Posted by finitelife

I am actively pursuing fixes to the FB_MXC_EINK_PANEL problem currently. I'd like to blame the dev environment, but so far everything has been Amazon oversight. Fingers crossed, coffee at the ready.

Look for the two NEON #if in drivers/video/mxc/mxc_epdc_fb.c and replace them with "#if 0", then you just need the missing #defines/struct members in include/linux/mxcfb.h, they should be present in the PW2 source.

[knc1]

Originally Posted by finitelife

i2c-utils didn't reveal much
- - - - -

That is the list of the three I2C bus's present, next you have to tell the utility to walk each of those bus's.

The name I couldn't recall yesterday is: "lm-sensors"
And:
http://www.lm-sensors.org/wiki/man/i2cdetect
So:
i2cdetect -F i2c-0
* i2c-1
* i2c-2

Should find the hall sensor if it is there.

Since your missing two values (*Name and *Address) I expect the first will be "i2c-?" and the scanner will give you the byte address of the device.

[knc1]

Originally Posted by lyssdod

I have K4NT, will try to build some modules on it using your manual.

Most likely already built and attached to my thread on the subject (and the work is also in a public repository).

[eureka]

Originally Posted by finitelife

If anyone wants to discuss opkg/optware/cramfs/aufs, please PM me. I should have a release this week.

JFYI: topic opkg, opkg GUI and plans on package repository for Kindle Touch. contains working script for installing mini_fo (overlay filesystem) module and opkg (putting packages on rootfs overlay). Thread Overlay for root filesystem contains technical details of the overlay mounting process.

I'd vote for xbps instead of opkg.

You may also be interested in recipe for reparitioning userstore (FAT partition) without any harm for stock firmware. Further messsage in that thread shows how to use space available after shrinking userstore for separate writable ext3 partition accessible even when Kindle is connected to computer.