KOA2 KOA2 jail break

[fllc]

Originally Posted by knc1

When the Kindle boots, there are two splash screens shown.
The first is the "Please wait while your Kindle starts up..."
The second one is the one with the restart progress bar.

When run by the automation, the bridge messages use the screen between when the two splash screens are shown.

I does not stay on long enough to study the messages, but the screen being cleared and the messages bars appearing are a clear indication that the bridge code ran.

Which I consider is alright, people would complain if we slowed the start-up too much.
It currently uses about 2 seconds on the (very) slow original Kindle Touch.

What I could do is keep track if there is anything found that the user should know about -
If such a situation occurs, then I could trigger a sleep for long enough to read the messages.
Otherwise, the screen flash with a rapidly written set of lines and then continuing with the boot-up should be enough feedback.

Who wants to read a bunch of messages that say everything is alright?
(Or do as radamo did, take a video of the Kindle as it starts up with your camera or phone.)
If it does not stop long enough to read them, then nothing is wrong.

I have a feeling that it will be hard to satisfy everyone on this matter.

I will take suggestions on this subject in this thread.

How about just putting all messages (good and bad) into /mnt/us/bridgeoutput.txt?
This way anybody can look at them later.

[Cinisajoy]

Originally Posted by fllc

How about just putting all messages (good and bad) into /mnt/us/bridgeoutput.txt?
This way anybody can look at them later.

Plagiarism.

[knc1]

Originally Posted by fllc

How about just putting all messages (good and bad) into /mnt/us/bridgeoutput.txt?
This way anybody can look at them later.

/mnt/us is not available at that point in the start-up sequence.
The FUSE file system layer has not been started.

[radamo]

Originally Posted by knc1

...
What I could do is keep track if there is anything found that the user should know about -
If such a situation occurs, then I could trigger a sleep for long enough to read the messages..

This gives a solid way to alert when something is amiss. Or create a log of errors. Either would be a great addition.

[NiLuJe]

Now that you mention it, that's probably one of the reasons I went with a very short, one-line only feedback in the original bridge: between the eink driver bundling or throttling updates, and the boot process triggering some (or not) depending on the device and/or FW versions and/or ambient temperature, just a flash and a glimpse that something happened ended up being good enough .

eips -h *may* also exhibit some extra-weird behavior on that front, but I may be confusing things, or remembering its behavior on very old devices.

[knc1]

Originally Posted by NiLuJe

Now that you mention it, that's probably one of the reasons I went with a very short, one-line only feedback in the original bridge: between the eink driver bundling or throttling updates, and the boot process triggering some (or not) depending on the device and/or FW versions and/or ambient temperature, just a flash and a glimpse that something happened ended up being good enough .

eips -h *may* also exhibit some extra-weird behavior on that front, but I may be confusing things, or remembering its behavior on very old devices.

They never changed the embedded font size in eips -
Figure the onscreen size of a 16x24 cell at 300dpi.
It is like reading the engraving on the head of a pen.

It actually looks decent on a KT.
well, at least as decent a bit map font ever looked.
IIRC, it was a big thing when PC's went to that high res, 16x24 font.

[NiLuJe]

@knc1: Yeah, and, ironically enough, it was different on a K5 (12x20 on the 600x800 screens).

[knc1]

Originally Posted by NiLuJe

@knc1: Yeah, and, ironically enough, it was different on a K5 (12x20 on the 600x800 screens).

In a 600 line script, it only takes 100 lines to setup the *$%#% message printer.
Oh well, its done now.
If I don't have any more 'improvement' ideas, I might finish this before I die of old age.

Actually, today's effort is to cut it up into a bunch of re-usage (include) functions.
Mostly to make the job of the package author easier to write a "bridge helper" script for their package.

Of course, I will write the first few "bridge helpers" that can server as worked examples.
Kindlet JB, Kindlet keys, RP and CRP - things that are gone on some mode/firmware combinations.
Such changes will become just a drop helper script into bridge directory or remove the helper script;
not re-write this main bridge script.

(Translation: Once working, I don't ever want to see this script again.)

[otanim]

knc1, I'm curious, is there any possible way to help you and make a contribution on JB?

[knc1]

Originally Posted by otanim

knc1, I'm curious, is there any possible way to help you and make a contribution on JB?

Thanks, but not right at this moment.
Once I get this re-write finished ...
1) We can release the jail break
2) Start working on the other packages that need to be modified.
For the ones where the author has disappeared, we will need people who are interested to step up and help.

What I am working on is the part that auto re-installs the jailbreak after an Amazon update.
So it is important to have that working before the general public starts jail breaking their devices.

It is only a matter of age that is taking so long, the mind isn't as active as when I was half this age.

[kdusr]

HI Knc1, why I can not download koa2 Device Jail Break file, it is showing as follow after click download button, what is the pasword?
---------------------------------------------------------------------------------------
"The file is password protected!
To download this file please enter the password in the field below."

[kdusr]

Hi Knc1,
short question, as you mentioned, to Prevent OTA Update:

-------------------------------------
"In the topmost visible level of USB storage, add the OTA blocking directory name.
The blocking directory name is:
update.bin.tmp.partial"
------------------------------------

create a file or folder named like "update.bin.tmp.partial"?
and can I use this way to prevent OTA for KPW and KV?

thanks!

PS : during register KOA2, it was already starting to download OTA file, after registered, I imminently turn off wifi, but I found a file named "update.bin.tmp.partial" In the topmost visible level of USB storage, size is 60mb, then checked official OTA file size, it is 261mb, obviously the downloading process was not finished, then I delete the file and created a folder named "update.bin.tmp.partial"

[knc1]

It MUST be a folder name.

As far as we know, this OTA blocking directory will work on all known model/firmware combinations.
So the answer for other models is: Yes

You did well to keep an eye on what the device was doing and stopping its download.

PM sent in answer to your other questions.

[kdusr]

thanks for your answer

create an "update.bin.tmp.partial" folder to Prevent OTA Update,
does this way cause cpu busy?
-------------------
1. wifi connected
2. check fireframe version, if it is not the newest,
3. download OTA file
4. create "update.bin.tmp.partial" faile
5. goto step 3 or 4

how frequency is kindle to do this?

[knc1]

Originally Posted by kdusr

thanks for your answer

create an "update.bin.tmp.partial" folder to Prevent OTA Update,
does this way cause cpu busy?
-------------------
1. wifi connected
2. check fireframe version, if it is not the newest,
3. download OTA file
4. create "update.bin.tmp.partial" faile
5. goto step 3 or 4

how frequency is kindle to do this?

It should not impact the cpu usage.
It is an event driven system and the execution path to fail is quite fast.
It will post a re-try event, and the time delay has varied with the firmware version. I can't say what it is with the version you have on it from the factory.
It might be fairly aggressive, since Amazon/Lab126 knows the original firmware version can be jail broken and they do not want that to happen.
I have seen in some versions they will re-try every half an hour.

It should not effect the performance or time between battery re-charges.
Still, put it in airplane mode before letting it go to sleep.
There is no reason to let it connect while you are not using it.
And it will wake up and try to call home even when showing the "idle" screensaver. This is specially true on the Special Offers devices.
Yeah, like having an hour old advertisement on the device would hurt their sales.