<div dir="ltr">It's nr. 1 bug for me too. I have qTopia insalled, so in theory I've got working phone. But, I can't use it as such, because It constantly re-registers.<br>
<br><div class="gmail_quote">On Thu, Oct 16, 2008 at 5:41 PM, Joel Newkirk <span dir="ltr"><<a href="mailto:freerunner@newkirk.us" target="_blank">freerunner@newkirk.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Tue, 14 Oct 2008 22:35:43 -0400, Joel Newkirk <<a href="mailto:freerunner@newkirk.us" target="_blank">freerunner@newkirk.us</a>><br>
wrote:<br>
<div><div></div><div>> On Tue, 14 Oct 2008 10:34:17 -0700, Michael Shiloh <<a href="mailto:michael@openmoko.org" target="_blank">michael@openmoko.org</a>><br>
> wrote:<br>
>> Marco Trevisan (Treviņo) wrote:<br>
>>> Leonti Bielski wrote:<br>
>>>> As I get it it is unfortunately impossible to upgrade the firmware at<br>
>>>> home because of NDA - only Openmoko Inc. employee can do that.<br>
>>>> I hope (but doubt it ) it will will be available to the public someday<br>
>>>> in the future.<br>
>>><br>
>>> Why? Isn't it a binary blob?<br>
>>> I can't understand why they can't release the firmware binary...<br>
>>><br>
>><br>
>> Two issues:<br>
>><br>
>> 1. If we allow you to update the firmware, then our own standard of<br>
>> openness requires that we give you the source. Due to NDA with chip<br>
>> manufacturer, and probably FCC regulations as well, we're not allowed to<br>
><br>
>> give you the source, so therefore we chose not to allow you to update<br>
>> the firmware.<br>
>><br>
>> 2. The NDA with the chip manufacturer does not allow us to distribute<br>
>> the update utility.<br>
>><br>
>> Michael<br>
><br>
> I'm very curious if that restriction extends to Openmoko performing the<br>
> update via remote connection to the user's host computer or Freerunner...<br>
<br>
> ;) Something along the lines of a 'firmware update installer' that we<br>
run<br>
> locally, which tunnels to OM and triggers a firmware update run by &<br>
> managed by OM, but executing on the local host system or directly on the<br>
> Freerunner. I'd have no objection to setting up remote login to my FR if<br>
> that were needed for such an unusual circumstance as updating GSM<br>
> firmware.<br>
> (If it could be fully automated at your end so much the better, but even<br>
> requiring manual action at your end it would probably be faster and<br>
> cheaper<br>
> for you, and certainly for us, than shipping every Freerunner suffering<br>
> this issue back to OM for the update, always assuming that turns out to<br>
be<br>
> the needed resolution of course...)<br>
><br>
> I'm wondering if the restriction is more to protect the firmware itself<br>
or<br>
> the utility that performs the update.<br>
><br>
> j<br>
<br>
</div></div>I'm starting to think of this as BUG#1. I tested the other evening, and<br>
with nominal full-strength GSM signal, 45% of my inbound calls (9 of 20)<br>
never reached the phone because it was re-registering. And I'm damned sure<br>
NOT happy with the prospect of another 2-week+ RMA cycle to get the<br>
firmware bug addressed. (worse I expect for other who bought from a<br>
distributor instead of direct - I assume you have to RMA through the<br>
distributor, who would then need to ship back to OM for firmware update,<br>
then back to distrib, then back to customer?? How long, 4 weeks??)<br>
<br>
Are any other options being explored?<br>
<br>
(Can unpaid interns at Openmoko perform the operation under the terms of<br>
the NDA? If so, how many offsite interns can you get away with having? ;)<br>
<div><div></div><div><br>
j<br>
<br>
<br>
_______________________________________________<br>
support mailing list<br>
<a href="mailto:support@lists.openmoko.org" target="_blank">support@lists.openmoko.org</a><br>
<a href="https://lists.openmoko.org/mailman/listinfo/support" target="_blank">https://lists.openmoko.org/mailman/listinfo/support</a><br>
</div></div></blockquote></div><br></div>