Buildroot a linux 2.6.26-lab126 kernal. (3.3)

[hawhill]

Originally Posted by knc1

Here is another module to build:

# CONFIG_BLK_DEV_NBD is not set

Both Hawhill and GM have mentioned using that device, maybe they would like to let the Kindle kernel be the NBD server.

Nah, that's the "client side", i.e. the part that lets the kernel speak over network and present a block device. But thanks for noticing :-) On the Kindle, I do not see low-hanging fruits yet which would involve it. Servers can be (and usually are) userland programs. After all, they are just network servers.

(Short background: The k3flasher tool has a mode in which it presents the flash storage of a connected Kindle 3 via an NBD server. I used that because it is a dead-simple API to create a block device in userspace. Kind of a BUSE - block device in userspace, see FUSE for how I made that acronym up).

Though great progress here. I was thinking about creating a pure "open" Kindle OS, too (involving kindlepdfreader, simply since I know it well). But then, time...

[knc1]

Originally Posted by twobob

right. so I have decided to kill two birds with one stone then.


Grabbed a more compliant toolchain: from https://www.mobileread.com/forums/sho...6&postcount=11 link to external was still good.

Nope.

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.

The CS/MG tool chain should be usable, otherwise we can use the Ubuntu-Linaro tool chain (a gcc-4.6 one).

When I wake tomorrow - I will check if I put one of those on the KeK resource server, if not, I will put one there.

- - - -

Now, the question of getting a native tool-chain built for your Buildroot generated rootfs . . . .

The short answer: We get to do it ourselves (for the first time).

The longer answer:
Buildroot 2012.08 will be out within a couple of weeks - anything other than bug-fixes will not be added to it during those weeks.

In Buildroot 2012.11 - that "Native build tools on target" should be moved to "depends on BROKEN".
Which is just fine, it can only generate a uClibc based set of native tools on the target (when, if, it works and your extra lucky).

I have exchanged (on the BR M.L.) a few posts with the author of ct-ng . . . .
At the moment, ct-ng isn't ready to take over for the internal BR tool-chain generation in all situations, but the above BR change will mean that the internal one will not be replaced earlier than 2013.05.
So ct-ng **might** be "ready" within that time frame.

In addition to the "not ready" items of ct-ng . . . .
It has a config menu entry of: cross-native
but that entry doesn't have any code behind it at the moment (and is not likely to grow any, unless someone submits patches to add it).

We **could** patch BR-2012.08 to compile and cross-compile (both host and target) the tools and libraries required to support a tool-chain build as new "packages" rather than part of the "Broken" tool-chain generation.

Then we **could** patch ct-ng to cross-compile binutils, (e)glibc, and a bootstrap (I.E: "First stage") gcc build.

There is a good chance of getting those patches accepted by both BR and ct-ng.

Now, to finish up the gcc build (stages two and three) -
That would have to be done by "cherry picking" the rootfs built by BR into a rootfs that can be run under emulation and hand-off the second and third stage gcc build to the emulator.

Once that is done, then the new, tested, native, gcc can build the final native binutils and system library(ies) under the same emulator instance.

Pant, pant, pant, pant . . . .
Sounds like a lot of Makefile writing to me, but working with the two project teams makes it much more likely that it could happen.

It was a chore just writing this description, but the Makefile snippets that need to be patched into the two systems are just the things we would have to do by hand to add a tool-chain to your rootfs.

[twobob]

Right. So as it stands. a) I have the wrong stuff, again : )

b) in order to facilitate the use of something like BR to create us a truly native chain we need to do a bit of hand-canadian? Understood. I think. sounds a bit like compiling in the old days on a donor machine with enough memory to make a compiler. I'm sure I'll be able to get my head around it.

c) getting stuff included in the various toolchains actually **might** happen, well that sounds worth investigating. if we can get a native kindle builder OOB then by Jiminy it has to be something at least worth pursuing. my experience of BR has been - as you initially suggested - solid, outside of known experimental side-issues with static.

d) we need to cherry pick BR structure. well that at least is easy. one bash script.

e) we need to patch makefiles. Installed Merge and now getting my head around patch and diff on linux. patch has me a bit fuzzy when referring to folders rather than files but it will all drop into place. Patching the files themselves is at the edge of my price range in terms of skills right now but I'm learning as I go Nilujes patches are a bit ninja to we lesser mortals but giving them a good read does tell me lot (like - I need to know more). More of that type of thing for me I imagine.

f) config and launch a(n) interim/final compile of the tools - again another script. that part at least should be near trivial once we have the right settings.

So yeah, sounds do-able. Heavens aligning and all that. see what tomorrow brings.
Really would like to put my toolset to bed. I just want w/e amazon used lol. that will do

[twobob]

Originally Posted by hawhill

. Kind of a BUSE - block device in userspace...

aBuse Block Device? Genius.

[twobob]

Originally Posted by knc1

Nope.

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.

The CS/MG tool chain should be usable, otherwise we can use the Ubuntu-Linaro tool chain (a gcc-4.6 one).

When I wake tomorrow - I will check if I put one of those on the KeK resource server, if not, I will put one there.

- - - -.

Hmm well there are a bunch there.

I don't mean to appear stupid. but I clearly am. How the hell does one tell from a name which gcc it is?

google it? thanks. :\

[twobob]

The arm 2012.03 spits out too high a version as far as I can tell. (EDIT: FOR SOME THINGS)

As you say the version I linked is too old (Ill update is with the RIGHT link when I get one)

[knc1]

Originally Posted by twobob

Hmm well there are a bunch there.

I don't mean to appear stupid. but I clearly am. How the hell does one tell from a name which gcc it is?

google it? thanks. :\

For the one you linked to, it is in the archive name.

For most of the ones on the KeK server, you have to follow the link to release page, or read the changes file (sometimes called: getting started) or just believe me, that I looked it up.

I didn't make the links click-able in the reference manual for the "historic" compilers but if your trying to duplicate the lab126 setup - those are mentioned (by file name) in the "historic compilers" section of the manual and are present already on the KeK server.

http://knetconnect.com/KeK/KeK_refer...bsection-B.1.1

[NiLuJe]

@twobo: The kernel is *very* strict when checking modules. They must have been built with more or less the exact same GCC version as the running kernel to be loaded. Either flash your custom kernel, or use the same ancient TC Amazon used (one of the CodeSourcery from 2009, IIRC)...

That, and you probably need an up to date symbols table (depmod & co, with the modules in the right place in /lib/modules).

[knc1]

Originally Posted by NiLuJe

@twobo: The kernel is *very* strict when checking modules. They must have been built with more or less the exact same GCC version as the running kernel to be loaded. Either flash your custom kernel, or use the same ancient TC Amazon used (one of the CodeSourcery from 2009, IIRC)...

That, and you probably need an up to date symbols table (depmod & co).

But he already got binfmt_misc to load on his unmodified K3 from the user storage area.
So we have that covered.

The only incompatibility is with the Rob Landley compiler in our emulation image.
That is easy to solve - will just bit bucket that image

[geekmaster]

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.
...

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

[twobob]

well. the fuse module.ko seems fine. that was built with CS TS

but i really want the perfect match one for two reasons. 1) so I have it 2) so that's what is clearly documented on here and in use on the Buildroot project one.

If we are going to make an amazon compliant kernal builder and new resource building machine let's offer all the helping hands we can.

Make it fully compat and let the user work back from there rather than the other way round.

Also a nice list of these tweaks (I have managed to find a few whilst browsing but something cohesive) all splattered into an autotool sounds like paradise compared to the current melange of offerings.

I know that perhaps some will want the shiny and newest, and if that is the case then they can by all means - clicky button that makes it all CS new release - again and no hard feelings.

But there is no button for 'make it a damn close fit to a kindle 3' and then going forward perhaps we can expand on that but a clear list of steps to include the correct Headers, where from, what needs patching and at least a one liner about why, a few notes on handy CFLAGS or w/e and I think we have something that is very usable - and more to the point is the start of us devving GOTO references for more ugly and insidious wangles like the USB support and other hideous projects that some poor soul will no doubt find themselves doing.

They are my thoughts, feel free to throw rocks.

EDIT: The facility to inject /mnt/us* (or w/e) for SYSROOT in USR packages (or maybe even as a default with overrides . w/e ) would also be a bonus. I have the start of an amended BR skeleton to this end that could be added to the references.

[knc1]

Sort of like the breakdown in the KeK reference manual -

"Historic" (I.E: close match to original build tools of lab126) - there are two of them, K4&K5, everything else.

"Modern" (I.E: Ubuntu-core prior to the switch to multi-lib/multi-arch)
(This is what you have been using, and I still think you should archive that file glob in case you want to go back to it someday)

"Bleeding Edge" (I.E: Ubuntu-core after the switch to multi-lib/multi-arch (gcc-4.7, ld.so.3)

Those are already on the KeK resource server and I can revise the manual so they have click-links if that is really needed.

No: GenToo-From-Scratch - I will let other people supply that one.
Maybe: Ada
Found, waiting to be tested: Pascal.

One of the things I did not do was mirror the Amazon source releases. Maybe I should, manufacturers sometimes pull those "old" files without warning.

[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).

[knc1]

Originally Posted by geekmaster

(reserved)

Warning: Excessive whitespace.

[geekmaster]

Originally Posted by knc1

Warning: Excessive whitespace.

I had some EABI download links instead of gnueabi, so I temporarily changed it to (reserved). It now has a 2008q1-126 link, which contains gcc 4.2.3.