Re: SHR enlightenment crash
01.11.2009 17:38, Seth Rothenberg : On Sun, Nov 1, 2009 at 10:58 AM, Matthias Huber wrote: /etc/init.d/xserver-nodm restart dmesg is not the place where enlightenment logs, it is /tmp/x.log Thanks. I got the same message Enlightenment SIGABRT'd. dmesg output may help (below). I did not mention SHR unstable, has been working for a long time, did not update until this problem came up, then did update/upgrade today. Thanks Seth list(head=c038a75c) [21474537.33] s3c2440-uart.2: s3c2410_serial2 at MMIO 0x50008000 (irq = 76) is a S3C2440 [21474537.415000] brd: module loaded [21474537.415000] neo1973-version neo1973-version.0: starting [21474537.44] physmap platform flash device: 0020 at 1800 [21474537.44] physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank [21474537.44] Intel/Sharp Extended Query Table at 0x0039 [21474537.44] Intel/Sharp Extended Query Table at 0x0039 [21474537.44] Intel/Sharp Extended Query Table at 0x0039 [21474537.44] Intel/Sharp Extended Query Table at 0x0039 [21474537.44] Intel/Sharp Extended Query Table at 0x0039 [21474537.44] cfi_cmdset_0001: Erase suspend on write enabled [21474537.44] erase region 0: offset=0x0,size=0x2000,blocks=8 [21474537.44] erase region 1: offset=0x1,size=0x1,blocks=31 [21474537.44] physmap-flash.0: 1 set(s) of 1 interleaved chips --> 4 partitions of 512 KiB [21474537.445000] RedBoot partition parsing not available [21474537.455000] S3C24XX NAND Driver, (c) 2004 Simtec Electronics [21474537.46] s3c2410_nand_probe(c0372970) [21474537.46] s3c2440-nand s3c2440-nand: mapped registers at c8a0 [21474537.46] result 1 from 10, 0 [21474537.46] result 3 from 10, 25 [21474537.46] result 2 from 10, 15 [21474537.46] s3c2440-nand s3c2440-nand: Tacls=1, 10ns Twrph0=3 30ns, Twrph1=2 20ns [21474537.46] s3c2440-nand s3c2440-nand: NF_CONF is 0xf618 [21474537.46] initialising set 0 (c7994000, info c79a7ec0) [21474537.46] NAND device: Manufacturer ID: 0xec, Chip ID: 0xaa (Samsung NAND 256MiB 1,8V 8-bit) [21474537.46] s3c2440-nand s3c2440-nand: chip c79940d0 => page shift 11 [21474537.46] Bad block table found at page 131008, version 0x01 [21474537.46] Bad block table found at page 130944, version 0x01 [21474537.46] nand_read_bbt: Bad block at 0x0238 [21474537.46] 6 cmdlinepart partitions found on MTD device neo1973-nand [21474537.465000] Creating 6 MTD partitions on "neo1973-nand": [21474537.465000] 0x-0x0004 : "qi" [21474537.47] 0x0004-0x0008 : "depr-ub-env" [21474537.48] 0x0008-0x0088 : "kernel" [21474537.485000] 0x0088-0x0092 : "depr" [21474537.495000] 0x0092-0x0096 : "identity-ext2" [21474537.50] 0x0096-0x1000 : "rootfs" [21474537.51] initialised ok [21474537.52] usbcore: registered new interface driver libusual [21474537.535000] s3c2440-usbgadget s3c2440-usbgadget: S3C2440: increasing FIFO to 128 bytes [21474537.535000] gta02_udc_command S3C2410_UDC_P_DISABLE [21474537.54] mice: PS/2 mouse device common for all mice [21474537.555000] i2c /dev entries driver [21474537.565000] s3c2440-i2c s3c2440-i2c: slave address 0x10 [21474537.565000] s3c2440-i2c s3c2440-i2c: bus frequency set to 97 KHz [21474537.59] pcf50633 0-0073: Probed device version 19 variant 132 [21474537.645000] input: PCF50633 PMU events as /class/input/input0 [21474537.69] pcf50633-rtc pcf50633-rtc: rtc core: registered pcf50633-rtc as rtc0 [21474537.71] regulator: auto: 3300 mV normal [21474537.715000] regulator: down1: 1300 <--> 1600 mV normal [21474537.73] regulator: down2: 1800 mV normal [21474537.745000] regulator: ldo1: 3300 mV normal [21474537.76] regulator: ldo2: 3300 mV normal [21474537.775000] regulator: ldo3: 3000 mV normal [21474537.79] regulator: ldo4: 3200 mV normal [21474537.79] neo1973-pm-bt neo1973-pm-bt.0: FIC Neo1973 Bluetooth Power Management: starting [21474537.80] neo1973-pm-bt neo1973-pm-bt.0: __gta02_pm_bt_toggle_radio 1 [21474537.845000] regulator: ldo5: 3000 mV normal [21474537.845000] neo1973-pm-gps neo1973-pm-gps.0: starting [21474537.87] regulator: ldo6: 3000 mV normal [21474537.875000] regulator: hcldo: 2000 <--> 3300 mV normal [21474537.885000] Detected S-Media IRQ# pullup, enabling interrupt [21474537.885000] glamo3362 glamo3362.0: Glamo interrupt registered [21474537.925000] glamo3362 glamo3362.0: Glamo core PLL1: 49119232Hz, PLL2: 89980928Hz [21474537.935000] SMEDIA Glamo frame buffer driver (C) 2007 Openmoko, Inc. [21474538.08] Console: switching to colour frame buffer device 80x58 [21474538.15] fb0: SMedia Glamo frame buffer device [21474538.495000] Generic Backlight Driver Initialized. [21474538.495000] glamo-mci glamo-mci.0:
Re: SHR enlightenment crash
01.11.2009 16:31, Seth Rothenberg : > Enlightenment has been crashing for me today. > It gives 2 choices: Continue and Exit, and > Continue just brings me to the same place. > > I am getting this message > Unable to find swap-space signature > > So I logged in, looked at /etc/fstab, googled, and did this: > mkswap /dev/mmcblk0p4 > Setting up swapspace version 1, size = 822523904 bytes > and swapon > > but I don't know how to retry enlightenment > other than reboot. Should I do the above and then init 2 > or something like that? > > It's not an emergency to get autonous booting working, > but today I have a funeral to attend, need the phone > > Thanks > > /etc/init.d/xserver-nodm restart ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Flashing NAND from NAND
Werner Almesberger schrieb: Matthias Huber wrote: Werner Almesberger schrieb: # echo -en '\x17' | dd bs=1024 count=1 conv=sync >/dev/mtd4 [...] Can you tell why it worked ? In the 0x17 case, we're trying to go from 0x0f to 0x17. That's one bit set and one bit cleared. Clearing the 0x08 bit can be done, and happend when trying to write the 0x17. However, the 0x10 bit can't be set (without invoking an erase cycle). However, since NAND has an ECC, it can still correct a one-bit error. As it happens, the ECC pattern that gets written, just flips the 0x10 bit, so the byte in NAND is 0x07, but it gets corrected to 0x17 - which just happens to be the value we want. i can't. it is possible that i flashed my boot with dfu-util and the rootfs directly. Yes, DFU follows all the NAND erasing rituals properly. The rootfs is very tricky, because there you also have JFFS2 that tries to hide problems from you. For your backup system, you should at least add flash_eraseall to the restore procedure. To make things work also for systems that have bad NAND blocks, you would have to use nanddump and nandwrite. (And you still have to erase explicitly - nandwrite won't do it for you.) - Werner Thank you for this information about this nand* progs. I think, this should go into the wiki, if it isn't already. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Flashing NAND from NAND
Joachim Ott schrieb: 2009/10/20 Matthias Huber : Joachim Ott schrieb: 2009/10/20 Matthias Huber : ... just for clearness: is the boot - partition different from the rootfs ? and how are the other partitions ? /dev/mtd0 is the 2 MB NOR flash that contains the NOR bootloader /dev/mtd1 - mtd6 are the 256 MB NAND flash, the names and sizes are shown when the kernel boots (check "dmesg | more" after boot) and they contain: - u-boot or Qi - u-boot environment - kernel - splash image shown directly after power on - factory settings - rootfs my question was thougt as: do the other partitions also have to be erased ? on the mounted rootfs (/dev/mtdblock6) i am writing just normal without erasing, thats why i am stating this question. There's a difference between flashing a partition and writing to a mounted filesystem. When you edit a file and change only one byte, the whole block containig this changed byte will be erased and newly written. This happens transparent to you. and what is then the difference between /dev/mtd6 and /dev/mtdblock6 ? /dev/mtd6 is accessed as char device, while /dev/mtdblock6 is accessed as block device. See e.g. http://en.wikipedia.org/wiki/Device_file_system#Devices (... coming back to my method of restoring and saving) so is then in the driver a difference between /dev/mtd1 and /dev/mtd6 ? or between /dev/mtdblock1 and /dev/mtdblock6 ? and between mtd0 and mtd6 ? ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Flashing NAND from NAND
Joachim Ott schrieb: 2009/10/20 Matthias Huber : ... just for clearness: is the boot - partition different from the rootfs ? and how are the other partitions ? /dev/mtd0 is the 2 MB NOR flash that contains the NOR bootloader /dev/mtd1 - mtd6 are the 256 MB NAND flash, the names and sizes are shown when the kernel boots (check "dmesg | more" after boot) and they contain: - u-boot or Qi - u-boot environment - kernel - splash image shown directly after power on - factory settings - rootfs my question was thougt as: do the other partitions also have to be erased ? on the mounted rootfs (/dev/mtdblock6) i am writing just normal without erasing, thats why i am stating this question. and what is then the difference between /dev/mtd6 and /dev/mtdblock6 ? ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Flashing NAND from NAND
Werner Almesberger schrieb: Matthias Huber wrote: No, erasing seemed not to be necessary. why should i erase it ? Because a write to NAND normally only clears bits but never sets them: # flash_eraseall /dev/mtd4 # hexdump -C /dev/mtd4 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || # echo -en '\x0f' | dd bs=1024 count=1 conv=sync >/dev/mtd4 # hexdump -C /dev/mtd4 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |?...| # echo -en '\xff' | dd bs=1024 count=1 conv=sync >/dev/mtd4 dd: writing `standard output': Input/output error # hexdump -C /dev/mtd4 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |?...| Here's a little brain-twister: repeat the example from the beginning, but instead of trying to write '\xff', do this: # echo -en '\x17' | dd bs=1024 count=1 conv=sync >/dev/mtd4 dd: writing `standard output': Input/output error # hexdump -C /dev/mtd4 17 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || Can you tell why it worked ? - Werner i can't. it is possible that i flashed my boot with dfu-util and the rootfs directly. for the other partitions i cant tell. maybe because the contents didn't change i did'nt see any error. just for clearness: is the boot - partition different from the rootfs ? and how are the other partitions ? ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: Flashing NAND from NAND
Werner Almesberger schrieb:
Matthias Huber wrote:
# blockrestore.sh
#!/bin/sh -x
for i in 1 2 3 4 5 6 ; do echo cp ${i}_* /dev/mtdblock$i ; cp
${i}_* /dev/mtdblock$i ; done
and in practice, this works for backup _and_ restore
but the backup with the assumption, that there are the destination
files already in the directory, like:
Hmm, don't you also assume that the partition has been erased before
writing ? Also, what happens if you have any bad blocks ?
No, erasing seemed not to be necessary.
why should i erase it ?
Bad Blocks: No i didnt even thing of it.
the four times i did a backup and two or three times i did a restore,
there was no problem.
but you are of course right, one has to have a look at it.
___
support mailing list
support@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/support
Re: Flashing NAND from NAND
Matthias Huber schrieb:
i personally do my backups with "cp"
cp /dev/mtdblock6 /media/card/rootfs
and vice versa.
#blocksave.sh
#!/bin/sh -x
for i in 1 2 3 4 5 6 ; do echo cp /dev/mtdblock$i ${i}_* ; cp
/dev/mtdblock$i ${i}_* ; done
# blockrestore.sh
#!/bin/sh -x
for i in 1 2 3 4 5 6 ; do echo cp ${i}_* /dev/mtdblock$i ; cp ${i}_*
/dev/mtdblock$i ; done
and in practice, this works for backup _and_ restore
but the backup with the assumption, that there are the destination files
already in the directory, like:
-rw-r--r--1 root root 262144 Sep 25 09:11 1_uboot
-rw-r--r--1 root root 262144 Sep 25 09:11 2_uboot-env
-rw-r--r--1 root root 8388608 Sep 25 09:11 3_kernel
-rw-r--r--1 root root 655360 Sep 25 09:11 4_splash
-rw-r--r--1 root root 262144 Sep 25 09:11 5_factory
-rw-r--r--1 root root258605056 Sep 25 09:16 6_rootfs
Atilla Filiz schrieb:
On IRC, I asked someone to
dd if=/dev/mtd0 of=nor.img
for me. Does that work? The link in the wiki page is dead.
I always flash my kernel and rootfs from NAND u-boot menu.
On Sun, Oct 18, 2009 at 5:25 PM, Joachim Ott <mailto:jo.o...@googlemail.com>> wrote:
2009/10/18 Atilla Filiz mailto:atilla.fi...@gmail.com>>:
> Hello
> I have a blank NOR and didn't have time to hack and flash
it(don't want to
> buy a debug board). Is it safe to boot into NAND u-boot menu
and flash a new
> bootloader to NAND? Probably not a good idea.
To flash something via USB cable with dfu-util you have to be in the
NOR boot menu. But it's totally legal to reflash /dev/mtd1 (u-boot),
mtd2 (u-boot_env) or mtd3 (kernel) when you have booted into the
rootfs in NAND. When you've booted from sd-card, you can reflash mtd6
(rootfs) too. Use flash_eraseall and nand_write for this.
Writing to /dev/mtd0 (NOR boot) is possible without debug board too,
you need need to enable write access to it. See
http://wiki.openmoko.org/wiki/Flashing_NOR
--
Mit freundlichen Grüssen
Matthias Huber
Kohlstattstr. 14
86459 Wollishausen
Tel: 08238-7998
LPI000181125
___
support mailing list
support@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/support
Re: Flashing NAND from NAND
i personally do my backups with "cp"
cp /dev/mtdblock6 /media/card/rootfs
and vice versa.
#blocksave.sh
#!/bin/sh -x
for i in 1 2 3 4 5 6 ; do echo cp /dev/mtdblock$i ${i}_* ; cp
/dev/mtdblock$i ${i}_* ; done
# blockrestore.sh
#!/bin/sh -x
for i in 1 2 3 4 5 6 ; do echo cp ${i}_* /dev/mtdblock$i ; cp ${i}_*
/dev/mtdblock$i ; done
and in practice, this works for backup _and_ restore
Atilla Filiz schrieb:
On IRC, I asked someone to
dd if=/dev/mtd0 of=nor.img
for me. Does that work? The link in the wiki page is dead.
I always flash my kernel and rootfs from NAND u-boot menu.
On Sun, Oct 18, 2009 at 5:25 PM, Joachim Ott <mailto:jo.o...@googlemail.com>> wrote:
2009/10/18 Atilla Filiz mailto:atilla.fi...@gmail.com>>:
> Hello
> I have a blank NOR and didn't have time to hack and flash
it(don't want to
> buy a debug board). Is it safe to boot into NAND u-boot menu and
flash a new
> bootloader to NAND? Probably not a good idea.
To flash something via USB cable with dfu-util you have to be in the
NOR boot menu. But it's totally legal to reflash /dev/mtd1 (u-boot),
mtd2 (u-boot_env) or mtd3 (kernel) when you have booted into the
rootfs in NAND. When you've booted from sd-card, you can reflash mtd6
(rootfs) too. Use flash_eraseall and nand_write for this.
Writing to /dev/mtd0 (NOR boot) is possible without debug board too,
you need need to enable write access to it. See
http://wiki.openmoko.org/wiki/Flashing_NOR
___
support mailing list
support@lists.openmoko.org <mailto:support@lists.openmoko.org>
https://lists.openmoko.org/mailman/listinfo/support
--
-
Atilla Filiz
Eindhoven University of Technology
Embedded Systems, Master's Programme
___
support mailing list
support@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/support
--
Mit freundlichen Grüssen
Matthias Huber
Kohlstattstr. 14
86459 Wollishausen
Tel: 08238-7998
LPI000181125
___
support mailing list
support@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/support
Re: [SHR-Unstable] swapon: swapfile has holes
Greg Bonett schrieb: > Hi there, > I just installed SHR unstable and I'm impressed at how usable and > responsive it is. However, while I was performing a opkg operation I > ran out of memory so I tried to add a swap file. > When following the instructions at: > http://wiki.openmoko.org/wiki/SHR_User_Manual#SwapSpace > I get the error: > "swapon: /swapfile: Invalid argument" > and dmesg shows: > "swapon: swapfile has holes" > > I've tried files on the sd card and also on the internal memory. > Any suggestions? > > i could imagine, it must be at one extent, so you should try two things: * format your sdcard and make the swapfile on the newly created fs. *** but if you are formatting the card, you can make a real swap _partition_ also. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: SHR headphones not detecting
Paul schrieb: > Anyone else experiencing issues where the phone doesn't react to the > plugging in of headphones? I found that when it doesn't detect the > head phones, only one ear (the left year) works and the speaker on the > phone is also on. This isn't great when commuting on public transit. > > Sometimes restarting the alsa service gets it to detect the > headphones, though I cannot recreate this with great reliability. > > Any ideas? Is this a hardware or a software issue? (I do hear blips > in both ears when plugging them in. i tried that to bring to work (hacked rules.yaml) et al. and gave finally up. support for bluetooth seems to be there. You will read much about state files and to adjust the volumes of this and that, but all that tips don't seem to work :-( The push knob on the headphones isn't supported too. -- Matzehuber ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
[shr-unstable] missing file in repo shr-unstable 2009-08-25
aehh. sorry, typo, missing is formatter.py in shr-unstable upgraded to 2009-08-25 there is missing /usr/lib/python2.6/parser.py -- Matzehuber ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
[shr-unstable] missing file in repo shr-unstable 2009-08-25
in shr-unstable upgraded to 2009-08-25 there is missing /usr/lib/python2.6/parser.py -- Matzehuber ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [android] strong echo with buzz-fixed A6
Thomas Otterbein schrieb: > Hi, > > I installed Koolu's Android Betra 7 on my recently buzz-fixed Freerunner A6. > It > has the well known echo problem now. On the lists and forums I could find > only > solutions (dbus commands) for other distros. However I hope similar settings > may help on Android too, just that I have no idea on how to apply them. :-) > > > maybe: alsactl -f /usr/share/openmoko/scenarios/gsmhandset.state restore does the job. take the gsmhandset.state from shr.jffs2 (mount -oloop jffs2 /mnt) ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
