[fdutils] Putting FDC into FM mode?
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.
>> 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.
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
Well in hindsight, there were no new commands since then, so this
point is somewhat moot...
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
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
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.
fdutils mailing list
fdutils at tux.org
More information about the Fdutils