Re: SD on Sharp Zaurus 5500 (was: GPLv3 and Mobile Phones)
Am Samstag, 9. Dezember 2006 22:06 schrieb Michael 'Mickey' Lauer: > > This is just plain wrong. It is extremely hard to come up with an SD > driver for the Sharp Zaurus 5500, because there is 0 documentation > about the Locomo custom ASIC used in this particular model. > Sorry for the offtopic, but i think it is a very important issue for the Linux development. AFAIK almost everything you need to know about Locomo ASIC is already documented. The only undocumented part is the SPI clock speed <-> divisor relation. If somebody wants to operate an SD card at a lower speed as it is now, he can manually change the divisor bits in LOCOMO_SPIMD and measure the clock frequency on an SD pin. What is really missing is the SPI MMC control code, but it was documented from the very beginning by Sandisk. A minimal hack can be found here http://opensimpad.org/index.php/Simpad-mmc.c but somebody more experienced with the mainline MMC code should write a proper driver. > I don't know where you got the notion of some "protest against the > decision made by Sharp", but this is just nonsense. > There was a strong movement against writing a Linux SD driver without having a vendor chipset documentation. We have 4-5 of them now, almost all are reverse engineered, and are simply not comparable in complexity with the Locomo SPI used on SL-5500. Just take HTC ASIC3 as an example. Oleg. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
SD on Sharp Zaurus 5500 (was: GPLv3 and Mobile Phones)
This is way off topic, but I can't stand it uncorrected. Oleg Gusev wrote: > Am Samstag, 9. Dezember 2006 17:59 schrieb Richard Franks: >> >> You might have to perform some really ugly hacks to ensure this >> backwards compatibility, and it may even affect overall system >> performance - but it's still a pragmatic choice - the Zaurus was stuck >> on principle, the unwillingness to invest significant kernel changes >> or compromises because of a closed-source module. >> > I have an original Zaurus 5500, and it still does not support SD/SDIO > in the 2.6 kernel. An experienced kernel hacker can easily write a driver, > because the card is on a simple SPI port. > It was not done to protest against the decision made by Sharp to > include a binary driver. > Was it really a pragmatic choice ? This is just plain wrong. It is extremely hard to come up with an SD driver for the Sharp Zaurus 5500, because there is 0 documentation about the Locomo custom ASIC used in this particular model. I don't know where you got the notion of some "protest against the decision made by Sharp", but this is just nonsense. Having been the maintainer of OpenZaurus for some years, I know everything about the SD problem. If it would be easy, it would've been done since long. Regards, :M: -- Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
On 12/9/06, Stefan Schmidt <[EMAIL PROTECTED]> wrote: With ROM you refer to chips that can be written only once? I doubt that many of such chips are still alive. PROM's are used typically where you are producing an end product where you don't need to update. They're MUCH cheaper than an EPROM, and when you're turning out millions of a cheap mickey-d's video game toy, being able to erase the chip doesn't matter Likewise, they're used when extreme ruggedness is needed, since you actually burn part of the silicone during writing, it is more secure from tampering, and less susceptible to damage than a more complex (E)EPROM, EPROMs are susceptible to UV radiation, and EEPROMs to electrical voltages. Since once a fuse cannot be changed once it is blown, it is much more difficult to tamper with the circuit. However, in this case, we're talking about memory that we don't have access to, this could be an (E)EPROM or even flash that we just can't send an erasure signal to. anyways, just thought I'd let you know -- --Jeff What DO you call whitewater when you live in the desert? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
Hello. On Sat, 2006-12-09 at 11:45, Dave Crossland wrote: > > My question is if the separate system-on-a-chip is ROM, or if it can > be upgraded? With ROM you refer to chips that can be written only once? I doubt that many of such chips are still alive. Keep in mind that I'm not speaking for the FIC team here. The flash chips containing the BP OS will be able get new firmware flashed. I'm pretty sure that no GSM stack is bugfree. regards Stefan Schmidt signature.asc Description: Digital signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
On Saturday 09 December 2006 19:46, Stefan Schmidt wrote: > On Sat, 2006-12-09 at 14:00, Gabriel Ambuehl wrote: > > Personally I say add the hardware, even if it needs a binary driver (or > > even just firmware). The religious group is then free to remove the > > driver and not use WiFi ;) > > This "religious group" contains the coreteam of OpenMoko. :) > From a marketing point of view, it would likely still be beneficial to add the hardware... At least it would all of the "we want wifi" group shut up for good ;) pgpab1znpGfma.pgp Description: PGP signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
Hello. On Sat, 2006-12-09 at 13:24, Gabriel Ambuehl wrote: > On Saturday 09 December 2006 13:00, Oleg Gusev wrote: > > The TI acx100 driver used by many PDAs and phones > > is released under GPL and loads the binary firmware > > into baseband and radio amplifier. > > Supposedly even that is too proprietary (I think we were over this at some > point)... But then a closed GPS daemon is ok just because it doesnt live in > kernel. So if we can figure out a way to have WiFi drivers run in userspace > that might be ok? Userspace driver don't use all the GPL code inside the kernel. It is a question of derived work. regards Stefan Schmidt signature.asc Description: Digital signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
Hello. On Sat, 2006-12-09 at 13:00, Oleg Gusev wrote: > Am Samstag, 9. Dezember 2006 12:34 schrieb Stefan Schmidt: > > > > Keep in mind that the FIC team have no wifi on > > the phone because no vendor allowed them to put the wlan driver under > > GPL. So they make the dicision to lack wifi instead of using unethical > > binary-only kernel modules. > > > The TI acx100 driver used by many PDAs and phones > is released under GPL and loads the binary firmware > into baseband and radio amplifier. IIRC TI acx100 driver is a re driver. It's not the only one in the kernel. Wireless driver are hard to be done right and without datasheets it's even harder. The vendors can still offer the datasheets under a NDA which allows and GPL driver written with this information. It is totaly fine to re a driver for your private hardware, but if you are a company which like to builf this hardware into their devices, a re driver is not a good choice in my opinion. > > For your questions about GPLv2 vs. GPLv3 I can just say it is the > > choice of the company which version they choose. Not everybody is > > happy with the new version. > > > Any developer is free to include the "or (at your option) any later version" > clause for his work. If you do this other people can use your code under GPLv3 or GPLv4 which you perhaps don't like. regards Stefan Schmidt signature.asc Description: Digital signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
Hello. On Sat, 2006-12-09 at 14:00, Gabriel Ambuehl wrote: > > Personally I say add the hardware, even if it needs a binary driver (or even > just firmware). The religious group is then free to remove the driver and not > use WiFi ;) This "religious group" contains the coreteam of OpenMoko. :) regards Stefan Schmidt signature.asc Description: Digital signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
RE: GPLv3 and Mobile Phones
>> It was not done to protest against the decision made by Sharp to >> include a binary driver. >> Was it really a pragmatic choice ? > >This is a rhetorical question? :-) I find this all kind of fascinating. I doubt this "protest" particularly impacts Sharp: after all, they've already gotten your money for the Zaurus. The main outcome here seems to be ensuring your own inability to take advantage of small, high-capacity storage media. I guess if that makes one feel virtuous, that's something, anyway... (For what it's worth, my general view is that making technical decisions based on political agendas leads to ungainly implementations, at the very least. ) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
On 12/9/06, Oleg Gusev <[EMAIL PROTECTED]> wrote: I have an original Zaurus 5500, and it still does not support SD/SDIO in the 2.6 kernel. An experienced kernel hacker can easily write a driver, because the card is on a simple SPI port. It was not done to protest against the decision made by Sharp to include a binary driver. Was it really a pragmatic choice ? This is a rhetorical question? :-) Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
Am Samstag, 9. Dezember 2006 17:59 schrieb Richard Franks: > > You might have to perform some really ugly hacks to ensure this > backwards compatibility, and it may even affect overall system > performance - but it's still a pragmatic choice - the Zaurus was stuck > on principle, the unwillingness to invest significant kernel changes > or compromises because of a closed-source module. > I have an original Zaurus 5500, and it still does not support SD/SDIO in the 2.6 kernel. An experienced kernel hacker can easily write a driver, because the card is on a simple SPI port. It was not done to protest against the decision made by Sharp to include a binary driver. Was it really a pragmatic choice ? Oleg. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
Hi Dave, On 12/9/06, Dave Crossland <[EMAIL PROTECTED]> wrote: I thought this blogpost from the FSFE might be of interest to the list and also relates to the question I asked earlier about how the openmoko relates to the FSF philosophy: OpenMoko = Open Mobile Communications Platform Neo1973 = physical handset using OpenMoko applications I think it may depend on how the Neo1973 specific code is distributed? OpenMoko is intended to run upon many different mobile architectures, so it would make a certain amount of sense (although this is an assumption) to not contain any Neo1973-specific code in the OpenMoko repository, but supply it through a software feed via the OpenMoko servers. I can also see the reasoning behind a kernel-type distribution, where support for (almost) everything comes in the same tarball. But I think the answer to that question probably shapes the answer to your question :-) Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
On 12/9/06, Paul Bohme <[EMAIL PROTECTED]> wrote: Would like to avoid similar again, if at all possible. Loading firmware into a device is no big deal - it doesn't link into any other code so might as well be any random opaque blob of data. Having to deal with the contortions involved when one of the modules you need is pinned in time while the rest of the system is straining to grow is something else entirely. Logical and reasoned argument like that above, is one thing. Turning it into an ethical issue implies that there is an ethical absolute which imbues ones opinion or preference with more 'correctness' than the next persons opinion or preference or logical argument. For example, it would be possible to support a even a 1.x closed-source, binary module in any kernel release version you wish. You might have to perform some really ugly hacks to ensure this backwards compatibility, and it may even affect overall system performance - but it's still a pragmatic choice - the Zaurus was stuck on principle, the unwillingness to invest significant kernel changes or compromises because of a closed-source module. But I don't think there is a 'right' or 'wrong' way here - everyone is free to choose what amount of closed-source software they are comfortable with. I'm just not comfortable seeing ethics and philosophy used as intellectual sledgehammers to crush dissenting viewpoints. It's not exactly honest! Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
Gabriel Ambuehl wrote: Personally I could care less if there was a binary only module there. I'm pragmatic, not religious. Saying we don't add that for such a reason doesn't help freedom of choice either. Personally I say add the hardware, even if it needs a binary driver (or even just firmware). The religious group is then free to remove the driver and not use WiFi ;) Am of similar opinion - while I'm fastidious about licensing (both on personal projects and using Linux extensively at work), it's for purely pragmatic reasons. Am of different opinion, however, on the binary modules, again for pragmatic reasons. The Zaurus was stuck with an old 2.4.x kernel for an extended period of time because the SD driver was a binary. Since that was one of the features that made the device great (CF and SD.. Yum) it was like having an anchor you have to drag around. Sucked. Would like to avoid similar again, if at all possible. Loading firmware into a device is no big deal - it doesn't link into any other code so might as well be any random opaque blob of data. Having to deal with the contortions involved when one of the modules you need is pinned in time while the rest of the system is straining to grow is something else entirely. -P ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
On Saturday 09 December 2006 13:42, Oleg Gusev wrote: > Am Samstag, 9. Dezember 2006 13:24 schrieb Gabriel Ambuehl: > > Supposedly even that is too proprietary (I think we were over this at > > some point)... > > I guess you are booting your computer from linuxbios ? :) Personally I could care less if there was a binary only module there. I'm pragmatic, not religious. Saying we don't add that for such a reason doesn't help freedom of choice either. Personally I say add the hardware, even if it needs a binary driver (or even just firmware). The religious group is then free to remove the driver and not use WiFi ;) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
Am Samstag, 9. Dezember 2006 13:24 schrieb Gabriel Ambuehl: > > Supposedly even that is too proprietary (I think we were over this at some > point)... I guess you are booting your computer from linuxbios ? :) > But then a closed GPS daemon is ok just because it doesnt live in > kernel. Closed GPS daemon is not a smart idea from the very beginning. AFAIK it does not load anything to the receiver, and only processes the incoming data. > So if we can figure out a way to have WiFi drivers run in userspace > that might be ok? It is unethical behaviour and defeats the idea of Openmoko. Such approach is already implemented by wince ;) Oleg. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: idea: security badge consolidation?
On 12/1/06, justin hugh daly <[EMAIL PROTECTED]> wrote: i work with multiple clients and vendors, and have amassed a good number of security badges. i was curious about the feasibility of being able to program the transmitter to send out the appropriate badge id based on location? well. that would defeat the whole security purpose of those badges - if you can record what they send and play that. technically it is possible to implement that of course. unless the badge is smart - e.g. does some rsa crypto for authentication. but very, very few people do that. Andreas ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
On Saturday 09 December 2006 13:00, Oleg Gusev wrote: > The TI acx100 driver used by many PDAs and phones > is released under GPL and loads the binary firmware > into baseband and radio amplifier. Supposedly even that is too proprietary (I think we were over this at some point)... But then a closed GPS daemon is ok just because it doesnt live in kernel. So if we can figure out a way to have WiFi drivers run in userspace that might be ok? pgpCJ2gCgtul1.pgp Description: PGP signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
Am Samstag, 9. Dezember 2006 12:34 schrieb Stefan Schmidt: > > Keep in mind that the FIC team have no wifi on > the phone because no vendor allowed them to put the wlan driver under > GPL. So they make the dicision to lack wifi instead of using unethical > binary-only kernel modules. > The TI acx100 driver used by many PDAs and phones is released under GPL and loads the binary firmware into baseband and radio amplifier. > > For your questions about GPLv2 vs. GPLv3 I can just say it is the > choice of the company which version they choose. Not everybody is > happy with the new version. > Any developer is free to include the "or (at your option) any later version" clause for his work. Oleg. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
On 09/12/06, Stefan Schmidt <[EMAIL PROTECTED]> wrote: Keep in mind that the FIC team have no wifi on the phone because no vendor allowed them to put the wlan driver under GPL. So they make the dicision to lack wifi instead of using unethical binary-only kernel modules. I did not know that. I really respect this decision - *very* impressive :-) For your questions about GPLv2 vs. GPLv3 I'm sorry I didn't write clearly enough - I wasn't asking about that :-) That is exactly what is happen with the gsm part of the phone. It is on a separate system. Own cpu, ram, etc. It communicate with the linux system over seriæl connection. My question is if the separate system-on-a-chip is ROM, or if it can be upgraded? -- Regards, Dave ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: GPLv3 and Mobile Phones
Hello. On Sat, 2006-12-09 at 10:52, Dave Crossland wrote: > > I thought this blogpost from the FSFE might be of interest to the list > and also relates to the question I asked earlier about how the > openmoko relates to the FSF philosophy: Of course you already know that Harald Welte, one of the OpenMoko devs, is the founder of gpl-violations.org and also attened most of the GPLv3 conferences. I think he will take care about potential prblem with the GPL. Keep in mind that the FIC team have no wifi on the phone because no vendor allowed them to put the wlan driver under GPL. So they make the dicision to lack wifi instead of using unethical binary-only kernel modules. For your questions about GPLv2 vs. GPLv3 I can just say it is the choice of the company which version they choose. Not everybody is happy with the new version. Another point is that personally I would not release software under a license which final version not not yet available. FSF did a good job. But I don't like the GFDL and I will see what I think about GPLv3 after I have read them on my own, not interpretated from other people. I would be thankfull if you could stop questions about this until the phone and source is released. The team need to focus on develpment right know. The philosophy stuff can be done later. [snip complete blog quote] That is exactly what is happen with the gsm part of the phone. It is on a separate system. Own cpu, ram, etc. It communicate with the linux system over seri?l connection. regards Stefan Schmidt signature.asc Description: Digital signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
GPLv3 and Mobile Phones
Hi, I thought this blogpost from the FSFE might be of interest to the list and also relates to the question I asked earlier about how the openmoko relates to the FSF philosophy: http://fsfe.org/en/fellows/greve/freedom_bits/back_from_gplv3_conference_in_tokyo_japan -- 8< -- I think the issue of GPLv3 in embedded software falls into two categories: warranties, and regulated hardware. The warranties issue is quite simple. If a hardware vendor wants to say that installing modified software voids the warranty, that's ok with GPLv3. GPLv3 says that if the software is modified, it must be able to interact with the same online services. Warranties are not an online service, so the warranty can be changed or voided when modified software is installed and that won't violate GPLv3. The more complex issue is with regulated devices such as mobile phones, wireless cards, voting machines, and medical devices. If a company decides to produce mobile phones, how can they use GPLv3'd software if they are required to prevent customers from transmitting or receiving signals outside of the permitted ranges? With GPLv2, they could have built the phone to stop functioning if it detects that the software has been modified. This is what has become known as "tivoisation". This solves their regulatory problem, but it means that the GPL has not done its job of ensuring the recipient has the freedom to modify the software. It may seem that these two goals are fundamentally incompatible, but they are not. A solution is that the phone manufacturer can put the part of the software which sets the signal transmission/reception into unmodifiable memory (ROM - read-only memory), and the remaining majority of the software can go in modifiable memory. Thus, the phone will not be used to break regulations, and the recipient has the freedom to modify most of the software, with the exception of the small part which it would have been illegal to modify anyway. This is not immune to abuse. Phone manufacturers could put all of the software in unmodifiable memory. If they do this, we are no worse off, and no better off, than we are today. However, it seems more likely that they will opt to split the software between modifiable and unmodifiable, because that way.bugs can be fixed, and software updates can enable new services, etc. So the deal is, if they want to retain the ability to modify the software, they have to let you modify it too. -- 8< -- -- Regards, Dave ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
