Re: FreeBSD's embedded agenda

On Mon, May 29, 2006 at 10:01:37PM -0700, marty fouts wrote:
> On 5/29/06, John Birrell <jb_at_what-creek.com> wrote:
> 
> >The smallest embedded system using FreeBSD consists of just a kernel
> >and a threaded program which runs as 'init'. No other files are required.
> 
> 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.

> >the FreeBSD system
> >detected the fact that the bike was turned off and went through it's
> >shutdown sequence, closing the video file which was on CF (not NAND
> >where the OS was) and then when the buffers were flushed, it toggled
> >an output bit which opened a relay contact and powered itself down.
> 
> I guess you missed the discussion earlier where it was pointed out
> that there are significant applications in which CF is not an
> available option.  If you didn't have CF on the device, but you did
> have NAND, (which is where we are in smartphone land) you'd need a
> NAND based file system, for the data that has to persist across phone
> shutdowns.

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.

As I said, writing a NAND driver under geom on FreeBSD is a trivial matter.
That is what I did. The driver wasn't committed to FreeBSD because it
is hardware specific to the board due to the way the the processor I/O
is mapped. 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.

--
John Birrell