Prev: Reaction on fpga
Next: EI Compendex、 ISTP检索的计算机应用与计算科学国际会议2010 Dec.Sinapore
From: Stuart Longland on 8 Apr 2010 23:15
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/
From: Frank-Christian Krügel on 9 Apr 2010 03:50
Am 09.04.2010 05:15, schrieb Stuart Longland:

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

BSD also supports EXT2, and you are allowed to use it. Get the OpenBSD
sources and look in sys/ufs/ext2fs.

--
Mit freundlichen Gr��en

Frank-Christian Kr�gel

From: Stefan Reuther on 9 Apr 2010 13:05
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

From: Stuart Longland on 10 Apr 2010 20:46
On Apr 9, 5:50 pm, Frank-Christian Krügel <dontmai...(a)news.invalid>
wrote:
> BSD also supports EXT2, and you are allowed to use it. Get the OpenBSD
> sources and look in sys/ufs/ext2fs.
>

That certainly does look like a good option. I was under the
impression that some of the BSD code for EXT2 was GPL-licensed due to
comments that it would "taint" the kernel with GPL code... but I'll
admit I was not looking particularly hard.

I'll have a closer look.

On Apr 10, 3:05 am, Stefan Reuther <stefan.n...(a)arcor.de> wrote:
> 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.

Indeed... I'm having difficulties getting FatFS to behave in this
regard. The documentation takes a bit of getting used to, and thus
far I have not succeeded in getting long filenames to work.

> > (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 upshot being that I have difficulty locating files on the embedded
system, that have been placed there by a Windows XP system.

There are other issues with FAT, that don't affect this project, but
might affect others in the future. I'm raising the question here
however since I know it's been a major bugbear of a lot of projects;
since FAT16 doesn't really cater for modern requirements.

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

Implementing a FAT driver from scratch is certainly a possibility.
For what it's worth, I've got the time to implement neither FS ...
this would be a personal persuit in my spare 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.

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.
From: Stefan Reuther on 11 Apr 2010 07:08
Hi there,

Stuart Longland wrote:
> On Apr 10, 3:05 am, Stefan Reuther <stefan.n...(a)arcor.de> 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

 |  Next  |  Last
Pages: 1 2
Prev: Reaction on fpga
Next: EI Compendex、 ISTP检索的计算机应用与计算科学国际会议2010 Dec.Sinapore