COS File System

[Indan Zupancic]

Hello,

I'm interested in working on CardOS, especially on the flash file system.
Seems like a fun project, and I think it's important to have an open
source GSM stack from top to bottom.

On Wed, November 27, 2013 17:39, Tom Schouten wrote:
> Most of the effort there seems to be testing with different phones, as
> behavior varies wildly.

Yes, that's important, and one of the harder things is to figure out
why it doesn't work for a particular phone. It's probably a good idea
to have SIM tracing built-in in CardOS so that we can see what happened
afterwards.

>
> Any ideas on how to design the file system?

I have some ideas, I'll email them later. The main design points are:

- Simple and very robust to avoid any data corruption problems.
  It has to be obviously correct, we don't want to debug subtle FS problems.
- Low write amplification.
- Low RAM usage.
- Fast reads.
- Some kind of wear-leveling.

Considering that the CC32RS512 has NAND flash which is fast enough to execute
code from at 28MHz, reading is very fast and writing/page erase is very slow.

> Anything to reuse?

I haven't seen anything yet. Both SSIM and SOSSE use EEPROM file systems,
which have very high endurance and are byte writeable.

>
> I'm not aware of any reusable FS for NOR flash - not needing all the
> error handling in NAND flash code.

The CC32RS512 has NAND flash, probably SLC with ECC handled in hardware,
if at all.

>
> Comparing the size of the flash (512k) to a typical GSM/USIM profile
> (64k?), it seems that using 256 byte sectors for writable EFs might be
> good enough in a first iteration.

The amount of flash does seems rather high compared to how much we can use.
Both the list of dialling numbers and stored SMS are linear fixed, which
means they have at most 254 entries each.

>  From what I gather from phone<->SIM traces, only a couple of temporary
> key EFs change frequently, and using wear-leveling this should never
> pose any real problems.  SMS message update seems infrequent enough also.

My understanding is that the provider can choose their own encryption scheme,
so I'm pretty sure that with CardOS we can store those frequently changing
temporary key's in RAM only. This is probably true for most frequently changing
files. Storing the last known value at shutdown or with a very infrequent timer
seems often good enough. Frequently changed files are all quite small, so there
is plenty of space left for a write counter for wear-leveling.

Files listed with high update frequency are:

EF Kc (Ciphering key Kc, 9 bytes)
EF ACM (Accumulated call meter, 3 bytes)
EF BCCH (Broadcast control channels, 16 bytes)
EF LOCI (Location information, 11 bytes)
EF KcGPRS (9 bytes)
EF LOCIGPRS (14 bytes)
EF CPBCCH
EF MWIS (Message waiting indication status, ~5 bytes)
EF COUNT (call count, 3 * N bytes)

According to ETSI TS 151 011:

Digital cellular telecommunications system (Phase 2+);
    Specification of the Subscriber Identity Module -
            Mobile Equipment (SIM-ME) interface
    (3GPP TS 51.011 version 4.15.0 Release 4)

This and ETSI TS 102 221:
           Smart Cards;
     UICC-Terminal interface;
Physical and logical characteristics

are my main sources of knowledge. Anything else I should read?

The most surprising thing was how unnecessarily complex they tried to make
smart cards. SIM cards use a somewhat sane subset, so I think it's probably
a good idea to focus on SIM cards first, and extend to other smart card uses
only when necessary.

> Read-only files could be packed more closely if necessary.

All files can be packed more closely, no need to waste 256 bytes
for a 3 byte file.

It seems that although some files are writeable, the file system layout
and file sizes are fixed. This simplifies things considerably.

> For a more complex "and mask" programming approach, it's not sure
> whether that works or not.
>
>    From the CS32RS512 DS:
>
>      1.3.2 Memory
>      Page Erase is mandatory before a Page Program operation
>      (consecutive Page Program is NOT supported)
>
> Not sure what this refers to:
> - programming can only bring 1->0 (the obvious)
> - consecutive programming causes interference to nearby unprogrammed
> bits, degrading retention time (electrical)
> - other?

The CS32RS512 "scrambles" data written to flash for security reasons,
this means that you don't end up writing the bits you think you do
and why partially writing pages can't be supported.

Greetings,

Indan