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. [Bug 1168] eliminate GCC warning for gsmd
      ([EMAIL PROTECTED])
   2. [Bug 1168] eliminate GCC warning for gsmd
      ([EMAIL PROTECTED])
   3. [Bug 806] Standby voltage set to 2.1V, not 1.8V as datasheet
      says. ([EMAIL PROTECTED])
   4. [Bug 1038] Problem in trying to make openmoko-devel-image..
      ([EMAIL PROTECTED])
   5. [Bug 1175] New: Automatic ipkg kernel upgrade needs stricter
      sanity    check ([EMAIL PROTECTED])
   6. [Bug 1176] New: Truncated u-boot printout of kernel version
      string ([EMAIL PROTECTED])
   7. [Bug 1177] New: '-e command' support for virtual terminal
      ([EMAIL PROTECTED])
   8. Your Bugzilla buglist needs attention. ([EMAIL PROTECTED])
   9. [Bug 1145] add hw assisted rotation support to xglamo via
      randr ([EMAIL PROTECTED])
  10. [Bug 1067] artifacts when doing glamo HW rotation
      ([EMAIL PROTECTED])
  11. [Bug 1145] add hw assisted rotation support to xglamo via
      randr ([EMAIL PROTECTED])
  12. [Bug 1178] New: iron out XVideo support in Xglamo
      ([EMAIL PROTECTED])
  13. [Bug 1178] iron out XVideo support in Xglamo
      ([EMAIL PROTECTED])
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1168

[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[EMAIL PROTECTED]



------- Additional Comments From [EMAIL PROTECTED]  2008-01-10 12:15 -------
By the way, as a general remark, I find the following options useful
for makeing gcc find my areas of sloppiness:

-Wall -Wshadow -Werror -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations

Particularly -Werror may be a bit ambitious for production code (sometimes,
some header files produce an unexpected warning on some obscure platform),
but it can be quite useful for occasional checking.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.



--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1168





------- Additional Comments From [EMAIL PROTECTED]  2008-01-10 12:22 -------
Hi Werner, 
Thanks a lot for ur suggestions, i will try try see! :) --Erin



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.



--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=806





------- Additional Comments From [EMAIL PROTECTED]  2008-01-10 14:33 -------
Sorry about the delays - the bugzilla mail was getting sent to the wrong 
mailbox.

It looks like I was partially mistaken - I hadn't found a spec for vddalive, so
ignored it and simply looked at the vddrtc rating - which explicitly says 2.1v
isn't allowed.

Where I got the information from was
http://www.samsung.com/global/business/semiconductor/productRightMenuDown.do?doc_file=26537
- the datasheet linked from 
http://wiki.openmoko.org/wiki/Neo1973_hardware#Processor

On page 487, table 24-2 Recommended Operating Conditions

I think the initial problem is that the wiki page says
 STBY_1V8

    * Standby Voltage for S3C2410
    * Generated by PMU D3REG
    * Used by
          o S3C2410 (vddalive/rtc) 

On that table, Vddrtc is clearly stated as 1.8V+-0.15 at both speeds.
The datasheet never actually specifies as I can see it a voltage for VDDalive,
it merely implies it as notes on clock timing constraints.

2.1V is actually a bit above the recommended maximum of 1.95 of VDDrtc, so
operation is not guaranteed.
As the absolute maximum is 2.7V, damage will almost certainly not occur.

(the PMU supply in question has a granularity of 300mv as I understand it, as
indicated by your other calcs - typo I assume)

The 'right' thing to do would seem to be to on shutdown go to 200Mhz mode first,
then off.
This is at best a small power saving, 40uA at most.
Or to put another way will decrease standby in RAM time (with GSM and everything
else off by some 10%)



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.



--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1038





------- Additional Comments From [EMAIL PROTECTED]  2008-01-10 15:57 -------
In My case I'm getting up to this point:

NOTE: Resolving missing task queue dependencies
NOTE: preferred version 2.5 of glibc not available (for item
virtual/arm-angstrom-linux-gnueabi-libc-for-gcc)
NOTE: preferred version 0.10 of hicolor-icon-theme not available (for item
hicolor-icon-theme)
NOTE: preferred version 20070918+git of hal-info not available (for item 
hal-info)
NOTE: multiple providers are available for virtual/libqte2 (qte-mt-static, qte,
qte-mt);
NOTE: consider defining PREFERRED_PROVIDER_virtual/libqte2
NOTE: Preparing runqueue
NOTE: Executing runqueue
NOTE: Running task 525 of 5288 (ID: 135,
/home/moko/openembedded/packages/glibc/glibc_2.5.bb, do_package)
NOTE: package glibc-2.5: started
NOTE: package glibc-2.5-r8: task do_package: started
NOTE: preparing tree for binary locale generation
NOTE: generating locale es_NI (UTF-8)
NOTE: Task failed: localedef returned an error (command was
PATH="/home/moko/build/tmp/staging/i686-linux/bin/arm-angstrom-linux-gnueabi:/home/moko/build/tmp/staging/i686-linux/bin:/home/moko/build/tmp/staging/i686-linux/bin:/home/moko/build/tmp/cross/bin:/home/moko/build/tmp/staging/i686-linux/bin:/home/moko/bitbake/bin:/home/moko/bitbake/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/bin:/bin:/usr/bin:/home/moko/bin"
I18NPATH="/home/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/glibc-2.5-r8/locale-tree//usr/share/i18n"
qemu-arm -r 2.6.16 -L
/home/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/glibc-2.5-r8/locale-tree
/home/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/glibc-2.5-r8/locale-tree/bin/localedef
--force --old-style --no-archive
--prefix=/home/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/glibc-2.5-r8/locale-tree
--inputfile=/usr/share/i18n/locales/es_NI --charmap=UTF-8 es_NI).
NOTE: package glibc-2.5-r8: task do_package: failed
ERROR: TaskFailed event exception, aborting
NOTE: package glibc-2.5: failed
ERROR: Build of /home/moko/openembedded/packages/glibc/glibc_2.5.bb do_package
failed
ERROR: Task 135 (/home/moko/openembedded/packages/glibc/glibc_2.5.bb,
do_package) failed
NOTE: Tasks Summary: Attempted 524 tasks of which 524 didn't need to be rerun
and 1 failed.
ERROR: '/home/moko/openembedded/packages/glibc/glibc_2.5.bb' failed
NOTE: Handling BitBake files: \ (4933/4933) [100 %]
NOTE: Parsing finished. 4694 cached, 0 parsed, 239 skipped, 0 masked.
NOTE: build 200801101443: started

OE Build Configuration:
BB_VERSION     = "1.8.8"
OE_REVISION    = "d0954a8a227efc014d29aba8d911adfc59934357"
TARGET_ARCH    = "arm"
TARGET_OS      = "linux-gnueabi"
MACHINE        = "fic-gta01"
DISTRO         = "openmoko"
DISTRO_VERSION = "P1-Snapshot-20080110"
TARGET_FPU     = "soft"

ERROR: No providers of build target u-boot-openmoko (for [])
make: *** [openmoko-devel-image] Error 1




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.



--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1175

           Summary: Automatic ipkg kernel upgrade needs stricter sanity
                    check
           Product: OpenMoko
           Version: 2007.2
          Platform: Neo1973
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: kernel
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]
                CC: [email protected]


Last night, I did a bleeding-edge update and build, then did the usual ipkg
update && ipkg upgrade dance.

A new version of the kernel was built (svnr3810), and I ended up with an .ipk
but for some reason I *didn't* get a corresponding kernel image file.

During the ipkg upgrade, the automatic ipkg kernel flasher erased the existing
kernel partition before discovering it didn't have anything to flash, so I ended
up with an empty kernel partition and the device would not boot.

This was easy enough to fix (this time) with a manual kernel flash using
dfu-util, but it probably shouldn't have erased the partition without first
checking (and perhaps even MD5-ing) the image it intends to flash.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.



--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1176

           Summary: Truncated u-boot printout of kernel version string
           Product: OpenMoko
           Version: 2007.2
          Platform: Neo1973
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: u-boot
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]
                CC: [email protected]


I'm pretty sure this is a u-boot function and not a kernel function, but in any
event . . .

It's not a trivial matter to figure out what kernel is installed and operative.
 The obvious choices would be uname -r or look at what ipkgs are installed.

Unfortunately, uname omits the svn revision -- I get only "2.6.22.5-moko11". 
And ipkg list_installed gives me:

kernel - 2.6.22.5-moko11+svnr3743-r10 - Linux 2.6.x kernel for FIC SmartPhones
shipping w/ OpenMoko
kernel-2.6.21.6-moko11 - 2.6.21.6-moko11-r2 - 2.6 Linux Development Kernel for
FIC Neo1973 (GTA01)
kernel-2.6.22.5-moko11 - 2.6.22.5-moko11+svnr3777-r10 - Linux 2.6.x kernel for
FIC SmartPhones shipping w/ OpenMoko
kernel-image-2.6.21.6-moko11 - 2.6.21.6-moko11-r2 - 2.6 Linux Development Kernel
for FIC Neo1973 (GTA01)
kernel-image-2.6.22.5-moko11 - 2.6.22.5-moko11+svnr3801-r10 - Linux 2.6.x kernel
for FIC SmartPhones shipping w/ OpenMoko

. . . which doesn't narrow things down much.

But by going into the u-boot menu and booting from there, there is a display for
a fraction of a second of the full kernel file information, including the svn
revision, build date, etc.

HOWEVER the svn revision is truncated by one digit.  In my case, the info ended
in "r377" which, when checked against the ipkg list, suggests that I have r3777.
 But it would not distinguish between multiple kernel options having svn
revisions that differ only in the last digit.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.



--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1177

           Summary: '-e command' support for virtual terminal
           Product: OpenMoko
           Version: 2007.2
          Platform: Neo1973
        OS/Version: FreeBSD
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: openmoko-terminal
        AssignedTo: [email protected]
        ReportedBy: [EMAIL PROTECTED]
                CC: [email protected]


It would be nice to support launching applications in openmoko-terminal from the
command line like '-e' in rxvt.  This would allow launching terminal
applications from a .desktop entry in a virtual terminal.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You are on the CC list for the bug, or are watching someone who is.



--- End Message ---
--- Begin Message ---
[This e-mail has been automatically generated.]

You have one or more bugs assigned to you in the Bugzilla 
bugsystem (http://bugzilla.openmoko.org/cgi-bin/bugzilla/) that require
attention.

All of these bugs are in the NEW state, and have not been touched
in 7 days or more.  You need to take a look at them, and 
decide on an initial action.

Generally, this means one of three things:

(1) You decide this bug is really quick to deal with (like, it's INVALID),
    and so you get rid of it immediately.
(2) You decide the bug doesn't belong to you, and you reassign it to someone
    else.  (Hint: if you don't know who to reassign it to, make sure that
    the Component field seems reasonable, and then use the "Reassign bug to
    owner of selected component" option.)
(3) You decide the bug belongs to you, but you can't solve it this moment.
    Just use the "Accept bug" command.

To get a list of all NEW bugs, you can use this URL (bookmark it if you like!):

    
http://bugzilla.openmoko.org/cgi-bin/bugzilla/buglist.cgi?bug_status=NEW&[EMAIL 
PROTECTED]

Or, you can use the general query page, at
http://bugzilla.openmoko.org/cgi-bin/bugzilla/query.cgi.

Appended below are the individual URLs to get to all of your NEW bugs that 
haven't been touched for a week or more.

You will get this message once a day until you've dealt with these bugs!

  http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=934
  http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=935
  http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1012
  http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1081
  http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1107
  http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1127
  http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1133
  http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1136



--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1145

[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From [EMAIL PROTECTED]  2008-01-11 08:54 -------
Okay, my kernel patches have been reworked and pushed to svn in revions #3788,
#3790 and #3801. So now, the kernel recipe
packages/linux/linux-openmoko_2.6.22.5.bb from OpenMoko should just build the
kernel with those patches in. They bring rotation support to the framebuffer.

On top of that, xglamo commits until
http://cgit.freedesktop.org/~dodji/xglamo/commit/?id=4ac647010aef6b955d6dfb4864dcc58494561b06
 should bring RandR rotation/resize support to the Xglamo server on GTA02.

The kdrive recipe packages/xorg-xserver/xserver-kdrive_1.3.0.0.bb from OpenMoko
has been updated to grab the Xglamo sources from my git repo from now. The
corresponding revision number from monotone.openmoko.org is
d0954a8a227efc014d29aba8d911adfc59934357.

So basically, getting the last OpenMoko and generating an image should bring
RandR support in Xglamo for now.

So I am closing this bug.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.



--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1067

[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From [EMAIL PROTECTED]  2008-01-11 08:56 -------
Okay to overcome the artifacts, the solution is just to set the right pixclock
depending on the orientation. Basically 50000 picoseconds for 480x640 and 100000
picoseconds for 640x480.

So closing this bug now.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.



--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1145

Bug 1145 depends on bug 1067, which changed state.

Bug 1067 Summary: artifacts when doing glamo HW rotation
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1067

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED





------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.



--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1178

           Summary: iron out XVideo support in Xglamo
           Product: OpenMoko
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Xfbdev (kdrive), Xglamo
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]
                CC: [email protected]


Take over XVideo support and finish what needs to be done, basically.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.



--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1178

[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED





------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.



--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog

Reply via email to