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 141] Need support for device under WIndows and OS X
([EMAIL PROTECTED])
2. [Bug 141] Need support for device under WIndows and OS X
([EMAIL PROTECTED])
3. [Bug 220] libgsmd_device.c is missing
([EMAIL PROTECTED])
4. [Bug 220] libgsmd_device.c is missing
([EMAIL PROTECTED])
5. [Bug 210] "now" causes frequent rebuilds and fills disks
([EMAIL PROTECTED])
6. [Bug 210] "now" causes frequent rebuilds and fills disks
([EMAIL PROTECTED])
7. [Bug 210] "now" causes frequent rebuilds and fills disks
([EMAIL PROTECTED])
8. [Bug 195] passthrough mode (Directly use GSM Modem from PC
([EMAIL PROTECTED])
9. [Bug 195] passthrough mode (Directly use GSM Modem from PC
([EMAIL PROTECTED])
10. [Bug 195] passthrough mode (Directly use GSM Modem from PC
([EMAIL PROTECTED])
11. [Bug 195] passthrough mode (Directly use GSM Modem from PC
([EMAIL PROTECTED])
12. [Bug 195] passthrough mode (Directly use GSM Modem from PC
([EMAIL PROTECTED])
13. [Bug 81] Decide how PMU RTC alarm interrupt is signalled to
userspace ([EMAIL PROTECTED])
14. [Bug 81] Decide how PMU RTC alarm interrupt is signalled to
userspace ([EMAIL PROTECTED])
15. [Bug 226] dfu-util-native do_deploy tries to install from
wrong source filename ([EMAIL PROTECTED])
16. [Bug 226] dfu-util-native do_deploy tries to install from
wrong source filename ([EMAIL PROTECTED])
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=141
------- Additional Comments From [EMAIL PROTECTED] 2007-03-03 14:56 -------
This basically means two things
1) bootloader access (CDC ACM)
this should generally work, but might need some changes in the CDC ACM
descriptor in our u-boot version.
2) ethernet access to the linux kernel (CDC Ethernet / RNDIS)
This is generally well supported and lots of other Linxu handhenlds use it.
Please see http://maemo.org/maemowiki/USBnetworkingWinXP
Somebody might consider looking into
http://www.microsoft.com/whdc/device/network/NDIS/rndis.mspx
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=141
------- Additional Comments From [EMAIL PROTECTED] 2007-03-03 14:56 -------
This basically means two things
1) bootloader access (CDC ACM)
this should generally work, but might need some changes in the CDC ACM
descriptor in our u-boot version.
2) ethernet access to the linux kernel (CDC Ethernet / RNDIS)
This is generally well supported and lots of other Linxu handhenlds use it.
Please see http://maemo.org/maemowiki/USBnetworkingWinXP
Somebody might consider looking into
http://www.microsoft.com/whdc/device/network/NDIS/rndis.mspx
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=220
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Additional Comments From [EMAIL PROTECTED] 2007-03-03 17:35 -------
fixed by backing out that commit
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=220
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Additional Comments From [EMAIL PROTECTED] 2007-03-03 17:35 -------
fixed by backing out that commit
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=210
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
------- Additional Comments From [EMAIL PROTECTED] 2007-03-04 00:18 -------
I have written a proof-of-concept implementation against bitbake-1.6.2 which
calls 'svn info' on the repository to obtain the current revision number and
then use this for tarball filenames and within PR.
Henryk (new owner of this bug) has more of a clue about python and will clean it
up and port it to other fetchers (git at least), and then merge it with current
upstream bitbake.
Henryk: Please have a look at bitbake 1.6.6 and see whether the new svn fetcher
would help us.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=210
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
------- Additional Comments From [EMAIL PROTECTED] 2007-03-04 00:18 -------
I have written a proof-of-concept implementation against bitbake-1.6.2 which
calls 'svn info' on the repository to obtain the current revision number and
then use this for tarball filenames and within PR.
Henryk (new owner of this bug) has more of a clue about python and will clean it
up and port it to other fetchers (git at least), and then merge it with current
upstream bitbake.
Henryk: Please have a look at bitbake 1.6.6 and see whether the new svn fetcher
would help us.
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=210
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
------- Additional Comments From [EMAIL PROTECTED] 2007-03-04 00:18 -------
I have written a proof-of-concept implementation against bitbake-1.6.2 which
calls 'svn info' on the repository to obtain the current revision number and
then use this for tarball filenames and within PR.
Henryk (new owner of this bug) has more of a clue about python and will clean it
up and port it to other fetchers (git at least), and then merge it with current
upstream bitbake.
Henryk: Please have a look at bitbake 1.6.6 and see whether the new svn fetcher
would help us.
------- 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 ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=195
------- Additional Comments From [EMAIL PROTECTED] 2007-03-04 00:28 -------
I'm not entirely sure if u-boot is really the right location to do this.
Having it in u-boot would make sure that there is no conflict between native
phone gsmd (plus higher level apps) and the passthrough/host access.
Heving it in userspace on linux would mean that the phone could still be used as
a PDA. Also, an userspace implementation could probably even be accessed via
Bluetooth at some later point. Plus it could be extended to just give access to
one of the demultiplexed DLC's, 'sharing' the phone.
Also, having it not in u-boot means we don't need to do a u-boot update (which
is critical).
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You reported the bug, or are watching the reporter.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=195
------- Additional Comments From [EMAIL PROTECTED] 2007-03-04 00:28 -------
I'm not entirely sure if u-boot is really the right location to do this.
Having it in u-boot would make sure that there is no conflict between native
phone gsmd (plus higher level apps) and the passthrough/host access.
Heving it in userspace on linux would mean that the phone could still be used as
a PDA. Also, an userspace implementation could probably even be accessed via
Bluetooth at some later point. Plus it could be extended to just give access to
one of the demultiplexed DLC's, 'sharing' the phone.
Also, having it not in u-boot means we don't need to do a u-boot update (which
is critical).
------- 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=195
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
Target Milestone|--- |Phase 1
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=195
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
Target Milestone|--- |Phase 1
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You reported the bug, or are watching the reporter.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=195
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
Target Milestone|--- |Phase 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=81
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
------- Additional Comments From [EMAIL PROTECTED] 2007-03-04 00:58 -------
There already is an environment variable that gets initialized with the first
read of OOCS (or was it INT1) register of the PMU.
We somehow need to pass this variable either as boot parameter to the kernel (if
the alarm is actually waking us up from power off mode).
If we're resuming from power off, then the PMU wakeup reason should not be read,
and the kernel PCF50606 driver should receive the ALARM interrupt.
This needs to be implemented and verified.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=81
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
------- Additional Comments From [EMAIL PROTECTED] 2007-03-04 00:58 -------
There already is an environment variable that gets initialized with the first
read of OOCS (or was it INT1) register of the PMU.
We somehow need to pass this variable either as boot parameter to the kernel (if
the alarm is actually waking us up from power off mode).
If we're resuming from power off, then the PMU wakeup reason should not be read,
and the kernel PCF50606 driver should receive the ALARM interrupt.
This needs to be implemented and verified.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You reported the bug, or are watching the reporter.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=226
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
------- Additional Comments From [EMAIL PROTECTED] 2007-03-04 01:04 -------
no, the source filename is quite correct. We do want the statically linked
version in the deploy directory, to get rid of dependencies to libusb.
I would accept a patch that modifies "upstream" dfu-util to only statically link
against libusb, while being dynamically linked against glibc.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=226
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
------- Additional Comments From [EMAIL PROTECTED] 2007-03-04 01:04 -------
no, the source filename is quite correct. We do want the statically linked
version in the deploy directory, to get rid of dependencies to libusb.
I would accept a patch that modifies "upstream" dfu-util to only statically link
against libusb, while being dynamically linked against glibc.
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
