-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: | I wrote: |> I set up an automated test for this with and without DFU: |> svn.openmoko.org/developers/werner/bug1252/ | | After applying Andy's Glamo band-aid, things are much better. I still | get the occastional boot failure, though. (About 3%, down from 10%.)
Yesterday I started to study the timing for access to Glamo from CPU, since olv changed it to 4-4-4 cycles we stopped having this PLL init failure / slow refresh bug from months ago, but it isn't a very satisfying solution. I sent it back to 1-4-1 and I was disappointed the graphics speed for stuff like framebuffer text scroll did not radically increase. However when in X, I did see a hard lockup during redraw I never saw before. So I wouldn't discount there is some more evil lurking in the Glamo somehow that can cause hard lockup, and the 4-4-4 cycle thing just reduces the probability rather than eradicates it. Glamo also has the ability to drive nWAIT on the CPU. There are dead-times specified in Glamo docs where you must wait after touching registers of specific kinds, quite a complex table: we didn't take any care about it. The Glamo MMC does take care about it, but the rest doesn't. Maybe it comes from that. | Anyway, unless there's more information on bug 1252, I'd consider it | as not reproducible. Hm "not reproducible on your setup" might be more correct. I would ask about if folks are running NetworkManager on the host. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfuHOUACgkQOjLpvpq7dMq+2QCeMFWikjY2362yhT9JIcNNvk1t SiQAn3MumTrWpjadwBlJinabP7ewRnAb =WF5u -----END PGP SIGNATURE-----
