PaperWhite 1 Kernel Build Walkthrough

[finitelife]

I have once again updated the original post to include a now full kernel config. All the fixes are, from what I can tell, perfectly compatible with the PW1.

Special thanks to bulsa for looking forward into other source packages. With that in mind, I downloaded the newest kindle release for pw2 and managed to confirm all my fixes.

frontlight.h is 100% fixed.

lab126_hall.h is also 100% fixed. #define HALL_MISC_DEV_NAME "hall" ... Wow, should have guessed.

I am fairly certain that the FB_MXC_EINK_PANEL issues are resolved. I disabled the neon extensions, but they are only used once in the entire kernel and there is a fallback that seems compatible. With that in place, all I had to do was insert 5 defines to get a working build.

There are additional FB_MXC_* problems when using imx50_yoshime_defconfig. I may be be addressing them shortly, but if you just want modules, you can disable some stuff in the config (FB_EINK_HAL=m -> n FB_EINK_SHIM=m -> n)

From this point I will be working on 2 things;
1. testing/comparing the kernel/modules
- will add booting instructions asap
- will add single module instructions asap
2. switching to the included build_linaro-gcc_4.5.4.tar.gz toolchain
- seems simple enough
- this should allow for cross-compiling kernel modules with aligned symbols

My end goal of getting OTG working may not be feasible, but in any case I will be getting at least BT on this sucker, so all this is not in vain.

A note on running modules with the default kernel:
As far as I can tell, most of them work. FS modules complain about unknown symbols that do exist in the kernel, but the entry points are messed up. This is why I am switching toolchains.

More to come.

[bulsa]

I would be particularly grateful if you could upload a kernel binary with working usbnet and kexec . That would make testing kernels so much more fun.

[finitelife]

Originally Posted by bulsa

I would be particularly grateful if you could upload a kernel binary with working usbnet and kexec . That would make testing kernels so much more fun.

Done. First post Updated. That kernel also includes aufs, which I have yet to write up.

I've updated the instructions to allow easier toolchain and build root changes

I've switched to the included cross-linaro-gcc toolchain

[knc1]

I posted a two or three section "HowTo" on the auFS mailing list, sometime back.
Long enough ago that I have lost the link(s).
But an "archive search" there might find them (as mszick there, I think).

OR maybe jro indexed them from his main page.

[bulsa]

Originally Posted by finitelife

Done. First post Updated. That kernel also includes aufs, which I have yet to write up.

Sounds great! Just to be sure I won't brick my Kindle, is the kernel bootable without taking the initramfs from the existing kernel? I remember reading something like this was necessary for older kindles.

Are you sure your modules are working the way you packaged them? They are in a path containg "2.6.31-rt11-lab126", but in modules.dep you list them as "2.6.22.19-lab126".

[knc1]

Originally Posted by bulsa

Sounds great! Just to be sure I won't brick my Kindle, is the kernel bootable without taking the initramfs from the existing kernel? I remember reading something like this was necessary for older kindles.

Are you sure your modules are working the way you packaged them? They are in a path containg "2.6.31-rt11-lab126", but in modules.dep you list them as "2.6.22.19-lab126".

They will work from anywhere,
**IF** you use the individual commands and full path/filename(s).
You also have to pre-load dependencies yourself this way.

If you want to use the auto-dependency loading command(s), such as: modprobe
The above organization breaks the automation.

[finitelife]

Originally Posted by bulsa

Sounds great! Just to be sure I won't brick my Kindle, is the kernel bootable without taking the initramfs from the existing kernel? I remember reading something like this was necessary for older kindles.

Are you sure your modules are working the way you packaged them? They are in a path containg "2.6.31-rt11-lab126", but in modules.dep you list them as "2.6.22.19-lab126".

Good catch- I've updated the first post and the kernel image with the correct path

As for the initramfs... I don't think we need it. The baseline config for the kernel is intact, and all the original fs support is compiled in. Also, CONFIG_INITRAMFS_SOURCE is unset, so I'm going to say no.

That being said, you could still easily brick. I've just been testing the modules (which work fine afaik).

Have a serial cable ready.

[finitelife]

Update: yoshime and yoshime3 both build using the instructions provided. Only the fs modules (ntfs,ext4,aufs) don't load on the standard kernel. They complain about unresolved symbols. My troubleshooting is as follows;

So I've patched in the aufs-standalone module (2.6-31) and compiled it using multiple toolchains (including the one used to compile the default kernel). Still no luck.

Grabbing the default toolchain (ldd --version):

ldd (Sourcery G++ Lite 2009q3-67) 2.10.1
...

Getting errors after insmod aufs.ko (dmesg):

...
aufs: Unknown symbol __lookup_one_len
aufs: Unknown symbol lookup_hash
aufs: Unknown symbol cap_file_mmap
aufs: Unknown symbol do_truncate
aufs: Unknown symbol deny_write_access

Checking exported kernel symbols (cat /proc/kallsyms):

...
c01868fc t __lookup_one_len.clone.26
c0185818 t __lookup_hash
c0185940 t lookup_hash
c0239fe8 T cap_file_mmap
c017c570 T do_truncate
c0187da8 T deny_write_access
...

Checking aufs symbols (nm --demangle aufs.ko):

...
U __lookup_one_len
U lookup_one_len
U lookup_hash
U cap_file_mmap
U do_truncate
U deny_write_access
...

Once more with feeling (objdump -t aufs.ko):

...
00000000 *UND* 00000000 __lookup_one_len
00000000 *UND* 00000000 lookup_hash
00000000 *UND* 00000000 cap_file_mmap
00000000 *UND* 00000000 do_truncate
00000000 *UND* 00000000 deny_write_access
...

I'm a little fuzzy on what this all means, but from my understanding, the kernel has the symbols exported, as does aufs. The problem here is that the symbol addresses aren't aligned. If this is so... is there a way to manually set the aufs symbol?

Should I be setting CONFIG_MODVERSIONS=y ?

Any ideas?

[knc1]

Compile auFS as a built-in, rather than as a module.
Also ensure that the build isn't picking up the host Linux headers or the toolchain Linux headers.
(There is something funky in those reports.)

See what the results are.

ModVersions == **NO** - don't version them if you can avoid it.

- - - - -

Note: The 2.6.31 auFS is too old. It is no longer maintained.
(Hey, auFS is a lot of work, and is still only a single author project.)

But was active for a long time - we should be able to figure this out with a bit of M.L. archive diving.
And without bugging jro.