Re: Making Neo Brickproof, was comments after reading Wiki
I would have thought it would be nice to avoid an extra chip. I noticed after a quick scan through the documentation on the flash currently being used by the Neo that there is one 16K block of OTP memory. Of course this would only be any good if it could be mapped to the addresses that get downloaded by the CPU before it starts. I see a couple of problems with having one large complex bootloader. If it is large and complex there is more chance it will need to be changed due to changes in functionality or bugs. Each time it is changed you have a chance of bricking the device, either by the code not programming correctly or the code being wrong. If you always have a small stage 1 bootloader in place you can circumvent these problems. Regarding the simple interface, i agree that having an asynchronous serial interface (RS232) that goes to the outside world would be nice, but wonder how hard it would be to write a very basic USB driver with just enough functionality to do the job of downloading some fixed format data from a host. On the host side a simple program that can download data to a USB slave device would all that would be needed. From a user perspective it should be kept as simple as possible so if the main bootloader gets screwed up for whatever reason it would be nice to just plug it into your computer and execute a simple program to restore it. Simon On Thu, 2007-05-17 at 01:58 -0300, Werner Almesberger wrote: We rejected it, because we don't want to have yet more code duplicating functionality found elsewhere to maintain. Besides, it wouldn't be all that trivial, given that we don't have any simple interfaces. (Anything that needs a debug board or other fancy adapters doesn't count.) Also, there really isn't much difference between a few protected bytes or hundreds of protected kilobytes. We need an extra chip anyway, and if we want something reasonably small and modern, it'll have plenty of space. Thus there's no penalty in using it. But yes, the small loader approach works well enough in other contexts. I've used it myself. - Werner ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Making Neo Brickproof, was comments after reading Wiki
Hi folks, I would strongly support putting a no-way-writable ROM chip as this first level boot loader. If there is no such option, I really wonder what is my option if somehow it gets screwed up, other than the trash can? Is there an always working solution to reset my moko? Emre Turkay On 5/17/07, Werner Almesberger [EMAIL PROTECTED] wrote: Simon Matthews wrote: It seems to me as someone who designs and makes embedded devices (mainly using the Freescale MC9S12 processors) that you need another lower level bootstrap loader that is small, Ah yes, we've been through that idea as well :-) We rejected it, because we don't want to have yet more code duplicating functionality found elsewhere to maintain. Besides, it wouldn't be all that trivial, given that we don't have any simple interfaces. (Anything that needs a debug board or other fancy adapters doesn't count.) Also, there really isn't much difference between a few protected bytes or hundreds of protected kilobytes. We need an extra chip anyway, and if we want something reasonably small and modern, it'll have plenty of space. Thus there's no penalty in using it. But yes, the small loader approach works well enough in other contexts. I've used it myself. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Making Neo Brickproof, was comments after reading Wiki
Just had a further thought about what to do if the main bootstrap loader gets trashed that maybe easier to implement. Rather than a stage 1 bootstrap loader looking to the USB interface for a replacement how about looking on the SD card? Simon On Thu, 2007-05-17 at 01:58 -0300, Werner Almesberger wrote: Simon Matthews wrote: It seems to me as someone who designs and makes embedded devices (mainly using the Freescale MC9S12 processors) that you need another lower level bootstrap loader that is small, Ah yes, we've been through that idea as well :-) We rejected it, because we don't want to have yet more code duplicating functionality found elsewhere to maintain. Besides, it wouldn't be all that trivial, given that we don't have any simple interfaces. (Anything that needs a debug board or other fancy adapters doesn't count.) Also, there really isn't much difference between a few protected bytes or hundreds of protected kilobytes. We need an extra chip anyway, and if we want something reasonably small and modern, it'll have plenty of space. Thus there's no penalty in using it. But yes, the small loader approach works well enough in other contexts. I've used it myself. - Werner ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Few comments after reading Wiki
1. I hope, that there will be made SAR tests and results will be very low Why? It may help with marketing, but the worst it could do (unless it's several orders of magnitude beyond what current phones) is make you a bit warm. Non-ionizing radiation is not a cause of cancer. Better to worry about things that there is actually evidence to back up - like radon, or using the phone while driving :-) Not exactly only marketing. When I used phone with SAR 1,2, I feel much worse sometimes. When I have phone with 0,5, I can speak hours. This is maybe suggestion only, but maybe not... And I don't care about cancer and similiar things. Please note, that nobody has given profs for and against cell phones. IMHO, people will think more and more about it. If you want to have more sells, you have to think about it. Pozdrowienia/Best Regards -- Marcin Wiacek (www.gammu.org, www.mwiacek.com, I'm looking for a job) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
5. hav developers though about creating it on kind of x86 compatible platform ? I know, it could be more difficult to create energy efficient device, but having PC in pocket (with ability to running dos, windows after changing SD card) would be more than excellent yes, i have. i don't know about any others though i'm waiting for via to release the pico-itx board they've been promising and will see what i can do with that to create a UMPC/phone/pda type combo. this board/cpu promises ultra-low power and hw accelerated video playback, looks very interesting and would be awesomely flexible/powerful as you say, the main issue is power - x86 isn't really optimized for anything as it's such a generalised architecture. my calcs at the moment on power are struggling to get more than a few hours use with a reasonable size battery As I'm not hardware guy, I don't know if it has sence, but (of course, it will be more diffiult than current): Chipset will have support for CPU, RAM, flash, one USB hub. No SATA, PATA and similiar. Additionaly cpu 9something about 200 - 400 Mhz), ram, flash and devices connected over usb... Maybe this will be more exergy efective Pozdrowienia/Best Regards -- Marcin Wiacek (www.gammu.org, www.mwiacek.com, I'm looking for a job) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Few comments after reading Wiki
I was thinking about protecting memory with main phone software (like kernel, boot loader, main apps). You'll (almost certainly) be able to do this as well: the new MCU will allow you to specify which NAND Flash area can be written to. Once this is set, it cannot be changed without a reset. So this would be a hardware assisted solution. Unfortunately, you can probably bypass it if you're determined. So, the scenario can be: spefifying area by virus and getting device to reset to have full control... Pozdrowienia/Best Regards -- Marcin Wiacek (www.gammu.org, www.mwiacek.com, I'm looking for a job) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Making Neo Brickproof, was comments after reading Wiki
JTAG, via the debug port. From: [EMAIL PROTECTED] on behalf of Emre TurkaySent: Thu 5/17/2007 5:25 AMTo: community@lists.openmoko.orgSubject: Re: Making Neo Brickproof, was comments after reading Wiki Hi folks,I would strongly support putting a no-way-writable ROM chip as this first level boot loader. If there is no such option, I really wonder what is my option if somehow it gets screwed up, other than the trash can? Is there an always working solution to reset my moko?Emre Turkay On 5/17/07, Werner Almesberger [EMAIL PROTECTED] wrote: Simon Matthews wrote: It seems to me as someone who designs and makes embedded devices (mainly using the Freescale MC9S12 processors) that you need another lower level bootstrap loader that is small, Ah yes, we've been through that idea as well :-)We rejected it, because we don't want to have yet more codeduplicating functionality found elsewhere to maintain. Besides, itwouldn't be all that trivial, given that we don't have any "simple" interfaces. (Anything that needs a debug board or other fancyadapters doesn't count.)Also, there really isn't much difference between a few protectedbytes or hundreds of protected kilobytes. We need an extra chip anyway, and if we want something reasonably small and modern, it'llhave plenty of space. Thus there's no penalty in using it.But yes, the "small loader" approach works well enough in other contexts. I've used it myself.- Werner--_/ Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] //_http://www.almesberger.net//___OpenMoko community mailing listcommunity@lists.openmoko.orghttp://lists.openmoko.org/mailman/listinfo/community NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately. Thank you. AuthenTec, Inc. http://www.authentec.com ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
Marcin Wiacek wrote: So, the scenario can be: spefifying area by virus and getting device to reset to have full control... At which time your (still protected) firmware sets the protection again, and executes the regular code. But yes, if you add an easily changeable vector before that point, you lose :-) The bypass I'm thinking of is a little harder, either by messing up the NAND state machine in the MCU (so it doesn't notice we're about to write), or, if they've been really careful, by toggling the bits through GPIO and carefully timed memory accesses. Something your virus author may still do, of course. And that's when the second chip kicks in. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Making Neo Brickproof, was comments after reading Wiki
Simon Matthews wrote: I would have thought it would be nice to avoid an extra chip. Yeah, we tried, but it just doesn't seem to be possible :-( There are some alternatives, but they then lead to other problems, such as chips not being available in quantity, etc. (And we've had our number of surprises with that. Once bitten, ...) Of course this [OTP} would only be any good if it could be mapped to the addresses that get downloaded by the CPU before it starts. That's in NAND Flash, which isn't really mapped. Instead, you transfer data in pages. So it's more like a disk than RAM. The MCU has a build-in boot loader that does this, but it doesn't know about OTP. Besides, that OTP can still be changed. I see a couple of problems with having one large complex bootloader. If it is large and complex there is more chance it will need to be changed due to changes in functionality or bugs. No, I don't think this will be needed. The basic recovery functions will be exercised well enough. To the contrary, since this is code we already use daily, it's more likely to be correct than a special-purpose loader that only gets used rarely. Even better: a more general recovery loader will give you more than one way to do things (e.g., SD card and USB), so even if one method fails, you still have a backup. but wonder how hard it would be to write a very basic USB driver with just enough functionality to do the job of downloading some fixed format data from a host. You'd have to ask Harald for comments on USB (among other things, he implemented DFU in u-boot), but my impression is that it's hard and messy enough that nobody wants to maintain yet another stack. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Iphone eat your heart out.
This 8GB, of course, depends on support by our hardware... -- start using Free software http://www.linux.org http://www.fsf.org It's a matter of Liberty not Price: Free Software exists to free you from the artificial constraints set by Apple and Microsoft. Free software is Unrestricted software. Get Free. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Iphone eat your heart out.
Will the iPhone support the bluetooth harddrives? I'm guessing they'll work nicely with a linux phone with bluetooth. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of mathew davis Sent: Thursday, May 17, 2007 12:16 PM To: community@lists.openmoko.org Subject: Iphone eat your heart out. Now the neo can hold as much memory as the upcoming Iphone but better. Samsung just announced that it has developed an 8 Gigabyte microSD memory card. That means that the $350 neo equiped with a 8GB microSD card will have the same storage capacity as the 600 + 2 year contract Iphone. Just would like to say keep up the good work to every one on the team. I know you have been working your buts off and I for one sincerly appreciate it. With all the talk of not being able to wait for the I phone, I would like to say that I am patiently waiting through the thick and thin for the phone. I am excited about the progress made and am also glad to hear any update weither it be good or bad, I am loyal to the end. http://www.samsung.com/PressCenter/PressRelease/PressRelease.asp?seq=200 70517_346824 Thanks, Matt ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Status of phoneME?
I'm embarking on a project where I need to work at the c/c++ level under J2ME and tie into the native phone stack as well. I'm trying to determine whether I should initially target OpenMoko or Qtopia's Greenphone initially. One of the decision points in this for me is the question of whether phoneME Feature has been ported to the platform. I was pointed here by information I got at the JavaOne conference and I've seen hints that such a port is in progress for OpenMoko and/or Greenphone, but it has been very hard to determine if such beasts actually exist. Can someone fill me in on the status of phoneME on either of these devices? - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Iphone eat your heart out.
mathew davis wrote: Now the neo can hold as much memory as the upcoming Iphone but better. Samsung just announced that it has developed an 8 Gigabyte microSD memory card. That means that the $350 neo equiped with a 8GB microSD card will have the same storage capacity as the 600 + 2 year contract Iphone. Just would like to say keep up the good work to every one on the team. I know you have been working your buts off and I for one sincerly appreciate it. With all the talk of not being able to wait for the I phone, I would like to say that I am patiently waiting through the thick and thin for the phone. I am excited about the progress made and am also glad to hear any update weither it be good or bad, I am loyal to the end. http://www.samsung.com/PressCenter/PressRelease/PressRelease.asp?seq=20070517_346824 No indication, though, of when it will ship or how much it will cost is there? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Fwd: Iphone eat your heart out.
No nothing on it yet. On 5/17/07, Duncan Hudson [EMAIL PROTECTED] wrote: mathew davis wrote: Now the neo can hold as much memory as the upcoming Iphone but better. Samsung just announced that it has developed an 8 Gigabyte microSD memory card. That means that the $350 neo equiped with a 8GB microSD card will have the same storage capacity as the 600 + 2 year contract Iphone. Just would like to say keep up the good work to every one on the team. I know you have been working your buts off and I for one sincerly appreciate it. With all the talk of not being able to wait for the I phone, I would like to say that I am patiently waiting through the thick and thin for the phone. I am excited about the progress made and am also glad to hear any update weither it be good or bad, I am loyal to the end. http://www.samsung.com/PressCenter/PressRelease/PressRelease.asp?seq=20070517_346824 No indication, though, of when it will ship or how much it will cost is there? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
OpenMoko at Maker Faire, San Mateo, California THIS WEEKEND
Maker Faire (www.makerfaire.com) is an event put on by MAKE magazine, the O'Reilly publication that has become the darling of the entire DIY community. The fair is at the San Mateo fairgrounds, about 30 minutes south of San Francisco. OpenMoko has a booth, and it will be staffed entirely by volunteers. Currently there are two of us (myself and Jon of Creative Commons), and we would love help. What's in it for you: 1. Free entrance to the Maker Faire (a $15 value!) 2. Play with the Neo 1973 and the experimenters lunchbox 3. Play with the source code, write you own application, download it into a Neo, and see if it works 3. Free OpenMoko t-shirt to the first 4 of you (probably the rest of you will get shirts as well, just not now because we only have 4 left) What's in it for us: 1. Jon and I get to take a break and work at our own booths What you have to do: 1. Agree to put in some amount of time at the OpenMoko booth 2. Show up at the fair and tell them you are volunteering at the OpenMoko booth 3. Answer questions about the OpenMoko project The OpenMoko booth will be next to the Creative Commons booth. Sorry for the short notice, but we weren't sure we were going to be able to pull this off. Email me if you have any questions, or call me at (415) 425 5320. Michael ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Iphone eat your heart out.
This new 8GB microSD is SDHC Class4 Compliant. According to the wiki the Neo supports SDHC. Maybe a owner of a p0 device could check this with a smaller (but available :) ) SDHC microsSD. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Making Neo Brickproof, was comments after reading Wiki
On Thu, 2007-05-17 at 09:19 -0300, Werner Almesberger wrote: Yeah, we tried, but it just doesn't seem to be possible :-( There are some alternatives, but they then lead to other problems, such as chips not being available in quantity, etc. (And we've had our number of surprises with that. Once bitten, ...) If you do find a chip with a small protected page i might be interested in writing the loader i have outlined. will be exercised well enough. To the contrary, since this is code we already use daily, it's more likely to be correct than a special-purpose loader that only gets used rarely. As long as the bootstrap code reprogramming is bullet proof or you don't see the need for changing the boot code i can't see any problems with one large bootstrap. You'd have to ask Harald for comments on USB (among other things, he implemented DFU in u-boot), but my impression is that it's hard and messy enough that nobody wants to maintain yet another stack. I looked at using USB a few years ago and decided it was too convoluted and complex. IMHO a powered Ethernet variant would have been a much better arrangement that the USB mess. Regards Simon ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Making Neo Brickproof, was comments after reading Wiki
Simon Matthews wrote: If you do find a chip with a small protected page i might be interested in writing the loader i have outlined. Thanks ! As long as the bootstrap code reprogramming is bullet proof or you don't see the need for changing the boot code i can't see any problems with one large bootstrap. Yes, that emergency bootstrap should be both bulletproof and immutable (with very few exceptions), but you have basically the same code also in the part of the system that is meant to be easily upgradeable, so even development that's very close to the hardware doesn't need to touch the recovery stuff. Perhaps a good analogy would be the recovery CD one may have for a PC. (Only that PC hardware can change a lot more than what's in a given phone. About the worst that could happen is that it may not recognize your brand-new 1TB uSD card, so you'd have to find one of the old and boring 4GB ones, or use USB :-) I looked at using USB a few years ago and decided it was too convoluted and complex. IMHO a powered Ethernet variant would have been a much better arrangement that the USB mess. Yeah, USB is a fine triumph of NIH. And of course, they had to add isochronous transmissions. That's to low-level communications about what the video phone is to telephony :-( - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
On Wed, 2007-05-16 at 19:55 -0300, Werner Almesberger wrote: You'll (almost certainly) be able to do this as well: the new MCU will allow you to specify which NAND Flash area can be written to. Once this is set, it cannot be changed without a reset. So this would be a hardware assisted solution. Unfortunately, you can probably bypass it if you're determined. Could you tell me the make and model of the new MPU, and maybe some links to datasheets. I did look in the WIKI and in previous messages but couldn't find these details. I am intrigued to see how they implement the protection. Thanks Simon ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
