OpenBIOS

openbios@openbios.org

4297 discussions

Openbios site at sourceforge.net
by Chris Davis 17 Mar '00

17 Mar '00

Hello, I don't know whether this is useful or not, but I have registered an OpenBios development stite at Sourceforge.net. You can get to it at https://sourceforge.net/project/?group_id=3423 or very soon at http://openbios.sourceforge.net/ There is nothing there yet -- just the basic sourceforge project structure. But I'll probably put some messaages and files there over the weekend. I don't know if this is useful, and I certainly have NO INTEREST in 'stealing' the openbios web site away from others. Take a look at the site for what is possible there, and let me know what you think. If there is sufficient interest, I'm willing to devote some time to this. Thanks Chris Davis - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

get ints turned on
by Wallace I. Kroeker 17 Mar '00

17 Mar '00

Hello, At least part of the puzzle is getting the PIIX set up. On my system (a 440bx) there is a PIIX4 (sometimes called the SouthBridge I believe) this contains the interrupt handler (it used to be a separate chip(s) on the old systems). In the OpenBIOS code I set mine up in the SuperIO (I generated one for the 440bx) by writing the values out. Code follows: #include <io.h> #include <types.h> #define CS440BX_INDEX 0xf2 #define CS440BX_DATA 0xf3 /* Write val to reg# reg. */ #define WRITE_440BX(reg, val) { \ outb_p(reg, CS440BX_INDEX); \ outb_p(val, CS440BX_DATA); } static struct { u8 reg; u8 val; }sio_regs[] = { { 0x20, 0x11 }, /* ICW1 1st 82C59 setup */ { 0x21, 0x08 }, /* ICW2 1st 82C59 setup */ { 0x21, 0x04 }, /* ICW3 1st 82C59 setup */ { 0x21, 0x01 }, /* ICW4 1st 82C59 setup */ { 0xA0, 0x11 }, /* ICW1 2nd 82C59 setup */ /** Linux put out 0x70 for ICW2 ??? why ??? **/ { 0xA1, 0x08 }, /* ICW2 2nd 82C59 setup */ { 0xA1, 0x02 }, /* ICW3 2nd 82C59 setup */ { 0xA1, 0x01 }, /* ICW4 2nd 82C59 setup */ { 0xff, 0x00 } }; void sio_init(void) { int i; for (i=0; sio_regs[i].reg != 0xff; i++) { WRITE_440BX(sio_regs[i].reg, sio_regs[i].val); } } The documentation states that you need to program them in order from ICW1, ICW2, ICW3, ICW4 for address 0x20 and 0x21 and ICW1, ICW2, ICW3, ICW4 for 0xA0 and 0xA1 Linux also sets up the interrupts on boot (look for the code near code just before "steenking BIOS" in setup.S) This is where he is setting up the interrupt chips as he would like them. Now in both the OpenBIOS and Linux the need to set up the IDT to properly use the interrupt vectors. The OpenBIOS is probably a littler simpler to understand: The OpenBIOS sets up RAMSTART as 0x400 The GDT start at RAMSTART of 0x400 ( note this is mulitply defined in the assembler code and in the header segment.h ... bad form and error prone) The GDT is 0x800 bytes big The IDT starts next at 0xC00. There is some preliminary set up of these in the boot/boot16/start.asm code The code in firmware/init/traps.c does further initializing of the interrupt vector table and viola you get the OpenBIOS firmware responding to interrupts. I have added support for Int 0x13 (floppy read write) in so far as I can issue an int 0x13 as inline assembler in the main.c which cause my interrupt handler to be called. (I gave up on writing the floppy driver as there seems to be some problems getting the floppy to respond properly and it wasn't critical to what I was doing. ) I have spent my time writing a utility for downloading a real OS via the serial port instead and am in the process of getting linux bmvlinux to boot. After I have loaded it into upper memory and vectored to the entry point. I am currently looking into the setup.S code to determine how I should be setting things up to make linux happy. I believe that I still need to do a some preliminary IDT setup (as would come with a regular BIOS) so that Linux can pull it's socks up. (If I put a simple assembly instruction in upper memory and call it, it will return. If I put Linux up there and call it it currently dies.) Another thing that Linux folks should watch out for is that Linux can be compiled to either use BIOS32 (PCI bioses) or do all the PCI enumeration and setup. You should compile your kernel to do it's own PCI enumeration. I have been working on the memory setup and haven't had too much luck yet. (Ron's 440gx code doesn't work for my system even with minor changes for chipset differences etc.) Wallace > -----Original Message----- > From: Ronald G. Minnich [SMTP:rminnich@lanl.gov] > Sent: Thursday, March 16, 2000 9:39 PM > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: Re: [OpenBIOS] Re: Status > > On Thu, 16 Mar 2000, Edwin Rhodes wrote: > > > i know this may sound real stupid, but have you checked out Ralf Brown's > > Interrupt List? > > Hmm, tell me more. I think I have, but I'm not sure that Ralf tells you > how to init the cold hardware to enable timer interrupts. > > ron > > - > To unsubscribe: send mail to majordomo(a)freiburg.linux.de > with 'unsubscribe openbios' in the body of the message - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] Unofficial OpenBIOS web page
by Ross 05 Mar '00

05 Mar '00

All of my code has been converted to asm. //Ross ---------- > From: Ronald G. Minnich <rminnich(a)lanl.gov> > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: Re: [OpenBIOS] Unofficial OpenBIOS web page > Date: Sunday, March 05, 2000 9:24 PM > > On Sun, 5 Mar 2000, Ross wrote: > > 1). a routine in x86 asm code that can test the > > cache memory on the 430XX chipset. > > sorry, I have not looked at the 430xx at all yet. I'm still stuck on the > 440 :-( > > > 2). a routine in x86 asm code that can test the > > the USB Interface on the 430XX chipset. > > oh horrors, usb. > > Question, though: why assembly for the usb. I understand for (1) but not > (2) > > ron > > - > To unsubscribe: send mail to majordomo(a)freiburg.linux.de > with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] Unofficial OpenBIOS web page
by Ross 05 Mar '00

05 Mar '00

Jeff, I'am working on the i430FX but I want to code this in asm you can call it from C code if you want to. //Ross ---------- > From: Jeff Garzik <jgarzik(a)mandrakesoft.com> > To: Ross <rossio(a)hoeftd.reno.nv.us> > Cc: openbios(a)elvis.informatik.uni-freiburg.de > Subject: Re: [OpenBIOS] Unofficial OpenBIOS web page > Date: Sunday, March 05, 2000 9:41 AM > > Ross wrote: > > 1). a routine in x86 asm code that can test the > > cache memory on the 430XX chipset. > > > > 2). a routine in x86 asm code that can test the > > the USB Interface on the 430XX chipset. > > Why can you not do this in C code? > > Also, my initial contribution to the FreeBIOS project is i430FX support, > so we should work together if you are working on the same chipset. > > Regards, > > Jeff > > > > > > -- > Jeff Garzik | Rule 1: > Building 1024 | There is no cabal. > MandrakeSoft, Inc. | > - > To unsubscribe: send mail to majordomo(a)freiburg.linux.de > with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] Unofficial OpenBIOS web page
by Ross 05 Mar '00

05 Mar '00

Hey, ron: I have two questions that you may be able to help me out wit or point me to the proper source. I'am in need of the following: 1). a routine in x86 asm code that can test the cache memory on the 430XX chipset. 2). a routine in x86 asm code that can test the the USB Interface on the 430XX chipset. I know you are not a fan of assembly code but you appear to be very knowledgeable about it. BTW thanks for the win32 tools tar stuff. //Ross ---------- > From: Ronald G. Minnich <rminnich(a)lanl.gov> > To: OpenBIOS Mailing List <openbios(a)elvis.informatik.uni-freiburg.de> > Subject: Re: [OpenBIOS] Unofficial OpenBIOS web page > Date: Saturday, March 04, 2000 11:13 PM > > why not put them on the official one? I'm missing something. > > ron > > - > To unsubscribe: send mail to majordomo(a)freiburg.linux.de > with 'unsubscribe openbios' in the body of the message

3 2

Unofficial OpenBIOS web page
by Bob Dobbs 05 Mar '00

05 Mar '00

I have been collecting some of the important messages of the OpenBIOS mailing list discussing various thing and I was thinking about compiling them and making an unofficial OpenBIOS web page. Anybody have any comments? -graham - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

4 3

RE: [OpenBIOS] Clarification needed
by Winter Jörg 03 Mar '00

03 Mar '00

... > So what I am doing right now is implementing the interrupts via the > firmware/init/irq.c capabilities so that I can get linux to come up. > > Is this correct or should I be putting in BIOS IRQ support in another > location (e.g. in the boot/ code)? > This may have impacts on how Ron re-organizes things too. > Any feedback would be appreciated. > Thanks > Wallace ... I dont have the source at hand now. But if the firmware/init/main.c is running you are already in protected mode with all 32bit mechanisms running. Here you are in a state where you can ignore the bootsect.S and even the setup.S of the kernel. just try to read the kernel off your disk with plain ATA commands and then jump to the adress of the a symbol called "start_kernel" or something like that. Sorry for the fuzzy description, but as I said I dont have the sources at hand now ... hope it helped although ... If you are interested in further discussion of this topic I can grab my sources next week, let me know! bye byte, Jake. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] asm code
by Edwin Rhodes 03 Mar '00

03 Mar '00

thanks for the code, it didnt work straight off but after 20 mins of hacking it, i got it working :) thanks, one last question, this code clears the memory but doesnt move the cursor to the top left hand corner of the screen, how to i do this? can i use the gotoxy function or will that not work in the kernel? i have afeeling that it wont work. what code do i need to move the cursor to the top left hand corner? im sure its somthing simple but since im new to this kernel hacking business im still getting used to the linux kernel. thanks again for the code. edwin ----- Original Message ----- From: James <jvh(a)uclink4.berkeley.edu> To: <openbios(a)elvis.informatik.uni-freiburg.de> Sent: Wednesday, March 01, 2000 11:03 AM Subject: Re: [OpenBIOS] asm code > /* > Since you are already in C after it uncompresses the kernel, you could > do something like: > */ > > int i; > void *vidmem = 0x0b8000; > > for (i = 0; i < 80*25*2; i++) { /* Clear an 80*25 screen */ > *(vidmem + i) = 0; > } > > /* > Something like that, at least; I've been doing way too much Java > recently, I can't think straight.. > The harder part is writing something to the screen; letters are on the > even bytes (0xb8000, 0xb8002, 0xb8004, etc), attributes are on the odd > ones (0xb001, 0xb003...). > - James > > > what code do i need to zero 0b8000 - 0bfff0. > > thanks edwin > > ----- Original Message ----- > > From: James <jvh(a)uclink4.berkeley.edu> > > To: <openbios(a)elvis.informatik.uni-freiburg.de> > > Sent: Monday, February 21, 2000 3:27 PM > > Subject: Re: [OpenBIOS] asm code > > > > > > > > hi sorry this is slightly off topic but i need some asm code to clear > > > > the screen in the linux kernel -- just after it says uncompressing > > > > linux. how would i implement this in assembler, that would compile > > > > under gas. thanks edwin > > > > > > By the time it says "uncompressing linux" it is already in 32 bit mode C > > > code (inflate.c). It is writing to the screen directly at memory address > > > 0b8000. To clear the screen, just zero 0b8000 - 0bfff0. > > > > > > > ps. will you eventually implement all the standard bios calls so that > > > > other os's such as dos etc will run under open bios? or will it be > > > > just a bios for linux? thanks and good luck. > > > > > > I believe the goal is to get support for the 32 bit OSs that don't use the > > > BIOS, like WinNT, BeOS, Linux, BSD, and others (at least I think that is > > > the goal and I think those OSs don't use the BIOS). > > > > > > - James > > > > > > - > > > To unsubscribe: send mail to majordomo(a)freiburg.linux.de > > > with 'unsubscribe openbios' in the body of the message > > > > > - > > To unsubscribe: send mail to majordomo(a)freiburg.linux.de > > with 'unsubscribe openbios' in the body of the message > > > > - > To unsubscribe: send mail to majordomo(a)freiburg.linux.de > with 'unsubscribe openbios' in the body of the message > - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Clarification needed
by Wallace I. Kroeker 03 Mar '00

03 Mar '00

Hello, Now that I've been working with the OpenBIOS code for a little while and as I slowly pull back the skins of this Onion I would like to get some clarification about the structure. I will try to explain what I understand is to be the structure and maybe someone can correct me if I'm wrong. boot/ This contains all the code needed to get the basic BIOS up and running (excluding the actual specific chipset code). The final task under boot32 is to ungzip something and start running it. drivers/ This is the specific chipsets that are supported. firmware/ Hmmm ... what is this suppose to be ... it looks like the piece of code that would provide support for our BIOS interrupt handling. HOWEVER, there are some things to watch out for with this scenario. A standard x86 system has low memory usage as: 00000-001DF - Interrupt Vectors 001E0-002FF - User Vectors 00300-003FF - Bios stack/user Vectors 00400-004FF - Bios data 00500-005FF - DOS and Basic Use 00600-9FFFF - User Ram The built in payload that comes with OpenBIOS unloads in the low end and takes up some of the user space. This has implications for how OpenBIOS might actually load other OSs. Linux for example from a zImage disk loads starting at 0x1000 (contrary to the in-line documentation that claims 0x10000! If you look at the code the variable is set to 0x1000 which is the second 64K segment on the x86 machine). This means (as Ron pointed out a while back) that for Linux you should use a bzImage. The Linux kernel has a hack in it for magically moving the image to 0x10000 and everything is fine. The orginal intent was for this to be used with large linux kernels that won't fit in the low end. DOS isn't going to work as the OpenBIOS firmware uses up it's space. FreeDOS ... someone else will have to tell me about that but if it is following the DOS model then it will have problems too. Another thing of note is that the regular Linux boot requires the following Interrupts to be supported: Linux Interrupts expected in linux/arch/i386/bootsect .S: 0x13 - 00 reset the FDC (Floppy Disk Controller) 0x13 - 0x02 read the boot sector 0x13 - 0x15 read DASD type (check for a harddrive if DL bit 7 is set ... Linux set DL = 0x81) ... Likely for the flashdisk we will have to return something 0x10 - print of characters (e.g. new line ) ... SUPPORTED by the video BIOS for now ... 0x15 - memory size AH = 0x88 0x15 - Check AH = 0xC0 system config parameters - Micro Channel arch. : set the Carry flag for this. 0x16 - keyboard repeat rate setting AX=0305 BX = 0 to set it to the max 0x16 - 00 0x16 - 01 0x11 - Get installed capabilities (AX=0) EAX has equipment list ... used to determine if the Mouse is active 0x15 - 0x87 Move Block 0x1A - 0x02 Read the real time clock time So to avoid having to implement these you will have to modify the bootsect.S code and find other ways of feeding Linux the information it wants. So what I am doing right now is implementing the interrupts via the firmware/init/irq.c capabilities so that I can get linux to come up. Is this correct or should I be putting in BIOS IRQ support in another location (e.g. in the boot/ code)? This may have impacts on how Ron re-organizes things too. Any feedback would be appreciated. Thanks Wallace - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] STPC BIOS sources posted
by Jaime Dias 02 Mar '00

02 Mar '00

> > > Other than copyright questions STP pretty much is laid out (in how it > > works) just like I want. No NASM at all. Get memory going, get into 32-bit > > mode, get into C in short order. It's really a good design. > > "> I don't understand why you can't use directly vga cards bios????? I didn't mean computers > bios! Is there something memory stuff why we can't use cards bios? I can browse my old > source archives to find my old vesa code (It worked with and without dosextender). We cannot because: 1) vga BIOS often uses main BIOS for some things, 2) vga BIOS is a 16bit code and AROS uses 32bit code (first 4 kb - the bootsector and setup file are in 16bit) 3) We have destroyed BIOS area in memory because we keep there other things 4) calling ANY bios (16 bit) would destroy multitasking and slow performance down a lot." well i accept suggestions, anyway to improve this to take use of bios (openbios) ? thanks in advance, jaime dias - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

Jump to page: