Re: IO delay, port 0x80, and BIOS POST codes

Re: IO delay, port 0x80, and BIOS POST codes

[Gerald Champagne]

 > If we put every single requested obscure fix for one or two boxes into
 > the kernel configuration you'd be spending weeks wading through
 >
 > "Handle weird APM on Dave's homebrew mediagx"
 >
 > and other questions.
 >

A config option that lets you pick the address for the dummy io would
be a pretty obscure option.  But having a CONFIG_POST_SUPPORT buried
somewhere wouldn't be that obscure or confusing.  If that config
option is set, then a second question would prompt for an alternate
address to be used for the delay io, and a macro would be defined to
display post codes.  If the option is unset, then 0x80 would be the
default for the delay address, and the post code macro would be defined
to do nothing.

Gerald

Re: IO delay, port 0x80, and BIOS POST codes

[Thunder from the hill]

Martin Wilck wrote:
> Thunder from the hill wrote:
> > Maybe add a config option?
> It doesn't even have to be a config option - a line
> in a header file would perfectly suffice.
So guys who don't have an idea of it won't find it. Good idea!

> Martin
Thunder
-- 
begin-base64 755 -
IyEgL3Vzci9iaW4vcGVybApteSAgICAgJHNheWluZyA9CSMgVGhlIHNjcmlw
dCBvbiB0aGUgbGVmdCBpcyB0aGUgcHJvb2YKIk5lbmEgaXN0IGVpbiIgLgkj
IHRoYXQgaXQgaXNuJ3QgYWxsIHRoZSB3YXkgaXQgc2VlbXMKIiB2ZXJhbHRl
dGVyICIgLgkjIHRvIGJlIChlc3BlY2lhbGx5IG5vdCB3aXRoIG1lKQoiTkRX
LVN0YXIuXG4iICA7CiRzYXlpbmcgPX4Kcy9ORFctU3Rhci9rYW5uXAogdW5z
IHJldHRlbi9nICA7CiRzYXlpbmcgICAgICAgPX4Kcy92ZXJhbHRldGVyL2Rp
XAplIExpZWJlL2c7CiRzYXlpbmcgPX5zL2Vpbi8KbnVyL2c7JHNheWluZyA9
fgpzL2lzdC9zYWd0LC9nICA7CiRzYXlpbmc9fnMvXG4vL2cKO3ByaW50Zigk
c2F5aW5nKQo7cHJpbnRmKCJcbiIpOwo=
====
Extract this and see what will happen if you execute my
signature. Just save it to file and do a
> uudecode $file | perl

Re: IO delay, port 0x80, and BIOS POST codes

[Andi Kleen]

Martin Wilck <Martin.Wilck@fujitsu-siemens.com> writes:

> On Thu, 14 Mar 2002, Thunder from the hill wrote:
> 
> > I also remember this been discussed anually. Making it configurable with
> > a warning might be a solution, but that's nothing we could decide. Maybe
> > add a config option? It night be a [DANGEROUS] one, so the guys and gals
> > who might compile are warned of changing this.
> 
> It doesn't even have to be a config option - a line
> 
> /* Port used for dummy writes for I/O delays */
> /* Change this only if you know what you're doing ! */
> #define DUMMY_IO_PORT 0x80
> 
> in a header file would perfectly suffice.

That effectively already exists. You just need to change the __SLOW_DOWN_IO
macro in include/asm-i387/io.h

-Andi

Re: IO delay, port 0x80, and BIOS POST codes

[Martin Wilck]

On 15 Mar 2002, Andi Kleen wrote:

> > It doesn't even have to be a config option - a line
> >
> > /* Port used for dummy writes for I/O delays */
> > /* Change this only if you know what you're doing ! */
> > #define DUMMY_IO_PORT 0x80
> >
> > in a header file would perfectly suffice.
>
> That effectively already exists. You just need to change the __SLOW_DOWN_IO
> macro in include/asm-i387/io.h

No, that doesn't cover all accesses to port 80. I am still searching.

-- 
Martin Wilck                Phone: +49 5251 8 15113
Fujitsu Siemens Computers   Fax:   +49 5251 8 20409
Heinz-Nixdorf-Ring 1	    mailto:Martin.Wilck@Fujitsu-Siemens.com
D-33106 Paderborn           http://www.fujitsu-siemens.com/primergy

Re: IO delay, port 0x80, and BIOS POST codes

[Andi Kleen]

On Fri, Mar 15, 2002 at 01:47:39PM +0100, Martin Wilck wrote:
> On 15 Mar 2002, Andi Kleen wrote:
> 
> > > It doesn't even have to be a config option - a line
> > >
> > > /* Port used for dummy writes for I/O delays */
> > > /* Change this only if you know what you're doing ! */
> > > #define DUMMY_IO_PORT 0x80
> > >
> > > in a header file would perfectly suffice.
> >
> > That effectively already exists. You just need to change the __SLOW_DOWN_IO
> > macro in include/asm-i387/io.h
> 
> No, that doesn't cover all accesses to port 80. I am still searching.

It should. I would consider all other accesses a bug.
It is possible that some driver used it for private debugging and left it in by 
mistake. These should be removed.

-Andi

Re: IO delay, port 0x80, and BIOS POST codes

[Thunder from the hill]

Richard B. Johnson wrote:

> On Thu, 14 Mar 2002, Martin Wilck wrote:
> 
> 
> >Hello,
> >
> >the BIOS on our machines (Phoenix) uses IO-port 0x80 for storing
> >POST codes, not only during sytem startup, but also for messages
> >generated during SMM (system management mode) operation.
> >I have been told other BIOSs do the same.
> >
> >Unfortunately we can't read this information because Linux uses
> >port 80 as "dummy" port for delay operations. (outb_p and friends,
> >actually there seem to be a more hard-coded references to port
> >0x80 in the code).
> >
> >It seems this problem was always there, just nobody took notice of it yet
> >(at least in our company). Sometimes people wondered about the weird POST
> >codes displayed in the LCD panel, but who cares once the machine is up...
> >
> >Would it be too outrageous to ask that this port number be changed, or
> >made configurable?
> >
> >Martin
> 
> This is a 'N' year-old question. Do you know of a port that is
> guaranteed to exist on the Intel/PC/AT class machine? If so, submit
> a patch.  I proposed using 0x19h (DMA scratch register) several
> years ago, but it was shot down for some reason. Then I proposed
> 0x42 (PIT Misc register), that too was declared off-limits. So
> I suggested that the outb to 0x80 be changed to an inp, saving 
> %eax on the stack first. That too was shot down. So, you try
> something... and good luck.
I also remember this been discussed anually. Making it configurable with
a warning might be a solution, but that's nothing we could decide. Maybe
add a config option? It night be a [DANGEROUS] one, so the guys and gals
who might compile are warned of changing this.
I think the problem is that on PC arch anything is quite limited.

Thunder

Re: IO delay, port 0x80, and BIOS POST codes

[Martin Wilck]

On Thu, 14 Mar 2002, Thunder from the hill wrote:

> I also remember this been discussed anually. Making it configurable with
> a warning might be a solution, but that's nothing we could decide. Maybe
> add a config option? It night be a [DANGEROUS] one, so the guys and gals
> who might compile are warned of changing this.

It doesn't even have to be a config option - a line

/* Port used for dummy writes for I/O delays */
/* Change this only if you know what you're doing ! */
#define DUMMY_IO_PORT 0x80

in a header file would perfectly suffice.

Martin

-- 
Martin Wilck                Phone: +49 5251 8 15113
Fujitsu Siemens Computers   Fax:   +49 5251 8 20409
Heinz-Nixdorf-Ring 1	    mailto:Martin.Wilck@Fujitsu-Siemens.com
D-33106 Paderborn           http://www.fujitsu-siemens.com/primergy

IO delay, port 0x80, and BIOS POST codes

[Martin Wilck]

Hello,

the BIOS on our machines (Phoenix) uses IO-port 0x80 for storing
POST codes, not only during sytem startup, but also for messages
generated during SMM (system management mode) operation.
I have been told other BIOSs do the same.

Unfortunately we can't read this information because Linux uses
port 80 as "dummy" port for delay operations. (outb_p and friends,
actually there seem to be a more hard-coded references to port
0x80 in the code).

It seems this problem was always there, just nobody took notice of it yet
(at least in our company). Sometimes people wondered about the weird POST
codes displayed in the LCD panel, but who cares once the machine is up...

Would it be too outrageous to ask that this port number be changed, or
made configurable?

Martin

-- 
Martin Wilck                Phone: +49 5251 8 15113
Fujitsu Siemens Computers   Fax:   +49 5251 8 20409
Heinz-Nixdorf-Ring 1	    mailto:Martin.Wilck@Fujitsu-Siemens.com
D-33106 Paderborn           http://www.fujitsu-siemens.com/primergy

Re: IO delay, port 0x80, and BIOS POST codes

[Richard B. Johnson]

On Thu, 14 Mar 2002, Martin Wilck wrote:

> 
> Hello,
> 
> the BIOS on our machines (Phoenix) uses IO-port 0x80 for storing
> POST codes, not only during sytem startup, but also for messages
> generated during SMM (system management mode) operation.
> I have been told other BIOSs do the same.
> 
> Unfortunately we can't read this information because Linux uses
> port 80 as "dummy" port for delay operations. (outb_p and friends,
> actually there seem to be a more hard-coded references to port
> 0x80 in the code).
> 
> It seems this problem was always there, just nobody took notice of it yet
> (at least in our company). Sometimes people wondered about the weird POST
> codes displayed in the LCD panel, but who cares once the machine is up...
> 
> Would it be too outrageous to ask that this port number be changed, or
> made configurable?
> 
> Martin

This is a 'N' year-old question. Do you know of a port that is
guaranteed to exist on the Intel/PC/AT class machine? If so, submit
a patch.  I proposed using 0x19h (DMA scratch register) several
years ago, but it was shot down for some reason. Then I proposed
0x42 (PIT Misc register), that too was declared off-limits. So
I suggested that the outb to 0x80 be changed to an inp, saving 
%eax on the stack first. That too was shot down. So, you try
something... and good luck.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.

Re: IO delay, port 0x80, and BIOS POST codes

[Alan Cox]

> Unfortunately we can't read this information because Linux uses
> port 80 as "dummy" port for delay operations. (outb_p and friends,
> actually there seem to be a more hard-coded references to port
> 0x80 in the code).

The dummy port needs to exist. By using 0x80 we have probably the only
port we can safely use in this way. We know it fouls old style POST 
boards on odd occasions.

Alan

Re: IO delay, port 0x80, and BIOS POST codes

[Linus Torvalds]

In article <E16lZg3-0001Ug-00@the-village.bc.nu>,
Alan Cox  <alan@lxorguk.ukuu.org.uk> wrote:
>> Unfortunately we can't read this information because Linux uses
>> port 80 as "dummy" port for delay operations. (outb_p and friends,
>> actually there seem to be a more hard-coded references to port
>> 0x80 in the code).
>
>The dummy port needs to exist. By using 0x80 we have probably the only
>port we can safely use in this way. We know it fouls old style POST 
>boards on odd occasions.

In fact, port 0x80 is safe exactly _because_ it is used for BIOS POST
codes, which pretty much guarantees that it will never be used for
anything else. That tends to not be as true of any other ports.

Also, it should be noted that to get the 1us delay, the port should be
behind the ISA bridge in a legacy world (in a modern all-PCI system it
doesn't really matter, because the ports that need more delays are
faster too, so this works out ok).  That's why I personally would be
nervous about using some of the well-specified (but irrelevant) ports
that are on the PCI side of a super-IO controller. 

I suspect the _real_ solution is to stop using "inb_p/outb_p" and make
the delay explicit, although it may be that some drivers depend on the
fact that not only is the "outb $0x80" a delay, it also tends to act as
a posting barrier.

			Linus

Re: IO delay, port 0x80, and BIOS POST codes

[H. Peter Anvin]

Followup to:  <a6qtb8$6fg$1@penguin.transmeta.com>
By author:    torvalds@transmeta.com (Linus Torvalds)
In newsgroup: linux.dev.kernel
> 
> I suspect the _real_ solution is to stop using "inb_p/outb_p" and make
> the delay explicit, although it may be that some drivers depend on the
> fact that not only is the "outb $0x80" a delay, it also tends to act as
> a posting barrier.
> 

... as well as a push-out to the ISA bus.  I suspect dumping the outb
way of doing it and instead wait in the CPU might cause the delay to
happen in the wrong part of the system (consider split-transaction
queued busses like HyperTransport, where a delay in the CPU doesn't
necessarily mean a delay in the southbridge.)

Port 0x80 has served us well, at least as a default.  If you really
care about the POST display you can recompile using a different port.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: IO delay, port 0x80, and BIOS POST codes

[John Heil]

On Thu, 14 Mar 2002, Linus Torvalds wrote:

> Date: Thu, 14 Mar 2002 19:23:20 +0000 (UTC)
> From: Linus Torvalds <torvalds@transmeta.com>
> To: linux-kernel@vger.kernel.org
> Subject: Re: IO delay, port 0x80, and BIOS POST codes
>
> In article <E16lZg3-0001Ug-00@the-village.bc.nu>,
> Alan Cox  <alan@lxorguk.ukuu.org.uk> wrote:
> >> Unfortunately we can't read this information because Linux uses
> >> port 80 as "dummy" port for delay operations. (outb_p and friends,
> >> actually there seem to be a more hard-coded references to port
> >> 0x80 in the code).
> >
> >The dummy port needs to exist. By using 0x80 we have probably the only
> >port we can safely use in this way. We know it fouls old style POST
> >boards on odd occasions.
>
> In fact, port 0x80 is safe exactly _because_ it is used for BIOS POST
> codes, which pretty much guarantees that it will never be used for
> anything else. That tends to not be as true of any other ports.
>
> Also, it should be noted that to get the 1us delay, the port should be
> behind the ISA bridge in a legacy world (in a modern all-PCI system it
> doesn't really matter, because the ports that need more delays are
> faster too, so this works out ok).  That's why I personally would be
> nervous about using some of the well-specified (but irrelevant) ports
> that are on the PCI side of a super-IO controller.
>
> I suspect the _real_ solution is to stop using "inb_p/outb_p" and make
> the delay explicit, although it may be that some drivers depend on the
> fact that not only is the "outb $0x80" a delay, it also tends to act as
> a posting barrier.
>
> 			Linus

No, the better/correct port is 0xED which removes the conflict.

We've used 0xED w/o problem doing an embedded linux implementation
at kernel 2.4.1, where SMM issues were involved. (It was recommended
to me by an x-Phoenix BIOS developer, because of its safety as well as
conflict resolution,

Johnh

-
-----------------------------------------------------------------
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
johnhscs@sc-software.com
http://www.sc-software.com
-----------------------------------------------------------------

Re: IO delay, port 0x80, and BIOS POST codes

[Richard B. Johnson]

On Thu, 14 Mar 2002, John Heil wrote:

> On Thu, 14 Mar 2002, Linus Torvalds wrote:
> 
> > Date: Thu, 14 Mar 2002 19:23:20 +0000 (UTC)
> > From: Linus Torvalds <torvalds@transmeta.com>
> > To: linux-kernel@vger.kernel.org
> > Subject: Re: IO delay, port 0x80, and BIOS POST codes
> >
> > In article <E16lZg3-0001Ug-00@the-village.bc.nu>,
> > Alan Cox  <alan@lxorguk.ukuu.org.uk> wrote:
> > >> Unfortunately we can't read this information because Linux uses
> > >> port 80 as "dummy" port for delay operations. (outb_p and friends,
> > >> actually there seem to be a more hard-coded references to port
> > >> 0x80 in the code).
> > >
> > >The dummy port needs to exist. By using 0x80 we have probably the only
> > >port we can safely use in this way. We know it fouls old style POST
> > >boards on odd occasions.
> >
> > In fact, port 0x80 is safe exactly _because_ it is used for BIOS POST
> > codes, which pretty much guarantees that it will never be used for
> > anything else. That tends to not be as true of any other ports.
> >
> > Also, it should be noted that to get the 1us delay, the port should be
> > behind the ISA bridge in a legacy world (in a modern all-PCI system it
> > doesn't really matter, because the ports that need more delays are
> > faster too, so this works out ok).  That's why I personally would be
> > nervous about using some of the well-specified (but irrelevant) ports
> > that are on the PCI side of a super-IO controller.
> >
> > I suspect the _real_ solution is to stop using "inb_p/outb_p" and make
> > the delay explicit, although it may be that some drivers depend on the
> > fact that not only is the "outb $0x80" a delay, it also tends to act as
> > a posting barrier.
> >
> > 			Linus
> 
> No, the better/correct port is 0xED which removes the conflict.
> 
> We've used 0xED w/o problem doing an embedded linux implementation
> at kernel 2.4.1, where SMM issues were involved. (It was recommended
> to me by an x-Phoenix BIOS developer, because of its safety as well as
> conflict resolution,
> 
> Johnh
> 

Well I can see why he's an EX-Phoenix BIOS developer. A port at 0xed
does not exist on any standard or known non-standard Intel/PC/AT 
compatible.

Remember DOS debug?

C:\>debug

-i ed
FF
-o ed aa
-i ed
FF
-o ed 55
-i ed
FF
-q
\x1a

This is not a DOS emulation. This is a real-mode boot where any ports
will be visible. If you used it with success, it means that you didn't
need the I/O delay of writing to a real port. Instead you got the
few hundred nanoseconds of delay you get by writing to nowhere.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.

Re: IO delay, port 0x80, and BIOS POST codes

[Pedro M. Rodrigues]

   This piece of code is taken from an old Minix source code tree, the file being 
boothead.s . Notice the port 0xED usage and the comment.


! Enable (ah = 0xDF) or disable (ah = 0xDD) the A20 address line.
gate_A20:
        call    kb_wait
        movb    al, #0xD1       ! Tell keyboard that a command is coming
        outb    0x64
        call    kb_wait
        movb    al, ah          ! Enable or disable code
        outb    0x60
        call    kb_wait


        mov     ax, #25         ! 25 microsec delay for slow keyboard chip
0:      out     0xED            ! Write to an unused port (1us)
        dec     ax
        jne     0b

        ret
kb_wait:
        inb     0x64
        testb   al, #0x02       ! Keyboard input buffer full?
        jnz     kb_wait         ! If so, wait
        ret



/Pedro

On 14 Mar 2002 at 16:03, Richard B. Johnson wrote:

> 
> 
> Well I can see why he's an EX-Phoenix BIOS developer. A port at 0xed
> does not exist on any standard or known non-standard Intel/PC/AT
> compatible.
> 
> Remember DOS debug?
> 
> C:\>debug
> 
> -i ed
> FF
> -o ed aa
> -i ed
> FF
> -o ed 55
> -i ed
> FF
> -q
> 
> 
> This is not a DOS emulation. This is a real-mode boot where any ports
> will be visible. If you used it with success, it means that you didn't
> need the I/O delay of writing to a real port. Instead you got the few
> hundred nanoseconds of delay you get by writing to nowhere.
> 
> Cheers,
> Dick Johnson

Re: IO delay, port 0x80, and BIOS POST codes

[John Heil]

On Thu, 14 Mar 2002, Pedro M. Rodrigues wrote:

> Date: Thu, 14 Mar 2002 22:19:23 +0100
> From: Pedro M. Rodrigues <pmanuel@myrealbox.com>
> To: John Heil <kerndev@sc-software.com>, root@chaos.analogic.com
> Cc: Linus Torvalds <torvalds@transmeta.com>, linux-kernel@vger.kernel.org,
>      Martin Wilck <Martin.Wilck@fujitsu-siemens.com>
> Subject: Re: IO delay, port 0x80, and BIOS POST codes
>
>
>    This piece of code is taken from an old Minix source code tree, the file being
> boothead.s . Notice the port 0xED usage and the comment.
>
>
> ! Enable (ah = 0xDF) or disable (ah = 0xDD) the A20 address line.
> gate_A20:
>         call    kb_wait
>         movb    al, #0xD1       ! Tell keyboard that a command is coming
>         outb    0x64
>         call    kb_wait
>         movb    al, ah          ! Enable or disable code
>         outb    0x60
>         call    kb_wait
>
>
>         mov     ax, #25         ! 25 microsec delay for slow keyboard chip
> 0:      out     0xED            ! Write to an unused port (1us)
>         dec     ax
>         jne     0b
>
>         ret
> kb_wait:
>         inb     0x64
>         testb   al, #0x02       ! Keyboard input buffer full?
>         jnz     kb_wait         ! If so, wait
>         ret
>
>
>
> /Pedro
>
> On 14 Mar 2002 at 16:03, Richard B. Johnson wrote:
>
> >
> >
> > Well I can see why he's an EX-Phoenix BIOS developer. A port at 0xed
> > does not exist on any standard or known non-standard Intel/PC/AT
> > compatible.
> >
> > Remember DOS debug?
> >
> > C:\>debug
> >
> > -i ed
> > FF
> > -o ed aa
> > -i ed
> > FF
> > -o ed 55
> > -i ed
> > FF
> > -q
> >
> >
> > This is not a DOS emulation. This is a real-mode boot where any ports
> > will be visible. If you used it with success, it means that you didn't
> > need the I/O delay of writing to a real port. Instead you got the few
> > hundred nanoseconds of delay you get by writing to nowhere.
> >
> > Cheers,
> > Dick Johnson
>
>

We did not want the I/O delay based on the port itself.
We specifically wanted an unused port, and avoid the 0x80 conflict.

Perhaps this should be a kernel hacking/debug option, due to the
difference in environments and needs.


Johnh

-
-----------------------------------------------------------------
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
johnhscs@sc-software.com
http://www.sc-software.com
-----------------------------------------------------------------

Re: IO delay, port 0x80, and BIOS POST codes

[Richard B. Johnson]

On Thu, 14 Mar 2002, Pedro M. Rodrigues wrote:

> 
>    This piece of code is taken from an old Minix source code tree, the file being 
> boothead.s . Notice the port 0xED usage and the comment.
> 
> 
> ! Enable (ah = 0xDF) or disable (ah = 0xDD) the A20 address line.
> gate_A20:
>         call    kb_wait
>         movb    al, #0xD1       ! Tell keyboard that a command is coming
>         outb    0x64
>         call    kb_wait
>         movb    al, ah          ! Enable or disable code
>         outb    0x60
>         call    kb_wait
> 
> 
>         mov     ax, #25         ! 25 microsec delay for slow keyboard chip
> 0:      out     0xED            ! Write to an unused port (1us)
>         dec     ax
>         jne     0b
> 
>         ret
> kb_wait:
>         inb     0x64
>         testb   al, #0x02       ! Keyboard input buffer full?
>         jnz     kb_wait         ! If so, wait
>         ret
> 
> 
> 
> /Pedro
> 

Well I see the comment. Writing to IO Space where there are no devices
is basically a no-op. The ISA/PC/AT bus is asynchronous, it is not
clocked. If there's is no contention due to bus activity from some
hardware read, it's just some address lines and data bits that are
eventually sinked by the bus capacity. The CPU isn't forced to wait
for anything. Since it's in I/O space, you don't even get the delay
from a cache-line reload. No thanks, it's bogus as a delay mechanism.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.

Re: IO delay, port 0x80, and BIOS POST codes

[Linus Torvalds]

On Thu, 14 Mar 2002, Richard B. Johnson wrote:
> 
> Well I can see why he's an EX-Phoenix BIOS developer. A port at 0xed
> does not exist on any standard or known non-standard Intel/PC/AT 
> compatible.

Note that "doesn't exist" is actually a _bonus_. It means that no 
controller will answer to it, which causes the IO to time out, which on a 
regular ISA bus will also take the same 1us. Which is what we want.

Real ports with real controllers can be faster - they could, for example,
be fast motherboard PCI ports and be positively decoded and be faster than
1us.

		Linus

Re: IO delay, port 0x80, and BIOS POST codes

[Richard B. Johnson]

On Thu, 14 Mar 2002, Linus Torvalds wrote:

> 
> On Thu, 14 Mar 2002, Richard B. Johnson wrote:
> > 
> > Well I can see why he's an EX-Phoenix BIOS developer. A port at 0xed
> > does not exist on any standard or known non-standard Intel/PC/AT 
> > compatible.
> 
> Note that "doesn't exist" is actually a _bonus_. It means that no 
> controller will answer to it, which causes the IO to time out, which on a 
> regular ISA bus will also take the same 1us. Which is what we want.
> 
> Real ports with real controllers can be faster - they could, for example,
> be fast motherboard PCI ports and be positively decoded and be faster than
> 1us.
> 
> 		Linus
> 

Well no, IO doesn't "time-out". The PC/AT/ISA bus is asychronous, it's
not clocked. If there's no hardware activity as a result of the write
to nowhere, it's just a no-op. The CPU isn't slowed down at all. It's
just some bits that got flung out on the bus with no feed-back at all.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.

Re: IO delay, port 0x80, and BIOS POST codes

[H. Peter Anvin]

Followup to:  <Pine.LNX.3.95.1020314164142.382B-100000@chaos.analogic.com>
By author:    "Richard B. Johnson" <root@chaos.analogic.com>
In newsgroup: linux.dev.kernel
> 
> Well no, IO doesn't "time-out". The PC/AT/ISA bus is asychronous, it's
> not clocked. If there's no hardware activity as a result of the write
> to nowhere, it's just a no-op. The CPU isn't slowed down at all. It's
> just some bits that got flung out on the bus with no feed-back at all.
> 

An OUT on the x86 architecture is synchronous... the CPU will not
proceed until the OUT is present on the bus.  This is a requirement of
the SMM architecture, actually.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: IO delay, port 0x80, and BIOS POST codes

[Richard B. Johnson]

On 14 Mar 2002, H. Peter Anvin wrote:

> Followup to:  <Pine.LNX.3.95.1020314164142.382B-100000@chaos.analogic.com>
> By author:    "Richard B. Johnson" <root@chaos.analogic.com>
> In newsgroup: linux.dev.kernel
> > 
> > Well no, IO doesn't "time-out". The PC/AT/ISA bus is asychronous, it's
> > not clocked. If there's no hardware activity as a result of the write
> > to nowhere, it's just a no-op. The CPU isn't slowed down at all. It's
> > just some bits that got flung out on the bus with no feed-back at all.
> > 
> 
> An OUT on the x86 architecture is synchronous... the CPU will not
> proceed until the OUT is present on the bus.  This is a requirement of
> the SMM architecture, actually.
> 
> 	-hpa

Yeh?  Then "how do it know?". It doesn't. I/O instructions are ordered,
however, that's all. There is no bus-interface state machine that exists
except on the addressed device. The CPU driven interface device just
makes sure that the data is valid before the address and I/O-read or
I/O-write are valid after this. The address is decoded by the device
and is used to enable the device. It either puts its data onto the
bus in the case of a read, or gets data off the bus, in the case of
a write. The interface timing is specified and is handled by hardware.
In the meantime the CPU has not waited because there is nothing to
wait for. On a READ, if the device cannot put its data on the bus
fast enough, it puts its finger io IO-chan-ready. This forces the
CPU (through its bus-interface) to wait.

Writes to nowhere are just that, writes to nowhere.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.

Re: IO delay, port 0x80, and BIOS POST codes

[H. Peter Anvin]

Richard B. Johnson wrote:

> 
> Yeh?  Then "how do it know?". It doesn't. I/O instructions are ordered,
> however, that's all. There is no bus-interface state machine that exists
> except on the addressed device. The CPU driven interface device just
> makes sure that the data is valid before the address and I/O-read or
> I/O-write are valid after this. The address is decoded by the device
> and is used to enable the device. It either puts its data onto the
> bus in the case of a read, or gets data off the bus, in the case of
> a write. The interface timing is specified and is handled by hardware.
> In the meantime the CPU has not waited because there is nothing to
> wait for. On a READ, if the device cannot put its data on the bus
> fast enough, it puts its finger io IO-chan-ready. This forces the
> CPU (through its bus-interface) to wait.
> 
> Writes to nowhere are just that, writes to nowhere.
> 


On the ISA bus, yes.  The PCI and front side busses will be held in wait 
until the transaction is completed.

The exact requirement is a bit more complicated, something along the 
lines of "an SMI triggered in response to an OUT will be taken before 
the OUT is retired."

	-hpa

Re: IO delay, port 0x80, and BIOS POST codes

[Richard B. Johnson]

On Thu, 14 Mar 2002, H. Peter Anvin wrote:

> Richard B. Johnson wrote:
> 
> > 
> > Yeh?  Then "how do it know?". It doesn't. I/O instructions are ordered,
> > however, that's all. There is no bus-interface state machine that exists
> > except on the addressed device. The CPU driven interface device just
> > makes sure that the data is valid before the address and I/O-read or
> > I/O-write are valid after this. The address is decoded by the device
> > and is used to enable the device. It either puts its data onto the
> > bus in the case of a read, or gets data off the bus, in the case of
> > a write. The interface timing is specified and is handled by hardware.
> > In the meantime the CPU has not waited because there is nothing to
> > wait for. On a READ, if the device cannot put its data on the bus
> > fast enough, it puts its finger io IO-chan-ready. This forces the
> > CPU (through its bus-interface) to wait.
> > 
> > Writes to nowhere are just that, writes to nowhere.
> > 
> 
> 
> On the ISA bus, yes.  The PCI and front side busses will be held in wait 
> until the transaction is completed.
> 
> The exact requirement is a bit more complicated, something along the 
> lines of "an SMI triggered in response to an OUT will be taken before 
> the OUT is retired."
> 

Correct! The PCI is very much different, I'm glad, and hopefully nobody
will be using that for deliberate waits.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.

Re: IO delay, port 0x80, and BIOS POST codes

[Alan Cox]

> Correct! The PCI is very much different, I'm glad, and hopefully nobody
> will be using that for deliberate waits.

On the x86 platform the PCI bridges make PCI out instructions synchronous.
Lots of driver code relies on this and people handling ports to non x86
where the odd bridge doesn't do this have had some real fun.

PCI mmio writes are however (even on the good old x86 platform) async

Alan

Re: IO delay, port 0x80, and BIOS POST codes

[Alan Cox]

> Yeh?  Then "how do it know?". It doesn't. I/O instructions are ordered,
> however, that's all. There is no bus-interface state machine that exists

How about because
	o	The intel docs say out is synchronizing
	o	HPA works for an x86 clone manufacturer

Alan

Re: IO delay, port 0x80, and BIOS POST codes

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.33.0203141234170.1286-100000@scsoftware.sc-software.com>
By author:    John Heil <kerndev@sc-software.com>
In newsgroup: linux.dev.kernel
> 
> No, the better/correct port is 0xED which removes the conflict.
> 
> We've used 0xED w/o problem doing an embedded linux implementation
> at kernel 2.4.1, where SMM issues were involved. (It was recommended
> to me by an x-Phoenix BIOS developer, because of its safety as well as
> conflict resolution,
> 

Sorry, causes breakage on quite a few machines.  I used it briefly in
SYSLINUX.  Phoenix doesn't have that issue since they're part of the
platform, so they can make it a requirement for their BIOS.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: IO delay, port 0x80, and BIOS POST codes

[Linus Torvalds]

On Thu, 14 Mar 2002, John Heil wrote:
> 
> No, the better/correct port is 0xED which removes the conflict.

Port ED is fine for a BIOS, which (by definition) knows what the
motherboard devices are, and thus knows that ED cannot be used by
anything.

But it _is_ an unused port, and that's exactly the kind of thing that
might be used sometime in the future. Remember the port 22/23 brouhaha
with Cyrix using it for their stuff, and later Intel getting into the fray
too?

So the fact that ED works doesn't mean that _stays_ working.

The fact that 80 is the post code register means that it is fairly likely 
to _stay_ that way, without any ugly surprises.

Now, if there is something _else_ than just the fact that it is unused
that makes ED a good choice in the future too, that might be worth looking
into (like NT using it for the same purpose as Linux does port 80),

		Linus

Re: IO delay, port 0x80, and BIOS POST codes

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.33.0203141318130.9855-100000@penguin.transmeta.com>
By author:    Linus Torvalds <torvalds@transmeta.com>
In newsgroup: linux.dev.kernel
> 
> Port ED is fine for a BIOS, which (by definition) knows what the
> motherboard devices are, and thus knows that ED cannot be used by
> anything.
> 
> But it _is_ an unused port, and that's exactly the kind of thing that
> might be used sometime in the future. Remember the port 22/23 brouhaha
> with Cyrix using it for their stuff, and later Intel getting into the fray
> too?
> 
> So the fact that ED works doesn't mean that _stays_ working.
> 

It is, in fact, broken on several systems -- I tried ED in SYSLINUX
for a while, and it broke things for people.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: IO delay, port 0x80, and BIOS POST codes

[John Heil]

On 14 Mar 2002, H. Peter Anvin wrote:

> Date: 14 Mar 2002 13:57:40 -0800
> From: H. Peter Anvin <hpa@zytor.com>
> To: linux-kernel@vger.kernel.org
> Subject: Re: IO delay, port 0x80, and BIOS POST codes
>
> Followup to:  <Pine.LNX.4.33.0203141318130.9855-100000@penguin.transmeta.com>
> By author:    Linus Torvalds <torvalds@transmeta.com>
> In newsgroup: linux.dev.kernel
> >
> > Port ED is fine for a BIOS, which (by definition) knows what the
> > motherboard devices are, and thus knows that ED cannot be used by
> > anything.
> >
> > But it _is_ an unused port, and that's exactly the kind of thing that
> > might be used sometime in the future. Remember the port 22/23 brouhaha
> > with Cyrix using it for their stuff, and later Intel getting into the fray
> > too?
> >
> > So the fact that ED works doesn't mean that _stays_ working.
> >
>
> It is, in fact, broken on several systems -- I tried ED in SYSLINUX
> for a while, and it broke things for people.

It does work on many, in fact, we used on a Crusoe based platform
as well as the other x86s

Let's make it a configurable kernel debug/hacking option else
we have the added burden of chasing down a common address.

Johnh

>
> 	-hpa
> --
> <hpa@transmeta.com> at work, <hpa@zytor.com> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
> http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-
-----------------------------------------------------------------
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
johnhscs@sc-software.com
http://www.sc-software.com
-----------------------------------------------------------------

Re: IO delay, port 0x80, and BIOS POST codes

[Alan Cox]

> > It is, in fact, broken on several systems -- I tried ED in SYSLINUX
> > for a while, and it broke things for people.
> 
> It does work on many, in fact, we used on a Crusoe based platform
> as well as the other x86s
> 
> Let's make it a configurable kernel debug/hacking option else
> we have the added burden of chasing down a common address.

We've got one. Its 0x80. It works everywhere with only marginal non
problematic side effects

Re: IO delay, port 0x80, and BIOS POST codes

[John Heil]

On Thu, 14 Mar 2002, Alan Cox wrote:

> Date: Thu, 14 Mar 2002 22:55:45 +0000 (GMT)
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> To: John Heil <kerndev@sc-software.com>
> Cc: H. Peter Anvin <hpa@zytor.com>, linux-kernel@vger.kernel.org
> Subject: Re: IO delay, port 0x80, and BIOS POST codes
>
> > > It is, in fact, broken on several systems -- I tried ED in SYSLINUX
> > > for a while, and it broke things for people.
> >
> > It does work on many, in fact, we used on a Crusoe based platform
> > as well as the other x86s
> >
> > Let's make it a configurable kernel debug/hacking option else
> > we have the added burden of chasing down a common address.
>
> We've got one. Its 0x80. It works everywhere with only marginal non
> problematic side effects
>

Ok, cool but does that mean you agree or disagree with a configurable
override for those of us in the minority?

Johnh

-
-----------------------------------------------------------------
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
johnhscs@sc-software.com
http://www.sc-software.com
-----------------------------------------------------------------

Re: IO delay, port 0x80, and BIOS POST codes

[Alan Cox]

> > We've got one. Its 0x80. It works everywhere with only marginal non
> > problematic side effects
> >
> 
> Ok, cool but does that mean you agree or disagree with a configurable
> override for those of us in the minority?

If we put every single requested obscure fix for one or two boxes into
the kernel configuration you'd be spending weeks wading through

"Handle weird APM on Dave's homebrew mediagx"

and other questions.

Let me suggest something else. For any kernel built with TSC assumed
(586TSC +) initialize the udelay loop to something guaranteed to be at
least too long for any conceivable processor and use udelay() for the I/O
delay timing.

Alan

Re: IO delay, port 0x80, and BIOS POST codes

[David Golden]

On Thursday 14 March 2002 22:55, Alan Cox wrote:
>
> We've got one. Its 0x80. It works everywhere with only marginal non
> problematic side effects

I've always liked POST cards.  They could hypothetically be useful
for kernel development,too  - who hasn't wanted a low-level 
single-asm-instruction status output from a running system at one time or 
another , independent of any other output mechanisms?

OK it's a single byte, but it's still nice...  That's two whole hex digits!
DE... AD...  BE... EF... !

Re: IO delay, port 0x80, and BIOS POST codes

[John Heil]

On Fri, 15 Mar 2002, David Golden wrote:

> Date: Fri, 15 Mar 2002 00:12:42 +0000
> From: David Golden <david.golden@oceanfree.net>
> To: linux-kernel@vger.kernel.org
> Subject: Re: IO delay, port 0x80, and BIOS POST codes
>
> On Thursday 14 March 2002 22:55, Alan Cox wrote:
> >
> > We've got one. Its 0x80. It works everywhere with only marginal non
> > problematic side effects
>
> I've always liked POST cards.  They could hypothetically be useful
> for kernel development,too  - who hasn't wanted a low-level
> single-asm-instruction status output from a running system at one time or
> another , independent of any other output mechanisms?
>
> OK it's a single byte, but it's still nice...  That's two whole hex digits!
> DE... AD...  BE... EF... !

Any number of consecutive bits and a target I/O address can be very
useful.

I do it regularly for embedded kernel hacking... harmless I/O, picked up
by your logic analyzer.

Only drawback is it adds pathlength which can impact realtime if you get
excessive.

Johnh

> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-
-----------------------------------------------------------------
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
johnhscs@sc-software.com
http://www.sc-software.com
-----------------------------------------------------------------

Re: IO delay, port 0x80, and BIOS POST codes

[Pavel Machek]

Hi!
> > We've got one. Its 0x80. It works everywhere with only marginal non
> > problematic side effects
> 
> I've always liked POST cards.  They could hypothetically be useful
> for kernel development,too  - who hasn't wanted a low-level 
> single-asm-instruction status output from a running system at one time or 
> another , independent of any other output mechanisms?
> 
> OK it's a single byte, but it's still nice...  That's two whole hex digits!
> DE... AD...  BE... EF... !

Use 0x378 for that, works equally well.
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: IO delay, port 0x80, and BIOS POST codes

[Eric W. Biederman]

Linus Torvalds <torvalds@transmeta.com> writes:

> On Thu, 14 Mar 2002, John Heil wrote:
> > 
> > No, the better/correct port is 0xED which removes the conflict.
> 
> Port ED is fine for a BIOS, which (by definition) knows what the
> motherboard devices are, and thus knows that ED cannot be used by
> anything.
> 
> But it _is_ an unused port, and that's exactly the kind of thing that
> might be used sometime in the future. Remember the port 22/23 brouhaha
> with Cyrix using it for their stuff, and later Intel getting into the fray
> too?
> 
> So the fact that ED works doesn't mean that _stays_ working.
> 
> The fact that 80 is the post code register means that it is fairly likely 
> to _stay_ that way, without any ugly surprises.
> 
> Now, if there is something _else_ than just the fact that it is unused
> that makes ED a good choice in the future too, that might be worth looking
> into (like NT using it for the same purpose as Linux does port 80),

Does the logic outb_p uses continue to work if you have a PCI post
card (possibly on the motherboard).  And an ISA device?

Systems without ISA slots but with ISA or LPC devices onboard must
use a PCI post card so I have trouble believing that outb_b and friends
really work as expected....


Eric