<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Christopher Earl schrieb:
<blockquote cite="mid:47AC2D340200003A00000B35@rhmail3.clarkstate.edu"
type="cite">
<pre wrap="">I think he had the right intentions about this idea, however it would require vast CPU resources or a coprocessor dedicated to firware/driver layer managment. This is unlikley to happen, However trying to unlock the virtual lips of companies would be a huge step forward. Not to play devils advocate but if the firmware was loaded into RAM at boot a simple RAM dump would allow reverse engineering of the data, and thus the device,So im OK with that.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Andy Powell <a class="moz-txt-link-rfc2396E" href="mailto:andy@automated.it"><andy@automated.it></a> 02/08/08 10:08 AM >>>
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->On Friday 08 February 2008 08:46, Lally Singh wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Feb 7, 2008 8:32 PM, Wolfgang Spraul <a class="moz-txt-link-rfc2396E" href="mailto:wolfgang@openmoko.com"><wolfgang@openmoko.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">He suggested we treat any chipset with proprietary firmware as a black-
box, a circuit. He suggested we ignore the firmware inside. If the
firmware is buggy and the vendor needs the ability to update the
firmware, we instead ask the vendor to reduce the firmware to the bare
minimum, so that it can be very simple and bug free, and move the rest
of the logic into the GPL'ed driver running on the main CPU. This way
we completely avoid the issue of distributing proprietary firmware
updates and binary firmware updaters with restrictive licensing that
load only cryptographically signed firmware.
</pre>
</blockquote>
<pre wrap="">While I see the benefits here, it seems that we're sacrificing CPU
time, power usage, and lowered utilization of other devices on the
phone to get over a license issue -- a technical resolution to a legal
problem.
</pre>
</blockquote>
<pre wrap=""><!---->
I have to agree here. This is a low powered (CPU) device that contains chips
designed to perform specific tasks. Why on earth would anyone think that
making the cpu handle those tasks be a good idea?
Apple can manage to allow their users to update the baseband on the iPhone so
why can't FIC on the neo?
Seriously, I want a phone that works properly more than I want one that dies
during a call because the cpu is maxed out doing stuff that the chips in the
same device should be doing..
Rome wasn't built in a day and you're not going to change manufacturers
overnight either. In the meantime we have to be flexible. Mr Stallman appears
to live in a land where every device has infinite resources - some would say
it's called 'LaLa'
Andy
</pre>
</blockquote>
I like the idea of having total control over my electronic devices -
especially if they are able to collect everything about my life like a
mobile phone. Thats why I'm currently living without any mobil.<br>
If I am able to look into what runs on my device, I can trust that
stuff. so I'm one of those guys saying doing everything open source is
way better than gaining a little cpu-speed. and by the way I don't
think that the cpu-speed is too limited on that device. usually cpus
don't have to do anything. and a driver doesnt need too much. This smal
gap could be closed esysly by optimizing things for the hardware.<br>
<br>
regards enaut<br>
</body>
</html>