Buildroot a linux 2.6.26-lab126 kernal. (3.3)

[twobob]

Originally Posted by geekmaster

This codesourcery 2008q1-126 toolchain has gcc 4.2.3:
http://www.codesourcery.com/public/g...ux-gnu.tar.bz2

Righto. I'll set off a build with that. see how it fares. : )

Much obliged. (Didn't see your stealth message! some kind of skunk tech??)

[twobob]

Originally Posted by NiLuJe

@twobob: Never played with the Kernel, but you might want to give the 'depmod with the custom modules put in the right place in /lib/modules' thing a go, if you managed to force-inject a custom-built module once.

On the TC front, more or less what knc1 said, except I'd stay away from multilib/interwork TC, unless you want a wall with an embossed version of your head on it ^^. And the things I mentioned/are commented in my x-tc script if you're using something recent and targetting the K2/3 (kill gcc's ssp: -fno-stack-protector in CFLAGS & CXXFLAGS, kill glibc's fortify: -U_FORTIFY_SOURCE in CPPFLAGS).

Yep those are the flags I managed to glean so far.

There was some talk on a thread somewhere - that I fail to find right now as per - that did have a nice list of compiler optimisations too (with tests for why they were decent choices) they would be a nice addition to a) this thread and b) the project effort as a whole. I'll see if I can find it. I think GM was chatting on it.

At the end of the day the type of people I envision - "Having a go" - at porting something will thank us for ensuring that the maximum amount of stuff-that-can-go-wrong has at least be thought about, documented, or covered. Thinking about it that's exactly what I would like too!

So I will pretty much go with the consensus on best TC - knc has some string and clear ideas about what the possible benefits of such an endeavour could be so I defer to him on the final say on these matters. This kind of input is invaluable in making good decisions, thank you.

So GM recommended TC DL (thanks GM, I really have to get my knowledge of this stuff sorted) Let's see how she goes.

EDIT:

[root@kindle fs]# strace -o /mnt/us/modules/gm-2008-CS.tc insmod /mnt/us/modules/smbfs.ko
insmod: error inserting '/mnt/us/modules/smbfs.ko': -1 Unknown symbol in module
[root@kindle fs]#

Fail

Spoiler:

execve("/sbin/insmod", ["insmod", "/mnt/us/modules/smbfs.ko"], [/* 22 vars */]) = 0
brk(0)                                  = 0x12000
uname({sys="Linux", node="kindle", ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001b000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/var/run/ld.so.cache", O_RDONLY)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=13788, ...}) = 0
mmap2(NULL, 13788, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001c000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\250J\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1348230, ...}) = 0
mmap2(NULL, 1135004, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40025000
mprotect(0x4012e000, 28672, PROT_NONE)  = 0
mmap2(0x40135000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x108) = 0x40135000
mmap2(0x40138000, 8604, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40138000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40020000
set_tls(0x400204a0, 0x400204a0, 0x40024058, 0x40020b78, 0x40) = 0
mprotect(0x40135000, 8192, PROT_READ)   = 0
munmap(0x4001c000, 13788)               = 0
brk(0)                                  = 0x12000
brk(0x33000)                            = 0x33000
open("/mnt/us/modules/smbfs.ko", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\1\0(\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 16384) = 16384
read(3, "\0@\316\345P\21\33\345\0P\301\345T1\33\345\0 \303\345X\341\33\345\0`\316\345L\21\33\345"..., 16384) = 16384
read(3, "\f@\223\345\2p\240\341\4\0\240\341\376\377\377\353\0PP\342\7\0\0\n\24 \224\345<\20\237\345"..., 32768) = 32768
read(3, "\0\0\0\0\0\0\2\0\362\6\0\0\4r\0\0\364\0\0\0\2\0\2\0\27\0\0\0\4r\0\0"..., 65536) = 10084
read(3, "", 55452)                      = 0
close(3)                                = 0
init_module(0x12018, 75620, "")         = -1 ENOENT (No such file or directory)
write(2, "insmod: error inserting '/mnt/us"..., 80) = 80
exit_group(1)                           = ?
+++ exited with 1 +++

Hmm Dunno.

I'll try again tomorrow with knc's recommendation when it sufaces : )
see how we go.

[twobob]

If knc1 is right and we can create a truly native compiler, I suppose none of those details will matter in one sense. Hmm. Dunno.

[geekmaster]

Originally Posted by twobob

Righto. I'll set off a build with that. see how it fares. : )

Much obliged. (Didn't see your stealth message! some kind of skunk tech??)

I just downloaded and extracted it. Running:
/CodeSourcery/arm-2008q1/bin/arm-none-linux-gnueabi-gcc --ver
shows:
gcc version 4.2.3 (Sourcery G++ Lite 2008q1-126)

[twobob]

Originally Posted by geekmaster

I just downloaded and extracted it. Running:
/CodeSourcery/arm-2008q1/bin/arm-none-linux-gnueabi-gcc --ver
shows:
gcc version 4.2.3 (Sourcery G++ Lite 2008q1-126)

And the really weird thing?

[root@kindle fs]# strace -o /mnt/us/modules/gm-2008-CS.tc insmod /mnt/us/modules/binfmt_misc.ko

Spoiler:

execve("/sbin/insmod", ["insmod", "/mnt/us/modules/binfmt_misc.ko"], [/* 22 vars */]) = 0
brk(0)                                  = 0x12000
uname({sys="Linux", node="kindle", ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001b000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/var/run/ld.so.cache", O_RDONLY)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=13788, ...}) = 0
mmap2(NULL, 13788, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001c000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\250J\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1348230, ...}) = 0
mmap2(NULL, 1135004, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40025000
mprotect(0x4012e000, 28672, PROT_NONE)  = 0
mmap2(0x40135000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x108) = 0x40135000
mmap2(0x40138000, 8604, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40138000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40020000
set_tls(0x400204a0, 0x400204a0, 0x40024058, 0x40020b78, 0x40) = 0
mprotect(0x40135000, 8192, PROT_READ)   = 0
munmap(0x4001c000, 13788)               = 0
brk(0)                                  = 0x12000
brk(0x33000)                            = 0x33000
open("/mnt/us/modules/binfmt_misc.ko", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\1\0(\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 16384) = 14041
read(3, "", 2343)                       = 0
close(3)                                = 0
init_module(0x12018, 14041, "")         = 0
exit_group(0)                           = ?
+++ exited with 0 +++

worked for this toolchain as well?

Spoiler:

[root@kindle fs]# lsmod
Module                  Size  Used by
option                 12512  2 
usbserial              27756  5 option
ehci_hcd               38880  1 option
usbcore               136388  4 option,usbserial,ehci_hcd
binfmt_misc             8392  0 
g_serial               16844  0 
arcotg_udc             38628  1 g_serial
ar6000                161076  0 
ppp_async               8612  1 
crc_ccitt               1856  1 ppp_async
ppp_generic            19252  5 ppp_async
slhc                    5984  1 ppp_generic
volume                  8900  1 
fiveway                23552  1 
mxc_keyb               15904  1 
uinput                  7776  0 
fuse                   48348  2 
mwan                    7324  2 ehci_hcd,ppp_async
eink_fb_shim          118588  0 
eink_fb_hal_broads    397532  0 
eink_fb_hal            59764  8 eink_fb_shim,eink_fb_hal_broads
[root@kindle fs]# rmmod binfmt_misc
[root@kindle fs]# strace -o /mnt/us/modules/gm-2008-CS.tc insmod /mnt/us/modules/binfmt_misc.ko 
[root@kindle fs]# lsmod
Module                  Size  Used by
binfmt_misc             8424  0 
option                 12512  2 
usbserial              27756  5 option
ehci_hcd               38880  1 option
usbcore               136388  4 option,usbserial,ehci_hcd
g_serial               16844  0 
arcotg_udc             38628  1 g_serial
ar6000                161076  0 
ppp_async               8612  1 
crc_ccitt               1856  1 ppp_async
ppp_generic            19252  5 ppp_async
slhc                    5984  1 ppp_generic
volume                  8900  1 
fiveway                23552  1 
mxc_keyb               15904  1 
uinput                  7776  0 
fuse                   48348  2 
mwan                    7324  2 ehci_hcd,ppp_async
eink_fb_shim          118588  0 
eink_fb_hal_broads    397532  0 
eink_fb_hal            59764  8 eink_fb_shim,eink_fb_hal_broads

where the others modules failed???:

maybe if I had tried other modules with my original TC they too would have failed... Hmm. Better test that tomorrow.
Sigh, just when you think you've got it sorted....

[twobob]

Original toolchain

Originally Posted by twobob

binfmt_misc             8392  0

and the latest one:

Module                  Size  Used by
binfmt_misc             8424  0

different sizes so definitely different files..

Hmm... err.. tomorrow.

[knc1]

Originally Posted by geekmaster

I just downloaded and extracted it. Running:
/CodeSourcery/arm-2008q1/bin/arm-none-linux-gnueabi-gcc --ver
shows:
gcc version 4.2.3 (Sourcery G++ Lite 2008q1-126)

Not even close.

Ref: https://wiki.mobileread.com/wiki/Tool...Anix_Knowledge

core2quad bin $ pwd
  /mnt/k321/bin
core2quad bin $ objdump -sx mountpoint
 - - - -
Contents of section .comment:
 0000 00474343 3a202847 4e552920 342e312e  .GCC: (GNU) 4.1.
 0010 31000047 43433a20 28474e55 2920342e  1..GCC: (GNU) 4.
 0020 312e3100 00474343 3a202847 4e552920  1.1..GCC: (GNU) 
 0030 342e312e 32000047 43433a20 28474e55  4.1.2..GCC: (GNU
 0040 2920342e 312e3200 00474343 3a202847  ) 4.1.2..GCC: (G
 0050 4e552920 342e312e 31000047 43433a20  NU) 4.1.1..GCC: 
 0060 28474e55 2920342e 312e3200 00474343  (GNU) 4.1.2..GCC
 0070 3a202847 4e552920 342e312e 3100      : (GNU) 4.1.1.  
Contents of section .ARM.attributes:
 0000 410f0000 00616561 62690001 05000000  A....aeabi......

[geekmaster]

Originally Posted by knc1

Not even close.
...

Not close to WHAT? You said:

Originally Posted by knc1

...
You want to build a (e)glibc based system and that is a gcc-4.2 series tool-chain.
gcc-4.2 series is too old to build a current (e)glibc system library.
...

So I provided a link to "a gcc-4.2 series tool-chain". How is that "not even close"?

Is this a "Canadian Cross" issue, where we need a "newer than 4.2.x" version x86 TC to build a gcc 4.2.x ARM native toolchain?

What does your "4.1.1/4.1.2" hex dump have to do with 4.2.x/newer than 4.2.x?

How is your link to the "*nix" section of your wiki page relevant to these gcc TC versions?

[knc1]

NO - two different objectives being discussed here.

One - Twobob wants to build a current (e)glibc tool chain. For that, the link he had was to a 4.2 series compiler which is too old to build the current glibc.

Second - Duplicate the original build tools of lab126. For that, as provided on the KeK resource server:

core2quad bin $ pwd
/home/mszick/arm-2006q3/bin
core2quad bin $ ./arm-none-linux-gnueabi-gcc --version
arm-none-linux-gnueabi-gcc (CodeSourcery ARM Sourcery G++ 2006q3-26) 4.1.1

Which is the closest CodeSourcery release to what lab126 used for the K3 system.

- - - -

Plus - I haven't seen **why** he wants to drop using the gcc-4.6 series tool chain he was using - it builds kernel modules acceptible to the Amazon kernel build.

There might be some C++ interworking problems, but we haven't seen any examples of that (yet).

The runtime Ruby errors are not related to the compiler that was used.

But I am sure Twobob has a plan in mind, so there is the closest compiler, already "in stock".

[geekmaster]

Originally Posted by knc1

NO - two different objectives being discussed here.
...

I just hope to use the final product(s) that you guys come up with, without having to devote too much attention to the "birthing pains" you guys are suffering here while bringing it to fruition. Thanks for the effort. Now "push".

[knc1]

Originally Posted by twobob

Original toolchain


and the latest one:

Module                  Size  Used by
binfmt_misc             8424  0

different sizes so definitely different files..

Hmm... err.. tomorrow.

That can be misleading, checking the over-all size of the file.

Use the binutils tools to isolate just the .text section of each and compare them.
(or, just dump the section headers, which list the sizes, and check those for size differences).

If you changed gcc versions between the two shown above, then yes, there should be size differences. Even with the same options and post-compile processing.

[NiLuJe]

@twobob:

K2/3: ARCH_FLAGS="-march=armv6j -mtune=arm1136jf-s -mfpu=vfp"
K4/5: ARCH_FLAGS="-march=armv7-a -mtune=cortex-a8 -mfpu=neon" (or -mfpu=vfpv3, which might in fact be a better choice right now, even with the latest Linaro GCC series, I have some benchmarks to do...)

The rest might start an unholy war, but I'd go with at least:
-O2 -ffast-math ${ARCH_FLAGS} -pipe -fomit-frame-pointer (unless you care about debugging stuff, in which case you'll want to replace all this with -O0 -g3 ${ARCH_FLAGS} -pipe -fno-omit-frame-pointer). (FWIW, Linaro recommends using -O3 or -Ofast on armv7... Again, I have some benchmarks to do ).

Unless you know that -ffast-math is going to break something, which should be approximately never, except for some really, really specific use cases.

All this with a softfp TC defaulting to softfp. Unless you're planning on taking over the entire system (and I do mean everything, because it *will* break Amazon's stuff with the latest Linaro releases, while it only *might* break stuff in fun and interesting ways otherwise ), in which case you can go with hardfloat.

And re: the kernel stuff: I'm still going with it needs a proper symbol table, while binfmt might not require some stuff exported, hence why it worked. At least check after a depmod run with the modules in the right place in /lib/modules, else it might need a full kernel flash & proper install. What does dmesg has to say about it? It should print the missing symbol(s), which should help pinpoint if it's indeed something that was EXPORT_SYMBOL'ed.

[geekmaster]

In case you are not aware of it, I used this patch a long time ago (when I first install CodeSourcery for a different ARM device):

https://www.ridgerun.com/developer/w...ain_2009q1-203

Using bash instead of dash

By default on Ubuntu systems, /bin/sh is linked to /bin/dash and that causes problems with certain versions of the toolchain and some SDK build scripts. Run the following commands to switch to using bash:
sudo rm /bin/sh
sudo ln -s /bin/bash /bin/sh

This may prevent possible build problems on Ubuntu-based systems such as Linux Mint.

[knc1]

@NiLuJe, towbob: Looks good, with two notes:

Originally Posted by gcc-4.6

If the selected floating-point hardware includes the NEON extension (e.g. -mfpu=`neon'), note that floating-point operations will not be used by GCC's auto-vectorization pass unless -funsafe-math-optimizations is also specified. This is because NEON hardware does not fully implement the IEEE 754 standard for floating-point arithmetic (in particular denormal values are treated as zero), so the use of NEON instructions may lead to a loss of precision.

Debian and Unbuntu have decided to move forward to newer minimum arm cores and using the half-wide floating point registers option:
-mfp=vfpv3-d16

Both notes above only apply to building code for the K4&K5 (armv7 core).

The other machines, which are actually vfp1.1, are matched by the gcc option 'vfp' (which in fact generates code for vfp1.1, vfp1 code never got into gcc before the change in the cores).

[knc1]

Originally Posted by knc1

But I am sure Twobob has a plan in mind, so there is the closest compiler, already "in stock".

My bad.
He does have a plan in mind, he wrote it, he posted it, I read it - - -
But none of that had any effect on my mind.

He wants to explore (or provide people with a way to explore) both ways of after-market modification of an embedded device (here: Kindles).

Create a complete system based on current software versions and selectively replace things with older versions as required to keep the device working.
(Most of his time so far has been on this track.)

Create a complete system based on the originally shipped software versions and selectively replace things with newer versions as required to advance the device features.
(This one is why he was looking for a "lab126-K3" compatible tool-chain.)

NOW, I have it sorted out in my mind, and perhaps this post will help others follow the work being done here.

The end result of all this will be a "check list" of things to do and things to avoid.
Sort of a "recommended practices" list - all in one place.