Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 May 1998 12:21:52 -1000
From:      "Randal S. Masutani" <randal@comtest.com>
To:        Andrzej Bialecki <abial@nask.pl>
Cc:        freebsd-small@FreeBSD.ORG
Subject:   Re: Embeded applications?
Message-ID:  <199805222203.MAA07511@oldyeller.comtest.com>
In-Reply-To: <Pine.NEB.3.95.980522075657.26144C-100000@korin.warman.org.pl>
References:  <199805212145.LAA05174@oldyeller.comtest.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 22 May 98 at 8:35, Andrzej Bialecki wrote:

> On Thu, 21 May 1998, Randal S. Masutani wrote:
> 
> > On 14 May 98 at 11:12, Andrzej Bialecki wrote:
> > 
> 
> > It emulates a hard drive at the BIOS level.  ie. it is accessed as
> > drive=0x80 and has cylinders=1021, heads=1, sectors=16, ~8MB Flash.  It
> > has a standard partition table in c=0, h=0, s=1.  The BIOS after POST
> > looks for a bootable floppy disk, then a bootable hard drive. Just like
> > a standard boot process.  The flash drive is setup with the standard DOS
> > FDISK and FORMAT commands. 
> 
> So, this looks _exactly_ like IDE drive. This means it can boot FreeBSD no
> problem.

No, no ... sorry if I was not clear with my statements above.

Let me clarify myself.  There are two major ways that manufactures 
implement access to Flash memory devices, Software or Hardware emulation.

1. Software BIOS emulation, INT 13H.  Also identified as Flash File System.  
This mean that you can only access the flash through BIOS call interrupt 13H.  
Using INT 13H you can specify CHS(cylinder,head,sector) values to access the 
flash.  It does not have any hardware compatibility with IDE I/O ports or 
registers.  Since DOS commands rely only on BIOS calls to access hard drives, 
this type of emulation works with the standard DOS commands FDISK and FORMAT.  
FreeBSD kernel cannot see this type of flash since it cannot call BIOS 
routines. (this is the type of flash that is built onto the PC/104 CPU board I 
am using)

2. Hardware IDE emulation.  This means hardware compatibility with IDE I/O ports 
and registers.  It physically attaches to an IDE controller cable as a drive.  
The FreeBSD kernel can see this type of flash.  It will show up as a 'disk wd0 
at wdc0 drive 0' device in the kernel.  (I do not have this type of IDE flash 
yet)

3. Hardware PCMCIA flash.  This type of flash plugs into standard PCMCIA 
slots.  This type of flash requires the standard PC CARD Socket Services.  The 
PAO version of FreeBSD supports this type of flash.

4. Hardware Floppy emulation.  This type of flash looks just like a floppy 
drive.  It attaches to the floppy controller cable as a drive.  FreeBSD kernel 
would work with this type also, as 'disk fd0 at fdc0 drive 0'.  However I 
haven't seen this type available in the form that I need.

> > I have copied over the floppy.tree/etc to mfs.tree/etc.  I did take into account 
> > the language files and mfs.rc.xx.  I had to modify the populate and stage3 
> > scripts accordingly.  I did get it to compile and work ok from floppy only.  
> > However I understand that the /etc files are static and cannot save changes.
> > Not what I want.  But I can work with this for now.
> 
> Hmmm... You see, FFS takes too much space from flash (which is expensive),
> so as long as you can you should avoid it. One possible solution would be
> to split flash into two partitions: one big (containing bootable image on
> raw partition), and the second one containing the configuration file
> (single). This way, you could use the whole partition for bootable image
> (no space wasted on FFS), and then you could access raw partition #2 to
> get raw blocks containing configuration data (and after changing, just
> write it block by block back on the raw partition). It's just an idea - it
> needs testing.. :-) 
> 
> > I haven't modified the boot block yet.  I am not sure which boot block
> > to use.  What's the difference in biosboot, dosboot, kzipboot, rawboot? 
> > Also what about the files in /usr/mdec/ bootfd, fdboot, bootwd, wdboot,
> > boot1, boot2, rawboot? 
> 
> * biosboot: uses BIOS services to find proper disk/partition, and uses its
> own knowledge of FFS to get kernel from there,
> * rawboot: as above, but doesn't understand FFS. All it knows is to pull
> the chain of next data blocks from the media it was started from
> * dosboot: EXE program, which can load FreeBSD kernel either from DOS
> partition or from FFS
> * kzipboot: it's a special stub which gets appended and prepended to
> kzipp'ed kernel in order to unpack it after loading. (see kzip(8)).
> 
> And the files:
> * bootfd, fdboot, bootwd, wdboot - links to so called 'stage 1 boot', i.e.
> the stub that pulls the data from media.
> * boot2 - the stub that actually loads the kernel (i.e. properly relocates
> appropriate sections of a.out binary file, and passes control to it).
> 
> > I am not sure what to modify in your scripts to put the right boot block info.
> > Could you show me what I need to change?
> 
> What really matters here is the 'dd if=/usr/mdec/boot1' line in 'stage3'
> script. It uses biosboot stub. In order to use rawboot you'd say something
> like:
> 	cat /usr/mdec/rawboot kernel.kz >/dev/rvn0c
> Of course, you loose the FFS now - the media it will be booting from can
> be accessed only as raw data blocks...

I will try using the rawboot, since I do not need FFS.  Technically I do not 
have access to FFS anyway as explained above, since I am using software BIOS 
flash drive.

> > Also once I have built the picobsd image how do I transfer that to the flash 
> > drive?  I need some kind of utility to transfer an image file to flash?
> 
> If you have the flash connected to FreeBSD machine, it should be detected
> during bootup (see 'dmesg') as one more IDE disk. Then you access it in
> quite normal way, i.e. /dev/rwdX. As for transfering the files... simply
> do dd if=you_file of=/dev/rwdX - it should work.

As explained above I do not have hardware IDE compatibility with this flash.  So 
I still need to figure out once I have the kernel and MFS built.  How to 
transfer that to the flash drive?  I need some kind of program that 
can transfer an image to the flash drive using BIOS-INT 13H calls.

I also need to figure out from what source will I get the image from.  I have 
only a floppy drive attached to the PC/104 board.  I can only boot from floppy 
since I do not have anything in flash drive yet.  So I probably need a DOS boot 
floppy with a image writer program and the picobsd image.

> > Can I have picobsd boot from a DOS partition using fbsdboot.exe ?
> 
> I think - yes. I didn't try it yet...
> 
> > Do I need to make the picobsd image differently for booting from a DOS 
> > partition using fbsdboot.exe?
> 
> In normal case of GENERIC kernel, it can be booted right from DOS
> partition. To be frank, I've never tried this... But I will. I plan to try
> to create something like bootable FreeBSD image which could be put on DOS
> partition, and be started from there... but it's still in plans only...

This would be an alternative.  Since I can format the flash drive as a 
bootable DOS FAT partition.  And put the fbsdboot.exe and a bootable kernel 
image in it.  And then boot DOS and have autoexec.bat execute fbsdboot.exe on 
startup. 

> > The IDE emulation is in hardware.  So it is register level compatible. 
> > The IDE flash looks like a wd hard drive to the kernel.  With this IDE
> > emulation we can have a FFS filesystem in flash just like a standard
> > hard drive. 
> 
> Yep. But as I said above, in most cases (except for development and
> debugging, and just to get the project started :-) you don't want to have
> FFS there - it wastes too much space. The target situation (IMHO) should
> be to live without FFS, and use raw pieces of flash for kernel and config
> data.
> 
> Andrzej Bialecki
> 

NOTE: FYI, "FFS" acronyms is used in two ways.
In FreeBSD FFS stands for Fast File System.
In the PC/104 industry FFS stands for Flash File System.
It can get confusing at times... :)

Randal Masutani

-------------------------------------------------------------------------
ComTest Technologies, Inc.
3049 Ualena St., Suite 1005
Honolulu, Hawaii  96819

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-small" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805222203.MAA07511>