Andy Green wrote:
Somebody in the thread at some point said:
|> NAND: 256 MiB
|> Found Environment offset in OOB..
|
| and there it hangs. Pushing all combinations of power, aux, or removing
| or inserting battery or USB have no effect.
That's unusual behaviour. Normally U-Boot is prone to going to poweroff
then for some reason, but not hang.
Actually, I can't say that I'd be able to determine whether it went to
poweroff or hung. The only thing I know is that I have to push the
RESET1 button on the Debug Board to get any response out of it (it just
does the exact same thing again when I do).
| Does any of this provide any clues on what might be happening on my
GTA02?
It ties into my current misery with Glamo very well. I can make a guess
about what is happening, somehow the framebuffer region has become
deadly to touch and it jams down nWAIT permanently when you do so.
Currently I routinely see this on resume on 2.6.26 which has a large
patchset on top to solve the device tree issues we always had, when I
force my way in to see what it is doing, it is locked up in the
framebuffer cursor code making the cursor flash. But I never saw it
with our canned U-Boot or Kernel driver init for Glamo.
It's another straw in the wind, thanks for the report (although I dunno
what it means yet).
What is on the LCM at that time, is it all white by any chance?
I have seen it all white, and I have seen it all black. Back when it
used to boot once in 50 times, I often saw the LCM seeming to "decay"
from a previously shown picture before bringing up the u-boot menu. But
today it was mostly black while doing this, and then at the end of the
day it did it while showing completely white for a short while.
Is there any test points I can probe to prove your theory? Anything I
can put a probe on to affect the capacitance and make it work (since you
said in the other thread that your CRO probe was able to affect it)?
-- Rod
