k3flasher, a USB download mode utility

[knc1]

Page 2,231 of 3,183 pages ...

The WDOG module has user-accessible, 16-bit registers used to configure, operate, and monitor the state of the watchdog timer.
. . . .
A 32-bit access should be avoided as the system might go to an unknown state.

Will have to look at the asm output of gcc to be certain, but that "watchdog_service" function quoted in an above post sure looks to me like it will generate 32-bit write operations.

And in contrast to that opening description, the watchdog service register, service keys are specified as the 32-bit writes used in the quoted bit of service code.

The test in the service code is testing if the watchdog has been enabled.

What is not (yet) exposed in the quoted code is the time period.
The range of time periods is from 0.5 to 128 seconds in 0.5 second increments based on a clock feed that does not change with core clock speed settings.
It is hard to imagine that USB can't transfer 32 packets in even the 1/2 second minimum time setting.

Grumble,
Will have to dig further into this RAM Kernel code to learn why it is failing.

[geekmaster]

Originally Posted by knc1

...
It is hard to imagine that USB can't transfer 32 packets in even the 1/2 second minimum time setting.

There is some useful information about USB timing and latency here:
http://www.ftdichip.com/Support/Docu...atencyFlow.pdf

Of particular interest is this quote: "From this it can be seen that small amounts of data (or the end of large amounts of data), will be subject to a 16 millisecond delay when transferring into the PC."

When taken with the fact that the RAM kernel code only services the watchdog timer every 32 packets, 16msec*32 = 512msec (more than 1/2 second), and there can be additional delays if there are multiple USB devices such as a USB mouse, USB keyboard, or USB mass storage device (especially if the file being flashed is on USB storage).

It appears that my previous suggestion to service the watchdog every 8 packets (or perhaps even every packet) is absolutely required here.

Of course, I only skimmed that USB document, so it may be more complicated than what I suggested above.

[knc1]

I agree and I think the trouble reports so far also agree - -
The timing is set to be marginal at best, and fail randomly at worse.

What you have found is a common problem with the Linux USB stack -
It has strange ideas of when a packet (and/or command) should be buffered at times.

I am about to post a plan to get more information out of the machine about how it is set before we try to load and start the RAM kernel.

Will have to wait for Hawhill's comments on that next post -
since he would have to make changes to his K3Flasher.

[knc1]

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.

[qlob]

Originally Posted by knc1

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.

I have no idea what I can do to contribute..... All of this is way over my head.... I can read/write docs....

Also some ideas:
Separate thread for this project?
Use the Dev Hub for project management?

[knc1]

Originally Posted by qlob

I have no idea what I can do to contribute..... All of this is way over my head.... I can read docs i guess....

Also some ideas:
Separate thread for this project?
Use the Dev Hub for project management?

An extra set of eyes reading things for the first time can always help.
People like GM and myself who have been reading docs longer than we care to admit, could easily miss something other eyes would spot.

Maybe another thread -
But this is the K3Flasher thread and it is K3Flasher problems we are trying to solve.

Since Freescale does not allow us to make the source code public, using a public repository is out of the question.

Plus, I do have my own repository server which includes **Non-published, Private** repository support.

Hawhill's source is "Open Source" he might push it to a repository somewhere. He does use public repositories for some of his work.

But keep the ideas coming, any/all ideas might help in some way.

[geekmaster]

Originally Posted by knc1

An extra set of eyes reading things for the first time can always help.
People like GM and myself who have been reading docs longer than we care to admit, could easily miss something other eyes would spot. ...

Back in the 70's, I purchased a TI Databook (containing 74xx logic spec sheets) for $75 plus shipping (when that was REAL money: back then gasoline and candy bars cost about 10% what they do now).

These days, you can get all that stuff for FREE. And google finds the right page faster than you could find it while holding the paper book in your hands. Amazing!

I still have my old specifications for RS-232, SASI (predates SCSI), and even the GIF file format purchased directly from Compuserve (in which specification it says to pronounce is as "Jiff, like the peanut butter"). It irks me when people mis-correct me and tell me I should pronounce it with a hard G like "gift".

Us "old guys" have been around awhile and have our "memories" archived on various "obsolete" media. I still have some of my code on punch cards, paper tape, and 7-track mag tapes, and 8-inch floppy disks too.

A trip down memory lane is a very easy trap to fall into and can take some time to climb back out of, when your head contains a lifetime of fond memories of technolust.

[knc1]

I only shared the directions with how to use our topic://Kloud in browsers.

See this post for how to mount it into your Linux file system:
https://www.mobileread.com/forums/sho...d.php?t=189470

[qlob]

I threw together this -- may help determine where the RAM kernel is dropping out.

[knc1]

Originally Posted by qlob

I threw together this -- may help determine where the RAM kernel is dropping out.

About 5.5 seconds after the USB gets setup client side and identified host side.

Maybe there is something significant about that time delay.

Thanks for the info.

[qlob]

Originally Posted by knc1

About 5.5 seconds after the USB gets setup client side and identified host side.
Maybe there is something significant about that time delay.
Thanks for the info.

How did you get 5.5 seconds? (I wanted to find a way to get timestamps on the k3flasher output, but didn't know of a way... any suggestions?)

[knc1]

1965.500593 - 1959.955446
Usually, I would expect the seconds field as the first field, but it looks like it is being printed within the brackets in this log file setup.

I haven't looked at the k3flasher code.
I am sure Hawhill will give us some help when he gets a free moment or two.

[qlob]

Originally Posted by knc1

1965.500593 - 1959.955446
Usually, I would expect the seconds field as the first field, but it looks like it is being printed within the brackets in this log file setup.

Ah. Never could figure what those pesky numbers meant. Thanks! Time to go correct the time on my computer to a correct one............

[hawhill]

I've added precompiled binaries to the OP, so if you're lazy and do want to take the risk, you can use these.

[horizon21]

Using the compiled binaries on a x86 distribution of Linux Mint 13 MATE Live USB. So far I've had success in flashing a 3.0.2 kernel on a Kindle 3 WiFi+3G. Rootfs flashing is being done at the moment (has been flashing for 2 hours+ to be percise, as stated, the process is slow).

As I have stated in my support thread, success has been achieved in flashing a complete 3.0.2 firmware!