View Single Post
Old 08-29-2012, 02:09 PM   #139
knc1
Going Viral
knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.
 
knc1's Avatar
 
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
Plan A (not yet Plan 9 from outer space)

First proposal of who knows how many proposals we will need to find this problem.

First: We need more information.

What we have is the iROM code to work with before we try to download and run another application (like the RAM kernel).
But it should be possible using the iROM "read memory" command to learn how the watchdog has been setup and what the default CSF and DCD provided by the iROM code are.

As a prolog to using the "write file" command to download and run the "RAM kernel" we could use it to re-program the CSF and DCD (Hawhill may already be doing this - I haven't looked at his code yet).
The iROM code will execute those replacements just prior to running the download application (RAM kernel).
Which, by the way, can cause the USB device to be re-programmed (I.E: disappear from the host's viewpoint).

The current RAM kernel could have a "get info" command added, modeled after the "get status" command.
That should not disturb the current binary ATK, since it does not know the command will exist, it will never try to send it and become lost in the MR version reply.

That command's response will be similar to:
ack/nak, cmnd version, response length, data ....
The "cmnd version" is because I assume this new command will have to be re-written a number of times until the response contains all the information needed to know the hardware (including battery charge) is ready for a "flash session".

All I can say is that it is a plan of how to get started on this problem.

I will be dealing with moving the device-program parts of the ATK source into a Linux cross-compile project.
So there will be plenty of time for people to comment on this initial plan and make suggestions.

Last edited by knc1; 08-29-2012 at 02:11 PM.
knc1 is offline   Reply With Quote