> Milosch Meriac described a great system he designed which re-uses the > bluetooth module for debricking and a debug console without physical > connection (!) but the JTAG need and USB-only bluetooth on our case > probably mean we should stick with FTDI.
That sounds intriguing! I can imagine... you need a programmable BT chip, then you set up an extra RFCOMM channel, and write some code for the BT chip to do the reflashing, right? But there is still the chance to "brick" the BT chip if you are hacking on that code. Then you need a physical connection to reflash it. (But since only a few people would probably do that, pads on the board would be enough to make it possible. And maybe you can program it from the main CPU, too.) Why does it have to be USB Bluetooth? In general are you trying to stick with BT modules, as opposed to putting the chip right on the board? (and then having to do BT certification) The microSD rootfs sounds interesting. It makes possible some physical problems with the slot to make the device unbootable though. And I agree that the phone needs to have two SD slots then. The one that is to be used for media files should be accessible without removing the battery (preferably a spring-loaded slot, just like a full-sized SD slot. The A780 has the best micro-SD slot I've seen anywhere so far.) How about Intel PCM though (since we are looking many months into the future, right?) http://www.intel.com/pressroom/archive/releases/20080206corp.htm It might make XIP (execute-in-place) practical if it's fast enough. I think that would be exciting, and would boot very fast: no need to copy code into RAM, just start running. But it would need to be on the memory bus. > > of SD is that you cannot use things like JFFS2 on it, i.e. you have to > > rely on the wear levelling of the SD card. Filesystems applicable for SD > > cards are not tuned very well for flash chips, like ext2/ext3 - ext I would like to see a filesystem that never needs to be fsck'd, and has extended attributes built-in, and has the ability to pack multiple small files into a block, which is optimized for flash. Basically ReiserFS with a different layout strategy (and it would probably be simpler without all the disk-specific optimizations). It should be so reliable and have such compelling performance that FAT finally dies, even on thumb drives and such. :-) Then again, when the combination of RAM + "storage" is replaced with a universal persistent type of memory (like PCM) there are going to be some big implications for software design. You don't need to load things from "files" too much when, after the data is loaded, it just stays there. And a small device like a phone is a good place to start figuring it out, because you don't expect as much from it as from a PC. So if there was a device with both RAM and PCM, it would be a good development platform to start making this transition: old-school software would run from RAM, part of the PCM is used as a ramdisk (but since it's persistent RAM, it is really a normal filesystem), and part of the PCM is used for newer software that has become simpler because it doesn't actually need a filesystem. (But because bugs are inevitable, you might need to reload individual programs from the FS once in a while and have them re-initialize themselves.) It sounds pie-in-the-sky from today's perspective, but the PCM is nearing availability, and I think there are some big advantages to this approach; but there is also a big hump to climb over. It would be nice if the open-source community was leading rather than following, as the whole industry needs to get over that hump eventually. > To be clear though -- GTA02 is soon going to actually exist, and this is > just future talk right now. But because of that, if you have any ideas > about future arch, now is the time to throw them in and they will at > least get the time of day. What else.... Multi-touch. In a year or two it will probably be considered mandatory on most new devices, IMO. Some way to charge without plugging in (there are several methods for charging by simply laying a device on an active charging pad: some use contacts arranged in clever ways, some use magnetic coupling, etc.) If the S3C6400 lets us get rid of the glamo, maybe it will have lower power consumption. I have doubts about how much 3D people are going to be doing on a phone anyway. A lot of regular UI eye-candy can be done with only 2D acceleration. But there could be 2 versions - populate the 3D accelerator, or not, depending on whether you want a gaming phone or want longer runtime. Make it way thinner and in general have a non-ugly design. ;-) Put at least 2 buttons on the face - a red and a green one, backlit with LEDs, below the screen. (Red is "hang up", "cancel", "close" and eventually "home". Green is "OK" and "dial".) Maybe the screen could be 800x480 like the Nokia tablets, but it's not a big deal. Put a piezo on the screen for tactile feedback. It might even be able to replace the speaker. (Jackito did this. It's not clear to me exactly how they did it, mechanically.) But only if this idea is compatible with multi-touch... if the overlay is glass, you probably can't make it vibrate. Include NFC (near-field communication). This is for reading RFID tags, and for doing transactions with other NFC devices over short distances. Maybe come up with a way to mount SDIO modules inside the phone in the micro-SD slot (depending on whether there is any space for that. If the phone is thin enough, there won't be.)
