Send buglog mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openmoko.org/mailman/listinfo/buglog
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of buglog digest..."
Today's Topics:
1. Openmoko Bug #2340: glamo-mci should use MODULE_DEVICE_TABLE
(Openmoko Public Trac)
2. Openmoko Bug #2341: u-boot environment isn't saved
(Openmoko Public Trac)
3. Re: Openmoko Bug #2341: u-boot environment isn't saved
(Openmoko Public Trac)
4. Re: Openmoko Bug #2341: u-boot environment isn't saved
(Openmoko Public Trac)
5. Re: Openmoko Bug #2340: glamo-mci should use
MODULE_DEVICE_TABLE (Openmoko Public Trac)
6. Re: Openmoko Bug #2328: touschreen sometimes stops generating
events (Openmoko Public Trac)
7. Re: Openmoko Bug #2340: glamo-mci should use
MODULE_DEVICE_TABLE (Openmoko Public Trac)
--- Begin Message ---
#2340: glamo-mci should use MODULE_DEVICE_TABLE
-------------------------+--------------------------------------------------
Reporter: ThibG | Owner: openmoko-kernel
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: kernel | Version: unspecified
Severity: normal | Keywords:
Haspatch: 1 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-------------------------+--------------------------------------------------
Hi,
in order to be auto-loaded by udev, the glamo-mci driver should use
MODULE_DEVICE_TABLE.
Here is a patch.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2340>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2341: u-boot environment isn't saved
----------------------+-----------------------------------------------------
Reporter: aikipooh | Owner: openmoko-devel
Type: defect | Status: new
Priority: highest | Milestone:
Component: unknown | Version:
Severity: critical | Keywords: nand
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible: always
----------------------+-----------------------------------------------------
I'm trying to modify kernel parameters, I do setenv, then saveenv. And the
latter doesn't seem to write the NAND. Everywhere I see that it should
write something like:
GTA01Bv3 # saveenv
Saving Environment to NAND...
Erasing Nand...Writing to Nand... done
GTA01Bv3 #
But i get (the log follows, i leave the tail of previous printenv to
compare):
mtddevnum=0
mtddevname=nor
Environment size: 1093/262140 bytes
GTA02v6 # setenv foo 1
GTA02v6 # printenv
boot_menu_timeout=60
bootargs_base=rootfstype=jffs2 root=/dev/mtdblock6 console=ttySAC2,115200
console=tty0 loglevel=4 regular_boot
bootcmd=setenv bootargs ${bootargs_base} ${mtdparts}; nand read.e
0x32000000 kernel 0x200000; bootm 0x32000000
bootdelay=5
menu_1=Boot from microSD (FAT+ext2): setenv bootargs ${bootargs_base}
rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 ${mtdparts} ro; mmcinit;
fatload mmc 1 0x32000000 ${sd_image_name}; bootm 0x32000000
menu_4=Set console to USB: setenv stdin usbtty; setenv stdout usbtty;
setenv stderr usbtty
menu_5=Set console to serial: setenv stdin serial; setenv stdout serial;
setenv stderr serial
menu_6=Reboot: reset
menu_8=Power off: neo1973 power-off
sd_image_name=uImage.bin
stderr=usbtty
stdin=usbtty
stdout=usbtty
usbtty=cdc_acm
mtdids=nor0=physmap-flash,nand0=neo1973-nand
pcb_rev=0x101
pcf50633_int1=0x80
pcf50633_int2=0x02
mtdparts=mtdparts=physmap-
flash:-(nor);neo1973-nand:0x00040000(u-boot),0x00040000(u-boot_env),0x00800000(kernel),0x000a0000(splash),0x00040000(factory),0x0f6a0000(rootfs)
partition=nor0,0
mtddevnum=0
mtddevname=nor
foo=1
Environment size: 1099/262140 bytes
GTA02v6 # saveenv
a0000(rootfs)
pnt to NAND...
Erasing Nand...GTA02v6 #
So there is nothing about writing NAND. What should i do in this
situation?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2341>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2341: u-boot environment isn't saved
----------------------+-----------------------------------------------------
Reporter: aikipooh | Owner: openmoko-devel
Type: defect | Status: new
Priority: highest | Milestone:
Component: unknown | Version:
Severity: critical | Keywords: nand
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible: always
----------------------+-----------------------------------------------------
Comment(by lindi):
Can you try fw_printenv and fw_setenv under Linux? (uboot-envtools package
in debian).
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2341#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2341: u-boot environment isn't saved
----------------------+-----------------------------------------------------
Reporter: aikipooh | Owner: openmoko-devel
Type: defect | Status: new
Priority: highest | Milestone:
Component: unknown | Version:
Severity: critical | Keywords: nand
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible: always
----------------------+-----------------------------------------------------
Comment(by gena2x):
also you can try to prepare environment on your host and flash it directly
via dfu-util. to do this use tools from here:
http://svn.openmoko.org/trunk/src/host/devirginator/
you need envedit.pl
only difficult thing - adjust your environment size for gta02 or it will
not work. i think it should be 2564 but unsure.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2341#comment:2>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2340: glamo-mci should use MODULE_DEVICE_TABLE
-------------------------+--------------------------------------------------
Reporter: ThibG | Owner: openmoko-kernel
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: kernel | Version: unspecified
Severity: normal | Keywords:
Haspatch: 1 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-------------------------+--------------------------------------------------
Comment(by lars):
Hi,
MODULE_ALIAS("platform:...") should have the same effect and is much more
readable. Could you test and resend a patch with MODULE_ALIAS instead of
MODULE_DEVICE_TABLE? It would be great if you could do it for all the
glamo modules which don't have it yet.
Thanks,
-Lars
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2340#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2328: touschreen sometimes stops generating events
--------------------+-------------------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: defect | Status: new
Priority: normal | Milestone:
Component: kernel | Version:
Severity: normal | Keywords: touchscreen
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible: rarely
--------------------+-------------------------------------------------------
Comment(by gena2x):
I spent some time trying to investigate this (or similar?) issue.
I got problems then i changed optimization from optimization for size to
optimization for speed (for andy-tracking).
Perfectly reproducible.
Interesting thing i found while investigation is that our touchscreen
sometimes start sending absolutely correct events (no need to filter).
This happens then screen is blanked for some period and perfectly
reproducible too.
Reloading touchscreen module restores functionality.
I can't recall correctly (i did investigation in Feb) but problem real
causes were following:
dmesg is like following:
...
Jan 1 03:49:06 debian-gta02 kernel: [ 2539.550000] s3c2440-ts s3c2440-ts:
Stylus timer, down state, samples: 1, 1, 4
Jan 1 03:49:06 debian-gta02 kernel: [ 2539.550000] s3c2440-ts s3c2440-ts:
Stylus irq, down state: 0, 0
Jan 1 03:49:06 debian-gta02 kernel: [ 2539.550000] s3c2440-ts s3c2440-ts:
stylus_irq: count=4
Jan 1 03:49:06 debian-gta02 kernel: [ 2539.560000] s3c2440-ts s3c2440-ts:
Stylus irq, down state: 0, 0
Jan 1 03:49:06 debian-gta02 kernel: [ 2539.560000] s3c2440-ts s3c2440-ts:
stylus_irq: count=4
Jan 1 03:49:06 debian-gta02 kernel: [ 2539.565000] s3c2440-ts s3c2440-ts:
Stylus timer, down state, samples: 0, 0, 4
Jan 1 03:49:06 debian-gta02 kernel: [ 2540.005000] s3c2440-ts s3c2440-ts:
Stylus irq, down state: 1, 1
Jan 1 03:49:06 debian-gta02 kernel: [ 2540.010000] s3c2440-ts s3c2440-ts:
Stylus timer, down state, samples: 1, 1, 4
Jan 1 03:49:06 debian-gta02 kernel: [ 2540.020000] s3c2440-ts s3c2440-ts:
Stylus timer, down state, samples: 1, 1, 4
[...same...]
Jan 1 03:49:06 debian-gta02 kernel: [ 2540.135000] s3c2440-ts s3c2440-ts:
Stylus timer, down state, samples: 1, 1, 4
Jan 1 03:49:06 debian-gta02 kernel: [ 2540.140000] s3c2440-ts s3c2440-ts:
Stylus timer, down state, samples: 1, 1, 4
Jan 1 03:49:06 debian-gta02 kernel: [ 2540.145000] s3c2440-ts s3c2440-ts:
Stylus irq, down state: 0, 0
Jan 1 03:49:06 debian-gta02 kernel: [ 2540.145000] s3c2440-ts s3c2440-ts:
stylus_irq: count=4
Jan 1 03:49:06 debian-gta02 kernel: [ 2540.150000] s3c2440-ts s3c2440-ts:
Stylus irq, down state: 1, 0
"Stylus irq, down state: 0, 0' is a 'up' interrupt
up prints also 'stylus_irq: count=?', this is count of measurements ready
at this point.
"Stylus irq, down state: 1, ?' is a 'down' interrupt
down starts 'timer'
main source of info about interrupt is reading registers after each
conversion/on interrupt. if that registers return 1 - ts is down. and we
start timer and adc. then it is 'up' 0 we only start waiting for down.
(this seen unneeded for me as we already know what are we waiting, we can
say state=!state, but this not works somehow)
this down state '1,1' is normal situation, the '1,0' is then bug occured.
so, interrupt happens but adc registers report stylus is 'up'. and so they
do forever from some point. I rewrited driver to check only interrupts,
but somehow this didn't helped. i tried other ideas also, but without
success.
all the tests are from .34-backported (as it was in february) driver
without filtering.
i fact i also did some investigation on touchscreen buzz, i tried
different combinations of delays, and scaling and all without luck too.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2328#comment:5>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2340: glamo-mci should use MODULE_DEVICE_TABLE
-------------------------+--------------------------------------------------
Reporter: ThibG | Owner: openmoko-kernel
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: kernel | Version: unspecified
Severity: normal | Keywords:
Haspatch: 1 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-------------------------+--------------------------------------------------
Comment(by ThibG):
Yes, indeed, MODULE_ALIAS is sufficient for the glamo modules, and much
more readable.
Here is a new patch, using MODULE_ALIAS, for glamo-mci and glamo-fb.
glamo-core and glamo-gpio already have the MODULE_ALIAS thing.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2340#comment:2>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
