Andy Green schrieb: > Hi folks - Hi! > We had some internal talk about how to go post GTA02 and Wolfgang wants > us to make it external.
Which is actually a very nice and good move, thanks! > We have a choice about basing on S3C2443 or S3C6400. A lot of the info > is confidential but not these high level things which are public domain > on Samsung's site. > > S3C2443 is an 130nm incremental improvement over the 2442 in GTA02 with > 480Mbps USB Device (not OTG) and better clock scaling. It can accept > x16 DDR memory. > > S3C6400 is 90nm and has 480Mbps USB2 OTG, 667MHz max clock, some 2D > acceleration and can accept x32 DDR memory. > > http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=S3C6400 > http://www.samsung.com/global/system/business/semiconductor/product/2007/8/21/661267ptb_s3c6400_rev15.pdf > > I like the 6400 better but information is a bit scarce right now and it > can go either way. OK, here I have not much of an opinion - though high-speed USB sounds promising. > Some other concepts kicked around: > - Merge the debug board function on to the phone, perhaps with internal > micro USB used for debricking and hacking. No write-once memory. I am not sure here. The advantage would be to get rid of the extra board and make the connector easier (like a mini-USB plug). On the other hand this means extra parts and extra complexity for only maybe 10% of users. Even most developers can easily survive without the debug board. There are enough cheap JTag adapters around, like the Olimex ARM USB JTag also based on the FTDI chip. Why not make the debug board just a passive adapter PCB and trying to use as standard as possible parts for it? I am sure there are suppliers for off-the-shelf FFC cables and connectors. > - Discard U-Boot, minimal bootloader direct to kernel Uh, sounds interesting ;) Though I wonder how the flashing procedure should look like then. Currently one of uboot's main functions is the dfu-update, which is actually *very* nice. If you have to reflash from a running Linux system then this makes it quite complicated (bootstrapping problem - reflashing the FS while it is still mounted). > - Focus on SD Card rootfs rather than internal memory Isn't the internal flash much much faster? Rootfs on SD would be quite cool, if it is fast enough. Another drawback 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 tries hard to cluster used sectors to avoid head movement on harddisks, quite the contrary should be done for flashes. And you actually have no clue what the SD controller inside the SD card translates your accesses into. Some cards might do it well, others do not and you hardly get to know which is doing what. > - 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 Could be helpful, yes. > 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. Sure;) > -Andy Cheers nils faerber -- kernel concepts GbR Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 D-57072 Siegen Mob: +49-176-21024535 --
