[ KURIMS | WWWFun | JG ]

FreeBSD hacking

As a FreeBSD user, I sometimes encounter situations where I need to hack my way around a problem here are some hints, patches and software that may be useful to others.

FreeBSD 4.5 on the Casio FIVA MPC-206VL FIVA

As noted by others, while the FIVA is a very nice machine, it has some quirks.

Partitioning and reinstalling windows

The first problem comes with making a partition for FreeBSD. In its original configuration, the FIVA comes with 2 partitions, a big one for Windows ME, and a very small one for a custom installation of Linux. That one is too small to install a real OS, but tools like fips will fail due to the presence of a Partition Boot Record at the head of the windows partition, which confuses them.

The only solution seems then fdisk and reinstall. If you don't have a bootable CD-Rom drive, but just a bootable USB floppy drive (most will do, I used one from Panasonic), you can still do it by first installing FreeBSD, and then copying the cabs to the Windows partition.

The overall process of installation is then

  1. Create all necessary floppies. That is FreeBSD boot floppies, and a Windows boot floppy containing fdisk and format.
  2. Either with the windows floopy or with the freebsd installer, cut 3 partitions: one for Windows, one for FreeBSD, and one for hibernation (partition ID is 160).
  3. Format the windows partition from the windows boot floppy, installing the system (format /s).
  4. Install FreeBSD.
  5. Inside FreeBSD, find a way to mount the Windows ME CD-ROM, and copy the contents of \WINDOWS\OPTIONS\CABS to the same location on the windows partition.
  6. Boot from the windows partition, and run the setup program in \WINDOW\OPTIONS\CABS.
  7. After installing windows, you can also get additional drivers and applications from the FIVA specific CD. Refer to the manual.
  8. Using the phdisk.exe utility, format the hibernation partition (needed by FreeBSD).
  9. Since Windows kindly deletes FreeBSD's MBR, boot once more from FreeBSD's boot floppy, and start a custom installation: ask for a new MBR, but do not give any mount point in the partition editor! When you commit, the installer will complain about not being able to install anything, but thankfully it will have installed the MBR. (I wish there were an easier way to do that.)

Configuring FreeBSD

Now, the serious part: making FreeBSD comfortable. The two difficulties are making PCMCIA work, and making APM work. The first one is easy: you just need to add the following two lines to /boot/loader.conf. 
hw.pcic.init_routing=1
hw.pcic.intr_path=1
This is enough for the main PCMCIA port, but you will not be able to use the flash card port until you remove sio1 from the kernel (there is an IRQ conflict). Here is my kernel configuration file: TET. It just excludes from GENERIC most of the things I do not use.

For APM, you need to apply a patch to the kernel. Here is the original version by Iwasaki-san, and here is the same patch for 4.5-RELEASE: fiva-apm-4.5R.diffs. You also need to patch the ata driver to slow down DMA: fiva-ata-dma-4.5R.diffs.

Kernel compilation is as usual: 

# cd /sys/i386/conf
# config TET
# cd ../../compile/TET
# make kernel-depend && make kernel
# make kernel-install
After adding the following two lines to rc.conf, you should be able to reboot into a pleasant environement. 
pccard_enable="YES"
apm_enable="YES"
In my experience, everything works fine, except some (apparently specific) problems using ppp on pccard modems (silo overflows are slowing throughput). Note also that the internal modem cannot be used: there is no driver, not even proprietary ones for Linux.

Making the hard disk quiet

This is not specific of the FIVA, but recent IBM hard drives have this clever design of parking the head as soon as possible (after about 10 seconds of inactivity). But since FreeBSD accesses the disk about once every minute, this just results in a sequence of clicks every minute.

One first approach is of course to add the "noatime" option to most filesystems (in particular to /). However, you may also want to delay access on write. For instance gnome has this strange behaviour of saving the panel settings every few seconds... On Linux, and old versions of FreeBSD, the solution was easy: increase intervals of the update daemon. But FreeBSD's update thread is continuous: there is no such notion of interval.

Here is a patch introduce such a notion.

For 4.5-RELEASE:
asyncdelay-vfs_subr-4.5R.diffs.
For 5.0-DP1:
asyncdelay-vfs_subr-5.0-DP1.diffs.
It adds a kern.asyncdelay variable to the kernel, which you can set with sysctl, and allows you to delay all writes to the disk for some amount of time (in seconds). Of course this only applies to asynchronous writes, so you should enable soft-updates on the interested partitions.

After recompiling your kernel, add the following line to /etc/sysctl.conf: 

kern.asyncdelay=900
This will make synchronization periods occur every 15 minutes. You can look were you are in the cycle with sysctl kern.asynccount. Calling sync immediately starts a new cycle.

I have been using this patch for about 6 months, without corruption occuring. On some occasions sync failedbefore reboot fails, and fsck was required. This seems to be only a problem with old metadata not being deleted, and fsck can correct it without data loss, but you're warned. Of course, the spirit of the patch itself means that you may lose up to 15 minutes of work, but hopefully it should not corrupt your data.
YET, I DO NOT ENDORSE ANY RESPONSIBILITY ABOUT THE CONSEQUENCES OF USING THIS PATCH.

Adding the following line to /etc/rc.shutdown, and using shutdown rather than reboot should avoid the problem. I avoided fsck for months. 

sysctl kern.asyncdelay=0
sync
This disables the feature, and returns to normal FreeBSD behaviour. There is a slight difference in behaviour between the 4.5R version and the 5.0 version. For the former, a cycle lasts asyncdelay seconds, meaning that nothing happens if asyncdelay <= syncdelay, while for the latter it lasts asyncdelay + syncdelay seconds, asynccount being negative during the synchronization periods.

JG 2002.04.24