Hi,
Does anybody know why we reserve this range of IO ports for 'fpu'?
AFAIK from all the IO maps I can find on the internet for various x86
chipsets only 0x00f0 is actaully ever used.
./arch/i386/kernel/setup.c
282 }, {
283 .name = "fpu",
284 .start = 0x00f0,
285 .end = 0x00ff,
286 .flags = IORESOURCE_BUSY | IORESOURCE_IO
287 } };
The reason I ask is that I've written a watchdog driver for a Nexcom
MAX6600 server blade type device which has the watchdog control
register at 0xF2. Currently request_region fails due to the fpu
reservation.
regards,
Pete Fordham
Hi Peter,
> Does anybody know why we reserve this range of IO ports for 'fpu'?
> AFAIK from all the IO maps I can find on the internet for various x86
> chipsets only 0x00f0 is actaully ever used.
There are two ports used: 0xf0 is the busy latch reset and 0xf1 is the
coprocessor reset. They are legacy ports resulting from the interesting
way the FPU has been wired by IBM in their PC design. None of them is
used by Linux for i486 and newer systems, which can support the FPU in its
native configuration.
> ./arch/i386/kernel/setup.c
> 282 }, {
> 283 .name = "fpu",
> 284 .start = 0x00f0,
> 285 .end = 0x00ff,
> 286 .flags = IORESOURCE_BUSY | IORESOURCE_IO
> 287 } };
The reason is most likely the definition of the address decoder for the
chip-select for this range in the IBM PC -- like with all motherboard port
I/O peripherals the smallest size of the chunk the decoder resolved to was
16 bytes, with unused locations aliasing to defined ones.
> The reason I ask is that I've written a watchdog driver for a Nexcom
> MAX6600 server blade type device which has the watchdog control
> register at 0xF2. Currently request_region fails due to the fpu
> reservation.
Reservations for some of the legacy ranges have been shrunk in the past;
perhaps this one could too. I hope you have a way to make sure not to
interact badly with the FPU possibly being decoded there on other systems
-- the original registers are write-only.
Maciej
"Maciej W. Rozycki" <[email protected]> writes:
> Hi Peter,
>
> > Does anybody know why we reserve this range of IO ports for 'fpu'?
> > AFAIK from all the IO maps I can find on the internet for various x86
> > chipsets only 0x00f0 is actaully ever used.
>
> There are two ports used: 0xf0 is the busy latch reset and 0xf1 is the
> coprocessor reset. They are legacy ports resulting from the interesting
> way the FPU has been wired by IBM in their PC design.
Was it really needed on 386s? I didn't think there was a IBM 386 PC.
> None of them is
> used by Linux for i486 and newer systems, which can support the FPU in its
> native configuration.
I can remove it from x86-64 at least.
-Andi
On Fri, 21 Sep 2007, Andi Kleen wrote:
> > There are two ports used: 0xf0 is the busy latch reset and 0xf1 is the
> > coprocessor reset. They are legacy ports resulting from the interesting
> > way the FPU has been wired by IBM in their PC design.
>
> Was it really needed on 386s? I didn't think there was a IBM 386 PC.
That comes back from the 80286-based original PC/AT and was carried over
to the 80386 by cloners (and then the i486 and further by Intel itself,
forced by the market).
A way to reset the FPU was required by the 80287 part when switching back
from the protected mode similarly to the 80286. Like the CPU which had no
way to clear the MSW.PE bit in software (obscure stuff of LOADALL aside;
;-) and LMSW carried it over to the 80386 and further for compatibility),
the FPU had no counterpart to the FSETPM instruction that was used to
switch to the different internal address format used by the FPU in the
protected mode (FRSTPM was only introduced to a newer 287 variation, long
after the original PC/AT). Note that the 80287 can be used in conjunction
with the 80386, so some of this black magic may even apply to Linux.
The busy latch had to be used (and cleared explicitly) because of the
violation of the FPU exception signalling protocol as the PC/AT
incorrectly wired the FPU error output line to IRQ 13 rather than the CPU
error input. This was done because IBM reused the interrupt vector range
reserved by Intel for exception handling for hardware interrupts and (in
this case) some of their BIOS calls. Unfortunately, in their infinite
wisdom, the responsible people in IBM provided no way to switch exception
signalling in the PC/AT to the native mode (for use in the protected mode
if nothing else). This, too, was carried over to the 80386 and only
sorted out by the CR0.NE bit in the i486.
For the curious the details of all the hassle are reasonably well
described in the Intel's AP-578 application note.
Maciej
> For the curious the details of all the hassle are reasonably well
> described in the Intel's AP-578 application note.
Thanks. Ok it has to stay for for i386 then; although it would be in theory
possible to only reserve when the CPU is a real 386. For x86-64 it's
gone now.
-Andi
On Fri, 21 Sep 2007, Andi Kleen wrote:
> > For the curious the details of all the hassle are reasonably well
> > described in the Intel's AP-578 application note.
>
> Thanks. Ok it has to stay for for i386 then; although it would be in theory
> possible to only reserve when the CPU is a real 386. For x86-64 it's
> gone now.
For anything newer the latch is still there in the chipset; most likely
in the south bridge and probably actively decoded (irrespective of the
architecture of the bit behind the north bridge) though it may be possible
to disable it in a chip-specific manner. If there is no south bridge in a
given system, then it is probably safe not to claim the port.
Maciej
Andi Kleen wrote:
> "Maciej W. Rozycki" <[email protected]> writes:
>
>> Hi Peter,
>>
>>> Does anybody know why we reserve this range of IO ports for 'fpu'?
>>> AFAIK from all the IO maps I can find on the internet for various x86
>>> chipsets only 0x00f0 is actaully ever used.
>> There are two ports used: 0xf0 is the busy latch reset and 0xf1 is the
>> coprocessor reset. They are legacy ports resulting from the interesting
>> way the FPU has been wired by IBM in their PC design.
>
> Was it really needed on 386s? I didn't think there was a IBM 386 PC.
There were 386 PC clones for sure, and they almost certainly needed it
and still do. IBM was doing the MCA thing at that time and it was a
wonderful time for the clone makers.
>
>> None of them is
>> used by Linux for i486 and newer systems, which can support the FPU in its
>> native configuration.
>
> I can remove it from x86-64 at least.
>
AFAIK you are just right, I'm pretty sure there will be systems needing
it for 386 and 486, and maybe the old Pentium systems as well. A lot of
system vendors wanted it so software for the old systems would still work.
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot