Re: FreeBSD's embedded agenda

On 5/29/06, John Birrell <jb_at_what-creek.com> wrote:
> On Mon, May 29, 2006 at 10:01:37PM -0700, marty fouts wrote:
> > Unfortunately, in my world, the smallest embedded system isn't of
> > interest. We need something a bit larger.  That threaded program needs
> > a data store for persistant data.
>
> Yes, you write persistent data to the NAND disk. As I said, you remount
> the file system as write enabled when you need to save data then leave
> it read-only for the rest of the time. This doesn't take very long to do.
> It's not like you have gigabytes of data buffered because you mount
> the file system write enabled synchronously.

A smartphone is constantly writing data to persistant storage. It
needs a real file system that's r/w all the time.

> The example that I gave uses NAND flash to boot the OS and save
> persistent configuration data. The CF was only used because the MPEG
> file for a race video was 1GB. If I wasn't writing such a large amount
> of data, the CF would not have been required. At the time it was the
> easiest way to get a large amount of storage in a small system which
> had to stand the rigor race motorcycle vibrations.

The next generation of smartphones are likely to have GBs of NAND
storage. Some of them are going to include ipod-like NAND based media
players and the ability to capture mpeg.  They're still not going to
have room for a CF card.

> If you study the NAND implementations on embedded hardware,
> you will see that making a general operating system support them all with
> drivers is hard to do because of the different ways that the NAND chips
> are mapped in I/O. It's not like they are on a general bus that makes
> access to them the same.

This is a general observation about embedded devices. GPIO is your
friend.  If you look at, for instance, the evolution of OMAP support
in Linux, you'll see a succession of attempts to abstract a GPIO
support service that provides an abstraction like the bus abstraction
to deal with this.

I think your comments highlight the difference between doing one-off
embedded devices, like your motorcycle camera, where quick hacks and
custom drivers are utterly appropriate, from doing long lived families
of embedded devices, where you have to routinely deal with several
generations of hardware.

If FBSD wishes to be the best-of-the-best and play in the embedded
space, then it has to accomodate the later as well as the former.