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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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 -- Jeff Garzik | Tact is the ability to tell a man Building 1024 | he has an open mind when he has a MandrakeSoft, Inc. | hole in his head. (-random fortune) - To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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 -- Jeff Garzik | Tact is the ability to tell a man Building 1024 | he has an open mind when he has a MandrakeSoft, Inc. | hole in his head. (-random fortune) - To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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. -- Are you sure there are only five basic questions? (who, what, where, when, and how) http://users.erols.com/alangrimes/ - To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + - To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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: owner-openbios@elvis.informatik.uni-freiburg.de [mailto:owner-openbios@elvis.informatik.uni-freiburg.de]On Behalf Of Marcus Gossner Sent: Tuesday, March 28, 2000 11:59 PM To: 'openbios@freiburg.linux.de' 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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message - To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + - To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + - To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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! =) -- To whomever it may concern: DO NOT RECCOMEND A PROGRAMMING LANGUAGE TO ME WITHOUT PROVIDING COMPLETE BIBILOGRAPHICAL INFORMATION ON WHAT YOU THINK TO BE THE BEST MANUAL FOR LEARNING AND USING IT. http://users.erols.com/alangrimes/ - To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
"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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
participants (9)
-
Alan Grimes -
Colin Jensen -
David Christensen -
Jeff Garzik -
Konstantin Zhidkov -
Maciej W. Rozycki -
Marcus Gossner -
Ronald G Minnich -
Ronald G. Minnich