Re: Survey about the Touchscreen
On Fri, 2008-11-21 at 13:16 -0500, Stefan Monnier wrote: So if we can't have multi-touch sensitivity, we need some other source of input. It could be buttons on the sides (e.g. I could imagine a phone where you use one hand for the touchscreen while the other hand holds the phone and can squeeze it to generate a modifier kind of event). For usability, I think it's important that this other source of input be usable at the same time as the touchscreen is used to move the cursor (so you can get similar effects as the 2-finger scroll, for exemples, or the mouse-3 context menus) so it probably would have to be activated by the other hand. I agree, a scroll wheel and an extra button on the side of the Freerunner, something like the old Sony Clie PDAs would be great, or maybe a tiny trackball/scrollball like the one on the Apple mouse would be useful. I would love the capacitive multitouch screen but not at the expense of input resolution. Simon ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: unable to read from Sandisk 8Gb SD
Andy, the version of the kernel build dated the 24th of Sept from the debian package deb http://prophet.homelinux.org/~lynx/debian unstable main linux-image-gta02 now corrupts my 8GByte Samdisk SDHC card on suspend, where i had no problems with the previous kernels with the workaround that turned the SD clock on when suspending. I assume this kernel has your latest SD mods in it. Has anyone actually checked to make sure that the SD drivers and uboot conform to the SDHC specification? Simon ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bad Magic Number while booting from SD card with new uImage!
My Sandisk 8GB breaks also. Some times the partiton and format works and sometimes the card would not be recognized. Always after reboot the whole partion table is away. I also have an 8GByte Sandisk SDHC card and was having exactly the same problems until turning the SD clock on when the Freerunner is suspended. This has been incorporated in the kernels newer than the 4th of September. Since using kernels newer than this i have not had any problems with data corruption on my SD card. Simon ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Problems with SD boot of FSO, OM 2008.8, add /dev/mmcblk0... to distros?
card driver not reading some cards. The mmcblk0p1, p2, etc. device files actually will be autocreated whenever Linux thinks there are partitions there, but the problem is that sometimes when it tries to read the partition table of the card it fails to get any data, so it doesn't think any partitions exist. Make sure you are running a kernel newer than the 4th of September which starts the SD clock up on suspend. Wih this workaround i haven't had any problems with corruption of my Sandisk 8GByte SDHC card ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Workaround for suspend/resume SD card problems
On Tue, 2008-08-26 at 18:38 +0200, AVee wrote: Depending on your usage of the SD card you could also workaround the issue with a few symlinks. When the card is wrongly mounted just add symlinks to the new location of the content of the card in /media/card/. Once you did that /media/card will either contain the contents of the card (before suspend) or valid symlinks to the content of the card (after suspend) which works just as well. I can't see how this will help if you are booted off the SD card and your whole file system is on the card. Also this bug/fault is corrupting the information on the SD card. If it is indeed a bug with the SD card driver not providing enough SD clock cycles for the card to finish executing commands it needs to be fixed with modification to the SD card driver. My workaround is only providing more clock cycles to the SD card. I would be interested to know if anyone else has tried it and if it works for them. Simon ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Workaround for suspend/resume SD card problems
With my 8G Sandisk SD card, i can reliably fix the problems i have been having by turning on the SD clock all the time. To do this type the command echo 1 /sys/module/glamo_mci/parameters/sd_idleclk then do something that will access the SD card before doing a suspend. This of course won't do the GPS much good, but i think the real fix might be to give the SD card more clock cycles before and after commands to give it time to finish executing commands. Simon ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Australian Second Group Purchase
The Australian second group purchase of Freerunners is making good progress. We still have a few unsold phones out of the batch of fifty that Openmoko have reserved for us. These will be shipped from China as soon as we send the money. Current indications are that the price will be around $440 for the phone. I hope to send an order to Openmoko early next week so you don't have much time. Can anyone who is SERIOUSLY INTERESTED in this please send an email to [EMAIL PROTECTED] with the email subject being Second Purchase state quantity So if you were living in NSW and wanted 2 phones you would reply with the subject Second Purchase NSW 2 Thanks Simon Matthews ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Second Australia wide group purchase
As overall organiser of the first batch I am happy to put my hand up to organise another batch of 50 phones if there is enough demand and i resolve a legal issue that is worrying me. I have resolved the legal issue to my satisfaction. For those that are interested in the details they are. For the first group purchase i used the following information from the booklet Telecommunications Labelling and Compliance Information for suppliers of telecommunications equipment and cabling in Australia from www.acma.gov.au In the introduction there is the statement Australian manufacturers and importers of telecommunications items, or their Australian authorised agents acting on behalf of manufacturers and importers (collectively referred to as ‘suppliers' throughout this booklet), are required to label each item with either a compliance label or non-compliance label. Items not specified by the Labelling Notice must not be labelled. But there is an exemption cellular mobile phones imported for personal use that meet the applicable technical standard(s); For someone importing a single unit for themselves or in our case where i am acting on behalf of a number of individuals one would think this exemption should apply, but as i was importing sixty phones i started wondering if i would be legally seen as a 'supplier' and that the exemption wouldn't apply. But looking at the actual Telecommunications Act we have 413 Supply of unlabelled customer equipment or unlabelled customer cabling (1) If a person: (a) is a manufacturer or importer of customer equipment or customer cabling; and (b) is required under section 407 to apply to it a label in a particular form; the person must not supply the equipment or cabling unless a label in that form has been applied to the equipment or cabling. (2) A person who contravenes subsection (1) is guilty of an offence punishable on conviction by a fine not exceeding 100 penalty units. (2A) Subsection (2) does not apply if the person has a reasonable excuse. Note: A defendant bears an evidential burden in relation to the matter in subsection (2A) (see subsection 13.3(3) of the Criminal Code). (3) In this section: supply includes supply (including re-supply) by way of sale, exchange, lease, hire or hire-purchase. I am confident that the definition of supply lets me off the hook here. Section 2A is also comforting. If anyone has any further thoughts about this i would like to know. Simon ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Second Australia wide group purchase
The first group purchase of sixty phones and eight debug boards have arrived in Perth and the batches for the eastern states are now in transit via Australian Post. The total cost of the phones worked out at $440 each. Each phone had as extra goodies an adaptor to plug into Australian power points, headphones and a carrying pouch. I cannot guarantee that the price or the accessories will be the same for the second batch but they should be. As overall organiser of the first batch I am happy to put my hand up to organise another batch of 50 phones if there is enough demand and i resolve a legal issue that is worrying me. I believe Openmoko have reserved 50 phones from a production batch in early August for us. I have to confirm with Openmoko in the next few days if we will be taking these 50 phones. Can anyone who is SERIOUSLY INTERESTED in this please send an email to [EMAIL PROTECTED] with the email subject being Second Purchase state quantity So if you were living in NSW and wanted 2 phones you would reply with the subject Second Purchase NSW 2 Simon Matthews ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found! / more patches
Thanks for that Andy, There are some numbers here: http://git.openmoko.org/?p=kernel.git;a=commitdiff;h=66a83c97c4545ce4f07e0d90998f906fae49caf2 Could you tell me what exactly you are measuring, radiated power? and under what conditions. How was the noise floor measured. Thanks Simon ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found! / more patches
Surely the hardware and software 'fixes' can only be seen as a total fix if they make the SN (signal to noise ratio) of the GPS the same as if the SD card is not present. FWIW and IMAO, this definition of a total fix is impractical almost to the point of uselessness. There will always be some noise in a tightly packed product incorporating many high frequency sources. The question is if the noise is significant (as it seems to have originally been). Sorry i don't think i have made myself clear. What i meant is that each of the modifications has been claimed to be a fix, when i would think they are only an improvement. What i am trying to get at is to find which of the modifications gives the best improvement. I know it is difficult to quantify this but it would be nice to know that say the clock current drive decrease by itself improved the SN ratio by say 6dB, the capacitor mod by itself improved the SN by say 3dB, and combined the change was 6dB. If this was the case just the software mod would be necessary. If on the other hand the combined change was 9dB then both would be worthwhile. Again, kudos to the team for a job well done on all fronts, sw and hw, with regard to this issue. I agree with this. I find it very impressive that they can get three radio transmitters, four radio receivers, high speed electronics and audio working in such a small package without more problems, and probably done on a shoestring budget as well. Simon ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Experiances purchasing and using a neo fr in australia?
Im currently looking very hard at purchasing the neo freerunner from the official store on july 25, i live in melbourne australia and was wondering if anyone has purchased either the freerunner or 1973 and used it in australia. There is an Australian wide group of sixty waiting for their Freerunners to arrive. They are currently in customs. There are some 1973s and a few pre production Freerunners in Australia There is information on importing the phones into Australia in the wiki at http://wiki.openmoko.org/wiki/Group_Sales_Australia. There maybe a second group purchase happening. Put your name down in the wiki if you are interested in this. Simon ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found! / more patches
So the fact you were OK at drive level 0 should mean are able to use SD card how you like without problems from SD_CLK to GPS any more. Surely the hardware and software 'fixes' can only be seen as a total fix if they make the SN (signal to noise ratio) of the GPS the same as if the SD card is not present. I would have thought that each of these modifications would improve the SN ratio but would not make it the same as not having the SD card present. I know it is hard but it would be nice to get some figures on how each of these modifications by themselves and together effect the SN ratio. It might turn out that the software clock drive solution by itself is as good as or better than adding the capacitor, and adding the capacitor does not improve the SN ratio any further once the clock drive mod is done, which would make it unnecessary. Simon ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Isolating GPS noise source was Re: Reason for GPS problems found!
Is the noise from the SD card itself, most likely or from pcb signal/power lines going to/from the SD card? I should have my Freerunner by now so i could do some tests, but it is still stuck in China! Here are some ideas. If you mask off all the data and clock with sticky tape, but leave the power pads on the SD card unmasked and see if this makes any difference. The SD card pinouts are -- / 1 2 3 4 5 6 7 8 | |9 | | | | | | | | | -- 1 CD/DAT3 2 CMD 3 VSS 4 VDD 5 CLK 6 VSS 7 DAT0 8 DAT1 9 DAT2 So mask off 1,2,5,7,8,9 Maybe soldering a 0.1uF decoupling cap between VDD and VSS as close to the SD connector as possible may help. Trying to shield the GPS connector might help or more radical surgery like cutting the connector off and patching it directly into the antenna mux and chopping the tracks to the internal antenna plug. I don't think this wouldn't be good for the warranty though. I must say i don't like the position of the internal antenna plug. Simon On Tue, 2008-07-15 at 16:37 +0200, Yorick Moko wrote: they know about it now (joerg even replied in this thread, he's a member) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found!
I would like to know if the SD card noise is desensitising the external antenna as well. This would point to noise getting into the antenna mux and front end of the GPS circuit. Simon On Tue, 2008-07-15 at 23:29 +0200, Joerg Reisenweber wrote: So we can assume this is pretty confirmed by quite some reports now. Thanks to community for the awesome help on this! Special thanks to *sbeh* for finding this. Please mail me directly ;-)!! We did quite some tests on this as fast as we could (and I never assumed we could be *that* fast), and it seems we found the root cause of the problem. ALL THIS IS PRELIMINARY INFO! Due to further tests to confirm. Just to let you all know we're on it, and please stop thinking about shielding the SDcard with tin foil or relocating internal gps-antenna. It won't probably help. The good news: *IF* all pans out, there's (or soon will be) a new kernel at Andy branch that stops SD-card clock when SDcard is idle. We hope this will almost cure the problem, at least reduce it to sth like you can't GPS while watching video from SD or the like (hope you can cope with that ;). We're about to verify a hw-fix so you could even watch video and still have GPS positioning during that. Please stay tuned and be patient, we'll come up with news *really soon*. And *please* don't try weird reworks and maybe break your FR by doing so ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) cheers jOERG ___ 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
Shipping details
Hi Steve, Firstly i would like to thank you and everyone at Openmoko for being so open about the production process. As one who has been involved with the design, manufacture and sales of electronic products for many years i know how complex and frustrating it is to get product out the door, with Murphy's law waiting at every turn! It is a real breath of fresh air, especially in an industry which is getting more and more closed and hard to deal with unless you are talking in 100K+ quantities. Now back to some of those frustrating details. So we can finalise our group buy details could you please enlighten us on the following. What courier companies/the postal service and shipping options (express versus normal etc) will you be using to ship the phones (only UPS or others as well?) Will you be offering the option of having the shipments insured? Do you know how much the insurance will cost. I can't find much information on the UPS web site on insurance. What payment options will you have. Thanks Simon Matthews ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yummy new CPU/GPU combo
The big companies making these hi-tech electronic parts are probably only interested in orders it the hundred of thousands if not millions of parts. There is less risk to them of intellectual property being stolen or parts copied having a few customers buying large quantities at low margins than lots of smaller companies buying small numbers at higher margins and it is also less hassle. It is probably not worth the big companies to get their lawyers to draw up the contracts for small quantities (we all know how much lawyers cost!) Then there are the cosy exclusive deals that only the big companies have the power to negotiate. I would think it has been a big advantage for Openmoko having FIC behind it when trying to source all the specialised components. Even then they are still a small fish in a very large and expensive pond. On Sat, 2008-06-07 at 19:15 -0700, Dave O'Connor wrote: Thanks for the response and don't take this the wrong way but it doesn't really answer my question. :) Openmoko could take these sweet spec components and do stuff with them. That would lead to increased sales for these component manufacturers. It's in their interest to make them, and hopefully therefore the specs, available to you. 1) Why don't they make the components available to anyone other than the manufacturers for phones meant for the japanese market, even those who wouldn't care about open specs? Regards Dave ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Importing Freerunners to Australia
Hi, I think there are a few mistakes in the calculations i have seen for importing the Freerunners into Australia. Here is my take on all this. From Steve at Openmoko's email on shipping costs Subject:RE: Shipping questions, customer organized distribution in Europe Date: Sun, 27 Apr 2008 10:56:22 -0700 (Mon, 01:56 WST) the expected shipping costs for 10 phones to Europe would be US$160 or US$16 each. Cost for individual phones will be US$70 each. I think the charges to Australia would be similar. Maybe Steve can confirm this for us, also will Openmoko give the option of sending the phones insured and what would be the extra charge for insurance be. There is no customs duty payable CUSTOMS TARIFF SCHEDULE 3 Section 16 R.10 Chapter 85/19 Reference Statistical NumberCode/Unit Goods Rate # 8517.12.00 10 No - - Telephones for cellular networks or for other Free wireless networks There is a customs entry fee and UPS will charge a fee to lodge all the documentation. This is around AUS$140, i can't remember the exact figure, i will phone UPS on Monday. If the units were sent by post you could do all the paperwork yourself and save around AUS$100, but I think Steve has already said Openmoko is only sending via UPS. So at an exchange rate of US$1.00=AUS$1.07 Cost of phone (10 pack) AUS$394.83 Shipping costs AUS$ 17.12 Entry feeUAS$ 14.00 GST AUS$ 42.60 -- TotalAUS$468.55 Cost of individual phone AUS$426.93 Shipping costs AUS$ 74.90 -- TotalAUS$501.83 Regards Simon ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: proprietary firmware
Due to regulatory requirements over wireless frequencies, power and modulation i can't see it being possible for the low level software that controls the RF transmitters being Open Source. Moving the software that modulates the transmitted RF and demodulates the received RF onto the user space CPU just increases the burden on that CPU, which might be acceptable for users who want to tinker with this data, but for the majority of users just results in poorer performance of the phone/computer as a whole. Would it be possible to try to get the manufacturers of the chipsets to install a standardised loader in flash or ROM on their devices that would make it easy to download and flash a new binary image with data encryption if need be. Would be great if this download was via a standard hardware link like JTAG or some other simple synchronous/asynchronous interface. This would make it easy to fix bugs in the firmware, and would make it easier to have different versions of the firmware that could allow more or less processing be done on the user space CPU depending on the users needs. Regards Simon ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hooks in Base Code
Hi, Here is my two cents worth. I also hope what i am saying here is not too basic and is comprehensible. I program in Forth so my knowledge of C vocabulary is not fabulous. On Sat, 2007-07-21 at 12:28 -0400, Clayton Jones wrote: I like the ideas presented here, but i have some experience designing building real time embedded systems so some points to think about: I too have a long history designing, building and writing code for real time embedded systems and all my current designs implement a similar strategy of having Event Generators (usually interupts), an Event Dispatcher and Event Handlers. IMHO the Event Router should be as simple and fast as possible. Any complex sorting/ checking of event lists etc etc should be left to code sitting on the sidelines 1) The Event Router should also have some sort of priority mechanism ... How about a linked list of Event Objects which would contain the Link to next Event, Event Priority, Event Parameters and Link to a specific Event Handler. The Event Router would pass execution to the specific Event Handler for the Event Object at the top of the list. When the specific Event Handler had finished it would pass control back to the Event Router which would delete the finished Event Object and move on to the next in the list. The Event Handler could simply be a list of calls to various code. This list could be easily edited to change the functionality of the device. Would have to have a mechanism for handling errors. Rather than having fixed Event Parameters i would go for a Parameter Heap which would be part of the Event Object. It doesn't need any fixed format as both the code that generated the event and the Event Handler know what the parameters are. To generate a new event one creates a new Event Object with say one of three functions CreateEventAtTopOfList - Would be used if immediate execution is needed CreateEventAtBottomOfList - Execute when you have time CreateEventInMiddleOfList - Insert in execution list, location dependent on Event Priority 2) We have to be careful about race conditions in event notification latency and order. This sequential execution of the Event Objects should reduce the chance of race conditions but will mean that the Event Handlers will need to execute expeditiously so as not to hold up the Event handling system. Other code could sit on the sidelines keeping track of the event list to make sure nothing is going wrong. 3) Finally, we have to keep in mind that this is a small-form factor, battery-powered system - we'll always be behind on the power/resource curve from our desktops, so we have to be aware of speed and resources. I couldn't agree more. I have seen a number of engineering projects fail due to overcomplexity and inattention to low level design resulting in unacceptably slow response and too much power consumption. If anyone thinks this is a good idea i will flesh it out more in the wiki. Regards Simon Matthews ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Information on importing mobile phones into Australia
I noticed that Australia is not mentioned on the list of countries you can ship to direct. Is this correct? I have done done a quick search on bringing mobile phones that are not covered by the A-Tick telecommunications regulations into Australia. The system of regulation in Australia is that a supplier or manufacturer applies for registration to use an A-Tick label. Once this is granted you can place this sticker on any equipment you market but you are responsible to have the equipment tested to the appropriate standards and keep documentation of compliance. You may be audited and if the documentation is not up to scratch legal action may be taken against you. As far as i can see the customs service does not list non compliant mobile phones as prohibited or restricted goods and the following statement from the regulatory authority http://www.acma.gov.au may apply. A mobile phone (for personal use) may be brought into Australia and connected to a mobile telecommunications network provided the phone meets Australian standards. If you are travelling and plan to purchase a GSM mobile phone overseas, ACMA recommends that prior to departing from Australia you contact your mobile carrier to find out what mobile phones are suitable for use in Australia. Some features on certain models of mobile phones purchased overseas may not work on the Australian mobile networks. There are no labelling requirements for a mobile phone imported for personal use by this method. This link gives more information http://www.acma.gov.au/WEB/STANDARD//pc=PC_1687. It is illegal to connect any equipment that does not comply with the relevant standards up to the telecommunications network. Interestingly enough i think you can still market the device if it is labelled as non compliant and has the following label on it WARNING: IT IS ILLEGAL TO CONNECT THIS ITEM TO ANY TELECOMMUNICATIONS NETWORK OR FACILITY, UNLESS YOU HAVE PERMISSION For more information see http://www.acma.gov.au/WEB/STANDARD//pc=PC_1687 Hope this is of use Simon ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Making Neo Brickproof, was comments after reading Wiki
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, can be protected and will either jump to the main bootstrap loader if it is functional or be able to download a new 2nd stage bootstrap loader and program it into flash via the USB port. Here is a flow chart for the proposed loader RESET 1. Turn protection on for this first level bootstrap code (if necessary) 2. Check if user wants to download new 2nd stage bootstrap (could use AUX button), if so goto 5 3. Check if 2nd stage bootstrap exists (is 2nd stage bootstrap flash blank?), if so goto 5 4. Check 2nd stage bootstrap code in Flash via checksum, if OK load into RAM and jump to else goto 5 5. Download new second stage bootstrap image from the USB port and store into FLASH. I would use some simple HEX format like Intel or Motorola HEX format. I have used a similar scheme for some time now and it has been bullet proof for me. Simon Matthews On Wed, 2007-05-16 at 19:55 -0300, Werner Almesberger wrote: Marcin Wiacek wrote: Of I see that we think about different things Yup :-) 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. - Werner ___ 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
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
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: 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: 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
Making Neo Brickproof, was comments after reading Wiki
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, can be protected and will either jump to the main bootstrap loader if it is functional or be able to download a new 2nd stage bootstrap loader and program it into flash via the USB port. Here is a flow chart for the proposed loader RESET 1. Turn protection on for this first level bootstrap code (if necessary) 2. Check if user wants to download new 2nd stage bootstrap (could use AUX button), if so goto 5 3. Check if 2nd stage bootstrap exists (is 2nd stage bootstrap flash blank?), if so goto 5 4. Check 2nd stage bootstrap code in Flash via checksum, if OK load into RAM and jump to else goto 5 5. Download new second stage bootstrap image from the USB port and store into FLASH. I would use some simple HEX format like Intel or Motorola HEX format. I have used a similar scheme for some time now and it has been bullet proof for me. Simon Matthews On Wed, 2007-05-16 at 19:55 -0300, Werner Almesberger wrote: Marcin Wiacek wrote: Of I see that we think about different things Yup :-) 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. - Werner ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
