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 321] ftdi_eeprom often fails silently
([EMAIL PROTECTED])
2. [Bug 321] ftdi_eeprom often fails silently
([EMAIL PROTECTED])
3. Your Bugzilla buglist needs attention. ([EMAIL PROTECTED])
4. [Bug 322] New: gsmd phonebook cache and OTA updates to
ADN/FDN/SDN ([EMAIL PROTECTED])
5. [Bug 322] New: gsmd phonebook cache and OTA updates to
ADN/FDN/SDN ([EMAIL PROTECTED])
6. [Bug 321] ftdi_eeprom often fails silently
([EMAIL PROTECTED])
7. [Bug 321] ftdi_eeprom often fails silently
([EMAIL PROTECTED])
8. [Bug 321] ftdi_eeprom often fails silently
([EMAIL PROTECTED])
9. [Bug 321] ftdi_eeprom often fails silently
([EMAIL PROTECTED])
10. [Bug 321] ftdi_eeprom often fails silently
([EMAIL PROTECTED])
11. [Bug 321] ftdi_eeprom often fails silently
([EMAIL PROTECTED])
12. [Bug 288] Openmoko-appmanager need report install status
after install single .ipk files
([EMAIL PROTECTED])
13. [Bug 321] ftdi_eeprom often fails silently
([EMAIL PROTECTED])
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=321
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
------- 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=321
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
------- 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 ---
[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=69
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=70
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=112
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=114
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=137
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=141
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=181
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=192
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=204
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=232
--- End Message ---
--- Begin Message ---
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=322
Summary: gsmd phonebook cache and OTA updates to ADN/FDN/SDN
Product: Neo1973 Hardware
Version: unspecified
Platform: Neo1973
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: GSM Modem
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
If gsmd employs a cache to avoid repeated accesses to the SIM addressbooks there
is a danger that it will not be up-to-date if the SIM has had an OTA update.
In such circumstances the SIM should issue a REFRESH command to the GSM modem so
that it will be aware of the change. I am not familiar enough with 07.10 and GSM
modems to know if this REFRESH would be propogated to gsmd. If it is then we
should ensure that gsmd handles it and refreshes the cache.
Notes:
1) Some operators provide a web interface to allow subscribers to send such OTA
updates to the addressbooks.
2) Older Nokia handsets had a mechanism which would read directly from the SIM
(ie pressing "1#" to read ADN record 1). Otherwise the handset uses its cached
version which would differ following an OTA on Phase 2 handsets which don't
support REFRESH. Maybe a similar approach should be adopted so the API allows
the cached version to be used or can force the entry to be read from the SIM.
------- 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=322
Summary: gsmd phonebook cache and OTA updates to ADN/FDN/SDN
Product: Neo1973 Hardware
Version: unspecified
Platform: Neo1973
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: GSM Modem
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
If gsmd employs a cache to avoid repeated accesses to the SIM addressbooks there
is a danger that it will not be up-to-date if the SIM has had an OTA update.
In such circumstances the SIM should issue a REFRESH command to the GSM modem so
that it will be aware of the change. I am not familiar enough with 07.10 and GSM
modems to know if this REFRESH would be propogated to gsmd. If it is then we
should ensure that gsmd handles it and refreshes the cache.
Notes:
1) Some operators provide a web interface to allow subscribers to send such OTA
updates to the addressbooks.
2) Older Nokia handsets had a mechanism which would read directly from the SIM
(ie pressing "1#" to read ADN record 1). Otherwise the handset uses its cached
version which would differ following an OTA on Phase 2 handsets which don't
support REFRESH. Maybe a similar approach should be adopted so the API allows
the cached version to be used or can force the entry to be read from the SIM.
------- 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=321
------- Additional Comments From [EMAIL PROTECTED] 2007-03-29 06:49 -------
More data: according to the data read back from the EEPROM, the board
where the IDs are okay and the board where they aren't, both a) have
indeed the EEPROM content ftdi_eeprom intended to write, and b) the
two EEPROM contents are identical.
A cursory check of the code in libftdi-0.9/src/ftdi.c:ftdi_eeprom_build
vs. the EEPROM content indicates that the EEPROM contains indeed what
was intended there. (E.g., that we don't have any integer size or byte
order issues.)
As a further verification step, I read back the EEPROM of my JTAGkey.
Now it gets spooky: that EEPROM contains only the IDs, but no strings.
However, usbview and lsusb happily print them. A quick search in
/usr/share/misc/usb.ids turned up neither the JTAGkey product ID, nor
any of the JTAGkey-specific strings. So it seems that this information
does indeed come from the USB device.
Also checked schematics and data sheets, for good measure. Everything
looks good there.
Closer inspection reveals that the string descriptors have quite
reasonable sizes, which indeed correspond to what lsusb et al. show.
Hmm. That looks interesting. If my suspicion is right, ftdi_eeprom
didn't get all too much testing with >64 words parts ...
------- 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=321
------- Additional Comments From [EMAIL PROTECTED] 2007-03-29 06:49 -------
More data: according to the data read back from the EEPROM, the board
where the IDs are okay and the board where they aren't, both a) have
indeed the EEPROM content ftdi_eeprom intended to write, and b) the
two EEPROM contents are identical.
A cursory check of the code in libftdi-0.9/src/ftdi.c:ftdi_eeprom_build
vs. the EEPROM content indicates that the EEPROM contains indeed what
was intended there. (E.g., that we don't have any integer size or byte
order issues.)
As a further verification step, I read back the EEPROM of my JTAGkey.
Now it gets spooky: that EEPROM contains only the IDs, but no strings.
However, usbview and lsusb happily print them. A quick search in
/usr/share/misc/usb.ids turned up neither the JTAGkey product ID, nor
any of the JTAGkey-specific strings. So it seems that this information
does indeed come from the USB device.
Also checked schematics and data sheets, for good measure. Everything
looks good there.
Closer inspection reveals that the string descriptors have quite
reasonable sizes, which indeed correspond to what lsusb et al. show.
Hmm. That looks interesting. If my suspicion is right, ftdi_eeprom
didn't get all too much testing with >64 words parts ...
------- 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=321
------- Additional Comments From [EMAIL PROTECTED] 2007-03-29 06:49 -------
More data: according to the data read back from the EEPROM, the board
where the IDs are okay and the board where they aren't, both a) have
indeed the EEPROM content ftdi_eeprom intended to write, and b) the
two EEPROM contents are identical.
A cursory check of the code in libftdi-0.9/src/ftdi.c:ftdi_eeprom_build
vs. the EEPROM content indicates that the EEPROM contains indeed what
was intended there. (E.g., that we don't have any integer size or byte
order issues.)
As a further verification step, I read back the EEPROM of my JTAGkey.
Now it gets spooky: that EEPROM contains only the IDs, but no strings.
However, usbview and lsusb happily print them. A quick search in
/usr/share/misc/usb.ids turned up neither the JTAGkey product ID, nor
any of the JTAGkey-specific strings. So it seems that this information
does indeed come from the USB device.
Also checked schematics and data sheets, for good measure. Everything
looks good there.
Closer inspection reveals that the string descriptors have quite
reasonable sizes, which indeed correspond to what lsusb et al. show.
Hmm. That looks interesting. If my suspicion is right, ftdi_eeprom
didn't get all too much testing with >64 words parts ...
------- 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=321
------- Additional Comments From [EMAIL PROTECTED] 2007-03-29 07:25 -------
Solved the strings problem. Since our EEPROM (a 93C56) is larger than 128
bytes, the address wrapping libftdi-0.9/src/ftdi.c assumes doesn't happen.
So we have to a) put the strings above 0x80 (the descriptors want the
addresses there, says the code, without explaining why), and b) write 256
instead of 128 bytes.
SVN: developers/werner/libftdi-c56-strings-dirty-hack.patch
Note that this doesn't solve the "programming ignored" problem. But I
suspect something along very similar lines there.
I also don't quite understand through which magic Harald got his boards
to work completely. Perhaps there is some sort of fallback mode that
simulates the wrap-around in the FT2232 if we just ask nicely.
------- 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=321
------- Additional Comments From [EMAIL PROTECTED] 2007-03-29 07:25 -------
Solved the strings problem. Since our EEPROM (a 93C56) is larger than 128
bytes, the address wrapping libftdi-0.9/src/ftdi.c assumes doesn't happen.
So we have to a) put the strings above 0x80 (the descriptors want the
addresses there, says the code, without explaining why), and b) write 256
instead of 128 bytes.
SVN: developers/werner/libftdi-c56-strings-dirty-hack.patch
Note that this doesn't solve the "programming ignored" problem. But I
suspect something along very similar lines there.
I also don't quite understand through which magic Harald got his boards
to work completely. Perhaps there is some sort of fallback mode that
simulates the wrap-around in the FT2232 if we just ask nicely.
------- 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=321
------- Additional Comments From [EMAIL PROTECTED] 2007-03-29 07:25 -------
Solved the strings problem. Since our EEPROM (a 93C56) is larger than 128
bytes, the address wrapping libftdi-0.9/src/ftdi.c assumes doesn't happen.
So we have to a) put the strings above 0x80 (the descriptors want the
addresses there, says the code, without explaining why), and b) write 256
instead of 128 bytes.
SVN: developers/werner/libftdi-c56-strings-dirty-hack.patch
Note that this doesn't solve the "programming ignored" problem. But I
suspect something along very similar lines there.
I also don't quite understand through which magic Harald got his boards
to work completely. Perhaps there is some sort of fallback mode that
simulates the wrap-around in the FT2232 if we just ask nicely.
------- 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=288
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Additional Comments From [EMAIL PROTECTED] 2007-03-29 10:13 -------
At the r1547, the application manager shows a message dialog to report the
install result. And show the installed packages list in the navigation area.
------- 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=321
------- Additional Comments From [EMAIL PROTECTED] 2007-03-29 10:41 -------
I hate to say this, but the "can't program" issue seems to be hardware.
While fiddling with power to the "new" board that didn't want to be
programmed (I was setting it up for automated tests involving power
cycling), I all of a sudden got the "official" IDs. Needless to say, if
I just pulled and re-connected the good old USB plug, it reverted to the
default settings.
Now I just wish my scope had a PC output so that I could make my test
rig take pictures when "something happens" ...
Again, this is what happens:
- program the board with (hacked) ftdi_eeprom: success
- read back with ftdi_eeprom: EEPROM content is perfect
- power cycle (unplug, then re-plug USB): board comes up with default
values
- power cycle in a different way (*): board comes up with the correct
settings
(*) I haven't reproduced the exact timing yet. Also, since I only cut
VBUS, there may be some sneak current through D+/D-.
So this looks as if a logical level is marginal, the EEPROM doesn't
come up fast enough, or the FT2232 comes up way too quick.
------- 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
