Marcin Wiacek wrote: > In worst case device should start with default parameters and without > additional apps.
Our idea is that you can at least load a new boot loader, kernel, etc. over DFU. That's the minimum "sane" unbricking requirement. Anything else would require more space. (We may actually have enough space for also putting the kernel and a bit of user space there. But that wouldn't be a "regular" environment, but more something like kboot or linuxbios.) Note that there's also the option to do an "emergency boot" from the boot menu. This is for more benign screw-ups, e.g., incorrect touch screen calibration making the GUI unusable. For the "end user", this level of protection, combined with a bit of DFU hardening will be enough. > IMHO, the best is separating memory to two phisical chips and have > main software in first (with protection) and additional software/"HDD" > inside second (or protection should block writing to chip below specified > address). Per-block protection is tricky. There are only very few companies out there who have chips with this, and even fewer whose chips we could actually use. I don't know of any Flash chip with useful zone protection (you get a lot that protect about 16 kB, but that's not enough). Just protecting the whole chip won't do, since we expect our users (hackers) to install their own boot loaders, kernels, and such. With the MCU we'll use in the future, you also get (useful) zone protection. We think it can be circumvented (by malware but also by well-meant tools), so it's not the "100% carefree" solution we're looking for either. However, it will allow for more flexible use of the "recovery" Flash chip for those who choose to remove the bulletproof protection. (E.g., if they have a debug board.) - 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