Motherboard Forums


Reply
Thread Tools Display Modes

SD card filesystems for bare-iron use

 
 
Stuart Longland
Guest
Posts: n/a
 
      04-09-2010, 03:15 AM
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/NS4...87.html?kc=rss
3. http://efsl.be/
 
Reply With Quote
 
 
 
 
Stefan Reuther
Guest
Posts: n/a
 
      04-09-2010, 05:05 PM
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

 
Reply With Quote
 
 
 
 
Stefan Reuther
Guest
Posts: n/a
 
      04-11-2010, 11:08 AM
Hi there,

Stuart Longland wrote:
> On Apr 10, 3:05 am, Stefan Reuther <(E-Mail Removed)> 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

 
Reply With Quote
 
Stuart Longland
Guest
Posts: n/a
 
      04-14-2010, 09:51 PM
On Apr 11, 9:08*pm, Stefan Reuther <(E-Mail Removed)> 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.)
 
Reply With Quote
 
Stefan Reuther
Guest
Posts: n/a
 
      04-15-2010, 04:17 PM
Stuart Longland wrote:
> On Apr 11, 9:08 pm, Stefan Reuther <(E-Mail Removed)> 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

 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
RAM-based filesystems metadata Spoon Embedded 13 08-09-2007 09:05 AM
Embedded Filesystems Library problem... Pawel K Embedded 1 06-25-2007 08:10 PM
u-boot and root filesystems psommerfeld@gmail.com Embedded 11 06-08-2006 06:48 PM
Filesystems karthik.balaguru@lntinfotech.com Embedded 18 04-06-2006 02:43 PM
best way to move entire filesystems to a new disk? Craig Dewick Sun Hardware 12 12-05-2005 04:31 PM


All times are GMT. The time now is 12:34 PM.


Welcome!
Welcome to Motherboard Point
 

Advertisment