MobileRead Forums - View Single Post

knc1 · 08-28-2012, 03:20 AM

Sounds like good suggestions to me.

Plus, a USB transfer can "stall" or "delay", it can't be assumed it is a continuous stream. So in real life, outside of the Freescale lab, that routine may be even less reliable than you suggest.

I didn't quote the "write" routine but it has the same problems.

If this really has to be done, why not a bit of design change tossed in?
Set aside a few words of iRAM for a "parameter area" of critical values like the counts and watchdog settings.
Then those could be "poked" from the host to "tweak" the timing of things rather than re-building the RAM kernel.
Just like GM was hoping that Freescale had done to begin with in an earlier post.

Let me see now, how could that be made to work while the system was running ...
There are two watchdog values and at least two counter values ...
Set aside 8 u32 words; 4 + 3 "to be discovered" + 1 simple checksum.
If the all 8 words sum to zero (or other known value) then the first 7 values are valid and the run-time copies can be updated.
If they don't, then they have never been set or are in the process of being changed and the run-time copies are not modified.

For the host, that means poking all eight values, the checksum value last.
For the client (Kindle RAM kernel) that means summing 8 words and testing for 0. It should be able to do that even during a high speed transfer with the slowest of clocks.

Thoughts on that any one?

Has anyone read the SoC hardware manual? Does the SoC have another hardware counter/timer that we could use in place of that programmed delay loop?

What I saw in that routine was I think what GM saw in it - -

The watchdog is not testing for a "hung kindle side code" it is testing if the outside world can transfer xyz USB packets in time.
And in real life, you just can't count on the outside world to behave.

I am not all that certain about that watchdog service routine - -

Why the test? Why the counter? The ARM is a load/store machine, it can't take all that much time to poke two memory register values **every pass**.

We could get extra ambitious and see if we can fix the i.MX31 problem also. Just in case anyone ever discovers how to put a DX(G) in USB downloader mode.

08-28-2012, 03:20 AM	#109
knc1 Going Viral Posts: 17,212 Karma: 18210809 Join Date: Feb 2012 Location: Central Texas Device: No K1, PW2, KV, KOA	Sounds like good suggestions to me. Plus, a USB transfer can "stall" or "delay", it can't be assumed it is a continuous stream. So in real life, outside of the Freescale lab, that routine may be even less reliable than you suggest. I didn't quote the "write" routine but it has the same problems. If this really has to be done, why not a bit of design change tossed in? Set aside a few words of iRAM for a "parameter area" of critical values like the counts and watchdog settings. Then those could be "poked" from the host to "tweak" the timing of things rather than re-building the RAM kernel. Just like GM was hoping that Freescale had done to begin with in an earlier post. Let me see now, how could that be made to work while the system was running ... There are two watchdog values and at least two counter values ... Set aside 8 u32 words; 4 + 3 "to be discovered" + 1 simple checksum. If the all 8 words sum to zero (or other known value) then the first 7 values are valid and the run-time copies can be updated. If they don't, then they have never been set or are in the process of being changed and the run-time copies are not modified. For the host, that means poking all eight values, the checksum value last. For the client (Kindle RAM kernel) that means summing 8 words and testing for 0. It should be able to do that even during a high speed transfer with the slowest of clocks. Thoughts on that any one? Has anyone read the SoC hardware manual? Does the SoC have another hardware counter/timer that we could use in place of that programmed delay loop? What I saw in that routine was I think what GM saw in it - - The watchdog is not testing for a "hung kindle side code" it is testing if the outside world can transfer xyz USB packets in time. And in real life, you just can't count on the outside world to behave. I am not all that certain about that watchdog service routine - - Why the test? Why the counter? The ARM is a load/store machine, it can't take all that much time to poke two memory register values every pass. We could get extra ambitious and see if we can fix the i.MX31 problem also. Just in case anyone ever discovers how to put a DX(G) in USB downloader mode.