> Does anyone have an idea for the "right way" for performing a call
> ("shock, horror") to the mainboard BIOS?
I might not of made it clear why I want to do this in the first place. As the
current maintainer of the ZIP drive I often have email saying that the linux ZIP
driver is broken as it works at least twice as fast under "other GUI operating
systems".
The problem revolves around the fact that for parallel ports EPP mode is the
fastest mode for disk like devices while ECP is designed for printers and
scanners. However due to the market dominance of a particular operating
system which originally specified the ECP protocol most machines default to
this mode. Several hardware vendors are shipping machines with BIOS which
only allows selection of SPP (nibble mode read parallel ports) and ECP
modes. The machine at the chipset level can in fact support EPP (DELL
desktops are a classic, model series can be supplied on request).
The commercial drivers supplied with the ZIP drive include code which
scratches around in bowels of the machine and changes the parallel port
mode. I have already coded a small program to change the parallel port
mode for National Semiconductor chipsets except that it causes the BIOS
on Toshiba laptops to print out wierd and wonderful messages
(reading/writing from 0x2e causes this, we think it is the BIOS since we can
not find the message anywhere in the Linux kernel source, nor does it
appear in the output from dmesg).
While flicking through the IEEE1284 standard, I noticed the EPP BIOS
specification in one of the appendices. This would be a nice way to be able
to change the parallel port mode on any machine cleanly without poking
around and performing strange rituals (disable IRQs, write twice to the same
port then read IMMEDIATELY from another port, enable IRQs).
Just a quick summary of what I have found to date:
a) Alan Cox stated that it would only be possible during start up, this is
because in real mode the BIOS could walk all over the DMA, IRQ
controller (etc) causing all sorts of grief. (*agree*)
b) The EPP bios extension is not as common as first thought
(The int 17h does not return a proper entry point on the machines I have
tested so far) This does not mean I have written it off just yet...
c) Further reading of the spec indicates that the bios entry is protected
mode (i386 kernel mode) safe providing I do not try to read/change the
parallel port mode. Presumably the BIOS needs to perform IO access
which under protected mode could cause an exception (dependent on
processor flags). This hints that calling the routine from protected mode
may be possible (under certain circumstances).
d) Both APM and PCI bios calls from Linux are performed in protected mode
(the APM code has some real paranoia traps around it for buggy BIOS,
IMHO is a good thing).
Thanks for all the comments.
David Campbell
=======================================================
campbell@torque.net
Current project list:
a) Maintain Linux ZIP drivers
b) Create Linux chipset specific parport drivers
c) Start on ParSCSI drivers
Any assistance to clearing this list most welcome
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/