Subject: RE: NetBSD File Systems
To: 'Unice, Kyle' <tech-embed@netbsd.org>
From: Bruce Martin <brucem@cat.co.za>
List: tech-kern
Date: 03/06/2001 08:12:15
Hi Kyle

We have had some success running diskless arm32 systems on some of our
products. We based our efforts on /usr/src/distrib/arm32/ramdisk. This
generates a crunched binary of a ffs filesystem, that is inserted into space
reserved for it in the kernel (see the "mdsetimage" manpage). At boot time,
the kernel fetches this filesystem out of itself, and mounts it in RAM. This
is a read only filesystem, and what we have done is written little utilities
that read and write different portions of flash to store the files that need
changing.

Let me know if this is the kind of thing you are looking for...

Cheers
 Bruce

-----Original Message-----
From: tech-kern-owner@netbsd.org [mailto:tech-kern-owner@netbsd.org]On
Behalf Of Unice, Kyle
Sent: 06 March 2001 01:31
To: 'tech-embed@netbsd.org'
Cc: 'tech-kern@netbsd.org'
Subject: FW: NetBSD File Systems


I am not sure if this made it .. so I am sending it again.
Forgive the repeat if you already received it.
Kyle

>  -----Original Message-----
> From: 	Unice, Kyle
> Sent:	Monday, March 05, 2001 2:27 PM
> To:	'tech-embed@netbsd.org'
> Subject:	NetBSD File Systems
>
> I have gotten to the point of having NetBSD trying to mount a file system
> on our little embedded system.  The system has FLASH and RAM but not much
> else.  What is the current thought on file systems inside these types of
> systems?  Does one allocat a piece of flash and format it as an ffs file
> system?  If so, is there a set of Flash chip drivers somewhere for NetBSD?
>
> Thanks for the help,
> Kyle
>
> W. Kyle Unice
> Senior Software Engineer                 Email: kyle <dot> unice <at>
> intel.com
> Internet Management Appliance Div.   Voice: (801) 445-0509
> Intel Corp.                                         FAX: (801) 445-0104
> 3740 West 13400 South
> Riverton, UT 84065
> Mail Stop  RV1-226
>
> Viewpoints, opinions, and content are my own and not necessarily those of
> Intel Corp.
>