KindleTool: Create/Unpack Kindle update files

[knc1]

Here is one, possibly useful bit of Windows trivia I read just recently:

-- In windows, if HOME isn't set, then USERPROFILE is used in preference to
-- HOMEDRIVE HOMEPATH. This is guaranteed to be writeable on all versions of Windows.

        local home = getenv('HOME')
        if not home then -- has to be Windows
            home = getenv 'USERPROFILE' or (getenv 'HOMEDRIVE' .. getenv 'HOMEPATH')

[NiLuJe]

Good to know .

But again, we'd have to deal with wchar crap for non-ASCII paths :/.

[knc1]

I just read what I quoted - -
get 'homedrive' ???

Does that mean it is possible to install Windows on something other than C:\ ?

[knc1]

Originally Posted by NiLuJe

Good to know .

But again, we'd have to deal with wchar crap for non-ASCII paths :/.

Hmm...
I wrote a paper on that, long, long, long ago in another universe ...

I'll see what I can turn up that might be of help.
The usual disclaimer follows:
Don't Hold Your Breath (tm).

Right now, I'm only waiting on feed-back about my cpu report on various device/firmware combinations that are having the short battery run-time problem.
(I can (did) write it, but I can't make anyone run it. )

[geekmaster]

Today's kindletool_mingw works great on my win7x64, but the cywin version is missing DLLs. I tried using the cygwin DLLs from yifanlu's kindletool package, but that gives "entry point errors" from incompatible cygwin version. Searching my computer for "cygwin.dll" shows many different versions packaged in many different app folders, and history shows that trying to test all the cygwin DLL sets to find one that works with a fussy app ranges between difficult and overtly annoying. I strongly suggest you package cygwin DLLs known to work with this app into the kindletool-cygwin zip file). Meanwhile, back on the hunt for compatible DLL sets from the many on my computer...

Though for me, I am only DLL-hunting to test it for you and those who may download it. The mingw version works great as-is, so I no longer need to run it in a win32 VM.

Thanks for the update.

[NiLuJe]

@GM:

Great! Thanks for the patch & testing .

As for the Cygwin build, I'm not sure shipping the DLL would help, it simply cannot be run from a classic shell, it has to be run from the Cygwin shell.

Which reminds me, I need to reinstall Cygwin *somewhere*, I don't have it installed anywhere on my new box, which explains why the Cygwin snapshots are lagging behind...

[geekmaster]

Originally Posted by NiLuJe

As for the Cygwin build, I'm not sure shipping the DLL would help, it simply cannot be run from a classic shell, it has to be run from the Cygwin shell.

Hmm... Lots of apps run from a cmd window, or by clicking their icon if gui (including yifanlu's kindletool), just by having require cyg*.dll file in the same dir as the .exe file. I am curious how your version could have stricter requirements, such as needing a cygwin shell...

And yes, it always works best when a complant is accompanied by a solution. Thanks for provinding this tool, and especially ready-to-rock binaries.

[geekmaster]

Okay, I just installed cygwin32, and kindletool_cygwin (running in the cygwin shell) gives me "error while loading shared libraries: cygnettle-4.dll: cannot open shared object file: No such file or directory".

It needs extra stuff installed into cygwin (or in the kindletool folder). This is not noob-friendly. It should have all its required dlls packaged with it, IMHO. It should work without a cygwin install, and especially without needing cygwin add-ons (such as nettle), just like yifanlu's kindletool.

Or just skip the cygwin two-step altogether, seeing as how kindletool_mingw works just fine, and not provide the cygwin binaries to save wasted noob brain cells? This option is simpler.

[NiLuJe]

Yup, the Cygwin build is a dynamic build, that was mostly on purpose, since the build is mostly there as a gadget now that the MinGW port is done . It's at the end of the list for that reason, I suppose if people are choosing it over the native binary, that's because they know what they're doing .

I seem to remember writing down the deps somewhere, but, heh, I might have dreamed that up (basically: nettle. Possibly libarchive too, in the future).

[shamanNS]

[NiLuJe]

Originally Posted by NiLuJe

Oh, joy, it's that time of the year again...

We'll see how that turns out, I guess...

=)

*la la la *

[geekmaster]

Regarding the comments I made last night, perhaps I was just using kindletool incorrectly. To keep file permissions, it makes more sense to pack payload files (including executables) in a tar.gz file, and unpack that with the install script (which not only preserves file permissions, but can also move files where they are needed).

Previous post content:

Spoiler:

Meh... One more windows thing to deal with: windows files are normally ALL "chmod 755" (executable) when copied from kindle userstore to a linux partition. However, especially on executables (ARM ELF files, in this case), the executable permissions on files in the update package (other than install.sh) are REMOVED by kindletool.exe for windows. We apparently need an extra step to set executable permissions (or at least not remove them) in kindletool for win32...

I am making an update_install.bin that includes gmplay and plays videos (on my K1 at this point) with no jailbreak or other mods to the filesystem. BTW, there is no /var/local on a K1, so any persistent stuff needs to go in /opt/var/. I am thinking a JB bridge may one day need a "rootkit" kernel module, to hide filesystem mods from OTA updates, and resurrect itself as needed during the update process. Yes?

Strangely, if I do not "chmod 755 ./gmplay" in install.sh, then I get a "not an executable" message on STDOUT when I pipe data to it, but if I DO change it to executable, then I get a "gmplay not found" message on STDOUT when I pipe data to it. Also, I cannot get file sourcing to work in an OTA update package, even though the OTA scripts themselves do that for eips helper functions. Perhaps that was a permissions problem too -- I will need to go back and revisit that...

[NiLuJe]

@geekmaster: Yeah, I was going to answer you that it's by design, and not win32 specific .

The permissions are normalized, and only install scripts end up with the exec bit, so, the usual idea is, either as you mentioned, tarball the payload yourself beforehand, or, set the exec bit on your binaries in your install scripts .

(I usually do both ^^).

[geekmaster]

Originally Posted by NiLuJe

...
The permissions are normalized, and only install scripts end up with the exec bit, so, the usual idea is, either as you mentioned, tarball the payload yourself beforehand, or, set the exec bit on your binaries in your install scripts .

(I usually do both ^^).

Sadly, on my K1, I tried setting permissions on both scripts and executables, but even though they show as executable in "ls -lash", trying to source them or execute them gives a "not found" error on my K1. BTW, K1 scripts use "." instead of "source", but even so, I could not get it to work.

Also, I can only find full-flash update. Contrast 7 does not work, nor does eips '', however, like the K5, trying to display a missing image with eips (-b option instead of -g) does force a page refresh (as does echo 1 > /proc/eink_fb/update_display), though I only tested from scripts so no ioctl attempts yet. gmplay will need an update to support /dev/fb/0 on the K1 instead of /dev/fb0 on all the newer kindles.

Anyway, I am getting K1 "animation" with dd in my update install script, though at only about ONE FPS full-flash updates (if you can even call that "animation").

Enough for awhile -- I have outdoors chores awaiting, not that the snow seems to be gone for now...

Thanks much for keeping the kindletool up to date. I eventually want a KUAL-like jailbreak "substitute" that will use the same tricks as jailbreak, but will launch a root GUI menu like KUAL from an "Update Your Kindle", so it can be used by folks who wish to not mod their root or var filesystems (and the K1 does not even have persistent /var/ anyway)...

[NiLuJe]

@geekmaster: That's usually what happens when the kernel doesn't know what to do with the binary (wrong arch), but, err, that seems unlikely here?

I'm not sure anyone here ever had any experience with a K1 though, so, good luck ;p.