Hi, On Wed, 19 Mar 2008 15:29:18 +0000, Andy Green <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
