Transferring an image to flash

There are many ways to transfer your image into your flash:

Use an EPROM burner that supports your socketed flash.
Use a flash burner that supports onboard flash via a special bus, such as JTAG.
Use a low-level monitor or a BIOS page with a flash burn command.
Use the flash filesystem raw mountpoints.

The details on how to transfer the image with anything other than the last method is beyond the scope of this document. Using the raw mountpoint is a convenient way that comes bundled with your flash filesystem library. You can actually read and write raw partitions just like regular files, except that when the raw mountpoint is involved, remember to:

go down one level in the abstraction ladder
perform the erase commands yourself.

For the sake of this discussion, we can use the devf-ram driver. This driver simulates flash using regular memory. To start it, log in as root and type:

# devf-ram &

You can use the flashctl command to erase a partition. You don't need to be root to do this. For instance:

$ flashctl -p /dev/fs0 -e

CAUTION:

Be careful when you use this command. Make sure you aren't erasing something important on your flash — like your BIOS!

On normal flash, the flashctl command on a raw partition should take a while (about one second for each erase block). This command erases the /dev/fs0 raw flash array. Try the hd command on this newly erased flash array; everything should be 0xFF:

$ hd /dev/fs0
0000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
*

Note: For more information on flashctl, see the Utilities Reference.

Let's make a dummy IPL for the purpose of this example:

$ echo Hello, World! > ipl
$ mkrec -s 128k -f full ipl > ipl_image
Reset jmps to 0x1FFE0 (jmp 0xFFED)
ROM offset is 0x1FFE0

Of course, this IPL won't work for real — it's just for trying out the flash filesystem. In any event, an IPL wouldn't be very useful in RAM. Let's make a dummy flash filesystem for the purpose of this example (the ^D means Ctrl–D):

$ mkefs -v - flash_image
[block_size=128k spare_blocks=1 min_size=384k]
/bin/ls
/bin/cat
^D
writing directory entry ->
writing file entry      -> ls **
writing file entry      -> cat *
Filesystem size = 384K
block size = 128K
1 spare block(s)

This flash filesystem actually works (unlike the IPL). Now, the flash partition images can be transferred to the flash using any file-transfer utility (such as cp or ftp). We have an IPL image created with mkrec (and properly padded to an erase block boundary) and a flash image created with mkefs, so we can use cat to combine and transfer both images to the flash:

$ cat ipl_image flash_image > /dev/fs0

If you use the hd utility on the raw mountpoint again, you'll see that your flash that had initially all bits set to ones (0xFF) now contains your partition images. To use the flash filesystem partition, you need to slay the driver and start it again so it can recognize the partitions and mount them. For instance, with devf-ram:

$ slay devf-ram
$ devf-ram &

From this point, you have a /fs0p1 mountpoint that's in fact a directory and contains the files you specified with mkefs to create your flash image. There's no /fs0p0, because the boot image isn't recognized by the flash filesystem. It's still accessible as a raw mountpoint via /dev/fs0p0. You can do the same operations on /dev/fs0p0 that you could do with /dev/fs0. Even /dev/fs0p1 is accessible, but be careful not to write to this partition while applications are using the flash filesystem at /fs0p1. Try:

$ /fs0p1/ls /fs0p1

You've just executed ls from your flash filesystem and you've listed its contents. To conclude, let's say that what we did in this example is a good starting point for when you customize the flash filesystem to your own platforms. These baby steps should be the first steps to using a full-blown filesystem on your target.