Quote:
Originally Posted by knc1
Kindle not required.
Cliff's Notes version: - Get Amazon update of your choice.
- Unpackage (to standard archive) using KindleTool
- From that archive, copy out the rootfs.img file
- Under Linux, create mount point of your choice.
- Mount the rootfs.img under that mount point.
- Add qemu static to the top layer (mnt point level) of the rootfs.img.
- chroot to the mnt point.
- Your X86/AMD64 will, with some Linux kernel magic, (see: bin-format-misc setup) run the ARM code.
- Which you can diddle with as you want.
Note: You often have to add-in the QEMU package provided by your distribution to get the above to work.
Note: It is also possible to run the Kindle kernel, on the Kindle, but referring to a network boot of that file system image. This note can remain as a student exercise (you will be the first to post the details here).
|
Ah, you've beaten me to something similar I have been thinking about
: running the Kindle firmware in full QEMU (
qemu-system-arm, that is, not
qemu-arm*). I have been waiting to get my Kindle fixed and finish my first goal of porting 5.6.x to the Kindle Touch before embarking on this endeavor and bringing the topic up, but not anymore, it seems.
- But the first issue, after building U-Boot by hand, is that QEMU doesn't "officially" support emulating a i.MX508 or i.MX6SL board. For the curious, it could only emulate these i.MX boards:
Code:
$ ./qemu-system-arm -M help | grep 'MX'
imx25-pdk ARM i.MX25 PDK board (ARM926)
mcimx6ul-evk Freescale i.MX6UL Evaluation Kit (Cortex A7)
mcimx7d-sabre Freescale i.MX7 DUAL SABRE (Cortex A7)
sabrelite Freescale i.MX6 Quad SABRE Lite Board (Cortex A9)
The last board is definitely out (Cortex-A9), and so is the first board (whatever that chip is called). That leaves us with the i.MX6UL and i.MX7. I'd test the former first, since it's the closest to an i.MX6SL.
- The next issue is that the Kindle has those little
idme variables.
But I imagine that a U-Boot that is compiled by hand from Amazon sources would have support for defining them.
- After that, one has to remember that QEMU doesn't emulate an e-paper display controller (as far as I know). This means that we either use the serial port (via serial console) "blindly", or we hope that it still retains VGA/LCD support in the kernel (and
not lock up hard when it doesn't find an EPDC).
I've done the first five steps before (for the aforementioned attempt at a port of 5.6.x), but not the rest, and I'm seriously contemplating giving it a spin until my newer Kindles arrive.
Note that if we're talking about running in userspace, a "Virtual Kindle" should be easy. Even X could be possibly brought up if we use Xephyr or something. (I know that you might find a Virtual Kindle to be useless, but I want to do it just for the sake of doing it).
- Hoping it would somewhat magically work, I tried this command when I had written this post:
Code:
$ ./qemu-system-arm -M mcimx6ul-evk -monitor stdio -kernel /path/to/diagkern.bin -drive file=/path/to/diagsys.bin
Alas, it didn't. It stared at me blankly, with a QEMU monitor redirected to my terminal and a black, blank serial console. I know I did something wrong. Is it that I haven't built U-Boot? But shouldn't it at least move a muscle without U-Boot?
Quote:
Note: You often have to add-in the QEMU package provided by your distribution to get the above to work.
|
Distro versions of QEMU, however, tend to be
very old (at least it's that way on Ubuntu, and should be even older on Debian). I compile my own QEMU builds from mainline to work around that issue.
Quote:
Note: It is also possible to run the Kindle kernel, on the Kindle, but referring to a network boot of that file system image. This note can remain as a student exercise (you will be the first to post the details here).
|
Ah, the holy grail of Kindle. But this requires a serial cable for U-Boot access as to pull that trick off, so until I find a damned serial cable, I'm out.