Post- GTA02

Shawn Rutledge shawn.t.rutledge at gmail.com
Thu Mar 20 03:11:35 CET 2008


>  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.)




More information about the openmoko-kernel mailing list