NAND vs SD on GTA02

[Michael Sokolov]

Radek Polak <psonek2 at seznam.cz> wrote:

> If you want to have the system stable NAND is good choice. I never had single 
> filesystem corruption with JFFS2 even after pulling battery. With SD card and 
> ext2/ext3 you will probably hit filesystem corruption after unclean resets.

Yup, that's what I was thinking too.

> I can see your point, but if the hardware and power management is done right, 
> you can power off Wifi, GPS and all unused things.
>
> Since you will have most of the time phone in suspend, you should care only 
> about power consumed in suspend - which is power drawed by GSM+RAM+PMU.

Yup, that's my thinking too.

> And btw do you think that your phone will draw less battery if you remove web 
> browser from the system?

Of course not.  However, I prefer to keep the application processor
front-end software as simple as possible (in *my* personal sense of
simplicity) in order to make it easier for me to tweak it to my peculiar
tastes and preferences.

I have considered the following question: if I were to succeed in
obtaining an illegal copy of the Calypso fw recompilable source, which
is what I am really after (i.e., that's what "free your phone" means to
me), do I really need something as fancy as a Neo, or would my needs be
better satisfied with something like this:

http://bb.osmocom.org/trac/wiki/MotorolaC123

I thought about it, and came to the conclusion that a *simple* Linux-based
application processor front-end would be useful even for someone like me:

* I would probably have an easier time making the UI look and work
  exactly the way I want if it's driven by Linux rather than Calypso;

* A lot of people with whom I have to interact in my daily life have
  adopted text/SMS as their primary means of communication, replacing
  both human voice calls and email.  I don't like it, but I need to
  interact with these people, and making them change their ways is not
  an option.  Therefore, I would like a phone with very powerful SMS
  handling capabilities.  Here's what I have in mind:

* I would like to archive *all* sent and received SMS, lots of them.  I
  doubt that doing it the way ancient phones did it (store it all on the
  SIM I guess?) would cut it; JFFS2 would do the job much better,
  methinks.

* Long messages sent over multiple SMS: my phone needs to be able to
  receive and reconstitute them at the very least, with full error
  handling: if only some part(s) arrived, let me see that etc.  Would
  like to be able to send such beasts as well, for communicating with
  people who don't do email and who would get upset if I actually
  called them at just the wrong instant...  I know there are feature
  phones (BP only, no AP) that can do it, so I reason it probably *can*
  be done on the Calypso.  But methinks it would be simpler to have the
  BP view each individual SMS as independent and have the AP handle
  segmentation and reassembly.

* I would like to be able to compose long text messages in vi on my
  laptop, then inject them into the phone for transmission over USB.

* I would like to save the complete log of all sent and received SMS
  and voice calls in long-term storage outside of the phone, i.e., on a
  UNIX minicomputer server in my own personal datacenter.  In the first
  version I'll do it indirectly via the laptop (USB between the phone
  and my laptop, then from the laptop to the mainframe via scp or
  whatever), but eventually I would like to have the AP wake up on its
  own once a day or so, establish a circuit-switched data call or GPRS
  IP connection to my server back in the datacenter, and transfer
  everything automatically.

> I doubt it is legal

And why should I care?

> and if your phone operator would be happy with hand-made 
> GSM firmware.

How would they know, and how would they enforce it?  As long as the
phone speaks the exactly correct protocol over the air (which it would
if I were to start with a known-working codebase and just tweak it
slightly to disable RRLP or whatever), they wouldn't be able to do
squat about it.

MS