Hi, Sorry for jumping late into this thread, but having that I didn't notice it earlier, and that I had no idea of these design challenges, I find the puzzle interesting and I hope I can provide some insight from on outsider point of view.
The way I see it, the two main problems, 'unbricking' the system and low level debugging it, share the common requirement of having to be handled externally, i.e. by running code outside the usual framework which is either broken, gone, corrupted, or simply under scrutiny. While this external code may still run on the main processor and use its internal memory banks, I think this is not only complicated, but also dangerous - if a piece of rogue code acquires root privileges, it might very well possess unseen means to erase the entire flash for either disabling or hijacking the phone. The recovery measures, at least, should be protected in hardware. Ideally, the processor on the other end of the JTAG, I2C or serial loader interfaces should be a PC, but computers these days cannot be assumed to have any communication port except USB, and that requires a second micro-controller to mediate between the two (some USB<->UART adapters will let you run them unconifugred, but then the host computer will not recognize the device, will be only seeing a serial interface on the other side, and will badly limit your options, unless you do have a second core to flexibly handle the serial stream). Putting the second core on an intermediate board seems to me inelegant for a consumer device. A second core might have been unreasonable when the PC was invented, but this is exactly why it is so 'brickable' - find a way to thrash your BIOS and unless you have pretty decent technical skills you can bin your computer. I'm sure we can do better than that. I suggest a solution that will have the smallest impact on the rest of the system - an 8-bit uC such as Microchip's PIC18LF4550, which will stay dormant and waiting when unneeded (at 2V/100nanoWatt, it might even be worth keeping alive when the phone is off) but when triggered (hidden button, watchdog, etc.), it will hijack the USB port (or the headset one) and take control over the main processor. The hardware cost is not trivial - in addition to the chip size of 8x8mm, it will require a few decoupling capacitors, two switches to divert the USB data lines and possibly an external oscillator for USB (which might already exist on the board, but perhaps cannot be relied on in all circumstances) - but I think it's still relatively small. At ~$3, their impact on the BOM cost will be small as well. In return, you get native full speed USB2.0 (i.e. 12Mbps) with 32 endpoints (perhaps the main processor's port can be tunneled through? It'll be a pity not to be able to debug it), hardware I2C, SPI, USART, SPP ְports (not all simultaneously, but you can bit bang the rest), 35 GPIOs, and even 13 A2D converters in case you want to beep the user that the battery is dying without waking up the main CPU. At full throttle, the chip can do 12MIPS (4.2-5.5V, 20~50mA) which isn't a cell processor, but should be enough for the intended tasks. The bootloader can be loaded over USB, which is useful both for catastrophic data loss cases and for developing/debugging it, and can be stored in an eeprom connected to the PIC, where it will be well protected, easily updated, and can be written before populating the PCB so the phone is bootable right out of assembly. The reason why the PIC will be far more secure than the main processor is that although it is capable of reprogramming itself (almost) completely via USB, its USB port is only connected to the external socket on the phone, and can be only accessed using deliberate, _physical_, action by the user. I can see why a second development environment can be a hassle, but as a second processor seems unavoidable, this is one of the simplest, best documented ones, with many Free tool chains, available code and supporting community. Or perhaps, since until my shiny new FR only arrives next weekend these crickets are still my hammer of choice, every problem seems to me to be their nail. :-) Happy hacking, Yair. PS. I had a look at the MSP430 family, and although they are quite similar in principle, you do need one of the larger ones in order to get a comparable feature-set to that of the PIC. If their size and requirements are what fuels the objection to a second MCU, perhaps the small but very flexible PIC can provide a suitable compromise. _______________________________________________ hardware mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/hardware
