1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

SD card filesystems for bare-iron use

Discussion in 'Embedded' started by Stuart Longland, Apr 9, 2010.

  1. Hi all,

    I've looked around for a solution to this, but haven't really come up
    with anything. I'm developing a controller based on the Luminary
    Micro EK-LM3S8962 evaluation board, and since it has a MicroSD card
    slot, we're using that as persistent storage for settings.

    This has the nice advantage that any settings can be backed up, and
    potentially viewed, on a desktop computer.

    At present we use FAT on the SD card, implemented using the FATFS
    module from Elm-chan[1]. We're using it with long filename support
    disabled. A few issues have been hit though.

    (1) If files are placed on a system using long filenames, this seems
    to make the files inaccessible to the microcontroller, even when done
    on Windows (XP). Only way that seems to work is to mount the card in
    Linux using the "msdos" driver, and copy them that way.
    (2) Long filenames don't seem to work... if enabled, I can't find any
    file.
    (3) There are patent concirns regarding long filenames and FAT.[2]

    For now we'll just continue using FAT... but really, I'd like to move
    to something else. EXT2 in particular is what I'm considering, as it
    works nicely with abstracted block devices such as SD cards (which
    implement wear levelling, unlike raw flash), and can be read from
    Windows with the installation of a suitable driver (which isn't an
    issue in our application).

    I've heard of the loop-mount solution being brought up... which is a
    possibility too, but for that to work we'd still need an EXT2 driver.

    The catch with EXT2: the only implementation I know of is the one in
    the Linux kernel. A right pain in the bum to extract and utilise in a
    standalone setting (think of how FATFS is used)... and legally
    unacceptable for applications that require static linking with
    proprietary code (ours does).

    Has anyone seen any project that would provide EXT2 support (much like
    the FATFS module provides FAT support) in bare-iron embedded
    projects? Or... is there any interest in developing such a project?
    (Maybe EFSL[3] could make a good basis? I couldn't get it to link...
    but that looks the closest/best offering.)

    Regards,
    Stuart Longland

    Footnotes:
    1. http://elm-chan.org/fsw/ff/00index_e.html
    2. http://www.desktoplinux.com/news/NS4980952387.html?kc=rss
    3. http://efsl.be/
     
    Stuart Longland, Apr 9, 2010
    #1
    1. Advertising

  2. Hi there,

    Stuart Longland wrote:
    > At present we use FAT on the SD card, implemented using the FATFS
    > module from Elm-chan[1]. We're using it with long filename support
    > disabled. A few issues have been hit though.
    >
    > (1) If files are placed on a system using long filenames, this seems
    > to make the files inaccessible to the microcontroller, even when done
    > on Windows (XP). Only way that seems to work is to mount the card in
    > Linux using the "msdos" driver, and copy them that way.
    > (2) Long filenames don't seem to work... if enabled, I can't find any
    > file.


    That must be a specific problem of your FAT module. Long file names are
    stored in a way that programs that don't talk long file names skip them
    automatically.

    > (3) There are patent concirns regarding long filenames and FAT.[2]


    I'm not a patent lawyer, but as far as I know, all those patents only
    apply to Microsoft's "common namespace" of short and long names. My
    implementation doesn't have a common namespace. A file has one name, and
    that's it. Period.

    > For now we'll just continue using FAT... but really, I'd like to move
    > to something else. EXT2 in particular is what I'm considering, as it
    > works nicely with abstracted block devices such as SD cards (which
    > implement wear levelling, unlike raw flash), and can be read from
    > Windows with the installation of a suitable driver (which isn't an
    > issue in our application).


    Instead of switching over everything, have you considered using another
    FAT implementation? I hear there are a few around, and making your own
    doesn't take too much time. At least, if implementing your own ext2 is
    an option, implementing your own FAT should be a better one because it's
    simpler. Mine took a week or so.


    Stefan
     
    Stefan Reuther, Apr 9, 2010
    #2
    1. Advertising

  3. Hi there,

    Stuart Longland wrote:
    > On Apr 10, 3:05 am, Stefan Reuther <> wrote:
    >>Stuart Longland wrote:
    >>>(3) There are patent concirns regarding long filenames and FAT.[2]

    >>
    >>I'm not a patent lawyer, but as far as I know, all those patents only
    >>apply to Microsoft's "common namespace" of short and long names. My
    >>implementation doesn't have a common namespace. A file has one name, and
    >>that's it. Period.

    >
    > It's the common namespace that seems to be giving me the most
    > trouble. Windows XP will use this by default. Linux is switchable
    > between namespaces, and thus I can easily control which namespace I am
    > looking at, but Windows seems to assume all systems can see both.


    The Windows API always gives you two file names, a short one and a long
    one. This is what I understand as "common namespace". Try 'dir /x' for
    example. Linux can be configured to ignore long file names (by mounting
    as 'msdos') or to prefer them (by mounting as 'vfat'). However, when
    mounting as 'vfat', you can still access files using their 8.3 alias.
    You don't see those in 'ls' output, but I recall there is some special
    call to convert a long file name into a short one, implemented for Samba.

    I see no reason why one would need *that* in an embedded file system.
    Mine ignores short names completely if there are long ones, and fills
    short ones with random junk when creating them (I tried leaving them
    blank, but then Windows refuses to read the files). So there's no common
    namespace - just an ignored field next to other ignored fields such as
    "creation time".

    > I saw another implementation, EFSL (linked to earlier), which seemed a
    > lot cleaner than FatFS and provided provisions for separate
    > filesystems (although only implements FAT at this stage). Not sure
    > what its status is these days. I attempted to port it across to
    > Luminary Micro, using StellarisWare as a backend for the SPI driver,
    > but I had trouble getting it to link. A bit more tinkering is in
    > order... and I think the Makefiles could do with a cleanup too to aid
    > portability.


    One implementation that I had briefly looked at was this one
    <http://www.roland-riegel.de/sd-reader/index.html>, but it's GPL'd.

    > I haven't gone looking for many other FAT implementations, partially
    > because I believe FAT really needs to give way to something more
    > modern. A tough ask when so much of the world is addicted to a
    > certain Redmond-developed OS, but a transition that needs to happen
    > nonetheless IMO.


    Well, being nitpicky, you don't have any option other than FAT for SD
    cards, because that's what the SD 2.0 spec requires. And the "more
    modern" thing for SDXC cards goes by the name exFAT, which seems to be
    nothing more than FAT with some more bells and whistles (a coworker
    converted my FAT interpreter into an exFAT interpreter within days).
    Of course using another file system works as long as you don't expect
    other consumer devices to be able to read it, but I would expect that at
    least some card controllers optimize upon the assumption of containing
    FAT (such as, giving the often-changing FAT more wear leveling room than
    the data area).


    Stefan
     
    Stefan Reuther, Apr 11, 2010
    #3
  4. On Apr 11, 9:08 pm, Stefan Reuther <> wrote:
    > Well, being nitpicky, you don't have any option other than FAT for SD
    > cards, because that's what the SD 2.0 spec requires. And the "more
    > modern" thing for SDXC cards goes by the name exFAT, which seems to be
    > nothing more than FAT with some more bells and whistles (a coworker
    > converted my FAT interpreter into an exFAT interpreter within days).


    This is most interesting... not doubting what you're saying of course,
    but I would have thought the SD standards would have dictated the
    protocol interface for storing filesystem blocks on the card, and left
    higher level things like filesystems to the end user. FAT being used
    of course because it is a lowest common denominator standard.

    As for exFAT... not sure what the support is for that FS. The thing
    I'm very conscious of though, is that most (if not all) FAT-based
    filesystems are hamstrung by the fact that they're trying to "bolt-on"
    features to a legacy filesystem which was never intended to implement
    these features. It just seems a bit of a hack to me. (Then again,
    EXT[234] has its share of hacks I suppose.)
     
    Stuart Longland, Apr 14, 2010
    #4
  5. Stuart Longland wrote:
    > On Apr 11, 9:08 pm, Stefan Reuther <> wrote:
    >>Well, being nitpicky, you don't have any option other than FAT for SD
    >>cards, because that's what the SD 2.0 spec requires. And the "more
    >>modern" thing for SDXC cards goes by the name exFAT, which seems to be
    >>nothing more than FAT with some more bells and whistles (a coworker
    >>converted my FAT interpreter into an exFAT interpreter within days).

    >
    > This is most interesting... not doubting what you're saying of course,
    > but I would have thought the SD standards would have dictated the
    > protocol interface for storing filesystem blocks on the card, and left
    > higher level things like filesystems to the end user. FAT being used
    > of course because it is a lowest common denominator standard.


    The point is interchange: everything that says "I support SD cards" has
    to support FAT, so consumers can be sure they can transfer their data
    from here to there using an SD card. Of course, if you control both
    ends, you're free to do whatever you want.


    Stefan
     
    Stefan Reuther, Apr 15, 2010
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mike Turco

    Soldering Iron Recommendations

    Mike Turco, Jul 7, 2004, in forum: Embedded
    Replies:
    16
    Views:
    723
    Mike Turco
    Jul 13, 2004
  2. Filesystems

    , Apr 5, 2006, in forum: Embedded
    Replies:
    18
    Views:
    526
    Tom Lucas
    Apr 6, 2006
  3. Replies:
    11
    Views:
    570
  4. amerdsp

    Variable Temp Soldering Iron

    amerdsp, Sep 12, 2007, in forum: Embedded
    Replies:
    4
    Views:
    497
    David M. Palmer
    Sep 14, 2007
  5. Al Dykes
    Replies:
    5
    Views:
    290
    Ben Myers
    Apr 2, 2010
Loading...

Share This Page