So would the asm code for fread from boot2 help you?

If someone could manage to write some fopen/fread/fwrite for the TI-Nspire's proprietary filesystem, that would certainly be a huge help to any sort of Linux port.

Quote from: calc84maniac on April 05, 2011, 01:38:52 pm

If someone could manage to write some fopen/fread/fwrite for the TI-Nspire's proprietary filesystem, that would certainly be a huge help to any sort of Linux port.

I'm not sure what you mean by this.

TI didn't use a standard filesystem like FAT, instead they used a proprietary filesystem called Datalight Reliance. This basically means we have to rely on TI's OS code to do file access (making ports of other OS's, such as Linux, somewhat difficult)

Out of curiosity, has anyone taken a look at the filesystem formats yet?

Not yet, but it's on my list.

TI didn't use a standard filesystem like FAT, instead they used a proprietary filesystem called Datalight Reliance. This basically means we have to rely on TI's OS code to do file access (making ports of other OS's, such as Linux, somewhat difficult)

I see. Thanks for clearing that up, I guess I'll add that to my list of things that need to be done.

Out of curiosity, has anyone taken a look at the filesystem formats yet?

I looked into it a little bit a while back.

The first thing you need to know is that there are two layers involved. FlashFX Pro does bad block management and wear leveling, essentially presenting a "hard-disk" abstraction to the code above it. (You can repeatedly tell FlashFX Pro to write to the same page, but it will actually cycle through many different pages, to avoid wearing out the flash with repeated erase/program cycles; it remembers which logical page corresponds to which physical page so you will always get the right data back on a read.) On top of FlashFX Pro is Reliance, the actual filesystem.

FlashFX Pro divides the physical space into 937 "units" of 64 pages (0x8000 bytes) each, and the logical space into 59 "regions" of 976 pages (0x7A000 bytes) each. Each unit has a header page (I don't know the exact meaning of all these fields; the names are from some code in the command shell)

Bytes 00-0F: signature (CC DD "DL_FS4.00" FF FF FF FF FF)
Bytes 10-13: "clientAddress" (logical address of which region this unit is holding data for; always a multiple of 0x7A000)
Bytes 14-17: "eraseCount"
Bytes 18-1B: "lnuTag"
Bytes 1C-1F: "ulSequenceNumber"
Bytes 20-23: "serialNumber"
Bytes 24-27: "lnuTotal"
Bytes 28-2B: "numSpareUnits"
Bytes 2C-2D: "blockSize"
Bytes 2E-2F: "lnuPerRegion"
Bytes 30-31: "partitionStartUnit"
Bytes 32-33: "unitTotalBlocks"
Bytes 34-35: "unitClientBlocks"
Bytes 36-37: "unitDataBlocks"
Bytes 38-39: "checksum"

The extra 16 bytes that the flash chip has for every page are also used to hold information:
Bytes 0-1: tells which logical page this is within the region; ranges from 0x4000 to 0x43CF. (All unit header pages have this field set to 0x48E2.) Sometimes the same page of the same region will appear multiple times in different units; I don't know yet how to tell which one is the latest version of the page.
Byte 2: ones-complement of byte 0 XOR byte 1
Byte 3: error-correcting Hamming code of bytes 0-2
Bytes 4-7: seems to always be FF FF FF 0F for used pages, FF FF FF FF for unused
Bytes 8-B: error-correcting code of second half of page data
Bytes C-F: error-correcting code of first half of page data

Reliance seems to be a fairly conventional filesystem, in terms of data layout. Here's the inode structure, used to describe a file or directory:
Bytes 00-03: "INOD"
Bytes 04-07: inode number
Bytes 08-0B: size of data
Bytes 10-17: some kind of timestamp (in microseconds since 1970)
Bytes 18-1F: some kind of timestamp (in microseconds since 1970)
Bytes 20-27: some kind of timestamp (in microseconds since 1970)
Bytes 28-2B: flags
Bytes 2C-3F: always zero?
Bytes 40+: data - format depends on low bits of flags:
  If 0: contains data directly (can be up to 448 bytes)
  If 1: contains pointers to data pages (up to 56 kB)
  If 2: contains pointers to "INDI" (indirect) pages containing pointers to data pages (up to 6272 kB)
  If 3: contains pointers to "DBLI" (double indirect) pages containing pointers to "INDI" pages (up to 686 MB)

You find an inode by looking it up in inode 1's data (inode 1 is a table of inode pointers). Not sure how you find inode 1, though :p

Edit:

The best thing would be to have an image with the linux rootfs, and just point the kernel to the raw location of the file on the nand. This way you would not need to know how the filesystem works.

The problem with this is the filesystem won't keep your image file contiguous.

Sorry if this a stupid question. But couldn't we just reformat a section of the flash memory(or whatever the correct term is)?

Oh Ok. would be to easy I suppose...

I suppose in theory if you could replace the flash chip with a larger one, then you could use the space beyond the filesystem (current boot2's and OSes have hard-coded the filesystem area to end at 32MB, although this may change when OS 3.0 comes out because the CX will have a 128MB flash chip). I don't think there are many of us who could do that, though :p

On the CAS+ nspires replacing the NAND wouldn't be too hard, but for the production nspires you would need some expensive equipment.