Post- GTA02

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

>>  - Merge the debug board function on to the phone, perhaps with internal
>> micro USB used for debricking and hacking.  No write-once memory.
> 
> the problem with the micro-usb is space on the case. It'd be cool if we
> could make GTA03 (or whatever name) was a thinner.

The idea here was that this connector is not externally visible... those
micro USB connectors are pretty thin too.  Just the normal one comes out
of the case and yu can debrick from this other one or hack on it.  Maybe
it can appear at the battery compartment or something like that.

>>  - Discard U-Boot, minimal bootloader direct to kernel
> 
> I really like the idea of minimal bootloader, but not direct on the kernel.
> LKML won't like it at all. We can have a separate project for this minimal
> bootloader. I'm pretty sure 50k lines of code is way enough.

Well I don't mean that it is part of the kernel image, it would be
separate, so LKML don't have to care :-)  Just that one never boots into
this bootloader and stays there like we currently do, when it runs its
only plan is to right away pull a kernel image from somewhere and jump
into it.  No shell, no init other than critical assets like clock and
GPIO.  Hence "direct to kernel".

>>  - Focus on SD Card rootfs rather than internal memory
> 
> This is also a bit weird as if our sd card break we can't use the device
> :-s
> I like the way it is today allowing the user to choose whether he wants
> NAND boot or SD card boot.

Well, I don't know why the internal SD card will break, but you can even
then get a new SD card, prep it on a PC and you are back in business.
If the NAND breaks for whatever mysterious reason things are breaking in
this scenario, you have worse trouble.  Also if NAND was not present at
all for whatever reason, we are still good to go via SD.

>>  - Add a small lowpower MPU like TI MPS430 to manage everything
>> seamlessly when main CPU is down.  Stuff like motion sensors, wake
>> sources, battery management, maybe touchscreen, leds so there is an
>> always-on "guiding hand" in the phone that is consistent and reliable
> 
> Are you taking about the msp430? I really like that chip it's really low
> power consumption and really easy to program ;-)
> Good catch

Yes, a typo.  The idea is it too should be user-programmable.

> Again, I really liked the s3c6400, it's already ARM11, operates in 533mhz,
> has HS-MMC/SD controller (worth checking if it's sdhci-compliant), it has a

Good point about sdhci but we are told a Linux driver exists already
anyway FWIW.

> What I'd suggest for the next device (if I can), would be to make it
> thinner and put a camera (or maybe two, like most of the phones are now),
> s3c6400 already has a camera interface which would really help us and maybe
> using a keyboard (qwerty i mean) sliding out from the back of the phone and
> accelerometers to get screen rotation; just to exemplify the keyboard
> thingy checkout [2[. Before I forget, change the usb connector to micro-AB
> receptacle ;-)

That last one sounds good :-)  The others go to product definition and
it's basically out of scope for me.  If we aren't to have a camera, we
will at least try to bring out the signals somehow.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFH4TFOOjLpvpq7dMoRAmFBAJ4p8tsHGX9w14TP3cqSVT1odirwsQCglTcj
vyv7jKw64U/GHdEBXs9XWS4=
=4Wj5
-----END PGP SIGNATURE-----