-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: > Hi, > I would very much welcome the S3C6400. > >>> S3C6400 is 90nm and has 480Mbps USB2 OTG, 667MHz max clock, some 2D >>> acceleration and can accept x32 DDR memory. >>> > Besides the USB niceties I think arm11 (armv6 isa) and hw floating point > support is what makes this device interesting. > > I really hope however that there is not all to much NDA restriction.
I can't say about the NDA stuff from vendors, but I can say ARM themselves document the ARM11 and FP unit, so that won't make trouble. http://www.arm.com/documentation/ARMProcessor_Cores/index.html http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301g/DDI0301G_arm1176jzfs_r0p7_trm.pdf http://infocenter.arm.com/help/topic/com.arm.doc.ddi0274h/DDI0274H_vfp11_r1p5_trm.pdf We should get Linux peripheral support quicker than previously, so again that limits the damage. And Openmoko proved they will ask vendors nicely and sometimes effectively to open their data if anyone can :-) > Regarding U-Boot: I second Nils' opinion. The dfu functionality is very > neat and I am sure some people would miss the possibility to use the GSM > modem from bootloader through USB serial connection. Ah well it sounds like a feature removal but it is really an expansion. The "dfu functionality" will be there in more standard protocols like scp via WLAN for example in Linux. For GSM modem over USB serial, you can do this is Linux again with more options like doing it over WLAN or BT, or running scripts or GSMd, or alsa routing that U-Boot can't hack. "Booting" to Linux has not been so fast in the past, but booting from SD into busybox ash is like 15s on GTA02 and the thin bootloader will chop several more seconds off it, as would this proposed 667MHz DDR platform again. So it is less of a burden than you might think to talk about using an OS kernel to replace U-Boot. In addition, whereas before you had to reboot into U-Boot to DFU, now if you had Linux up already to update the kernel or bootloader you can scp without the reboot and just reboot into the new guy. > Regarding rootfs on SD solely: I second Nils' arguments. NAND bad block management is hassle in production and we would love to let the SD card to deal with privately. But it is possible we can only get to use devices with NAND on board, in this case we will use it for something. > Everybody fears that internal flash one day dies and renders the device > unusable. How about replacable internal flash modules? Is that possible? The CPU NAND is integrated into the CPU physical package and that is BGA'd on to the PCB. Whereas any SD card inside would be in a socket and you can just pop it. But I think the wear-levelling in JFFS2 and most SD cards anyway is effective enough for normal use or even some abnormal use. I don't think this is going to be an issue unless you went behind JFFS2 and pushed your luck direct on to the block device in the CPU NAND case (and not even then for any reasonable scenario in the SD case where the SD card does any leveling, because you did not avoid the leveling). - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFH4RxwOjLpvpq7dMoRAq7PAJ9etIgcAE3eJ3T/lQfIoPtnecXEJgCfRQx8 AlgayKyTrscxSfh2/FvyHZ4= =uMBr -----END PGP SIGNATURE-----
