Post- GTA02

[Felipe Balbi]

Hi,

On Wed, 19 Mar 2008 15:29:18 +0000, Andy Green <andy at openmoko.com> wrote:
> -----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.

good point

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

And that's what a bootloader should do and only that. But you're
missing memory access timings :-p

We don't need such a big bootloader like u-boot. It should be used,
maybe, only during the product development on debugging purposes.

Otherwhise, we're just spending too much effort on that.

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

And I can't why would a NAND break as well. At least we don't have to
keep a sd card attached in the device, but if it's hidden to the user,
I mean, instead of using a slot soldering the card in the pcb, that's
also pretty much ok. :-p

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

Good, then ;-)

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

Good. If we have the signals out somehow, we can later make them usable.
How about some sort of FIC-only port where we could attach other devices?

-- 
Best Regards,

Felipe Balbi
http://felipebalbi.com
me at felipebalbi.com