[fdutils] Putting FDC into FM mode?

Alain Knaff alain at knaff.lu
Sat Jan 7 23:44:15 CET 2006

Jules Richardson wrote:
> Alain Knaff wrote:
>> Jules Richardson wrote:
>>> (Note that this question is only relevant for well designed clones of 
>>> the NEC and Intel chips - lots of broken clones don't support FM mode 
>>> at all...)
>>> Is it possible from user-space to either:
>>> a) put the linux floppy driver permanently into FM recording mode for 
>>> all subsequent requests, or
>> Using setfdprm, you can add the "fm" options to instruct the driver 
>> that the current disk should be accessed in FM mode.
>> Example
>> setfdprm /dev/fd0 sect=9 fm=1
> aha - thanks - I'd missed the 'fm' parameter when looking at the source.

It's fm_mode in fdrawcmd.c

> Does anyone know if there's documentation anywhere covering how the 
> kernel floppy driver works? I really need to access floppy data at the 
> sector level - in other words, send a true raw command to the FDC chip 
> (command byte plus several bytes of parameters).

There is fdutils doc and mailing list archives at the fdutils site. 
Intel doc about the FDC (which contains the explanation of the command 
bytes) may be found at 
(until they move it again...)

> It's unclear to me at the moment whether I can actually do this with the 
> standard Linux floppy driver - the 'floppy_raw_cmd' structure holds 16 
> bytes for the command, but it's not obvious at the moment whether this 
> is actually for a single command byte + parameters, or whether it's just 
> for specifying multiple commands within one command structure.

Each instance of floppy_raw_cmd holds a single command (command byte + 
If you want to chain multiple commands, you make an array of 
floppy_raw_cmd structures, and set the FD_RAW_MORE flag on each one, 
except the last.

> If it *is* for command byte + parameters, then the 'flags' field seems a 
> little redundant.

There are several types of flags.

Protocol flags:

   These are flags that specify that specify some aspect of the
   communication protocol (data, interrupts) to be used with the

   FD_RAW_INTR: if set, the CPU will be notified by an interrupt, rather
   than get an immediate result.

   FD_RAW_READ/FD_RAW_WRITE: if set, the command involves data
   (typically, sector contents) in addition to the parameters. Data is
   handled differently than command parameters, it is transmitted over
   a different "channel", so to speak.

   Theoretically, these could be inferred from the command byte (a seek
   command always has FD_RAW_INTR, a read command has always
   FD_RAW_READ|FD_RAW_INTR, etc.). However, such reasoning would only
   work for *known* command bytes, and back in the time when I first
   wrote the rawcmd interface, I intended it to be as generic and
   "future-proof" as possible.
   If later FDC chips would have added new commands, they would be usable
   immediately without changing the driver: the application
   (fdrawcmd) can tell the kernel what data transfer and interrupt the
   (new) command involves, and this info doesn't need to be hardcoded in
   the driver.
   Well in hindsight, there were no new commands since then, so this
   point is somewhat moot...

Syntactic sugar:
   The purpose of these is just to make the FDRAWCMD API more pleasant to
   use, they don't add any functionality that wouldn't otherwise
   exist. They are indeed redundant:
    FD_RAW_NEED_SEEK: seek to a certain track before the main command is
    issued (works by internally prepending a seek command before the
    command supplied by the user)
    FD_RAW_NEED_DISK: check whether a disk is present

Chaining commands:
   As mentioned, the FD_RAW_MORE flag is used to chain raw commands

 > If it's just for chaining commands, then why also have
 > the 'next' pointer there in the structure? Unfortunately the comments
 > don't say one way or the other!

The 'next' pointer is only for use in-kernel. It is indeed used for 
chaining (in-kernel). During copy-in the application's _array_ of raw 
commands is converted to a linked list.

> I've got a horrible feeling I'll need to write my own kernel floppy 
> driver, as the kernel's idea of what a 'raw' command is will turn out to 
> be at a higher level than actually sending raw data to the FDC chip...

I'm not sure how much more low-level than FD_RAWCMD you want to get... 
If you just want to read/write sectors of some non-standard format, the 
FD_RAWMCD API is suitable enough. And in most cases, you won't even need 
that: many formats can be read using FDSETPRM followed by normal Unix 
read/write commands.

If you need something more than just reading data (... or if you intend 
to access some really *special* format...) please tell us what it is, 
and maybe we can help.

> cheers
> Jules


fdutils mailing list
fdutils at tux.org

More information about the Fdutils mailing list