ARMhf on the Kindle(s)

[knc1]

Originally Posted by twobob

actually a lot less than I thought it was gonna have in there. 184 aint none but meh.

Encouraging

It is enough to "apt-get" anything else from the Ubuntu 14.04 LTS repository.

To make that work, I will have to mangle the "apt-get install" thingy to munge the executable and library headers + pre-pend our /mnt/us/esys tree to the installation point.

Which in turn means I will probably have to learn how to handle the snake (Python).

I expect the LuaJit.FFI interface to also help in that cause.

= = = =

Is this all worthwhile ?
I am not sure but this has one big advantage over running a distro in a loop mounted chroot - - -

Still have runtime access to all the existing Amazon system functions.
(Which can't be done from inside a chroot.)

Doing it all from FAT32 is just PFM.
(Entry #3: http://www.urbandictionary.com/define.php?term=PFM -
it dates back to before networking was even a wet dream in DARPA's eye.)

[twobob]

well said.

not much else to be said really. It's great idea and like most great ideas will be buckets of sweat to make work. ah the joy of effort-based reward.

I hear there is some

[knc1]

This (v-2.0.3) of LuaJit is still generating Rpi compatible code (ARMv5-VFP).

Two articles This article (old, from LuaJit-2.0.0-Beta era):
http://cellux.github.io/articles/int...luajit-part-1/

Just use BR 2014.05 rather than the BR 2012.11.1 mentioned in the article.

[knc1]

Ah, something is finally easy!

Since FAT32 does not support symbolic links;
We need to use loader script snippets to go from the link-time generated library name to the versioned library name ( libwhatever.so -> libwhatever.so.99 ).

The LuaJit documentation describes the: whatever -> libwhatever.so conversion in detail.
Without any mention of loader script handling.

**Sometimes you just get lucky:**
http://repo.or.cz/w/luajit-2.0.git/b.../src/lj_clib.c
line 80 and following.

tl;dr: The LuaJit library loader already recognizes: GROUP( .... ) and INPUT( .... ) loader scripts and uses them as in-direction to the actual filename.

- - - -

Edit:
Just from code reading (not testing) it looks like GROUP( ... ) is broken and INPUT( ... ) is broken for more than a single filename.
But we only need INPUT( ... ) with a single filename.

[knc1]

Project completion delayed by the demands of "life" on free time available.
Delayed, but not forgotten.

[knc1]

The required patches to Buildroot to support this development project are pending for inclusion in the 2014.08 release.

This is good news (tm) -
Means all that anyone will need is a copy of the project's BR config file(s) and a copy of the project's post-image processing script to duplicate any of this work.

Which of course I will post in this thread when it is all ready.

[knc1]

A bit early in the release plan, but a new thread to describe "how to do it":
https://www.mobileread.com/forums/sho...d.php?t=243061

[knc1]

Originally Posted by knc1

The required patches to Buildroot to support this development project are pending for inclusion in the 2014.08 release.
- - - - -

The Buildroot changes have been committed for the 2014.08 release.

As a requirement for creating a base filesystem for a target device (by cross-compiling), BR must also build some host tools.

Now, BR will build a copy of patchelf for your host machine.
Which can be used by a user-supplied, post image-build script to do the fixups required.

Although the original bug in BR concerning ld.so token handling could not be fixed. . . .
That problem has been documented and the above host tool provides a work-around.

[knc1]

With the intent of installing **binary** packages from a standard distribution in a non-standard place, the Kindle's non-writable /etc directory needs to be dealt with.

Note:
The Kindle's /etc directory **can** be written too, but we don't want to alter Amazon's portion of the system image.

One possible answer to be investigated:
http://www.openadk.org/docs/html/man...on_file_system

- - - - -

Our previous and current Kindle add-ons usually handle this situation by copying the original contents to a directory in the user storage sub-tree and then "mount -bind ..." that back over the source directory.

Over time, it has been discovered that the kernel builds provided with the Kindles have a relatively low limit for "-bind" mounts.
It would be nice to avoid that limitation here.

[knc1]

Originally Posted by knc1

One possible answer to be investigated:
http://www.openadk.org/docs/html/man...on_file_system

Another possibility:
http://git.korsgaard.com/cgi-bin/git....git;a=summary

[knc1]

Originally Posted by knc1

Another possibility:
http://git.korsgaard.com/cgi-bin/git....git;a=summary

Just by code reading (no run-time testing), this one looks like the closest to what we need to support **unmodified** (ones that want to write configuration info. into /etc) distribution packages.

The author, Peter Korsgaard, is the lead maintainer of the Buildroot project.
If he doesn't know how to write embedded systems support firmware, embedded systems are in a world of hurt.

[thatworkshop]

Oh knc1, this toolset just gives me so much more ideas for implementation on older devices which I adore! Thanks for being, man!

@NiLuJe: Why are you doing this to me?!!!! Seems viable, eh?...

I'll be around.

[knc1]

Originally Posted by idoit

Oh knc1, this toolset just gives me so much more ideas for implementation on older devices which I adore! Thanks for being, man!

@NiLuJe: Why are you doing this to me?!!!! Seems viable, eh?...

I'll be around.

I intend to update this thread with another release (RSN).
("soon" == some number of months).

I have the run-time path handling in LuaJit fixed, next release will also have Python in the base package.

[thatworkshop]

Originally Posted by knc1

I intend to update this thread with another release (RSN).
("soon" == some number of months).

I have the run-time path handling in LuaJit fixed, next release will also have Python in the base package.

Boy, oh boy... I have so much to read...

[knc1]

Originally Posted by idoit

Boy, oh boy... I have so much to read...

There is a back-story to this, in addition to "too busy" - - - -

Buildroot's normal operation is to download source packages from the project repository of each package.

But to "fix" LuaJit I needed to maintain a modified version of the original sources.
Not to worry, Buildroot has that requirement handled (in the manual) -
You can specify a local directory as the source tree of each and any package (a source dir override).

But I discovered it was broken in the Buildroot infrastructure (at least how I wanted to use it).

That problem has been fixed and the next release of Buildroot will be around the end of this month.

- - - -

Which (**should**) get me to the point I want to reach - -
Only need to post the fairly small config files for Buildroot and with those, anyone can duplicate what I do -
and then continue in their own direction from that point.

- - - -

Oops - except for that "write to a read-only etc" handler.
That will still need some work/testing.