fpu IO port reservation (arch/i386)

fpu IO port reservation (arch/i386)

[Peter Fordham]

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

Re: fpu IO port reservation (arch/i386)

[Maciej W. Rozycki]

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

Re: fpu IO port reservation (arch/i386)

[Andi Kleen]

"Maciej W. Rozycki" <macro@linux-mips.org> 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

Re: fpu IO port reservation (arch/i386)

[Maciej W. Rozycki]

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

Re: fpu IO port reservation (arch/i386)

[Andi Kleen]

>  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

Re: fpu IO port reservation (arch/i386)

[Maciej W. Rozycki]

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

Re: fpu IO port reservation (arch/i386)

[Bill Davidsen]

Andi Kleen wrote:
> "Maciej W. Rozycki" <macro@linux-mips.org> 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 <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot