OpenBIOS

openbios@openbios.org

4297 discussions

state of play for freebios/linuxbios
by Ronald G. Minnich 07 Apr '00

07 Apr '00

I have it going into protected mode basically instantly. I am loading a GDT from the NVRAM and it works just great. I have the DRAM up (with only one simm, but...). Having the machine in protected mode from the very start is SO MUCH BETTER. DRAM config is really going to be easy! The automake is not as helpful as I hoped. I am finding that compared to all the things I've seen I still like Berkeley 'config' the best for this sort of thing ... ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

RE: [OpenBIOS] VESA & DMA
by Marcus Gossner 07 Apr '00

07 Apr '00

>Hi everybody, > >This has not much to do with the OpenBIOS project, but with low level >programming. Everyone here seems to know lot of things in this domain, >that's why i'm asking to all of u those questions : > >1. Can we setup a VESA 2 (not VESA 3 !) configuration (select video >mode, and everything) without making a int 0x10 ? We're programming a >protected mode OS, and switching to VM86 sucks. I know it's possible >with VESA 3, but with VESA 2 ? >If yes, do you have any docs about it ? I think it is NOT possible without INT 10. Have a look at Ralph Brown's Interrupt list: http://www.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/WWW/files.html and look at INT 10/AX=4F0A. >Is the int 0x10 VESA code specific to each graphic card ? No. >2. I've got a problem with DMA programming, here's my source : > (....) >I use it to transfer a sector from the floppy disk. Do you see anything >wrong in this code ? >The transfer is not made by the floppy, and i don't know why... >I don't know if it's in the DMA programming, or in the floppy driver >.............. I'm not sure, but I think the floppy don't support DMA and it is as default disabled by the floppy controller. >Help ! > >Thanks, > >Thomas, from france Marcus - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

VESA & DMA
by Petazzoni Thomas 07 Apr '00

07 Apr '00

Hi everybody, This has not much to do with the OpenBIOS project, but with low level programming. Everyone here seems to know lot of things in this domain, that's why i'm asking to all of u those questions : 1. Can we setup a VESA 2 (not VESA 3 !) configuration (select video mode, and everything) without making a int 0x10 ? We're programming a protected mode OS, and switching to VM86 sucks. I know it's possible with VESA 3, but with VESA 2 ? If yes, do you have any docs about it ? Is the int 0x10 VESA code specific to each graphic card ? 2. I've got a problem with DMA programming, here's my source : const static DmaChannel dmainfo[] = { { 0x87, 0x00, 0x01 }, { 0x83, 0x02, 0x03 }, { 0x81, 0x04, 0x05 }, { 0x82, 0x06, 0x07 } }; void dma_transfer(int channel, long physical_address, unsigned int length, unsigned sh ort read) { long page, offset; if(channel >= 4) { printk("\nThis function does to manage with channel 4, 5, 6, 7"); return ; } page = physical_address >> 16; offset = physical_address & 0xFFFF; length -= 1; // DIsable IRQs outb(0xFF, 0x21); outb(0xFF, 0xA1); // Masking channel (disable) outb(channel | 4, 0x0A); // Reset Flip-Flop outb(0, 0xC0); // Mode outb( (read ? 0x48 : 0x44) | channel, 0x0B); // Page outb(page, dmainfo[channel].page); // Offset outb(offset & 0xFF, dmainfo[channel].offset); outb((offset >> 8) & 0xFF, dmainfo[channel].offset); // Length outb(length & 0xFF, dmainfo[channel].length); outb((length >> 8) & 0xFF, dmainfo[channel].length); // Unmask outb(channel, 0x0A); // Enabling IRQs outb(0, 0x21); outb(0, 0xA1); } I use it to transfer a sector from the floppy disk. Do you see anything wrong in this code ? The transfer is not made by the floppy, and i don't know why... I don't know if it's in the DMA programming, or in the floppy driver .............. Help ! Thanks, Thomas, from france (If you speak french, you can join the KOS project : http://kos.enix.org) -- PETAZZONI Thomas, coordinateur du projet KOS thomas.petazzoni(a)ifrance.com ICQ : 34937744 Home page : http://perso.worldonline.fr/petazzoni/thomas/ Home Page Projet KOS : http://kos.enix.org - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 2

None
by Kent Nyberg 06 Apr '00

06 Apr '00

I was talking to my friend on irc today.. and i was wondering on thing. When you have written a bad bios and want to copy the normal bios, which i have learned is on a rom, which cant be removed. How do you do that, is it with that switch which says "clear cmos" ?? - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

sorry to ask this again
by Ronald G. Minnich 04 Apr '00

04 Apr '00

If someone has the *code* example for calling the vga init on a vga card I could use it. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

6 12

separate question on PnP and BIOS POST
by Jessen, Per 04 Apr '00

04 Apr '00

All, not exactly an openbios question, but judging by the traffic on the list, I'm sure someone has an answer - I'm trying to add a PnP header structure to a BIOS-image, and need to have the Bios_Connect_Vector and possibly the Static_ Resource_Information_Vector called immediately after POST. This is (as far as I can tell) what a PnP BIOS will do according to the spec (various documents, approx. 1994) The card itself is NOT PnP, but the software on the EPROM will be. Problem is that the BIOS on my system (Abit BP6, Award BIOS) doesn't seem to (1) either recognise the PnP-header in my BIOS-image or (2) doesn't follow the PnP POST-sequence. Does anyone have any pointers for me ? Is it a problem if my BIOS-image is placed at C000 (where the video would normally be found) ? I have all the documents, but it looks like my system BIOS (BP6, Award) isn't behaving as it should ? I had a quick look at the etherboot package, which also has a PnP-header in the BIOS-image - I can't tell if it is being used, though. But the structure looks exactly like what I have coded. any help would be much appreciated! regards, Per Jessen, London - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Fixed part of it
by Ronald G. Minnich 30 Mar '00

30 Mar '00

OK, I've added simple pcibus_fixup_mem_addr code to 2.2.10, so that memory BARs get set up correctly. As for this discussion of interrupt mapping: a quick look at any motherboard spec will show you how trivial the mapping of four interrupt lines for 4 or 5 PCI slots is. There's only so many permutations you can do, and most motherboards do them the same. There aren't that many motherboards out there. Do the math. It's a very small table, and if we really ever want hot swap, we'll need it anyway. So why not just do it now? ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] PCI setup code
by Ronald G. Minnich 30 Mar '00

30 Mar '00

On Mon, 27 Mar 2000, Jeff Garzik 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 - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

3 5

RE: [OpenBIOS] PCI setup code
by Marcus Gossner 30 Mar '00

30 Mar '00

Jeff wrote: >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. > Detect only the chipset type will not solve the problem. The wireing from the chipset to the PCI Slots ist the interessting thing. > >> 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 > I think you should not do the assignment in the OS but you can do a reconfiguration there. All are talking about Linux but I like to use poor old DOS and WinNT 4 and other OS and I don't linke to write a device driver for PCI configuration for each OS. I agree, that the OS can change the settings made by the BIOS. I don't understand the problem. If you like you can clear all PCI registers and set up them again in the OS, but there should be done something for all OS that can't do the configuration. And one other thing: When the Linux code is the best in the world, why not put it into the BIOS? > >This is also why newer motherboards include a Windows' "IRQ driver" or >similar -- so the --OS-- can talk to your motherboard. > > Jeff Marcus - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

PCI setup
by Ronald G. Minnich 29 Mar '00

29 Mar '00

much improved in 2.3, so I am moving linuxbios to 2.3.45 ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 2

Jump to page: