Kindle 2 Clock Webpage

[knc1]

Originally Posted by knc1

First days effort (built, haven't tried any of it to see if it runs) -
All built ARMv6, hard float, fpu=vfp2, optimized for speed on the ARM1136, and built against the musl libc.

Still need to build the Lua bindings for libffi and libcairo -
Also fix fbset problems (which looks like a missing header file):
- - - -

A night's sleep and - -
Going back to glibc - this project is already big enough without fighting header problems in an experimental libc.

And then, see how far back (in version) I can roll the kernel headers I'm building against.

Hmm...
Seems I saw that information here, somewhere -
https://www.mobileread.com/forums/sho...d.php?t=206188
Ah, yes -
See how much of the above can be done against kernel headers for version: 2.6.22

[NiLuJe]

@knc1: FWIW, I'm using the closest LTS kernel to 2.6.22 in my TC (which is 2.6.27.62, AFAICT). That's not a terribly great idea, though, but I'm already not using the right glibc either, so, what the hell ;D.

[knc1]

Originally Posted by NiLuJe

@knc1: FWIW, I'm using the closest LTS kernel to 2.6.22 in my TC (which is 2.6.27.62, AFAICT). That's not a terribly great idea, though, but I'm already not using the right glibc either, so, what the hell ;D.

Thanks, I'll give that a try.
Otherwise, I am going to have to patch the 2.6.22 headers (some definitions have moved to other files since then).

Edit:
I fixed that little problem, now I learn:

Originally Posted by glibc-2.21

configure: error: GNU libc requires kernel header files from
Linux 2.6.32 or later to be installed before configuring.

Which is the oldest (!!!) glibc still supported in BR without patching BR.

= = = =

I am playing catch-up here -
*) Update my year old "ARMhf on Kindle" project thread -
*) Build stuff for the handling of fonts, graphics, framebuffer on the 2.x series Kindles -
*) Build some of the stuff idoit has asked about and/or might be interested in.

[NiLuJe]

@knc1: Yeah, fear of these kinds of things (that, and recent GCC versions plain failing to build old glibcs) were why I initially chose NOT to match exactly the god-awfully ancient K2/K3 toolchain (Linux ~2.6.22, glibc 2.5, GCC 4.2?, IIRC), and instead went with 2.6.27 LTS, glibc 2.9 & an up to date GCC.

I do have to jump through a number of hoops to get buildsystems to play nice and not pull anything newer than GLIBC_2.5, but it's fine for my needs.

If I had to do it all over again, I'd probably go with the 'right' TC, with backported glibc patches as needed to make it build. (I did just that for the Kobo when crosstool-ng dropped eglibc support: the Kobos use eglibc 2_15, which is fine, while on the other hand, mainline glibc 2.15 is horribly broken, so that was fun...).

[knc1]

The problems with patchelf, bypassed, maybe:

bin $ patchelf --print-interpreter busybox
/mnt/base-us/esys/lib/ld-2.21.so
bin $ patchelf --print-rpath busybox
/mnt/base-us/esys/lib:/mnt/base-us/esys/usr/lib

I got the build system to build it that way, I didn't patch it at all.

I also think that the first package I hit that does not use gcc as the linker is going to blow up.

Thank goodness this is a three day weekend here.

[space_escalator]

Alright I have a copy of Debian running as a virtual machine in VirtualBox. I've installed packages lua5.1 and cairo. Then I downloaded both luacairo and oocairo. For each I ran through the process of trying make and apt-getting all of the packages it says it's missing. In luacairo's case, my final error is that lcairo.c doesn't seem to compile without errors. In oocairo's case, I managed to get make to run, but make install gives error: cannot stat ‘.libs/liblua-oocairo.so.0.0.0’: No such file or directory.

How did you install a cairo binding to lua? I'll create a virtual machine of whatever distro you use and start from scratch from your instructions. I'd love to start making sand castles but first I have to nail together my sandbox.

[knc1]

I have not (yet) built the Lua binding to the Cairo library.
So I don't have the slightest idea yet of what I will find.

But I am working towards that getting that done.

OR

We will just use the ffi library to only call what we need.

= = = =

What processor is your Mac ?
PPC, Intel-32bit, Intel-64bit, something else?

[space_escalator]

Intel-64bit, however I believe VirtualBox is capable of emulating either 32 or 64. I can run any (free) operating system under the sun if that helps.

[knc1]

Don't you mean under the Oracle?
I think Sun sold Virtualbox when they where selling off things.

[space_escalator]

*rimshot*
I was very tempted to write "...under the sun (microsystems)" Hahaha

[knc1]

Sorry, nothing useful to report this morning - maybe latter.

- - Edit: - -
When the automation fails you, re-invent the wheel:

configure:6680: checking for sysroot
configure:6710: result: /mnt/base-us/esys

This post would be the length of War and Peace if I told the story of getting that path from a block in the Buildroot menu system all the way into the configure log of an autotools package.

Maybe I learned something in the process.

- - Edit: - -
Getting closer, the build running now might even be worth testing.

- - Edit: - -
After a few false starts (and full builds) tossed due to typo's . . . .
I have something close enough to start looking at build bugs in the resultant binaries.

One of the big ones, this last build does not use -rpath - - -
Because some of the applications where already using it (they aren't suppose to be, but not everything has been patched (yet) ).

Instead, (eventually) everything will get a -sysroot set that places the new file system tree at /mnt/base-us/esys (rather than at "/").

This build run does (well, **should**) have everything requesting our own dynamic linker (which **is** a multi-library loader).

This combination is a bit 'strange' -
I don't think any of the distributions build an eabihf for ARMv6, their oldest arm supported for eabihf is ARMv7.
But this extension to my old "ARMhf on Kindle" project thread is intended to retrofit the K2, DX, DXG, and K3 (with maybe the K4 thrown in).

Later, another build, only optimized for the i.MX6 SoC's processor devices.
(running ARMv6 code on those is sort of a waste of time - literally).

Although just at the 'rough draft' stage - my changes to Buildroot-2015.08 release are attached.

[knc1]

And as an indicator of the features supported, a list of the libraries included in the build output, attached.
There are 324 of them.

@idoit: notice this one:
esys/usr/lib/wireshark/plugins/1.12.7/m2m.so
That one should capture the information your looking for about 3G

[thatworkshop]

Originally Posted by knc1

And as an indicator of the features supported, a list of the libraries included in the build output:

This is going to be awesome... awesome!



We love you!

[knc1]

Originally Posted by idoit

This is going to be awesome... awesome!
- - - -

Thanks.

but it is also going to take more time.
I had a serious misunderstanding about part of what I was doing.

I will have to go back to using the rpath entries, and that means more (after build) scripted munging of the files.

So I used up my three day weekend, and will have to keep working on this during the week.

= = = =

I guess it doesn't matter, since I have had zero feed-back about my "paint and play" thread to avoid hot soldering of serial port connections.
Maybe that is one of those: "no news is good news" situations.

= = = =

Attached, a few of documents for those having trouble going to sleep:

[thatworkshop]

Originally Posted by knc1

Attached, a few of documents for those having trouble going to sleep:

First PDF goes right into my DXG for reading, now!