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

==> specifies a nine sector fm format

It's not real permanent, but lasts until the next disk change.

b) do this temporarily for a per-command basis?

I suspect that b) *might* be possible via a raw command, but the man page for fdrawcmd doesn't seem to mention being able to change the density bit (bit 6 of the first byte in the command).

You can also add the fm parameter to fdrawcmd:

fdrawcmd readid 0 fm

This issues the readid command in fm mode.

Regards,

Alain _______________________________________________ fdutils mailing list fdutils@tux.org http://www.tux.org/mailman/listinfo/fdutils

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 ftp://download.intel.com/design/archives/periphrl/docs/29046803.pdf (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 + parameters). 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 command.

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 together

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

Regards,

Alain _______________________________________________ fdutils mailing list fdutils@tux.org http://www.tux.org/mailman/listinfo/fdutils