PW3 FW 5.9.6.1 Software Jailbreak for PW3

[ilovejedd]

Originally Posted by knc1

If a Kindle, then you have Linux.
If the Kindle has MrPI install, then you have the Kindle/Linux build of kindletool installed (it is part of MrPI).
So I am pretty sure everything is available on the Kindle itself.
Unless you do not have MrPI installed, but if you don't, then why do you need packages generated for it to use?

I meant Linux on PC.

Interesting. I didn't know you can build update.bin packages on the Kindle itself.

That said, instructions for building an update*.bin package for LibrarianSync using the Kindle itself (likely via kterm or something) just so MrPI can then copy/untar the librariansync folder to /mnt/us/extensions seem unnecessarily complicated.

Admittedly, I'm interested in trying to do it now.

[knc1]

It does sound a bit of over-kill.
Unless your PC happens to be broke, or your working in the field ...

NiLuJe can correct me if I don't have this correct, but I don't think the Kindle build of kindletool is "special" (as in, only unpack).

[ilovejedd]

Alas, the build script wasn't designed for running under kterm.

First, it looks for git to check for PKGREV. I just hard coded that one based on the latest commit.

Second, it expects kindletool to be in /usr/bin/. As far as I can tell, MrPI doesn't bother with creating a /usr/bin/kindletool symlink and just calls kindletool from the full path. (incidentally, I just noticed MrPI recognizes the PW4 as a K5 instead of a PW2)

Last: Unexpected "(" in Line 16.
I'm not at all familiar with Linux shell, though, so I'm stumped as to how to edit line 16 to make it palatable for the Kindle.

KT_PM_FLAGS=( "-xPackageName=${PKGNAME}" "-xPackageVersion=${PKGVER}-g${PKGREV}" "-xPackageAuthor=barsanuphe" "-xPackageMaintainer=barsanuphe" "-X" )

After that error, I gave up trying to package librariansync on the Kindle.

Of course, after switching to the PC and reading the kindletool readme, I realized that line was likely unnecessary. Alas, I'm way too tired of typing on the Kindle's onscreen keyboard to try again.

[j.p.s]

With usb networking and ssh, I've never felt the need for kterm.

[ilovejedd]

Originally Posted by j.p.s

With usb networking and ssh, I've never felt the need for kterm.

Lol, I'm on Windows so I figured unzipping kterm to /extensions was much simpler than installing and learning how to use usbnet and ssh.

I usually have no need for terminal access on the Kindle.

[knc1]

I am not surprised that the scripting isn't for the Kindle environment.
But -

(incidentally, I just noticed MrPI recognizes the PW4 as a K5 instead of a PW2)

That might well cause some of the problems that where reported early on with the PW4 support.

NiLuJe will stumble on this and add his insight to the matter.

[NiLuJe]

Yup, KindleTool on ARM is a Real Boy .

As for MRPI's CPU detection, that's quite probable... What does /proc/cpuinfo look like on the PW4?

(And, yeah, no, my packaging scripts are pretty much desktop only, they may depend on Bash 3+, SVN, git, wget/curl, GNU tar, rar, xz, ...).

[ilovejedd]

Now that I'm not completely clueless (just mostly clueless), edited the build script to make it more kterm-friendly as well as fixed some minor stuff. Would you look at that, it actually worked.

I used the PW2 kindletool binary for packaging. (extracted from: kual-mrinstaller-1.7.N-r15706.tar.xz/extensions/MRInstaller/data/mrpi-PW2.tar.gz/bin/PW2)

Tested working on a PW4 running 5.10.1.2 using latest snapshot versions (2019-01-28).

[ilovejedd]

Originally Posted by NiLuJe

Yup, KindleTool on ARM is a Real Boy .

As for MRPI's CPU detection, that's quite probable... What does /proc/cpuinfo look like on the PW4?

(And, yeah, no, my packaging scripts are pretty much desktop only, they may depend on Bash 3+, SVN, git, wget/curl, GNU tar, rar, xz, ...).

processor       : 0
model name      : ARMv7 Processor rev 1 (v71)
BogoMIPS        : 7.54
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x4
CPU part        : 0xc09
CPU revision    : 1

Hardware        : Freescale i.MX6 SoloLite (Device Tree)
Revision        : 0000
Serial          :

I noticed detection looks for "i.MX 6SoloLite". I wonder does FBInk also use this detection method? Because LibrarianSync logging on the PW4 kinda looks ugly after the switch to FBInk (big, bold, pixelated characters).

[knc1]

When the switch was made to the i.MX6SoloLite - there was only one screen size / resolution.

Now there are several, plus the i.MX6Dual core and an even larger screen size / resolution.

Not exactly "bit rot", but more of a "bit race" problem.
Just detecting the processor type will no longer be unique to the model.

[NiLuJe]

@ilovejedd:

Huh. Will have to fix that, thanks! (to match against someting like "i.MX[[:space:]]?[6-7]" instead)

That's mainly to pickup a potentially slightly better optimized binary, there's no functional change.

As far as logging goes, it's because eips is not accounting for dpi (and is still using the exact same cell size since the PW, which means it's been rendering text smaller and smaller as the years went on ), unlike FBInk, so, yeah, the font is going to be bigger (plus, it's already "bigger/blockier" to begin with, since the default font is ye olde IBM VGA font (as seen in your BIOS POST, f.g.), i.e., it's semi-bold), whereas eips's one is thin. Also, one of 'em is square (FBInk), the other tall-ish (eips).

The scaling tries to match the original intent of the PW days (as far as column width is concerned), as that looked perfectly fine at the time (and is what I roughly based the length of my messages on).
But, on 300dpi devices, we jump a scaling step, mainly to make things better on 7" & 8" devices, where eips is ridiculously unreadable.
Which means things might be a tad cramped on 6" 300dpi devices like the PW4, even if the maths still yields roughly the same amount of columns as expected (>= 32 IIRC).

[ilovejedd]

Originally Posted by NiLuJe

As far as logging goes, it's because eips is not accounting for dpi (and is still using the exact same cell size since the PW, which means it's been rendering text smaller and smaller as the years went on ), unlike FBInk, so, yeah, the font is going to be bigger (plus, it's already "bigger/blockier" to begin with, since the default font is ye olde IBM VGA font (as seen in your BIOS POST, f.g.), i.e., it's semi-bold), whereas eips's one is thin. Also, one of 'em is square (FBInk), the other tall-ish (eips).

The scaling tries to match the original intent of the PW days (as far as column width is concerned), as that looked perfectly fine at the time (and is what I roughly based the length of my messages on).
But, on 300dpi devices, we jump a scaling step, mainly to make things better on 7" & 8" devices, where eips is ridiculously unreadable.
Which means things might be a tad cramped on 6" 300dpi devices like the PW4, even if the maths still yields roughly the same amount of columns as expected (>= 32 IIRC).

Thanks for the explanation!

Didn't realize the smallish text with eips was unintended behavior. I kinda prefer it since it's more discreet and doesn't block any of the menu items.

Lol, I just frankensteined my librariansync folder (latest from github with old eips logging from 12/08/18 commit).

[knc1]

Originally Posted by ilovejedd

Now that I'm not completely clueless (just mostly clueless), edited the build script to make it more kterm-friendly as well as fixed some minor stuff. Would you look at that, it actually worked.

I used the PW2 kindletool binary for packaging. (extracted from: kual-mrinstaller-1.7.N-r15706.tar.xz/extensions/MRInstaller/data/mrpi-PW2.tar.gz/bin/PW2)

Tested working on a PW4 running 5.10.1.2 using latest snapshot versions (2019-01-28).

Hey, I got the overall correct, with only errors in all of the details.

[NiLuJe]

@ilovejedd: You could arguably enforce a different scaling factor, but it's going to be tedious to maintain .

For ref.,

LS: After L#14 (the FBINK_CFG.row line), add

FBINK_CFG.fontmult = 3

For (almost) everything else, dig up libkh5 in the hack's folder, and switch L#202 to

        FBINK_BIN="${my_fbink} -S3"

[ilovejedd]

Originally Posted by NiLuJe

@ilovejedd: You could arguably enforce a different scaling factor, but it's going to be tedious to maintain .

For ref.,

LS: After L#14 (the FBINK_CFG.row line), add

FBINK_CFG.fontmult = 3

Thank you! I'll try that.

Shouldn't be tedious at all. LibrarianSync is stable and only gets updated when there's an incompatibility with new firmware. I don't update my firmware for it to be an issue.