Virtual Development

[knc1]

Originally Posted by nasser

knc1,

You're saying KT, PW1, PW2, PW3, KT2, KT3, KV, KOA are ALL armhf compatible.
In that case, would CLI applications built on a debian-armhf image run OK on these Kindles?

Only if you also supply the armhf system libraries, dynamic loader and use patchelf to point the armhf files at the armhf loader.

See my "ARMhf on Kindle" (or something similar) for worked examples and install-able code.

[nasser]

OK.. Thanks!
That path's a dead end!

[knc1]

Originally Posted by nasser

OK.. Thanks!
That path's a dead end!

Well, what is your goal?
You shouldn't expect me to give an answer that will help you, if I don't know what you are trying to do.

[nasser]

knc1,

Sorry! No offence..
I just wanted an a simple and easy to set up kindle compatible VM, where interesting Linux CLI applications can be ported and tested.
The armhf requirements are beyond my level!
I already have a debian-wheezy-armel Qemu VM, as mentioned in my other posts. Only, it's a bit dated and lacks some of the latest package versions.

[encol]

If you follow method #1 of coplate's thread, as I suggested you before, you'll get a jessie VM

[pete330]

I use and recommend Vagrant to build and run the virtual boxes.

[knc1]

Originally Posted by pete330

I use and recommend Vagrant to build and run the virtual boxes.

That is not a suitable solution to what I am building.
Great for the "instant gratification without requiring any thinking" generation (which I am not a member of).

[nasser]

Originally Posted by pete330

I use and recommend Vagrant to build and run the virtual boxes.

Pete330, Did you use this to build your interactive fiction interpreter ports?

[knc1]

For working with Amazon/Lab126 u-boot and kernel binaries requires 'system mode' qemu.
Since everything above the bare metal is emulated, the only thing that matters is having a hardware configuration that qemu can use that is 'close enough' to that of the Kindle.

The e-ink controls include some custom system control calls added to the main stream kernel by Amazon/Lab126.

The only way to test software that requires support for those custom system control calls is by running the actual Amazon/Lab126 kernel under 'qemu-system' mode.

The KT and the PW1 both use an i.MX50 system chip.
The PW2 through Oasis use an i.MX6SL system chip.
From the standpoint of user-land code the i.MX6SL chip will run anything the i.MX50 chip can run.
There are significant differences on the protected mode (supervisor mode) side of the fence.

= = = = =

Now the fun stuff, relevant to QEMU "User Mode" emulation, the Kindle run-time environment history:

KT (i.MX50):

Firmware 5.0.0 (November 3, 2011) ... firmware 5.3.2.1 (February 22, 2013) where all 'incremental update' packages. They did not contain a full system image.
But we do have, in the old repository of 'recovery images', some complete images for both 'main' and 'diag' systems.
If there is a need for such things, other firmware image versions can be recovered and/or made.

(Trivia: The update package names start with an uppercase 'U' with the incremental update packages.)

Firmware 5.3.7 (July 12, 2013) ... firmware 5.3.7.3 (July 20, 2014) are all the new 'full image update' packages.
All contain the 'main' system image and the matching 'main' kernel.
None contain a 'diag' system image or a matching 'diag' kernel.

All firmware versions in the KT series run:
Linux: 2.6.31-rt11-lab126
eGLIBC: 2.12.1, kernel ABI: 2.6.16
and both:
GCC: (Linaro GCC 4.5-2011.05-0) 4.5.4 20110505 (prerelease)
GCC: (Ubuntu/Linaro 4.4.4-14ubuntu1) 4.4.5 20100909 (prerelease)
where in use.

PW1 (i.MX50):

Although the introduction of the PW1 predates the change from incremental to full image updates for the KT, all PW1 updates are system images.
None of them include the 'diag' system image or the 'diag' kernel.

Firmware 5.2.0 (September 21, 2012) .. firmware 5.6.1.1 (June 23, 2015) all provide the same run-time environment as the KT:
Linux: 2.6.31-rt11-lab126
eGLIBC: 2.12.1, Kernel ABI: 2.6.16

PW2 (i.MX6SL):

In addition to the introduction of the newer SoC, a newer build environment was put to work.
Firmware 5.4.2 (December 30, 2013) .. firmware 5.8.9.2 (May 4, 2017) all use the same Linux kernel: 3.0.35-lab126

Firmware 5.4.2 (December 30, 2013) .. firmware 5.6.2.1 (April 15, 2015) all use the previous model's eGLIBC-2.12.1 built to a kernel ABI of 2.6.16

Firmware 5.6.5 (July 31, 2015) and firmware 5.7.4 (April 24, 2016) both use GLIBC-2.19 built to a kernel ABI of 2.6.16 also. Note: GLIBC-2.19 is the merge of GLIBC and eGLIBC and does not provide any symbols newer than GLBC-2.18

Firmware 5.8.9.2 marked a shift to GLIBC-2.20 built to a kernel ABI of 2.6.32

PW3 (i.MX6SL):

Firmware 5.6.1.1 (no date available) .. firmware 5.8.9.2 (May 4, 2017) all run the Linux 3.0.35-lab126 kernel version.

Firmware 5.6.1.1 (no date available) .. firmware 5.8.2.1 (August 29, 2016) all use GLIBC-2.19 built to a kernel ABI of 2.6.16
With the same note about GLIBC-2.19 here as above.

Firmware 5.8.5 (September 1, 2016) .. firmware 5.8.9.0.2 (May 4, 2017) all use GLIBC-2.20 built to a kernel ABI of 2.6.36

= = = = =

Newer model devices should not be using older system components than those shown for the PW3 (although they might use newer).

The discontinuity between system component versions on the i.MX50 and the i.MX6SL based devices is an artifact of two different build systems in use at the same time.

Phooey! That was one of my least interesting weeks.

[knc1]

Having found the boundaries within which the virtual development machine has to work . . . .

While gathering together the components, I decided to give the VMware "trial" download a try.
What can I say about that brain-fart?
It was a half-day's working time that was a pure loss.

VMware on Linux can not be run when KVM is enabled.
As it turns out, it can't even be fully installed without silent failures (not silent - put into an undisclosed logging location) when KVM is enabled.

VirtualBox and qemu both will take advantage of KVM when it is available.
So giving up that hardware acceleration just to run a 'for pay' competitor's product is too high a cost.
Even if they where giving it away, which they are not doing.

After a few hours of reverse engineering their installer - I was finally able to get the turkey to uninstall.
Well, it is mostly gone, although I kept finding pieces of it during my work last night.

[knc1]

Now into about the 13th build of this virtual kindle corner . . . .

Scripting languages?
I have add Lua (since I like it and it is preinstalled on the TS Kindles.)
Any votes for anything else? Python? Perl? Something outlandish?

GUI?
not for the vm, but for the Kindle . . . .
GTK+ (because it is preinstalled on the TS Kindles)?

Java?
Create support?
Decompile support?

Other suggestions?

[encol]

my vote is for python+gtk+java+some good editor (SciTE?)

[knc1]

Originally Posted by encol

my vote is for python+gtk+java+some good editor (SciTE?)

Isn't SciTE a GUI IDE?
This "small" VM is command line development (or via ssh or vnc).

Now if you are thinking of the 'large' VM for Kindle development - that one is GUI based.
(KDE4, on a 32bit Linux system).
Unfortunately, it looks like Kdevelop will have to be built for that combination.
Phooey!
Well, if I get Kdevelop built, I guess we can call that VM working.
Although I hate it myself, I have (just now) included the most recent Eclipse release.
I am not sure if that will run -
It is a GTK based system and KDE is QT.

Oh, well, tomorrow will be an interesting day.

[pete330]

Originally Posted by knc1

Great for the "instant gratification without requiring any thinking" generation (which I am not a member of).

Yeah, whatever. Or maybe you didn't understand the use-case for the tool, yet.

[pete330]

Originally Posted by nasser

Pete330, Did you use this to build your interactive fiction interpreter ports?

Yes.

I use Vagrant to run the Linux vbox image headless on macOS.

I use NetBeans and VS Code on macOS as the IDE.

And buildroot and crosstool inside the vbox image for the cross compilation setup.

That way I can develop, run and test & cross-compile the app from within the IDE.

All this requires no thinking, of course. Thanks god!