Post- GTA02

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

Hi Nils -

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

This and the others are related, but one advantage is 100% total brick
immunity.  On GTA02 we have what is for most users (you can rewrite if
you have a debug board) a "write-once" NOR which exists as a "consumer
debrick" device only, really.  Both the NOR and the troublesome "write
once" aspect wouldn't need to exist if instead of having two classes of
user, with and without full hack access, it was there for all.

Milosch Meriac described a great system he designed which re-uses the
bluetooth module for debricking and a debug console without physical
connection (!) but the JTAG need and USB-only bluetooth on our case
probably mean we should stick with FTDI.

>>  - Discard U-Boot, minimal bootloader direct to kernel
> 
> Uh, sounds interesting ;)
> Though I wonder how the flashing procedure should look like then.

If you didn't brick your device:

 - If you overwrite a non-live partition, just scp it in from the
working Linux boot direct to /dev/mmcblk0p2 or whatever

 - you hold down a button or somesuch and you come up into a backup
kernel + rootfs in its own partition.  You then scp your new bootloader
or other partition directly as above.  Because you came up on a
different backup rootfs or initrd, you can overwrite the main one
without any concern.

If the bootloader is OK but Linux / rootfs is trashed:

 - turn it off and pull the SD card, reinit on a PC with a flash/USB
adapter, reinsert and go

Bootloader is trashed:

 - you use the 100% available JTAG from the first proposal to overwrite
it from your PC, no worries.

The JTAG should reach any flash-based MPU as well, so that can also be
debricked.  Everything should be writable and debrickable.

>>  - Focus on SD Card rootfs rather than internal memory
> 
> Isn't the internal flash much much faster?

Yes and no on 2442, it has an 8-bit connection to the CPU and tops out
at 4-5MBytes/sec read I was told.  Glamo SD card was ~ 1.2MBytes/sec
last time I measured it, CPU based SD can be a lot faster, 8MBytes/sec
sustained.  And these cards are getting faster too, allowing up to 50MHz
clock (supported by both Glamo and CPUs).

> Rootfs on SD would be quite cool, if it is fast enough. Another drawback

GTA02 supports this already and in fact I stopped using the JFFS2 rootfs
a while ago myself in favour of it (actually I used VFAT partition for
the kernel and then ext2 partition for the rootfs, which I mount
read-only).  It boots nice and fast and the advantages if you messed
something up of just popping it and having access in your PC is nice too.

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

As I say I used this, and I have other devices doing the same for years
24/7 without trouble, and I think the cards will only get faster now.
Whatever wear-levelling the cheap cards I have used have on them seems
fine.  JFFS2 compression, which is not for free, is not needed if we are
using cheap, expandable storage like SD.

I think stuff that heads towards these device not being "an embedded
device" with special filesystems, and more like a mainstream "laptop"
type device (if it doesn't unduly cost us in money, CPU, power etc) will
serve us well.

- -Andy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFH4P6zOjLpvpq7dMoRAhYpAJ9Pfklu0s03EVV0QE0xeNPWMZOkPACdFIop
IbolxrtuNheM7ejoA4kq9cc=
=qtcu
-----END PGP SIGNATURE-----