Making a ctng Toolchain for the Kindle Touch via Buildroot

[twobob]

Hi.

I am endeavouring to make a nicely matching toolchain for the kindle touch using cross-tools ng.

http://crosstool-ng.org/#download_and_usage

This is because for some reason - I haven't got to the bottom of - the kernel headers don't "install" as I would expect on the prebuilt Toolchains (linux/eink.h missing for example after installation)

So. I fired up make ctng-menuconfig.

selected 32bit little endian Cortex A8

GCC 4.5.4
eglibc 2.12

all the settings outlined in https://www.mobileread.com/forums/sho...6&postcount=17

and pointed it to a custom folder for my kernel /usr/local/src/BUILD_KERNAL_5.1.2/gplrelease

(setup the other stuff to sensible defaults)

I also then saved out the .config file to
~/GIT/k5ctng/toolchain/toolchain-crosstool-ng folder as a custom -kindle named config file for future reference.

.config was from here
~/GIT/k5ctng/output/build/build-toolchain/.config

and then run a make.

all software is not enabled, nor is busybox etc...

which fails with:

[ALL ] make[3]: Leaving directory `~/GIT/k5ctng/output/build/build-toolchain/.build/arm-unknown-linux-gnueabi/build/build-cc-core-pass-1'
[ALL ] `~/GIT/k5ctng/output/build/build-toolchain/.build/arm-unknown-linux-gnueabi/buildtools/bin/arm-unknown-linux-gnueabi-cc' -> `arm-unknown-linux-gnueabi-gcc'
[INFO ] Installing pass-1 core C compiler: done in 73.02s (at 05:25)
[INFO ] ================================================== ===============
[INFO ] Installing kernel headers
[EXTRA] Installing kernel headers
[ALL ] make[3]: Entering directory `/usr/local/src/BUILD_KERNAL_5.1.2/gplrelease'
[ALL ] CHK include/linux/version.h
[ALL ] UPD include/linux/version.h
[ALL ] HOSTCC scripts/basic/fixdep
[ALL ] HOSTCC scripts/basic/docproc
[ALL ] HOSTCC scripts/basic/hash
[ALL ] HOSTCC scripts/unifdef
[ALL ] REMOVE cdev.h
[ALL ] INSTALL include/linux (374 files)
[ALL ] make[3]: Leaving directory `/usr/local/src/BUILD_KERNAL_5.1.2/gplrelease'
[EXTRA] Checking installed headers
[ALL ] make[3]: Entering directory `/usr/local/src/BUILD_KERNAL_5.1.2/gplrelease'
[ALL ] CHK include/linux/version.h
[ALL ] make[5]: `scripts/unifdef' is up to date.
[ALL ] CHECK include/linux (374 files)
[ALL ] ~/GIT/k5ctng/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/include/linux/fsl_devices.h:23: included file 'linux/cdev.h' is not exported
[ALL ] ~/GIT/k5ctng/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/include/linux/mxc_pf.h:53: found __[us]{8,16,32,64} type without #include <linux/types.h>

the file is indeed not exported (pictured) to
~GIT/k5ctng/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/include/linux

it (cdev.h) does exist in the kernel sources however.

so I guess my question is in order to fix such an error am I to use an #ifdef something ?

or have I foofed in the config? is it not being pulled because of some slight versioning issue. am digging around for clues but all help accepted.

further details available upon request. Thanks : )

[knc1]

Post the same to the BR mailing list (**not** the bug report thing, the mailing list).
There aren't enough BR people on this forum to help with that question.

[twobob]

I noted

Originally Posted by knc1

As can be seen from the above link (which lists version details of the dependencies), probably the best recommendation that can be made here is to use the second choice above (crosstool-ng) and set its configuration to download and build the older, 2.6.12 system library set.
Be certain to also set the kernel headers selection to 2.6.16 (the prior "build ABI standard") in the crosstool-ng configuration for the system libraries.

Note: The same comments above apply to using Buildroot (which can use crosstool-ng for its tool-chain building).

so I'm checking that

[twobob]

Originally Posted by knc1

Post the same to the BR mailing list (**not** the bug report thing, the mailing list).
There aren't enough BR people on this forum to help with that question.

okay. will do

[knc1]

Besides, most of those people are within 1 time zone of you, on your side of the pond.

[NiLuJe]

@twobob: I can gzip my ct-ng config, if you want, but, basically, it's outlined here, second column .

I went with Linaro 4.7/eglibc 2_12/Linux 2.6.31.14 (I rarely use lab126's kernels for a TC).

[twobob]

Originally Posted by NiLuJe

@twobob: I can gzip my ct-ng config, if you want, but, basically, it's outlined here, second column .

I went with Linaro 4.7/eglibc 2_12/Linux 2.6.31.14 (I rarely use lab126's kernels for a TC).

Okay, for now I have just pulled the -rt11 source and gone with the generic .14 flavour as you suggested.

how does one make kernel headers install correctly in this instance then?
eink.h for example. is it simply a case of copying them across?

much obliged.

very helpful link to your config mate.

[NiLuJe]

@twobob: Well, there's probably no eink.h in the mainline kernel, so... .

AFAIK, every project that wanted to rely on it bundled a version of it in their own project's includes. That might not be pretty, but it works .

If you plan to use it in a more widespread manner, putting it in the proper place might be a cleaner solution, but you'd have to use lab126's kernel, or patch mainline. (And given your experience with the first choice, it might *also* imply taking a hammer to some makefiles to fix it ^^).

EDIT: Attached my ct-ng config. (It's from a live mercurial version of ct-ng, so it might not be adequate for older releases).

[twobob]

Originally Posted by NiLuJe

@twobob: Well, there's probably no eink.h in the mainline kernel, so... .

AFAIK, every project that wanted to rely on it bundled a version of it in their own project's includes. That might not be pretty, but it works .

If you plan to use it in a more widespread manner, putting it in the proper place might be a cleaner solution, but you'd have to use lab126's kernel, or patch mainline. (And given your experience with the first choice, it might *also* imply taking a hammer to some makefiles to fix it ^^).

EDIT: Attached my ct-ng config. (It's from a live mercurial version of ct-ng, so it might not be adequate for older releases).

Ah phooey. Well. that's a bit of a PITA.

well. I'll give the first solution (mainstream) a try first.

[twobob]

so I went for the standard kernel

now I get...

checking installed Linux kernel header files... 2.0.10 or later
[CFG ] configure: WARNING: minimum kernel version reset to 2.6.16
[CFG ] checking for kernel header at least 2.6.16... ok
[CFG ] running configure fragment for ports/sysdeps/arm
[CFG ] checking whether the CFI directive .cfi_sections is supported... no
[ERROR] configure: error: need .cfi_sections in this configuration
[ERROR]
[ERROR] >>
[ERROR] >> Build failed in step 'Installing C library headers & start files'
[ERROR] >> called in step '(top-level)'
[ERROR] >>
[ERROR] >> Error happened in: CT_DoExecLog[scripts/functions@172]
[ERROR] >> called from: do_libc_backend_once[scripts/build/libc/glibc-eglibc.sh-common@347]
[ERROR] >> called from: do_libc_backend[scripts/build/libc/glibc-eglibc.sh-common@143]
[ERROR] >> called from: do_libc_start_files[scripts/build/libc/glibc-eglibc.sh-common@60]

Which I "understand" to be reference to arm debugging symbols.

EDIT: I'll step back to glibc2.11 and see what happens then

[EXTRA] Removing access to the build system tools
[EXTRA] Removing installed documentation
[INFO ] Cleaning-up the toolchain's directory: done in 1.15s (at 22:19)
[INFO ] Build completed at 20121016.174411
[INFO ] (elapsed: 22:18.62)
[INFO ] Finishing installation (may take a few seconds)...

YAY

[NiLuJe]

@twobob: That seems to imply that you're using a binutils version too old to build this libc. (FWIW, I'm using 2.22).

[twobob]

Originally Posted by NiLuJe

@twobob: That seems to imply that you're using a binutils version too old to build this libc. (FWIW, I'm using 2.22).

Ah thanks.

2.20 I believe. glibc2.11 builds okay with binutils 2.18

I could drag it forward a spot then... and try 2.12 next then

I misnamed my tuple (oops) so it will have to wait 30 mins or so
while I do a quickie rebuild and test.

EDIT: Okay, retrying with 2.20 now... and 2.12 - Fail

Retrying with 2.21.1 and 2.12

[knc1]

This "re-work" business is certainly more difficult than the "just make it, our way" business.

I would bump your karma through the roof for all this work, if the system would let me.

[twobob]

Originally Posted by knc1

This "re-work" business is certainly more difficult than the "just make it, our way" business.

I would bump your karma through the roof for all this work, if the system would let me.

Yup, hopefully should give us a nice stable(ish) and broad enough pallete of tools to throw at the BR file lists.

Got another odd error now - the tuple keeps getting messed up, sigh.

I'll figure it out in the end.

[baf]

If you still have problems, here is config that worked for me.
crosstool-ng-1.15.2
linaro-4.7-2012.04
glibc 2.12.1
binutils 2.20.1a
kernel 2.6.31.14