Re: Blank white screen on resume
2008/10/23 Lucas Charron <[EMAIL PROTECTED]>: > Sometimes, when the phone resumes, the screen turns white and doesn't > redisplay. I've had this happen with both QtExtended and OM2008.09. Possibly > a kernel issue? Anyone seen this before? I checked the archives, but didn't > find anything. lors of people have seen it. there's an entry in the bug tracker ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Blank white screen on resume
Sometimes, when the phone resumes, the screen turns white and doesn't redisplay. I've had this happen with both QtExtended and OM2008.09. Possibly a kernel issue? Anyone seen this before? I checked the archives, but didn't find anything. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Bad blocks in NAND
2008/10/23 Andy Green <[EMAIL PROTECTED]> > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Somebody in the thread at some point said: > | However, I get this messages when erasing the rootfs: > | > | debian-gta02:/media/mmcblk0p6/Om2008.9# flash_eraseall /dev/mtd6 > | Erasing 128 Kibyte @ f60 -- 99 % complete. > | Skipping bad block at 0x0f62 > | Skipping bad block at 0x0f64 > | Skipping bad block at 0x0f66 > | Skipping bad block at 0x0f68 > | debian-gta02:/media/mmcblk0p6/Om2008.9# > | > | Is it really always 128 kB that are marked as bad block? Anybody else > | got bad blocks already? It looks like dfu-util isn't reporting these > | errors from flash erase. > > There's a bad block table floating around at the end of the flash, it is > falsely marked as being itself in bad blocks so it is left alone. I > guess this is that. Ah, I see. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Bad blocks in NAND
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | As I said some days ago in a discussion about flashing via dfu-util or | doing it after having booted from SD, I did it several times now during | the last 2 days, and it works great. Another advantage is, after | flashing the rootfs, you can adjust settings on the newly flashed fs | (copy dropbear host keys, ssh authorized_keys, wpa_supplicant.conf and | such) before booting the new system. | | However, I get this messages when erasing the rootfs: | | debian-gta02:/media/mmcblk0p6/Om2008.9# flash_eraseall /dev/mtd6 | Erasing 128 Kibyte @ f60 -- 99 % complete. | Skipping bad block at 0x0f62 | Skipping bad block at 0x0f64 | Skipping bad block at 0x0f66 | Skipping bad block at 0x0f68 | debian-gta02:/media/mmcblk0p6/Om2008.9# | | Is it really always 128 kB that are marked as bad block? Anybody else | got bad blocks already? It looks like dfu-util isn't reporting these | errors from flash erase. There's a bad block table floating around at the end of the flash, it is falsely marked as being itself in bad blocks so it is left alone. I guess this is that. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkj/r8kACgkQOjLpvpq7dMoIrQCeOy8VtYO9La44nHahNW7srn4k LJMAnjPIgyeiyXAzMlRKMruEHwILcHqU =3LVb -END PGP SIGNATURE- ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Bad blocks in NAND
As I said some days ago in a discussion about flashing via dfu-util or doing it after having booted from SD, I did it several times now during the last 2 days, and it works great. Another advantage is, after flashing the rootfs, you can adjust settings on the newly flashed fs (copy dropbear host keys, ssh authorized_keys, wpa_supplicant.conf and such) before booting the new system. However, I get this messages when erasing the rootfs: debian-gta02:/media/mmcblk0p6/Om2008.9# flash_eraseall /dev/mtd6 Erasing 128 Kibyte @ f60 -- 99 % complete. Skipping bad block at 0x0f62 Skipping bad block at 0x0f64 Skipping bad block at 0x0f66 Skipping bad block at 0x0f68 debian-gta02:/media/mmcblk0p6/Om2008.9# Is it really always 128 kB that are marked as bad block? Anybody else got bad blocks already? It looks like dfu-util isn't reporting these errors from flash erase. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: WSOD solutions??
On Wed, Oct 22, 2008 at 12:58 PM, Michael 'Mickey' Lauer <[EMAIL PROTECTED]> wrote: > Am Dienstag, den 21.10.2008, 01:40 +0200 schrieb Pietro "m0nt0" > Montorfano: >> Hi i've read a little bit of this annoying problem that me and other >> people are experiencing: >> after a long sleep (> 20 mins), at the resume the screen turns white and >> you can't interact normally with the FR, it's still alive, you can get >> ssh to it but it's unusable in suspend. >> I'm using 2008.8-update (20-10-2008) and i'd like to use 2008.x or FSO >> image (FSO is preferred). >> Is there a solution? > > FYI: Harald Welte (the original author of this code) suspects this to be > a timing problem / command ordering problem when reenabling the display. > I have a device that exposes this problem at runtime which he's going to > inspect on the 27th of this month. > > :M: Thanks a lot for the reply. i'll stay tuned an i'll wait :D Pietro -- There's no place like 127.0.0.1 ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: WSOD solutions??
Am Dienstag, den 21.10.2008, 01:40 +0200 schrieb Pietro "m0nt0" Montorfano: > Hi i've read a little bit of this annoying problem that me and other > people are experiencing: > after a long sleep (> 20 mins), at the resume the screen turns white and > you can't interact normally with the FR, it's still alive, you can get > ssh to it but it's unusable in suspend. > I'm using 2008.8-update (20-10-2008) and i'd like to use 2008.x or FSO > image (FSO is preferred). > Is there a solution? FYI: Harald Welte (the original author of this code) suspects this to be a timing problem / command ordering problem when reenabling the display. I have a device that exposes this problem at runtime which he's going to inspect on the 27th of this month. :M: ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: 8Gb SD card and sd_max_clk
William Kenworthy wrote: > At the moment, I am using > > "echo 1000 > /sys/module/glamo_mci/parameters/sd_max_clk" > > for an 8GB SD card. It does seem more reliable, but there are still > problems that could be SD card related. (occasional hard locks when > using a swapfile (not partition) on the SD card) > > Is there a better value for this? - or is more a matter of keep slowing > it down until the problems go away altogether? Andy made some fixes too the SD code a few weeks ago and these went into his stable tree, but that was only available from the openmoko unstable repos. I don't know if the fixes have progressed into testing or stable yet, but if you aren't using a kernel with them you should give that a try. I'm not sure how to tell which kernels have the patches though. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
