Post- GTA02

[Andy Green]

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