Linux Post codes during runtime, possibly OT

Linux Post codes during runtime, possibly OT

[Ian S. Nelson]

I'm curious.  Why does Linux make that friendly 98/9a/88 looking
postcode pattern when it's running?  DOS and DOS95 don't do that.

I'm begining to feel like I can tell the system health by observing it,
kind of like "seeing the matrix."

Ian

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

Re: Linux Post codes during runtime, possibly OT

[H. Peter Anvin]

Followup to:  <3A709E99.25ADE5F6@echostar.com>
By author:    "Ian S. Nelson" <ian.nelson@echostar.com>
In newsgroup: linux.dev.kernel
>
> I'm curious.  Why does Linux make that friendly 98/9a/88 looking
> postcode pattern when it's running?  DOS and DOS95 don't do that.
> 
> I'm begining to feel like I can tell the system health by observing it,
> kind of like "seeing the matrix."
> 

It output garbage to the 80h port in order to enforce I/O delays.
It's one of the safe ports to issue outs to.

	-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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux Post codes during runtime, possibly OT

[Matthew Dharm]

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

It occurs to me that it might be a good idea to pick a different port for
these things.  I know a lot of people who want to use port 80h for
debugging data, especially in embedded x86 systems.

Matt

On Thu, Jan 25, 2001 at 02:26:36PM -0800, H. Peter Anvin wrote:
> Followup to:  <3A709E99.25ADE5F6@echostar.com>
> By author:    "Ian S. Nelson" <ian.nelson@echostar.com>
> In newsgroup: linux.dev.kernel
> >
> > I'm curious.  Why does Linux make that friendly 98/9a/88 looking
> > postcode pattern when it's running?  DOS and DOS95 don't do that.
> > 
> > I'm begining to feel like I can tell the system health by observing it,
> > kind of like "seeing the matrix."
> > 
> 
> It output garbage to the 80h port in order to enforce I/O delays.
> It's one of the safe ports to issue outs to.
> 
> 	-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
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

I say, what are all those naked people doing?
					-- Big client to Stef
User Friendly, 12/14/1997

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Linux Post codes during runtime, possibly OT

[H. Peter Anvin]

Matthew Dharm wrote:
> 
> It occurs to me that it might be a good idea to pick a different port for
> these things.  I know a lot of people who want to use port 80h for
> debugging data, especially in embedded x86 systems.
> 

Find a safe port, make sure it is tested the hell out of, and we'll
consider it.

	-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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux Post codes during runtime, possibly OT

[Matthew Dharm]

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

Isn't that always the way in the Open Source world? :)

Seriously, tho... does anyone have some list of who is using what ports?
At least, in general?

Matt

On Thu, Jan 25, 2001 at 02:32:41PM -0800, H. Peter Anvin wrote:
> Matthew Dharm wrote:
> > 
> > It occurs to me that it might be a good idea to pick a different port for
> > these things.  I know a lot of people who want to use port 80h for
> > debugging data, especially in embedded x86 systems.
> > 
> 
> Find a safe port, make sure it is tested the hell out of, and we'll
> consider it.
> 
> 	-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

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

P:  How about "Web Designer"?
DP: I'd like a name that people won't laugh at.
					-- Pitr and Dust Puppy
User Friendly, 12/6/1997

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Linux Post codes during runtime, possibly OT

[H. Peter Anvin]

Matthew Dharm wrote:
> 
> Isn't that always the way in the Open Source world? :)
> 
> Seriously, tho... does anyone have some list of who is using what ports?
> At least, in general?
> 

There is one included in Ralf Brown's Interrupt List.  No list you're
going to find is going to be complete, though.

	-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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux Post codes during runtime, possibly OT

[Richard B. Johnson]

On Thu, 25 Jan 2001, H. Peter Anvin wrote:

> Matthew Dharm wrote:
> > 
> > It occurs to me that it might be a good idea to pick a different port for
> > these things.  I know a lot of people who want to use port 80h for
> > debugging data, especially in embedded x86 systems.
> > 
> 
> Find a safe port, make sure it is tested the hell out of, and we'll
> consider it.
> 
> 	-hpa
> 

You could use the DMA scratch register at 0x19. I'm sure Linux doesn't
"save" stuff there when setting up the DMA controller.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


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

Re: Linux Post codes during runtime, possibly OT

[H. Peter Anvin]

"Richard B. Johnson" wrote:
> 
> On Thu, 25 Jan 2001, H. Peter Anvin wrote:
> 
> > Matthew Dharm wrote:
> > >
> > > It occurs to me that it might be a good idea to pick a different port for
> > > these things.  I know a lot of people who want to use port 80h for
> > > debugging data, especially in embedded x86 systems.
> > >
> >
> > Find a safe port, make sure it is tested the hell out of, and we'll
> > consider it.
> >
> >       -hpa
> >
> 
> You could use the DMA scratch register at 0x19. I'm sure Linux doesn't
> "save" stuff there when setting up the DMA controller.
> 

Does that break the BIOS in any way, shape, or form?  Again, someone gets
to make a patch and then test the hell out of it... and find the random
Olivetti which hooks the screen up to the A20M# signal and other weird
crap.

	-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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux Post codes during runtime, possibly OT

[Richard B. Johnson]

On Thu, 25 Jan 2001, H. Peter Anvin wrote:

> "Richard B. Johnson" wrote:
> > 
> > On Thu, 25 Jan 2001, H. Peter Anvin wrote:
> > 
> > > Matthew Dharm wrote:
> > > >
> > > > It occurs to me that it might be a good idea to pick a different port for
> > > > these things.  I know a lot of people who want to use port 80h for
> > > > debugging data, especially in embedded x86 systems.
> > > >
> > >
> > > Find a safe port, make sure it is tested the hell out of, and we'll
> > > consider it.
> > >
> > >       -hpa
> > >
> > 
> > You could use the DMA scratch register at 0x19. I'm sure Linux doesn't
> > "save" stuff there when setting up the DMA controller.
> > 
> 
> Does that break the BIOS in any way, shape, or form?  Again, someone gets
> to make a patch and then test the hell out of it... and find the random
> Olivetti which hooks the screen up to the A20M# signal and other weird
> crap.
> 
> 	-hpa
> 

I will change the port on my machines and run them for a week. I
don't have any DEC Rainbows or other such. Yes, I know Linux will
not run on a '286.

Since 0x19 is a hardware register in a DMA controller, specifically
called a "scratch" register, it is unlikely to hurt anything. Note
that the BIOS saves stuff in CMOS. It never expects hardware registers
to survive a "warm boot". It even checks in CMOS to see if it should
preserve RAM.



Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


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

Re: Linux Post codes during runtime, possibly OT

[Richard B. Johnson]

On Fri, 26 Jan 2001, Petr Vandrovec wrote:

> On 26 Jan 01 at 8:58, Richard B. Johnson wrote:
> > On Thu, 25 Jan 2001, H. Peter Anvin wrote:
> > > > You could use the DMA scratch register at 0x19. I'm sure Linux doesn't
> > > > "save" stuff there when setting up the DMA controller.
> > > > 
> > I will change the port on my machines and run them for a week. I
> > don't have any DEC Rainbows or other such. Yes, I know Linux will
> > not run on a '286.
> > 
> > Since 0x19 is a hardware register in a DMA controller, specifically
> > called a "scratch" register, it is unlikely to hurt anything. Note
> > that the BIOS saves stuff in CMOS. It never expects hardware registers
> > to survive a "warm boot". It even checks in CMOS to see if it should
> > preserve RAM.
> 
> Unless there are chips which need DELAY between accesses to DMA 
> controller ;-) And I'm sure there are such. Also, if DMA controller
> is integrated on board, outb is done in different speed than ISA 
> forwarded cycle to postcode port.
> 
> Just in case, on my VIA, 1e6 outb(0,0x80) tooks 2.07s, 1e6 outb(0,0x19)
> tooks 2.33s - so there is definitely difference - although in other 
> direction than I expected. (What you can expect from this ....)
>                                             Petr Vandrovec
>                                             vandrove@vc.cvut.cz

Each board has its own implimentation. This is what bothers Peter and
others. Embedded chip-sets don't do ISA bus-cycles. Some DMA controllers
now are accessed through a PCI/ISA bridge. Some are not, etc. Even
if you try to use a "spare" port existing in a Super I/O chip, this
if it exists at all, will run at a different speed than the old
board-mounted MFG port (where POST codes are written).

So. Here's stuff to test with.  The only thing on most machines that
actually uses the DMA controller is the floppy disk. I have done the
following.

(1)	Made a Linux floppy boot disk.
(2)	Did the following RAW copy:
	cp /dev/fd0 /tmp/foo
	cp /tmp/foo /dev/fd0
... A script that does this ten times.

Then I booted the machine from the floppy. It works okay. From this
I deduce that using the DMA scratch register doesn't hurt anything.

Here is a patch to try:




--- linux-2.4.0/include/asm/floppy.h.orig	Fri Jan 26 09:03:40 2001
+++ linux-2.4.0/include/asm/floppy.h	Fri Jan 26 09:05:50 2001
@@ -20,6 +20,9 @@
  * Went back to the 1MB limit, as some people had problems with the floppy
  * driver otherwise. It doesn't matter much for performance anyway, as most
  * floppy accesses go through the track buffer.
+ *
+ * Changed slow-down I/O port from 0x80 to 0x19.   rjohnson@analogic.com
+ *
  */
 #define _CROSS_64KB(a,s,vdma) \
 (!vdma && ((unsigned long)(a)/K_64 != ((unsigned long)(a) + (s) - 1) / K_64))
@@ -90,7 +93,7 @@
 4:     	movb (%2),%0
 	outb %b0,%w4
 5:	decw %w4
-	outb %0,$0x80
+	outb %0,$0x19
 	decl %1
 	incl %2
 	testl %1,%1
--- linux-2.4.0/include/asm/io.h.orig	Fri Jan 26 08:59:53 2001
+++ linux-2.4.0/include/asm/io.h	Fri Jan 26 09:06:21 2001
@@ -32,12 +32,15 @@
   *  isa_memset_io, isa_memcpy_fromio, isa_memcpy_toio added,
   *  isa_read[wl] and isa_write[wl] fixed
   *  - Arnaldo Carvalho de Melo <acme@conectiva.com.br>
+  *
+  *  Changed the slow-down I/O port from 0x80 to 0x19. 0x19 is a
+  *  DMA controller scratch register.  rjohnson@analogic.com
   */
 
 #ifdef SLOW_IO_BY_JUMPING
 #define __SLOW_DOWN_IO "\njmp 1f\n1:\tjmp 1f\n1:"
 #else
-#define __SLOW_DOWN_IO "\noutb %%al,$0x80"
+#define __SLOW_DOWN_IO "\noutb %%al,$0x19"
 #endif
 
 #ifdef REALLY_SLOW_IO






Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


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

Re: Linux Post codes during runtime, possibly OT

[Mark Hahn]

>  #ifdef SLOW_IO_BY_JUMPING
>  #define __SLOW_DOWN_IO "\njmp 1f\n1:\tjmp 1f\n1:"
>  #else
> -#define __SLOW_DOWN_IO "\noutb %%al,$0x80"
> +#define __SLOW_DOWN_IO "\noutb %%al,$0x19"

this is nutty: why can't udelay be used here?  empirical measurements
in the thread show the delay is O(2us).

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

Re: Linux Post codes during runtime, possibly OT

[Jamie Lokier]

Mark Hahn wrote:
> >  #ifdef SLOW_IO_BY_JUMPING
> >  #define __SLOW_DOWN_IO "\njmp 1f\n1:\tjmp 1f\n1:"
> >  #else
> > -#define __SLOW_DOWN_IO "\noutb %%al,$0x80"
> > +#define __SLOW_DOWN_IO "\noutb %%al,$0x19"
> 
> this is nutty: why can't udelay be used here?  empirical measurements
> in the thread show the delay is O(2us).

Does anyone remember where __SLOW_DOWN_IO is needed any more?

udelay() makes sense.  Modern drivers use small udelays themselves to
confirm to chip specs.

Some ISA drivers appear to use outb_p "just to be on the safe side", no
idea if it's appropriate or not.  Some even mix outb and outb_p based on
educated guesses.  I know, I've written such code :-)

-- Jamie


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

Re: Linux Post codes during runtime, possibly OT

[Petr Vandrovec]

On 26 Jan 01 at 8:58, Richard B. Johnson wrote:
> On Thu, 25 Jan 2001, H. Peter Anvin wrote:
> > > You could use the DMA scratch register at 0x19. I'm sure Linux doesn't
> > > "save" stuff there when setting up the DMA controller.
> > > 
> I will change the port on my machines and run them for a week. I
> don't have any DEC Rainbows or other such. Yes, I know Linux will
> not run on a '286.
> 
> Since 0x19 is a hardware register in a DMA controller, specifically
> called a "scratch" register, it is unlikely to hurt anything. Note
> that the BIOS saves stuff in CMOS. It never expects hardware registers
> to survive a "warm boot". It even checks in CMOS to see if it should
> preserve RAM.

Unless there are chips which need DELAY between accesses to DMA 
controller ;-) And I'm sure there are such. Also, if DMA controller
is integrated on board, outb is done in different speed than ISA 
forwarded cycle to postcode port.

Just in case, on my VIA, 1e6 outb(0,0x80) tooks 2.07s, 1e6 outb(0,0x19)
tooks 2.33s - so there is definitely difference - although in other 
direction than I expected. (What you can expect from this ....)
                                            Petr Vandrovec
                                            vandrove@vc.cvut.cz
                                            
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux Post codes during runtime, possibly OT

[Manfred Spraul]

> + * 
> + * Changed the slow-down I/O port from 0x80 to 0x19. 0x19 is a 
> + * DMA controller scratch register. rjohnson@analogic.com 
>    */ 
>  
What about making that a config option?

default: delay with 'outb 0x80', other options could be
	udelay(n); (n=1,2,3)
	outb 0x19

0x80 is a safe port, and IMHO changing the port on all i386 systems
because it's needed for some embedded system debuggers is too dangerous.

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

Re: Linux Post codes during runtime, possibly OT

[Richard B. Johnson]

On Fri, 26 Jan 2001, Jamie Lokier wrote:

> Mark Hahn wrote:
> > >  #ifdef SLOW_IO_BY_JUMPING
> > >  #define __SLOW_DOWN_IO "\njmp 1f\n1:\tjmp 1f\n1:"
> > >  #else
> > > -#define __SLOW_DOWN_IO "\noutb %%al,$0x80"
> > > +#define __SLOW_DOWN_IO "\noutb %%al,$0x19"
> > 
> > this is nutty: why can't udelay be used here?  empirical measurements
> > in the thread show the delay is O(2us).

NOT!  It takes almost exactly 300 ns to do port I/O on the motherboards
that actually do port I/O.

Slowing down I/O is absolutely necessary any time you set an index
register or a page register. For instance, to access the CMOS chip,
you write an index value out port 0x70, then you read or write from
port 0x71. Modern CPUs can execute instructions MUCH faster than
the port index can be switched. If you don't force the CPU to wait
until the hardware has actually switched the port offset, then
you read/write to/from the wrong location.

The same thing occurs with DMA page registers, i.e., 64 k chunks
of addresses. If takes time for hardware to switch in a new page --
a LOT more time than it takes to read/write RAM. If you don't wait,
you read/write to the wrong place.

The delay must be sufficient for the hardware to have accomplished
the switch. That's why writing to a hardware port is ideal. If you
have fast hardware, the delay is low. If you have slow hardware, the
delay is longer.

I'm not going to debate this. If you understand hardware there
is nothing to debate.

> 
> udelay() makes sense.  Modern drivers use small udelays themselves to
> confirm to chip specs.
> 

udelay() on a 33 MHz '486 makes no sense at all. The delay is always
much longer than the input value unless the input value exceeds 100.



Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


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

Re: Linux Post codes during runtime, possibly OT

[Richard B. Johnson]

On Fri, 26 Jan 2001, Manfred Spraul wrote:

> > + * 
> > + * Changed the slow-down I/O port from 0x80 to 0x19. 0x19 is a 
> > + * DMA controller scratch register. rjohnson@analogic.com 
> >    */ 
> >  
> What about making that a config option?
> 
> default: delay with 'outb 0x80', other options could be
> 	udelay(n); (n=1,2,3)
> 	outb 0x19
> 
> 0x80 is a safe port, and IMHO changing the port on all i386 systems
> because it's needed for some embedded system debuggers is too dangerous.
> 
Dangerous? udelay(1) on a 33 MHz system is like udelay(100). Don't
get too used to 800+ MHz CPUs. There are systems, probably most in
the world, that need 300 +/- nanosecond delays. This is what the
port I/O does.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


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

Re: Linux Post codes during runtime, possibly OT

[H. Peter Anvin]

"Richard B. Johnson" wrote:
> 
> I will change the port on my machines and run them for a week. I
> don't have any DEC Rainbows or other such. Yes, I know Linux will
> not run on a '286.
> 
> Since 0x19 is a hardware register in a DMA controller, specifically
> called a "scratch" register, it is unlikely to hurt anything. Note
> that the BIOS saves stuff in CMOS. It never expects hardware registers
> to survive a "warm boot". It even checks in CMOS to see if it should
> preserve RAM.
> 

Actually, what you need to do is change it and then try it on something
like 300 different systems.  Since noone has direct access to that kind
of system, you have to get people to help you out trying it.

A better idea might be to find out what port, if any, Windows uses.  If
Windows does it, it is usually safe.

	-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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux Post codes during runtime, possibly OT

[Jamie Lokier]

Richard B. Johnson wrote:
> Slowing down I/O is absolutely necessary any time you set an index
> register or a page register. For instance, to access the CMOS chip,
> you write an index value out port 0x70, then you read or write from
> port 0x71. Modern CPUs can execute instructions MUCH faster than
> the port index can be switched. If you don't force the CPU to wait
> until the hardware has actually switched the port offset, then
> you read/write to/from the wrong location.
> 
> The same thing occurs with DMA page registers, i.e., 64 k chunks
> of addresses. If takes time for hardware to switch in a new page --
> a LOT more time than it takes to read/write RAM. If you don't wait,
> you read/write to the wrong place.

Ah, I've always wondered when it's appropriate to use outb_p and when to
use outb.  The lack of comments in <asm-i386/io.h> kept this a mystery.
Modern bus hardware doesn't need this sort of thing -- it enforces the
required delays itself.

Is the list of ports for which outb_p is appropriate a small and well
defined one?

> The delay must be sufficient for the hardware to have accomplished
> the switch. That's why writing to a hardware port is ideal. If you
> have fast hardware, the delay is low. If you have slow hardware, the
> delay is longer.
> 
> I'm not going to debate this. If you understand hardware there
> is nothing to debate.

Agreed, however it's not that obvious.  Not all delays are to
synchronise at bus rates.  Sometimes the delay is because some _other_
component on a board, not directly connected to the bus, needs a short
delay.  E.g. a chip that can only be clocked at max. 1MHz.  The driver
author uses outb_p because he thinks that limits the rate to 0.5MHz, and
there is no other way to get that sort of data rate, but no it limits
the rate to 3MHz on your board.  Ah well.

If it was really as simple as matching the bus rate, there would be no
need for REALLY_SLOW_IO on some machines would there?  (Are
REALLY_SLOW_IO and SLOW_IO_BY_JUMPING ever used?)

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

Re: Linux Post codes during runtime, possibly OT

[Brian Gerst]

"Richard B. Johnson" wrote:
> 
> On Fri, 26 Jan 2001, Manfred Spraul wrote:
> 
> > > + *
> > > + * Changed the slow-down I/O port from 0x80 to 0x19. 0x19 is a
> > > + * DMA controller scratch register. rjohnson@analogic.com
> > >    */
> > >
> > What about making that a config option?
> >
> > default: delay with 'outb 0x80', other options could be
> >       udelay(n); (n=1,2,3)
> >       outb 0x19
> >
> > 0x80 is a safe port, and IMHO changing the port on all i386 systems
> > because it's needed for some embedded system debuggers is too dangerous.
> >
> Dangerous? udelay(1) on a 33 MHz system is like udelay(100). Don't
> get too used to 800+ MHz CPUs. There are systems, probably most in
> the world, that need 300 +/- nanosecond delays. This is what the
> port I/O does.

In most of the cases where this delay is needed, it is a _minimum_
delay.  It is usually time enough for the hardware to react to an index
register being written to, etc.  In most cases, a longer delay on slower
machines should not hurt.

--

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

Re: Linux Post codes during runtime, possibly OT

[David Welch]

On Fri, Jan 26, 2001 at 08:19:58AM -0800, H. Peter Anvin wrote:
> 
> A better idea might be to find out what port, if any, Windows uses.  If
> Windows does it, it is usually safe.
> 
Windows NT 4 Service Pack 6 doesn't use any delay however 
READ/WRITE_PORT_* are implemented as indirect function calls so they may
be slowed down enough.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux Post codes during runtime, possibly OT

[Rogier Wolff]

H. Peter Anvin wrote:
> Followup to:  <3A709E99.25ADE5F6@echostar.com>
> By author:    "Ian S. Nelson" <ian.nelson@echostar.com>
> In newsgroup: linux.dev.kernel
> >
> > I'm curious.  Why does Linux make that friendly 98/9a/88 looking
> > postcode pattern when it's running?  DOS and DOS95 don't do that.
> > 
> > I'm begining to feel like I can tell the system health by observing it,
> > kind of like "seeing the matrix."
 
> It output garbage to the 80h port in order to enforce I/O delays.
> It's one of the safe ports to issue outs to.

Yes, because it is reserved for POST codes. You can get "POST
debugging cards" that simply have a BIN -> 7segement encoder and two 7
segment displays on them. They decode 0x80. That's what it's for. 

Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux Post codes during runtime, possibly OT

[Pavel Machek]

Hi!

> > > > + *
> > > > + * Changed the slow-down I/O port from 0x80 to 0x19. 0x19 is a
> > > > + * DMA controller scratch register. rjohnson@analogic.com
> > > >    */
> > > >
> > > What about making that a config option?
> > >
> > > default: delay with 'outb 0x80', other options could be
> > >       udelay(n); (n=1,2,3)
> > >       outb 0x19
> > >
> > > 0x80 is a safe port, and IMHO changing the port on all i386 systems
> > > because it's needed for some embedded system debuggers is too dangerous.
> > >
> > Dangerous? udelay(1) on a 33 MHz system is like udelay(100). Don't
> > get too used to 800+ MHz CPUs. There are systems, probably most in
> > the world, that need 300 +/- nanosecond delays. This is what the
> > port I/O does.
> 
> In most of the cases where this delay is needed, it is a _minimum_
> delay.  It is usually time enough for the hardware to react to an index
> register being written to, etc.  In most cases, a longer delay on slower
> machines should not hurt.

Except getting your ne2000 slower by factor of 300.
								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux Post codes during runtime, possibly OT

[H. Peter Anvin]

Rogier Wolff wrote:
> 
> H. Peter Anvin wrote:
> > Followup to:  <3A709E99.25ADE5F6@echostar.com>
> > By author:    "Ian S. Nelson" <ian.nelson@echostar.com>
> > In newsgroup: linux.dev.kernel
> > >
> > > I'm curious.  Why does Linux make that friendly 98/9a/88 looking
> > > postcode pattern when it's running?  DOS and DOS95 don't do that.
> > >
> > > I'm begining to feel like I can tell the system health by observing it,
> > > kind of like "seeing the matrix."
> 
> > It output garbage to the 80h port in order to enforce I/O delays.
> > It's one of the safe ports to issue outs to.
> 
> Yes, because it is reserved for POST codes. You can get "POST
> debugging cards" that simply have a BIN -> 7segement encoder and two 7
> segment displays on them. They decode 0x80. That's what it's for.
> 

Again, if you want to change it, find another safe port, test the hell
out of it, an *PUBLICIZE IT* so noone will use it in the future.

	-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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux Post codes during runtime, possibly OT

[Rogier Wolff]

H. Peter Anvin wrote:
> Rogier Wolff wrote:
> > H. Peter Anvin wrote:
> > > It output garbage to the 80h port in order to enforce I/O delays.
> > > It's one of the safe ports to issue outs to.

> > Yes, because it is reserved for POST codes. You can get "POST
> > debugging cards" that simply have a BIN -> 7segement encoder and two 7
> > segment displays on them. They decode 0x80. That's what it's for.

> Again, if you want to change it, find another safe port, test the hell
> out of it, an *PUBLICIZE IT* so noone will use it in the future.

I may have missed too much of the discussion, but I thought that the
idea was that some people noted that their POST-code-cards don't
really work all that well when Linux is running because Linux keeps on
sending garbage to port 0x80. 

You seem to state that if you want POST codes, you should find a
different port, modify the code, test the hell out of it, and then
submit the patch.

That is NOT the right way to go about this: Port 0x80 is RESERVED for
POST usage, that's why it's always free. If people want to use it for
the original purpose then that is a pretty damn good reason to bump
the non-intended users of that port somewhere else. 

Now, we've found that small delays are reasonably well generated with
an "outb" to 0x80. So, indeed changing that to something else is going
to be tricky. 

All that I can think of right now is:
 - Find a register that can be written without side effects in 
  "standard" hardware like a keyboard controller, or interrupt 
   controller. Especially good are ones that already require us to keep
   a shadow value. Write the shadow variable to the register.
  (Tricky: not interrupt safe!)
 - Find a scratch register (like the one in the 16450). 

 - Is port 0x81 possibly "quite often" free?

		Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux Post codes during runtime, possibly OT

[H. Peter Anvin]

Rogier Wolff wrote:
> 
> You seem to state that if you want POST codes, you should find a
> different port, modify the code, test the hell out of it, and then
> submit the patch.
> 
> That is NOT the right way to go about this: Port 0x80 is RESERVED for
> POST usage, that's why it's always free. If people want to use it for
> the original purpose then that is a pretty damn good reason to bump
> the non-intended users of that port somewhere else.
> 

Again, such bumping entails:

	- Modify the code
	- Test the hell out of it
	- Submit the patch

> Now, we've found that small delays are reasonably well generated with
> an "outb" to 0x80. So, indeed changing that to something else is going
> to be tricky.
> 
> All that I can think of right now is:
>  - Find a register that can be written without side effects in
>   "standard" hardware like a keyboard controller, or interrupt
>    controller. Especially good are ones that already require us to keep
>    a shadow value. Write the shadow variable to the register.
>   (Tricky: not interrupt safe!)
>  - Find a scratch register (like the one in the 16450).
> 
>  - Is port 0x81 possibly "quite often" free?
> 

Who knows?  That's the thing you're going to have to find out if you want
to push this.  Again, the only way anyone is ever going to find out is by
doing *lots* of research (look at things like Ralf Brown's Interrupt
List), *then* followed by lots and lots of testing to smoke out boxes
that don't work for this.

For what it's worth, I'm talking from experience -- I tried to switch it
to port 0xED which I was told was used for this purpose by BIOS
manufacturers.  It didn't work.

	-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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux Post codes during runtime, possibly OT

[Rogier Wolff]

H. Peter Anvin wrote:
> > All that I can think of right now is:
> >  - Find a register that can be written without side effects in
> >   "standard" hardware like a keyboard controller, or interrupt
> >    controller. Especially good are ones that already require us to keep
> >    a shadow value. Write the shadow variable to the register.
> >   (Tricky: not interrupt safe!)
> >  - Find a scratch register (like the one in the 16450).
> > 
> >  - Is port 0x81 possibly "quite often" free?
> > 
> 
> Who knows?  That's the thing you're going to have to find out if you want
> to push this.  Again, the only way anyone is ever going to find out is by
> doing *lots* of research (look at things like Ralf Brown's Interrupt
> List), *then* followed by lots and lots of testing to smoke out boxes
> that don't work for this.


> Again, such bumping entails:
> 
> 	- Modify the code
> 	- Test the hell out of it
> 	- Submit the patch

Ok. I've thought about it some more, but I don't care enough about
this issue to do the painstaking legwork: I don't have one of those
POST-code indicators on port 0x80.

I've made the "pause" in outb_p just a few (*) ns slower, because it
now loads a variable before outputting the value to port 0x80. As the
whole idea about this is "pausing", making it a bit slower shouldn't
matter too much.  I've tested it: It compiles, it boots. 

I'm not too familar with the syntax of the "asm" statement. So I may
illegally be modifying the AX register. I don't care enough about this
to figure it out right now.

I expect the post_val not to do anything useful at the moment. That is
trivial to add, and not my problem. You can put the load in there
while the system runs. And/or output one byte of data when the system
Ooopses. And/or put values there during the boot process. This will
allow you for instance to see wether the system crashes because you
compiled it for the wrong processor.

Below is the patch. Feel free to test. Someone please jump in and try
to motivate more people to test and submit to Linus once convinced it
always works.

		Roger. 


(*) About 100 when the value is not in the cache.


-------------------------------------------------------------------------

diff -ur linux-2.4.0.clean/arch/i386/boot/compressed/misc.c linux-2.4.0.post/arch/i386/boot/compressed/misc.c
--- linux-2.4.0.clean/arch/i386/boot/compressed/misc.c	Mon Jul 31 19:48:17 2000
+++ linux-2.4.0.post/arch/i386/boot/compressed/misc.c	Sun Jan 28 11:02:26 2001
@@ -113,6 +113,8 @@
 static int vidport;
 static int lines, cols;
 
+int post_val;
+
 #include "../../../../lib/inflate.c"
 
 static void *malloc(int size)
diff -ur linux-2.4.0.clean/include/asm-i386/io.h linux-2.4.0.post/include/asm-i386/io.h
--- linux-2.4.0.clean/include/asm-i386/io.h	Fri Jan 26 10:27:44 2001
+++ linux-2.4.0.post/include/asm-i386/io.h	Sun Jan 28 10:53:23 2001
@@ -37,7 +37,7 @@
 #ifdef SLOW_IO_BY_JUMPING
 #define __SLOW_DOWN_IO "\njmp 1f\n1:\tjmp 1f\n1:"
 #else
-#define __SLOW_DOWN_IO "\noutb %%al,$0x80"
+#define __SLOW_DOWN_IO "\nmovb post_val,%%al\noutb %%al,$0x80"
 #endif
 
 #ifdef REALLY_SLOW_IO
@@ -45,6 +45,8 @@
 #else
 #define __FULL_SLOW_DOWN_IO __SLOW_DOWN_IO
 #endif
+
+extern int post_val; 
 
 /*
  * Talk about misusing macros..
diff -ur linux-2.4.0.clean/init/main.c linux-2.4.0.post/init/main.c
--- linux-2.4.0.clean/init/main.c	Thu Jan  4 05:45:26 2001
+++ linux-2.4.0.post/init/main.c	Sun Jan 28 10:50:31 2001
@@ -130,6 +130,8 @@
 char *execute_command;
 char root_device_name[64];
 
+int post_val;
+
 
 static char * argv_init[MAX_INIT_ARGS+2] = { "init", NULL, };
 static char * envp_init[MAX_INIT_ENVS+2] = { "HOME=/", "TERM=linux", NULL, };


-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux Post codes during runtime, possibly OT

[H. Peter Anvin]

Rogier Wolff wrote:
> 
> Ok. I've thought about it some more, but I don't care enough about
> this issue to do the painstaking legwork: I don't have one of those
> POST-code indicators on port 0x80.
> 
> I've made the "pause" in outb_p just a few (*) ns slower, because it
> now loads a variable before outputting the value to port 0x80. As the
> whole idea about this is "pausing", making it a bit slower shouldn't
> matter too much.  I've tested it: It compiles, it boots.
> 
> I'm not too familar with the syntax of the "asm" statement. So I may
> illegally be modifying the AX register. I don't care enough about this
> to figure it out right now.
> 

It is; you'd have to specify "eax" as a clobber value, and that is
undesirable.

And you're still overwriting the POST value written by the 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux Post codes during runtime, possibly OT

[Rogier Wolff]

H. Peter Anvin wrote:
> Rogier Wolff wrote:
> > 
> > Ok. I've thought about it some more, but I don't care enough about
> > this issue to do the painstaking legwork: I don't have one of those
> > POST-code indicators on port 0x80.
> > 
> > I've made the "pause" in outb_p just a few (*) ns slower, because it
> > now loads a variable before outputting the value to port 0x80. As the
> > whole idea about this is "pausing", making it a bit slower shouldn't
> > matter too much.  I've tested it: It compiles, it boots.
> > 
> > I'm not too familar with the syntax of the "asm" statement. So I may
> > illegally be modifying the AX register. I don't care enough about this
> > to figure it out right now.
> > 
> 
> It is; you'd have to specify "eax" as a clobber value, and that is
> undesirable.

OK. Then someone needs to do the legwork, and add that.

The "_P" version is intended to be inefficient "because the device
can't handle us pushing the limit". Thus a little more because of an
eax reload is unfortunate, but not the end of the world.

Everybody knows (I hope) that outb_p is not intended as an efficient
way to output a byte. So, when possible everybody should be avoiding
it already.

> And you're still overwriting the POST value written by the BIOS.

Yes, but by the time Linux boots, we should just start putting OUR
values there. If the BIOS goes up to 0x8f, then Linux could start at
0x90 and continue there. I don't have one of those thingies, so I
don't know what the last value would be that the BIOS leaves there.

				Roger. 


-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux Post codes during runtime, possibly OT

[Jamie Lokier]

H. Peter Anvin wrote:
> It is; you'd have to specify "eax" as a clobber value, and that is
> undesirable.

For outb_p, EAX is used, usually for the last time, in the preceding
"out" instruction so clobbering it is not a big deal.

For inb_p, you first have to copy EAX to another register before
outputting the post_byte.  That's a small penalty.  Are in[bwl]_p used
anywhere time critical?  (Richard Johnson's explanation for outb_p
implies that inb_p is not required, but perhaps that explanation doesn't
tell the whole story).

> And you're still overwriting the POST value written by the BIOS.

Can the BIOS-written value be read from port 0x80?

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

Re: Linux Post codes during runtime, possibly OT

[Pavel Machek]

Hi!

> > > > It output garbage to the 80h port in order to enforce I/O delays.
> > > > It's one of the safe ports to issue outs to.
> 
> > > Yes, because it is reserved for POST codes. You can get "POST
> > > debugging cards" that simply have a BIN -> 7segement encoder and two 7
> > > segment displays on them. They decode 0x80. That's what it's for.
> 
> > Again, if you want to change it, find another safe port, test the hell
> > out of it, an *PUBLICIZE IT* so noone will use it in the future.
> 
> I may have missed too much of the discussion, but I thought that the
> idea was that some people noted that their POST-code-cards don't
> really work all that well when Linux is running because Linux keeps on
> sending garbage to port 0x80. 
> 
> You seem to state that if you want POST codes, you should find a
> different port, modify the code, test the hell out of it, and then
> submit the patch.
> 
> That is NOT the right way to go about this: Port 0x80 is RESERVED for
> POST usage, that's why it's always free. If people want to use it for
> the original purpose then that is a pretty damn good reason to bump
> the non-intended users of that port somewhere else. 
> 
> Now, we've found that small delays are reasonably well generated with
> an "outb" to 0x80. So, indeed changing that to something else is going
> to be tricky. 
> 
> All that I can think of right now is:
>  - Find a register that can be written without side effects in 
>   "standard" hardware like a keyboard controller, or interrupt 
>    controller. Especially good are ones that already require us to keep
>    a shadow value. Write the shadow variable to the register.
>   (Tricky: not interrupt safe!)

What about just remembering shadow of 0x80 and always writing shadow
to 0x80? Interrupt unsafety hopefully does not matter much....
								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux Post codes during runtime, possibly OT

[Pavel Machek]

Hi!

> > Ok. I've thought about it some more, but I don't care enough about
> > this issue to do the painstaking legwork: I don't have one of those
> > POST-code indicators on port 0x80.
> > 
> > I've made the "pause" in outb_p just a few (*) ns slower, because it
> > now loads a variable before outputting the value to port 0x80. As the
> > whole idea about this is "pausing", making it a bit slower shouldn't
> > matter too much.  I've tested it: It compiles, it boots.
> > 
> > I'm not too familar with the syntax of the "asm" statement. So I may
> > illegally be modifying the AX register. I don't care enough about this
> > to figure it out right now.
> > 
> 
> It is; you'd have to specify "eax" as a clobber value, and that is
> undesirable.
> 
> And you're still overwriting the POST value written by the BIOS.

So save value from bios at initial boot ;-).
								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux Post codes during runtime, possibly OT

[Paul Gortmaker]

> Actually, what you need to do is change it and then try it on something
> like 300 different systems.  Since noone has direct access to that kind
> of system, you have to get people to help you out trying it.
> 
> A better idea might be to find out what port, if any, Windows uses.  If
> Windows does it, it is usually safe.

In the FWIW category, the collection of DOS packet drivers from Russ Nelson
(and the many commercial ones based on them) use a read of the NMI status
port to create a similar delay.  This code got used on lots of hardware
(although probably not much on current hw - mostly 386/486 type vintage
stuff I'd guess...)

I'm not advocating we move off 0x80 either - but people wanting to use
POST cards have at least a couple of options.  And if they have a POST
card, it is probably a safe bet that they can manage to apply one of
the patches and rebuild the kernel.

Paul.

[Booted old 486-66 with 8390 based card (uses inb_p/outb_p) & works fine]


--- include/asm-i386/io.h~	Thu May 11 15:19:27 2000
+++ include/asm-i386/io.h	Sun Jan 28 21:10:22 2001
@@ -23,6 +23,11 @@
  * I feel a bit unsafe about using 0x80 (should be safe, though)
  *
  *		Linus
+ *
+ * Some people get upset since they can't use their POST cards
+ * for diagnostics once linux boots and hammers 0x80 with garbage.
+ * DOS packet drivers do a dummy read of the NMI status port to
+ * obtain a similar delay.			Paul G.
  */
 
  /*
@@ -32,7 +37,11 @@
 #ifdef SLOW_IO_BY_JUMPING
 #define __SLOW_DOWN_IO "\njmp 1f\n1:\tjmp 1f\n1:"
 #else
+#ifdef HAVE_POST_CARD
+#define __SLOW_DOWN_IO "\n\tpushl %%eax\n\tinb $0x61,%%al\n\tpopl %%eax"
+#else
 #define __SLOW_DOWN_IO "\noutb %%al,$0x80"
+#endif
 #endif
 
 #ifdef REALLY_SLOW_IO




_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

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

Re: Linux Post codes during runtime, possibly OT

[Richard B. Johnson]

On Sun, 28 Jan 2001, Pavel Machek wrote:

> Hi!
> 
> > > Ok. I've thought about it some more, but I don't care enough about
> > > this issue to do the painstaking legwork: I don't have one of those
> > > POST-code indicators on port 0x80.
> > > 
> > > I've made the "pause" in outb_p just a few (*) ns slower, because it
> > > now loads a variable before outputting the value to port 0x80. As the
> > > whole idea about this is "pausing", making it a bit slower shouldn't
> > > matter too much.  I've tested it: It compiles, it boots.
> > > 
> > > I'm not too familar with the syntax of the "asm" statement. So I may
> > > illegally be modifying the AX register. I don't care enough about this
> > > to figure it out right now.
> > > 
> > 
> > It is; you'd have to specify "eax" as a clobber value, and that is
> > undesirable.
> > 
> > And you're still overwriting the POST value written by the BIOS.
> 
> So save value from bios at initial boot ;-).
> 								Pavel
> -- 

This is getting all too "strange". Somebody stated that they didn't
want the MFG port being overwritten so I posted a patch that would
use another port.

Instead of testing their machines with the patch, I get tons of
messages like this! I even explained what the purpose of the
delay was, just in case somebody really wanted to know. I suggest
that those who want their POST codes untouched test the patch, those
who don't care, ignore it. Those who are interested in backwards
compatibility should try the patch, those who are not interested
should ignore it also.

The all too often linux-kernel idea; "It doesn't have to be better,
only different..." is getting a bit stale. There are not any extra
hardware ports just laying around. The DMA scratch register, which
I proposed as an alternate to the MFG port, does not affect DMA
operations in any way. It's just one of the few read/write registers
available.

Pavel's idea of "saving" the value in the MFG port ignores the
fact that there is no specification making it readable. A board
manufacturer can save a few gates in his ASIC and leave it write-only.
Further, saving eax, reading the port, writing the port, then restoring
eax is at least twice the delay required.

If you insist upon using the MFG port (port 0x80), just read it.

	pushl	%eax
	inb	$0x80,al
	popl	%eax

Reads and writes take the same time. The extra overhead is the 
save/restore of register EAX. FYI, I would not trust gcc with a
"clobber" value of EAX. Many versions assume that EAX is usable
all the while (like in a called procedure). Just do the push/pop
yourself.

If you decide to do this, you also have to take care of the
code in floppy.h as well as io.h.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


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

Re: Linux Post codes during runtime, possibly OT

[H. Peter Anvin]

Pavel Machek wrote:
>> >
> > And you're still overwriting the POST value written by the BIOS.
> 
> So save value from bios at initial boot ;-).
>                                                                 Pavel

Write-only register.

	-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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux Post codes during runtime, possibly OT

[Mark H. Wood]

On Sat, 27 Jan 2001, Rogier Wolff wrote:
[snip]
> I may have missed too much of the discussion, but I thought that the
> idea was that some people noted that their POST-code-cards don't
> really work all that well when Linux is running because Linux keeps on
> sending garbage to port 0x80. 
> 
> You seem to state that if you want POST codes, you should find a
> different port, modify the code, test the hell out of it, and then
> submit the patch.
> 
> That is NOT the right way to go about this: Port 0x80 is RESERVED for
> POST usage, that's why it's always free. If people want to use it for
> the original purpose then that is a pretty damn good reason to bump
> the non-intended users of that port somewhere else. 
> 
> Now, we've found that small delays are reasonably well generated with
> an "outb" to 0x80. So, indeed changing that to something else is going
> to be tricky. 

So how bad would it be to give these people a place to leave the value
that they want to have displayed, and have the delay code write *that*
instead of garbage?

-- 
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
Make a good day.

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

Re: Linux Post codes during runtime, possibly OT

[Richard B. Johnson]

On Tue, 30 Jan 2001, Mark H. Wood wrote:

> On Sat, 27 Jan 2001, Rogier Wolff wrote:
> [snip]
> > I may have missed too much of the discussion, but I thought that the
> > idea was that some people noted that their POST-code-cards don't
> > really work all that well when Linux is running because Linux keeps on
> > sending garbage to port 0x80. 
> > 
> > You seem to state that if you want POST codes, you should find a
> > different port, modify the code, test the hell out of it, and then
> > submit the patch.
> > 
> > That is NOT the right way to go about this: Port 0x80 is RESERVED for
> > POST usage, that's why it's always free. If people want to use it for
> > the original purpose then that is a pretty damn good reason to bump
> > the non-intended users of that port somewhere else. 
> > 
> > Now, we've found that small delays are reasonably well generated with
> > an "outb" to 0x80. So, indeed changing that to something else is going
> > to be tricky. 
> 
> So how bad would it be to give these people a place to leave the value
> that they want to have displayed, and have the delay code write *that*
> instead of garbage?
> 
You need to save eax on the stack, you need to load al from memory,
you need to write al to the port, then you need to restore eax from
the stack, i.e.,

	pushl	%eax
	movb	(where_they_put_it),%al
	outb	%al,$0x80
	popl	%eax

This looks trivial. However, what happens if the kernel data segment
hasn't been set (yet), etc. To make this 'universal' you have to make
sure that "where_they_put_it" is accessible from the current segment.
Therefore, you have to do:

	pushl	%ds
	pushl	%eax
	movl	$KERNEL_DS,%eax
	movl	%eax,%ds
	movb	(where_they_put_it),%al
	outb	%al,$0x80
	popl	%eax
	popl	%ds

This gets a bit long for something that is, now, only:

	outb	%al,$0x80

I proposed a simple change, just do:

	outb	%al,$0x19

... instead.

That port is a R/W DMA scratch register. It's an 8-bit R/W latch
that is not internally connected to any DMA operations. It was
initially designed as a place to store page-register information
because the PC/XT/AT DMA controller is a 16-bit part. Since the
page register value must be computed for every DMA operation, it
is/was never used.

Simple decisions that used to be handled as; "Yeh, lets try it..."
now seem to be gobble-de-gooked with proving everything to the
world.

Just try it. You'll like it.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


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

Re: Linux Post codes during runtime, possibly OT

[mirabilos]

[...]
> > 
> > Now, we've found that small delays are reasonably well generated with
> > an "outb" to 0x80. So, indeed changing that to something else is going
> > to be tricky. 
> 
> So how bad would it be to give these people a place to leave the value
> that they want to have displayed, and have the delay code write *that*
> instead of garbage?

Because Port &h80 is _not_ decoded by the standard PC hardware.
There are some ISA and nowadays even PCI cards that convert the value
OUTted to that port into two 7-segment-digit-LCDisplays, buffered so
you can read it from the card, but normally no chipset actually
cares about that port. (I speak of Desktop PCs.)

I repeat: Any OUT to port &h80 is, as long as there are no special
extensions, just as well as any OUT to port &h1234 or &h4711 or
whateveryouwant as long as nothing uses it.
Since Port &h80 is now "reserved" for that POST code usage,
and it is the safest port one can use in order to delay,
Linux uses it.
If you don't want this, change it in your kernel or define
SLOW_BY_JUMPING.

-mirabilos


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

Re: Linux Post codes during runtime, possibly OT

[Richard B. Johnson]

On Tue, 30 Jan 2001, mirabilos wrote:

> [...]
> > > 
> > > Now, we've found that small delays are reasonably well generated with
> > > an "outb" to 0x80. So, indeed changing that to something else is going
> > > to be tricky. 
> > 
> > So how bad would it be to give these people a place to leave the value
> > that they want to have displayed, and have the delay code write *that*
> > instead of garbage?
> 
> Because Port &h80 is _not_ decoded by the standard PC hardware.
> There are some ISA and nowadays even PCI cards that convert the value
> OUTted to that port into two 7-segment-digit-LCDisplays, buffered so
> you can read it from the card, but normally no chipset actually
> cares about that port. (I speak of Desktop PCs.)
> 
> I repeat: Any OUT to port &h80 is, as long as there are no special
> extensions, just as well as any OUT to port &h1234 or &h4711 or
> whateveryouwant as long as nothing uses it.
> Since Port &h80 is now "reserved" for that POST code usage,
> and it is the safest port one can use in order to delay,
> Linux uses it.

This is not correct. Port 0x80 is not an "unused" port. It
is decoded by standard hardware:

C:\>debug

-i 80
AE
-o 80 20
-i 80
20
-q
\x1a

In this machine I do not have a 'POST-codes' board. Port 0x80 is
an 8-bit read/write latch. It always has been.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


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

Re: Linux Post codes during runtime, possibly OT

[mirabilos]

----- Original Message ----- 
From: "Richard B. Johnson" <root@chaos.analogic.com>
To: "mirabilos" <eccesys@topmail.de>
Cc: "Linux-Kernel ML" <linux-kernel@vger.kernel.org>; "Mark H. Wood" <mwood@IUPUI.Edu>
Sent: Tuesday, January 30, 2001 6:36 PM
Subject: Re: Linux Post codes during runtime, possibly OT


> On Tue, 30 Jan 2001, mirabilos wrote:
> 
> > [...]
> > > > 
> > > > Now, we've found that small delays are reasonably well generated with
> > > > an "outb" to 0x80. So, indeed changing that to something else is going
> > > > to be tricky. 
> > > 
> > > So how bad would it be to give these people a place to leave the value
> > > that they want to have displayed, and have the delay code write *that*
> > > instead of garbage?
> > 
> > Because Port &h80 is _not_ decoded by the standard PC hardware.
> > There are some ISA and nowadays even PCI cards that convert the value
> > OUTted to that port into two 7-segment-digit-LCDisplays, buffered so
> > you can read it from the card, but normally no chipset actually
> > cares about that port. (I speak of Desktop PCs.)
> > 
> > I repeat: Any OUT to port &h80 is, as long as there are no special
> > extensions, just as well as any OUT to port &h1234 or &h4711 or
> > whateveryouwant as long as nothing uses it.
> > Since Port &h80 is now "reserved" for that POST code usage,
> > and it is the safest port one can use in order to delay,
> > Linux uses it.
> 
> This is not correct. Port 0x80 is not an "unused" port. It
> is decoded by standard hardware:
> 
> C:\>debug
> 
> -i 80
> AE
> -o 80 20
> -i 80
> 20
> -q
> \x1a
> 
> In this machine I do not have a 'POST-codes' board. Port 0x80 is
> an 8-bit read/write latch. It always has been.
> 
> 
> Cheers,
> Dick Johnson

OK, I'll check it against every box I've got here. I just was
citing what I've learned "ages" ago.


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