RE: [OpenBIOS] PCI setup code

[Marcus Gossner]

Ronald G. Minnich wrote:
> > What problems exactly are you having in PCI setup?  I've been messing
> > around in that area lately and can help...
>
> first, in 2.2.10, it doesn't do ANY configuration of memory-addressable
> BARs. Second, it doesn't do any IRQ assignment. If 2.3 fixes this then
> I'll just cut over.
>
> ron

The IRQ assignment can't be done in the operating system. It depends on the
wireing on your board and therefore it is done in BIOS. You can check the
IRQ assignment with your original BIOS:

1. Select fixed ISA IRQs for PCI IRQs
   e.g.  PCI INTA = IRQ  9
         PCI INTB = IRQ 10
         PCI INTC = IRQ 11
         PCI INTD = IRQ 12
2. Put PCI cards in all slots
3. Boot something and look into PCI configuration space
   If for example the card in PCI Slot 1 got IRQ 11 you know now this Slot
uses PCI INTC.

Please remember to set up your chipset correctly to select with PCI IRQ use
with ISA IRQ. Then you can assign this IRQs to your PCI Slots.

Marcus

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

PCI setup code

[Jeff Garzik]

Marcus Gossner wrote:
> The IRQ assignment can't be done in the operating system.

Not correct.  Linux 2.3.x has support for assigning IRQs.  Linux
2.2.x+pcmcia_cs has support for this too.  IRQ assignment is required
for hotplug.

Further, "leave it to the BIOS" isn't really a good answer here :)

Jeff

PCI setup code

[Ronald G. Minnich]

On Wed, 29 Mar 2000, Marcus Gossner wrote:
> The IRQ assignment can't be done in the operating system. It depends on the
> wireing on your board and therefore it is done in BIOS. You can check the
> IRQ assignment with your original BIOS:

So I have to disagree. If the OS can figure out what motherboard it is,
then it ought to be able to do the assignment, since PCI int assignment is
known for a given motherboard. Or am I missing something (again) :-)? It
seems to me that all openbios has to do is communicate motherboard info to
the OS, and let the OS do the rest. BIOSes do a very poor job in interrupt
allocation anyway (as we have found the hard way out here -- we had one
COMPAQ motherboard that vectored everything to IRQ11 for very bad reasons)

But thanks, I will take a look at this.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

PCI setup code

[Colin Jensen]

On Wed, 29 Mar 2000, Ronald G. Minnich wrote:
> On Wed, 29 Mar 2000, Marcus Gossner wrote:
> > The IRQ assignment can't be done in the operating system. It depends on the
> > wireing on your board and therefore it is done in BIOS. You can check the
> > IRQ assignment with your original BIOS:
>
> So I have to disagree. If the OS can figure out what motherboard it is,
> then it ought to be able to do the assignment

You can't seriously suggest that the operating system should be able to detect
the motherboard type automatically!  While in *your* application, you could
hard code the motherboard setups into Linux, this is generally Not A Solution.

Marcus put it best: "IRQ assignment can't be done in the operating system".  And
this is for a simple reason: operating systems generally can't be hard-coded to
a particular motherboard.  And THERE IS NO WAY to automatically detect a
motherboard type.  NONE.  NADA.  CAN'T GO THERE.  The BIOS, since it is going to
be *glued* to the motherboard, is a much more reasonable choice for hard
coding...
-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

PCI setup code

[Ronald G. Minnich]

On Wed, 29 Mar 2000, Colin Jensen wrote:
> You can't seriously suggest that the operating system should be able
> to detect the motherboard type automatically!  While in *your*
> application, you could hard code the motherboard setups into Linux,
> this is generally Not A Solution.

read my mail. I said that openbios can set the motherboard type, and Linux
can pick it up. Read my mail.
> Marcus put it best: "IRQ assignment can't be done in the operating
> system".  And this is for a simple reason: operating systems generally
> can't be hard-coded to a particular motherboard.  And THERE IS NO WAY
> to automatically detect a motherboard type.  NONE.  NADA.  CAN'T GO
> THERE.  The BIOS, since it is going to be *glued* to the motherboard,
> is a much more reasonable choice for hard coding...

No kidding. read my mail. The BIOS can tell Linux what type the
motherboard is via the PARAM method already used to communicate memsize
and other vital stuff.

Once you know the motherboard type, you can do IRQ assignment in the
OS. And as experience is showing us here, you can probably do a better job
than the BIOSes out there.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

PCI setup code

[Jeff Garzik]

Colin Jensen wrote:
> You can't seriously suggest that the operating system should be able to detect
> the motherboard type automatically!  While in *your* application, you could
> hard code the motherboard setups into Linux, this is generally Not A Solution.

Not motherboard type.  Motherboard chipset type.
> Marcus put it best: "IRQ assignment can't be done in the operating system".  And
> this is for a simple reason: operating systems generally can't be hard-coded to
> a particular motherboard.  And THERE IS NO WAY to automatically detect a
> motherboard type.  NONE.  NADA.  CAN'T GO THERE.  The BIOS, since it is going to
> be *glued* to the motherboard, is a much more reasonable choice for hard
> coding...

You CAN detect a motherboard type, by grepping strings out of the BIOS
ROM.  But that is not the point here.  The motherboard CHIPSET type is
easily detected, generally by a simple PCI vendor/device id match.

WRT IRQ assignment, Marcus is wrong.  In a hotplug system, the OS _must_
do the assignment.  Even Microsoft knows this[1].  That is why most
modern BIOS ROMs come with interrupt routing tables, which give the OS a
[somewhat] standard method for

This is also why newer motherboards include a Windows' "IRQ driver" or
similar -- so the --OS-- can talk to your motherboard.

Jeff

[1] http://www.microsoft.com/hwdev/busbios/pciirq.htm

PCI setup code

[Alan Grimes]

I have been studying operating system design for years in hopes of writing my
own. I strongly agree with Colin, Hardware info, init, and drivers should be
in the bios or somewhere outside of the kernel... Even linux moves many
drivers out into loadables... =) This trend is good. It is still fairly kludgy
but its better than having everything inside the kernel.

PCI setup code

[Ronald G. Minnich]

On Wed, 29 Mar 2000, Alan Grimes wrote:
> I have been studying operating system design for years in hopes of
> writing my own. I strongly agree with Colin, Hardware info, init, and
> drivers should be in the bios or somewhere outside of the kernel...
> Even linux moves many drivers out into loadables... =) This trend is
> good. It is still fairly kludgy but its better than having everything
> inside the kernel.

well, that's ok. I've been doing OS for years. If you look inside the
kernels long enough, you'll find that the bios did not help you as much as
you think. It tends to get things wrong. Also, there are things you'd like
to be able to do that you can't because companies like Intel hide them in
proprietary BIOS code.

I have to say, having done OS porting and development in both BIOS and
non-BIOS environments, I've found the non-BIOS actually much easier. The
assembly code hackers who write BIOSes are not all that good, and they are
certainly not concerned about making life better for us open source OS
types.

Your comment about loadables really has no relation to BIOS or
non-BIOS. those are very different issues.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

PCI setup code

[Maciej W. Rozycki]

On Thu, 30 Mar 2000, Ronald G. Minnich wrote:
> well, that's ok. I've been doing OS for years. If you look inside the
> kernels long enough, you'll find that the bios did not help you as much as
> you think. It tends to get things wrong. Also, there are things you'd like
> to be able to do that you can't because companies like Intel hide them in
> proprietary BIOS code.

Well, in the PC world, BIOS is really the sucker.  Additionally it's
mostly DOS-centric which makes it hardly usable for any OS that does not
run in the real mode of the CPU.

But sane architectures do not have weird legacy issues or they are rather
emulated than executed (see MIPS and x86 emulators embedded in the Alpha
firmware for the purpose of executing firmware from old/incompatible
options).  For these architectures, firmware is rather cooperative.  See
the Alpha Linux startup code, for example.  I mean the SRM firmware (i.e. 
the Unix/VMS one) case, of course, and not the NT-centric ARC/AlphaBIOS.

The conclusion is a BIOS need not be bad as long as we do not make it
such.  Just follow good examples and not bad ones or even invent yet
better solutions.

PCI setup code

[David Christensen]

Actually, another method exists in most BIOS implementations that allows the
OS to read a table and know the PCI IRQ routing.  If you check the site
http://www.microsoft.com/HWDEV/busbios/PCIIRQ.htm you'll see the
specification.  Basically, search the BIOS for the string 'PIR$'.  What
follows is a description of the PCI IRQ routing for all of the embedded PCI
devices and all slots.  You MUST have this info to set up PCI cards
correctly, and this information can only come from the manufacturer of the
motherboard.  You'll have to copy this table from the original BIOS in order
to configure your system.

Dave

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of
Marcus Gossner
Sent: Tuesday, March 28, 2000 11:59 PM
To: '[e-mail]'
Subject: RE: [OpenBIOS] PCI setup code

Ronald G. Minnich wrote:
> > What problems exactly are you having in PCI setup?  I've been messing
> > around in that area lately and can help...
>
> first, in 2.2.10, it doesn't do ANY configuration of memory-addressable
> BARs. Second, it doesn't do any IRQ assignment. If 2.3 fixes this then
> I'll just cut over.
>
> ron

The IRQ assignment can't be done in the operating system. It depends on the
wireing on your board and therefore it is done in BIOS. You can check the
IRQ assignment with your original BIOS:

1. Select fixed ISA IRQs for PCI IRQs
   e.g.  PCI INTA = IRQ  9
         PCI INTB = IRQ 10
         PCI INTC = IRQ 11
         PCI INTD = IRQ 12
2. Put PCI cards in all slots
3. Boot something and look into PCI configuration space
   If for example the card in PCI Slot 1 got IRQ 11 you know now this Slot
uses PCI INTC.

Please remember to set up your chipset correctly to select with PCI IRQ use
with ISA IRQ. Then you can assign this IRQs to your PCI Slots.

Marcus

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

PCI setup code

[Ronald G. Minnich]

On Wed, 29 Mar 2000, Marcus Gossner wrote:
> The IRQ assignment can't be done in the operating system. It depends on the
> wireing on your board and therefore it is done in BIOS. You can check the
> IRQ assignment with your original BIOS:

wow, I've done more looking around. The IRQ assignment in linux is pretty
clearly being done in the OS in SMP kernels, check out io_apic.c ...

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

PCI setup code

[Maciej W. Rozycki]

On Fri, 31 Mar 2000, Ronald G. Minnich wrote:
> > The IRQ assignment can't be done in the operating system. It depends on the
> > wireing on your board and therefore it is done in BIOS. You can check the
> > IRQ assignment with your original BIOS:
>
> wow, I've done more looking around. The IRQ assignment in linux is pretty
> clearly being done in the OS in SMP kernels, check out io_apic.c ...

Nope.  Linux just sets IRQs up based on the MP table.  The MP table is
constructed by BIOS and it reflects physical routing of interrupt lines on
the board.  See the code in mpparse.c.  The code in io_apic.c is invoked
much later and depends on what gets prepared within mpparse.c.

Board manufacturers are free to route I/O APIC interrupt lines however
they like in MP systems, as long as the MP table gets these right.

PCI setup code

[Ronald G. Minnich]

On Mon, 3 Apr 2000, Maciej W. Rozycki wrote:
> Nope.  Linux just sets IRQs up based on the MP table.  The MP table is
> constructed by BIOS and it reflects physical routing of interrupt lines on
> the board.  See the code in mpparse.c.  The code in io_apic.c is invoked
> much later and depends on what gets prepared within mpparse.c.

what if there is no MP table?

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

PCI setup code

[Maciej W. Rozycki]

On Thu, 6 Apr 2000, Ronald G. Minnich wrote:
> > Nope.  Linux just sets IRQs up based on the MP table.  The MP table is
> > constructed by BIOS and it reflects physical routing of interrupt lines on

[...]
> what if there is no MP table?

Linux starts UP then and uses 8259A interrupt controllers which have to
work due to the DOS compatibility.

If you know the interrupt and CPU configuration in advance, you can
develop a platform-specific backend -- see the code for SGI Visual
Workstation support (CONFIG_VISWS).

PCI setup code

[Alan Grimes]

> Linux starts UP then and uses 8259A interrupt controllers which have 
> to work due to the DOS compatibility.

DAMNIT! I wish I could go back in time to 1978 and show microsoft how to write
a good unified driver and GFX library architecture so that all programs would
be written to use a single portable interface so we could have 32 peer
interrupt channels (no cascading) and a full 16 DMAs. =((((((((((((((

Just for fun: rewrite your autoexec.bat to read:

" Mem /c > prn "

turn your printer on, yank out your video card and then boot... You get like
900k of somewhat usable DOS memory! =) 
I have proof that this works, it is hanging on my wall! =)

PCI setup code

[Ronald G Minnich]

On Wed, 12 Apr 2000, Maciej W. Rozycki wrote:
> Linux starts UP then and uses 8259A interrupt controllers which have to
> work due to the DOS compatibility.

strange and interesting datapoint: I had not yet put in the "8259a" code
from Linux startup into freebios. We did have it in the openbios code, and
I thought I would need it, but decided to see what happen if I did not put
it in. This code is not run by linux when it is started up from linuxbios
because it is done in boot/setup.S and we don't run ANY of that code -- we
go right to the linux startup at 0x10:0x100000 in protected mode. In other
words, the "steenking bios" code is not run at all. The only interrupt
setup I initially did for linuxbios is as follows:

void
intel_interrupts_on()
{
  unsigned long low, high;

/* this is so interrupts work. This is very limited scope -- 
   * linux will do better later, we hope ...
   */
  rdmsr(0x1b, low, high);
  low &= ~0x800;
  wrmsr(0x1b, low, high);

}

(note how we can do things in C in freebios-based linuxbios, yee ha).

Clock interrupts work just fine. I'm not sure about other interrupts.

So what's going on? Well, turns out the code in boot/setup.S is there
because the BIOS misprograms the interrupts (at least as I read the
comments). Since we have no BIOS, we don't have misprogrammed
interrupts. We don't need that code in boot/setup.S to undo the damage
done by the PC BIOS.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

PCI setup code

[Konstantin Zhidkov]

"Ronald G. Minnich" wrote:
> On Mon, 3 Apr 2000, Maciej W. Rozycki wrote:
> > Nope.  Linux just sets IRQs up based on the MP table.  The MP table is
> > constructed by BIOS and it reflects physical routing of interrupt lines on
> > the board.  See the code in mpparse.c.  The code in io_apic.c is invoked
> > much later and depends on what gets prepared within mpparse.c.
>
> what if there is no MP table?

One of possible answers is "We should build one" (See my message about SMP
BIOS). As a temporary solution we can use statical MP table. The MP table built
by original BIOS may serve as a good reference.

Konstantin

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

PCI setup code

[Ronald G Minnich]

On Thu, 13 Apr 2000, Konstantin Zhidkov wrote:
> One of possible answers is "We should build one" (See my message about SMP
> BIOS). As a temporary solution we can use statical MP table. The MP table built
> by original BIOS may serve as a good reference.
>
> Konstantin

Yes, this is a very good idea. I'll try to dump the MP from a working box
and use that.

Thanks

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message