- OpenBIOS - mail.coreboot.org

BINGO!
by James V Hendricks 06 Jul '00

06 Jul '00

Procedure: 1) Load Intel L440GX Standard BIOS 2) Switch the BIOS recovery jumper on (while system is running) 3) Get to the LILO prompt and reboot processor 0 (leave proc 1 running!) 4) Load LinuxBIOS SMP kernel 5) Switch the BIOS recovery jumper off (while system is running) 6) Reboot processor 1 7) Get Linux to 0010:00100000 and set BX to 0x0 (workaround -- this should be in LinuxBIOS). 8) Run hit F5 and look at the (framebuffer's) penguins!!! (For the ACL guys, check out the VA slate on my workbench.) Ron: We are good to go!! It is pretty obvious to me that processor 2 needs to run the MTRR init code; how do you want to do this? Perhaps an #ifdef LINUXBIOS in the kernel, or do you want to do a startup IPI? {Free,Open}BIOS lists: Does anyone know why we have to set BX to 0x0? Does anyone know why we get 'unexpected IRQ trap at vector 31.' when we calibrate the delay loops (on both processors)? Cheers. - James Linux version 2.4.0-test2 (jimi@rockhopper1) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #18 SMP Sun Jul 2 18:07:05 MDT 2000. BIOS-provided physical RAM map:. e820: 000000000009f000 @ 0000000000000000 (usable). e820: 0000000003e00000 @ 0000000000100000 (usable). Scan SMP from c0000000 for 1024 bytes.. found SMP MP-table at 00000000. hm, page 00000000 reserved twice.. On node 0 totalpages: 16128. zone(0): 4096 pages.. zone(1): 12032 pages.. zone(2): 0 pages.. Intel MultiProcessor Specification v1.4. Virtual Wire compatibility mode.. Default MP configuration #5. Processor #0 Pentium(tm) Pro APIC version 16. Floating point unit present.. Machine Exception supported.. 64 bit compare & exchange supported.. Internal APIC present.. Processor #1 Pentium(tm) Pro APIC version 16. Floating point unit present.. Machine Exception supported.. 64 bit compare & exchange supported.. Internal APIC present.. Bus #0 is ISA . Bus #1 is PCI . I/O APIC #2 Version 16 at 0xFEC00000.. Int: type 0, pol 0, trig 0, bus 0, IRQ 00, APIC ID 2, APIC INT 02. Int: type 0, pol 0, trig 0, bus 0, IRQ 01, APIC ID 2, APIC INT 01. Int: type 0, pol 0, trig 0, bus 0, IRQ 03, APIC ID 2, APIC INT 03. Int: type 0, pol 0, trig 0, bus 0, IRQ 04, APIC ID 2, APIC INT 04. Int: type 0, pol 0, trig 0, bus 0, IRQ 05, APIC ID 2, APIC INT 05. Int: type 0, pol 0, trig 0, bus 0, IRQ 06, APIC ID 2, APIC INT 06. Int: type 0, pol 0, trig 0, bus 0, IRQ 07, APIC ID 2, APIC INT 07. Int: type 0, pol 0, trig 0, bus 0, IRQ 08, APIC ID 2, APIC INT 08. Int: type 0, pol 0, trig 0, bus 0, IRQ 09, APIC ID 2, APIC INT 09. Int: type 0, pol 0, trig 0, bus 0, IRQ 0a, APIC ID 2, APIC INT 0a. Int: type 0, pol 0, trig 0, bus 0, IRQ 0b, APIC ID 2, APIC INT 0b. Int: type 0, pol 0, trig 0, bus 0, IRQ 0c, APIC ID 2, APIC INT 0c. Int: type 0, pol 0, trig 0, bus 0, IRQ 0d, APIC ID 2, APIC INT 0d. Int: type 0, pol 0, trig 0, bus 0, IRQ 0e, APIC ID 2, APIC INT 0e. Int: type 0, pol 0, trig 0, bus 0, IRQ 0f, APIC ID 2, APIC INT 0f. Int: type 3, pol 0, trig 0, bus 0, IRQ 00, APIC ID 2, APIC INT 00. Lint: type 3, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 00. Lint: type 1, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 01. Processors: 2. mapped APIC to ffffe000 (fee00000). mapped IOAPIC to ffffd000 (fec00000). Kernel command line: root=/dev/hda1 single. Initializing CPU#0. Detected 497445265 Hz processor.. Console: colour dummy device 80x25. unexpected IRQ trap at vector 31. Calibrating delay loop... unexpected IRQ trap at vector 31. 989.59 BogoMIPS. unexpected IRQ trap at vector 31. Memory: 61888k/64512k available (723k kernel code, 2236k reserved, 83k data, 72k init, 0k highmem). Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes). Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes). Page-cache hash table entries: 16384 (order: 4, 65536 bytes). kmem_create: Poisoning requested, but con given - bdev_cache. Inode-cache hash table entries: 4096 (order: 3, 32768 bytes). kmem_create: Poisoning requested, but con given - inode_cache. CPU serial number disabled.. Checking 386/387 coupling... OK, FPU using exception 16 error reporting.. Enabling fast FPU save and restore... done.. Enabling unmasked SIMD FPU exception support... done.. Checking SIMD FPU exceptions... OK, SIMD FPU using exception 19 error reporting.. Checking 'hlt' instruction... OK.. POSIX conformance testing by UNIFIX. mtrr: v1.36 (20000221) Richard Gooch (rgooch(a)atnf.csiro.au). CPU serial number disabled.. CPU0: Intel Pentium III (Katmai) stepping 03. per-CPU timeslice cutoff: 0.00 usecs.. Getting VERSION: 40011. Getting VERSION: 40011. Getting LVT0: 700. Getting LVT1: 400. enabled ExtINT on CPU#0. ESR value before enabling vector: 00000000. ESR value after enabling vector: 00000000. CPU present map: 3. Booting processor 1/0 eip 2000. Setting warm reset code and vector.. 1.. 2.. 3.. Asserting INIT.. Waiting for send to finish.... +Deasserting INIT.. Waiting for send to finish.... +#startup loops: 2.. Sending STARTUP #1.. After apic_write.. Startup point 1.. Waiting for send to finish.... +Initializing CPU#1. Sending STARTUP #2.. After apic_write.. Startup point 1.. Waiting for send to finish.... +CPU#1 (phys ID: 0) waiting for CALLOUT. After Startup.. Before Callout 1.. After Callout 1.. CALLIN, before setup_local_APIC().. masked ExtINT on CPU#1. ESR value before enabling vector: 00000000. ESR value after enabling vector: 00000000. Calibrating delay loop... unexpected IRQ trap at vector 31. unexpected IRQ trap at vector 31. unexpected IRQ trap at vector 31. unexpected IRQ trap at vector 31. unexpected IRQ trap at vector 31. unexpected IRQ trap at vector 31. unexpected IRQ trap at vector 31. unexpected IRQ trap at vector 31. unexpected IRQ trap at vector 31. unexpected IRQ trap at vector 31. unexpected IRQ trap at vector 31. unexpected IRQ trap at vector 31. unexpected IRQ trap at vector 31. unexpected IRQ trap at vector 31. unexpected IRQ trap at vector 31. unexpected IRQ trap at vector 31. unexpected IRQ trap at vector 31. unexpected IRQ trap at vector 31. unexpected IRQ trap at vector 31. unexpected IRQ trap at vector 31. unexpected IRQ trap at vector 31. unexpected IRQ trap at vector 31. unexpected IRQ trap at vector 31. 992.87 BogoMIPS. Stack at about c112bfbc. CPU serial number disabled.. unexpected IRQ trap at vector 31. OK.. CPU1: Intel Pentium III (Katmai) stepping 03. CPU has booted.. Before bogomips.. Total of 2 processors activated (1982.46 BogoMIPS).. Before bogocount - setting activated=1.. Boot done.. ENABLING IO-APIC IRQs. ...changing IO-APIC physical APIC ID to 2 ... ok.. Synchronizing Arb IDs.. init IO_APIC IRQs. IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected.. ..TIMER: vector=49 pin1=2 pin2=0. activating NMI Watchdog ... done.. number of MP IRQ sources: 16.. number of IO-APIC #2 registers: 24.. testing the IO APIC........................ . IO APIC #2....... .... register #00: 02000000. ....... : physical APIC id: 02. .... register #01: 00170011. ....... : max redirection entries: 0017. ....... : IO APIC version: 0011. .... register #02: 00000000. ....... : arbitration: 00. .... IRQ redirection table:. NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: . 00 000 00 1 0 0 0 0 0 0 00. 01 003 03 0 0 0 0 0 1 1 39. 02 003 03 0 0 0 0 0 1 1 31. 03 003 03 0 0 0 0 0 1 1 41. 04 003 03 0 0 0 0 0 1 1 49. 05 003 03 0 0 0 0 0 1 1 51. 06 003 03 0 0 0 0 0 1 1 59. 07 003 03 0 0 0 0 0 1 1 61. 08 003 03 0 0 0 0 0 1 1 69. 09 003 03 0 0 0 0 0 1 1 71. 0a 003 03 0 0 0 0 0 1 1 79. 0b 003 03 0 0 0 0 0 1 1 81. 0c 003 03 0 0 0 0 0 1 1 89. 0d 000 00 1 0 0 0 0 0 0 00. 0e 003 03 0 0 0 0 0 1 1 91. 0f 003 03 0 0 0 0 0 1 1 99. 10 000 00 1 0 0 0 0 0 0 00. 11 000 00 1 0 0 0 0 0 0 00. 12 000 00 1 0 0 0 0 0 0 00. 13 000 00 1 0 0 0 0 0 0 00. 14 000 00 1 0 0 0 0 0 0 00. 15 000 00 1 0 0 0 0 0 0 00. 16 000 00 1 0 0 0 0 0 0 00. 17 000 00 1 0 0 0 0 0 0 00. IRQ to pin mappings:. IRQ0 -> 2. IRQ1 -> 1. IRQ3 -> 3. IRQ4 -> 4. IRQ5 -> 5. IRQ6 -> 6. IRQ7 -> 7. IRQ8 -> 8. IRQ9 -> 9. IRQ10 -> 10. IRQ11 -> 11. IRQ12 -> 12. IRQ13 -> 13. IRQ14 -> 14. IRQ15 -> 15. .................................... done.. calibrating APIC timer .... ..... CPU clock speed is 497.3914 MHz.. ..... host bus clock speed is 99.4782 MHz.. cpu: 0, clocks: 994782, slice: 331594. CPU0<T0:994768,T1:663168,D:6,S:331594,C:994782>. cpu: 1, clocks: 994782, slice: 331594. CPU1<T0:994768,T1:331568,D:12,S:331594,C:994782>. checking TSC synchronization across CPUs: passed.. Setting commenced=1, go go go. mtrr: your CPUs had inconsistent fixed MTRR settings. mtrr: your CPUs had inconsistent variable MTRR settings. mtrr: your CPUs had inconsistent MTRRdefType settings. mtrr: probably your BIOS does not setup all CPUs. PCI: Using configuration type 1. PCI: Probing PCI hardware. Linux NET4.0 for Linux 2.3. Based upon Swansea University Computer Society NET3.039. kmem_create: Poisoning requested, but con given - skbuff_head_cache. Starting kswapd v1.6. PCI: No IRQ known for interrupt pin A of device 00:09.0. Probably buggy MP table.. matroxfb: Matrox Millennium II (PCI) detected. matroxfb: MTRR's turned on. matroxfb: 640x480x8bpp (virtual: 640x13081). matroxfb: framebuffer at 0xA5000000, mapped to 0xc4805000, size 8388608. Console: switching to colour frame buffer device 80x30. fb0: MATROX VGA frame buffer device. Uniform Multi-Platform E-IDE driver Revision: 6.31. ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx. hd0: C/H/S=0/0/0 from BIOS ignored. hda: 0MB, CHS=0/0/0. Real Time Clock Driver v1.10c. end_request: I/O error, dev 03:01 (hard disk), sector 2. EXT2-fs: unable to read superblock. Kernel panic: VFS: Unable to mount root fs on 03:01............. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

5 8

L2 cache
by Ronald G Minnich 04 Jul '00

04 Jul '00

In case I did not mention it: we aren't turning on L2 cache. We need to figure this one out. All hints gratefully accepted ... ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 3

winfast 6300, PIII
by Ronald G Minnich 03 Jul '00

03 Jul '00

I just took the romimage for linuxbios and plugged it into the winfast 6300 board. This is the identical image to the one that works for the procomm bst1b. It works! we now have two sis630 mainboards up (but with no L2 ... :-( ) ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

L2 cache
by Ronald G Minnich 01 Jul '00

01 Jul '00

A quick run with lmbench shows we're not turning it on. Any ideas? ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

IO-APIC
by James Hendricks 30 Jun '00

30 Jun '00

I don't think our IO-APIC is enabled.. We tell it to set its ID to 2, but it continues to think its ID is F. Here is the kernel panic: ENABLING IO-APIC IRQs. ...changing IO-APIC physical APIC ID to 2 ... Kernel panic: could not set ID!. . In idle task - not syncing. APIC error interrupt on CPU#0, should never happen.. ... APIC ESR0: 00000000. ... APIC ESR1: 00000040. ... bit 6: Received Illegal Vector Does anyone know how to setup the IO-APIC correctly and/or know where I can find this information (Maciej, you wrote io_apic.c, right?)? Any help would be greatly appreciated. Thanks. - James >>>>>> Here is the full boot so far: Linux version 2.4.0-test1 (jimi@snaresland) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #7 SMP Mon Jun 26 16:46:02 MDT 2000. BIOS-provided physical RAM map:. e820: 000000000009f000 @ 0000000000000000 (usable). e820: 0000000003e00000 @ 0000000000100000 (usable). Scan SMP from c0000000 for 1024 bytes.. found SMP MP-table at 00000000. hm, page 00000000 reserved twice.. On node 0 totalpages: 16128. zone(0): 4096 pages.. zone(1): 12032 pages.. zone(2): 0 pages.. Intel MultiProcessor Specification v1.4. Virtual Wire compatibility mode.. Default MP configuration #5. Processor #0 Pentium(tm) Pro APIC version 16. Floating point unit present.. Machine Exception supported.. 64 bit compare & exchange supported.. Internal APIC present.. Processor #1 Pentium(tm) Pro APIC version 16. Floating point unit present.. Machine Exception supported.. 64 bit compare & exchange supported.. Internal APIC present.. Bus #0 is ISA . Bus #1 is PCI . I/O APIC #2 Version 16 at 0xFEC00000.. Int: type 0, pol 0, trig 0, bus 0, IRQ 00, APIC ID 2, APIC INT 02. Int: type 0, pol 0, trig 0, bus 0, IRQ 01, APIC ID 2, APIC INT 01. Int: type 0, pol 0, trig 0, bus 0, IRQ 03, APIC ID 2, APIC INT 03. Int: type 0, pol 0, trig 0, bus 0, IRQ 04, APIC ID 2, APIC INT 04. Int: type 0, pol 0, trig 0, bus 0, IRQ 05, APIC ID 2, APIC INT 05. Int: type 0, pol 0, trig 0, bus 0, IRQ 06, APIC ID 2, APIC INT 06. Int: type 0, pol 0, trig 0, bus 0, IRQ 07, APIC ID 2, APIC INT 07. Int: type 0, pol 0, trig 0, bus 0, IRQ 08, APIC ID 2, APIC INT 08. Int: type 0, pol 0, trig 0, bus 0, IRQ 09, APIC ID 2, APIC INT 09. Int: type 0, pol 0, trig 0, bus 0, IRQ 0a, APIC ID 2, APIC INT 0a. Int: type 0, pol 0, trig 0, bus 0, IRQ 0b, APIC ID 2, APIC INT 0b. Int: type 0, pol 0, trig 0, bus 0, IRQ 0c, APIC ID 2, APIC INT 0c. Int: type 0, pol 0, trig 0, bus 0, IRQ 0d, APIC ID 2, APIC INT 0d. Int: type 0, pol 0, trig 0, bus 0, IRQ 0e, APIC ID 2, APIC INT 0e. Int: type 0, pol 0, trig 0, bus 0, IRQ 0f, APIC ID 2, APIC INT 0f. Int: type 3, pol 0, trig 0, bus 0, IRQ 00, APIC ID 2, APIC INT 00. Lint: type 3, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 00. Lint: type 1, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 01. Processors: 2. mapped APIC to ffffe000 (fee00000). James: boot_cpu_id being set to 2016 from APIC_ID. mapped IOAPIC to ffffd000 (fec00000). Enabling extended fast FPU save and restore ... done.. Enabling KNI unmasked exception support ... done.. Kernel command line: root=/dev/hda1 ide0=reset. Initializing CPU#0. Detected 497445265 Hz processor.. Calibrating delay loop... 992.87 BogoMIPS. Memory: 61980k/64512k available (585k kernel code, 2144k reserved, 69k data, 156k init, 0k highmem). Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes). Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes). Page-cache hash table entries: 16384 (order: 4, 65536 bytes). kmem_create: Poisoning requested, but con given - bdev_cache. Inode-cache hash table entries: 4096 (order: 3, 32768 bytes). kmem_create: Poisoning requested, but con given - inode_cache. CPU serial number disabled.. Checking 386/387 coupling... OK, FPU using exception 16 error reporting.. Checking 'hlt' instruction... OK.. POSIX conformance testing by UNIFIX. mtrr: v1.36 (20000221) Richard Gooch (rgooch(a)atnf.csiro.au). CPU serial number disabled.. CPU0: Intel Pentium III (Katmai) stepping 03. per-CPU timeslice cutoff: 0.00 usecs.. Getting VERSION: 40011. Getting VERSION: 40011. Getting LVT0: 700. Getting LVT1: 400. enabled ExtINT on CPU#0. ESR value before enabling vector: 00000000. ESR value after enabling vector: 00000000. CPU present map: 3. Booting processor 1/0 eip 2000. Setting warm reset code and vector.. 1.. 2.. 3.. Asserting INIT.. Waiting for send to finish.... +Deasserting INIT.. Waiting for send to finish.... +#startup loops: 2.. Sending STARTUP #1.. After apic_write.. Startup point 1.. Waiting for send to finish.... +Initializing CPU#1. Sending STARTUP #2.. After apic_write.. Startup point 1.. CPU#1 (phys ID: 0) waiting for CALLOUT. Waiting for send to finish.... +After Startup.. Before Callout 1.. After Callout 1.. CALLIN, before setup_local_APIC().. masked ExtINT on CPU#1. ESR value before enabling vector: 00000000. ESR value after enabling vector: 00000000. Calibrating delay loop... 992.87 BogoMIPS. Stack at about c116dfbc. CPU serial number disabled.. OK.. CPU1: Intel Pentium III (Katmai) stepping 03. CPU has booted.. Before bogomips.. Total of 2 processors activated (1985.74 BogoMIPS).. Before bogocount - setting activated=1.. Boot done.. ENABLING IO-APIC IRQs. ...changing IO-APIC physical APIC ID to 2 ... Kernel panic: could not set ID!. . In idle task - not syncing. APIC error interrupt on CPU#0, should never happen.. ... APIC ESR0: 00000000. ... APIC ESR1: 00000040. ... bit 6: Received Illegal Vector - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

4 4

visitor
by ronnie-liu＠ali.com.tw 23 Jun '00

23 Jun '00

Hi: I found the OpenBIOS web site when surfing the internet. I am interesting in this topic. Is this project still going? Ronnie - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

RE: [OpenBIOS] Finding FlashROM chips?
by Jessen, Per 22 Jun '00

22 Jun '00

www.questlink.com regards, Per Jessen, ENIDAN Technologies, London > -----Original Message----- > From: Jeff Garzik [mailto:jgarzik@mandrakesoft.com] > Sent: 21 June 2000 16:06 > To: freebios-devel(a)sourceforge.net > Cc: openbios(a)elvis.informatik.uni-freiburg.de > Subject: [OpenBIOS] Finding FlashROM chips? > > > Can anybody point to a source of flashrom chips on the web? > Preferably > a US supplier since I don't want to ship overseas if I can avoid it.. > > Jeff > > > > > -- > Jeff Garzik | > Building 1024 | Free beer tomorrow. > MandrakeSoft, Inc. | > - > 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: Information on TIARA project
by Ollie Lho 22 Jun '00

22 Jun '00

"Larry G. Linde" wrote: > > We are working on a 540 design at present and need to start porting to the > 540/950 chipset. > > However we have not been able to find any off the shelf MB's with the 540 > yet. If you could get > Us the name of a existing 540 MB with the 950 that we could buy that would > help a lot. Also > And code/doc info in setup that required on the 540/950 would help as well. > > If you would like I will be in TW in about 2 weeks. I can stop by and say > hello and show you > What we are doing. > > -larry First of all, it is amazing (from our point of view) that without official support you could do such chip init stuff so clean, how did you do this ?? As you know we are working with FreeBIOS/LinuxBIOS project, we are also intrested in any similiar projects too. We will provide any support we can, we will provide you the necessary documents, BIOS source/pseudo code and hardware demo boards. As posted by Jeff Garzik et. al. on freebios list we think there is possibility to cooperate/merge these free bios projects. For 540+950 issue, there are two things to note. First is that, from business point of view, it seems that 540 chipset will not in mass production in the near future so it would be very difficult to find a 540 M/B in the market. We are rather focusing on 630 and the upcomming 730 series. As far as I know there is only WinFast 5400MA avaliable in Taiwan market. The second is that, of course we want our whole product line fully supported. I am personally planing to have full support (i.e. boot from cold power up without BIOS) for the following combination in the end of August (possible ??) 630/540 single chip + 950 LPC 620/530 north + 5595 sourth + 6801 SuperIO so we need somebody to "port" or try the current implementation on these different platforms. Finally, it glad that you are going to visit Taiwan. If you have time, please arrange to visit SiS and demo your work. We can show you how/what we have done on LinuxBIOS side. Ollie - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

5 5

another free bios project
by gram wilson 21 Jun '00

21 Jun '00

I just came across this project at SourceForge: Talkware TIARA, an Openbios/GRUB/PFORTH composite, BIOS replacement. Boots an unmodifed linux kernel from an IDE drive or ethernet, using only 128kb of flash. Works with INTEL/AMD K6/2-450, SiS 530/5595 and 8139 enet. VGA & Serial console supported. and was wondering if anybody had heard of it? It got me thinking that maybe all of the free bios developers (this project, freebios, openbios, linuxbios) should get together and collaborate on features. This way there would be more developers, which could mean accelerated development, better features, and more testing. Also, I would like to thank all of the people who work on these projects now, because a free/open source bios is something we all really need. -gram - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

5 5

TIARA URL
by Ed Dantes 20 Jun '00

20 Jun '00

Hi Joerg The only URL for TIARA seems to be http://sourceforge.net/projects/utcboot/ Have fun Ed - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Log_bufs
by James V Hendricks 20 Jun '00

20 Jun '00

OK. Another snapshot. What worries me is the per-cpu timeslice cutoff being listed as 0 usecs. The 'kernel bug' means that either the APIC is not on still or that we don't set boot_cpu_id correctly; the line is: if (GET_APIC_ID(apic_read(APIC_ID)) != boot_cpu_id) BUG(); Furthermore, if I skip the check, I get the following message: APIC error interrupt on CPU#0, should never happen.. ... APIC ESR0: 00000080. ... APIC ESR1: 00000080. ... bit 7: Illegal Register Address.. APIC error interrupt on CPU#0, should never happen.. ... APIC ESR0: 00000080. ... APIC ESR1: 00000080. ... bit 7: Illegal Register Address.. APIC error interrupt on CPU#0, should never happen.. ... APIC ESR0: 00000080. ... APIC ESR1: 00000080. ... bit 7: Illegal So here is where SMP boot is at now: Linux version 2.3.99-pre5 (rminnich@mini) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #57 SMP Mon Jun 19 17:40:30 MDT 2000. initially ALT_MEM_K is 0xf800, EXT_MEM_K is 0x3c00, E820_MAP_NR is 0x0. initially command line is root=/dev/hda1 ide0=reset. ALT_MEM_K is 0xf800, EXT_MEM_K is 0x3c00, E820_MAP_NR is 0x0. Scan SMP from c0000000 for 1024 bytes.. found SMP MP-table at 00000000. hm, page 00000000 reserved twice.. On node 0 totalpages: 16128. zone(0): 4096 pages.. zone(1): 12032 pages.. zone(2): 0 pages.. Intel MultiProcessor Specification v1.4. Virtual Wire compatibility mode.. Default MP configuration #5. Bus #0 is ISA. Bus #1 is PCI. Processors: 2. mapped APIC to ffffe000 (fee00000). mapped IOAPIC to ffffd000 (fec00000). Initializing CPU#0. Detected 497440714 Hz processor.. ide_setup: ide0=reset. Console: colour VGA+ 80x25. Calibrating delay loop... 989.59 BogoMIPS. Memory: 61356k/64512k available (898k kernel code, 2768k reserved, 96k data, 84k init, 0k highmem). Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes). Page-cache hash table entries: 16384 (order: 4, 65536 bytes). Pentium-III serial number disabled.. Checking 386/387 coupling... OK, FPU using exception 16 error reporting.. Checking 'hlt' instruction... OK.. POSIX conformance testing by UNIFIX. mtrr: v1.36 (20000221) Richard Gooch (rgooch(a)atnf.csiro.au). Pentium-III serial number disabled.. CPU0: Intel Pentium III (Katmai) stepping 03. per-CPU timeslice cutoff: 0.00 usecs.. Getting VERSION: 40011. Getting VERSION: 40011. Getting LVT0: 700. Getting LVT1: 400. enabled ExtINT on CPU#0. ESR value before enabling vector: 00000000. ESR value after enabling vector: 00000000. kernel BUG at smpboot.c:864! - James - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

AW: [OpenBIOS] another free bios project
by Winter Jörg 20 Jun '00

20 Jun '00

> ---------- > Von: gram wilson[SMTP:kwyjibo@flashcom.net] > Antwort an: openbios(a)freiburg.linux.de > Gesendet: Dienstag, 20. Juni 2000 17:45 > An: openbios(a)elvis.informatik.uni-freiburg.de > Betreff: [OpenBIOS] another free bios project > > I just came across this project at SourceForge: > > Talkware TIARA, an Openbios/GRUB/PFORTH composite, BIOS replacement. ... I cant find TIARA on the net. Can you post the url please ? Thanx. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

SMP Bootup
by James V Hendricks 20 Jun '00

20 Jun '00

Here is what I get on SMP bootup.. It goes into an infinite loop at the end. I generated the default MP tables on my own. Any suggestions? - James Linux version 2.4.0-test1 (jimi@yellow) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #41 SMP Fri Jun 16 11:38:58 MDT 2000. BIOS-provided physical RAM map:. e820: 000000000009f000 @ 0000000000000000 (usable). e820: 0000000003e00000 @ 0000000000100000 (usable). James: Generating my own MP Floating Pointer table kmem_alloc: NULL ptr (name=unknown). On node 0 totalpages: 16128. zone(0): 4096 pages.. zone(1): 12032 pages.. zone(2): 0 pages.. Intel MultiProcessor Specification v1.4. Virtual Wire compatibility mode.. Default MP configuration #5. Processor #0 Pentium(tm) Pro APIC version 16. Floating point unit present.. Machine Exception supported.. 64 bit compare & exchange supported.. Processor #1 Pentium(tm) Pro APIC version 16. Floating point unit present.. Machine Exception supported.. 64 bit compare & exchange supported.. Bus #0 is ISA . Bus #1 is PCI . I/O APIC #2 Version 16 at 0xFEC00000.. Int: type 0, pol 0, trig 0, bus 0, IRQ 00, APIC ID 2, APIC INT 02. Int: type 0, pol 0, trig 0, bus 0, IRQ 01, APIC ID 2, APIC INT 01. Int: type 0, pol 0, trig 0, bus 0, IRQ 03, APIC ID 2, APIC INT 03. Int: type 0, pol 0, trig 0, bus 0, IRQ 04, APIC ID 2, APIC INT 04. Int: type 0, pol 0, trig 0, bus 0, IRQ 05, APIC ID 2, APIC INT 05. Int: type 0, pol 0, trig 0, bus 0, IRQ 06, APIC ID 2, APIC INT 06. Int: type 0, pol 0, trig 0, bus 0, IRQ 07, APIC ID 2, APIC INT 07. Int: type 0, pol 0, trig 0, bus 0, IRQ 08, APIC ID 2, APIC INT 08. Int: type 0, pol 0, trig 0, bus 0, IRQ 09, APIC ID 2, APIC INT 09. Int: type 0, pol 0, trig 0, bus 0, IRQ 0a, APIC ID 2, APIC INT 0a. Int: type 0, pol 0, trig 0, bus 0, IRQ 0b, APIC ID 2, APIC INT 0b. Int: type 0, pol 0, trig 0, bus 0, IRQ 0c, APIC ID 2, APIC INT 0c. Int: type 0, pol 0, trig 0, bus 0, IRQ 0d, APIC ID 2, APIC INT 0d. Int: type 0, pol 0, trig 0, bus 0, IRQ 0e, APIC ID 2, APIC INT 0e. Int: type 0, pol 0, trig 0, bus 0, IRQ 0f, APIC ID 2, APIC INT 0f. Int: type 3, pol 0, trig 0, bus 0, IRQ 00, APIC ID 2, APIC INT 00. Lint: type 3, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 00. Lint: type 1, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 01. Processors: 2. James: a) 1 b) 3 c) 16 d) 16 e) fee00000. mapped APIC to ffffe000 (fee00000). mapped IOAPIC to ffffd000 (fec00000). Enabling extended fast FPU save and restore ... done.. Enabling KNI unmasked exception support ... done.. Kernel command line: root=/dev/hda1 ide0=reset. Initializing CPU#0. Detected 497438524 Hz processor.. Console: colour dummy device 80x25. Calibrating delay loop... 989.59 BogoMIPS. Memory: 61860k/64512k available (643k kernel code, 2264k reserved, 82k data, 180k init, 0k highmem). Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes). Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes). Page-cache hash table entries: 16384 (order: 4, 65536 bytes). kmem_create: Poisoning requested, but con given - bdev_cache. Inode-cache hash table entries: 4096 (order: 3, 32768 bytes). kmem_create: Poisoning requested, but con given - inode_cache. CPU serial number disabled.. Checking 386/387 coupling... OK, FPU using exception 16 error reporting.. Checking 'hlt' instruction... OK.. POSIX conformance testing by UNIFIX. mtrr: v1.36 (20000221) Richard Gooch (rgooch(a)atnf.csiro.au). CPU serial number disabled.. CPU0: Intel Pentium III (Katmai) stepping 03. per-CPU timeslice cutoff: 0.00 usecs.. weird, boot CPU (#15) not listed by the BIOS.. Getting VERSION: ffffffff. Getting VERSION: ffffffff. Getting LVT0: ffffffff. Getting LVT1: ffffffff. masked ExtINT on CPU#0. ESR value before enabling vector: ffffffff. ESR value after enabling vector: ffffffff. CPU present map: 8003. Booting processor 1/0 eip 2000. Setting warm reset code and vector.. 1.. 2.. 3.. Asserting INIT.. Waiting for send to finish.... + On Fri, 16 Jun 2000, Ronald G Minnich wrote: > on the SiS, 512Kb-64Kb. On the intel, well maybe that too. > > It's all driven by the damned NVRAM flasher program. > > what you at? > > cell: 505 699 0502, landline is 302 478 5291 except I'm using it for 10 > more minutes. > > ron > > > - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

4 6

Try again
by James V Hendricks 16 Jun '00

16 Jun '00

These are the _real_ logbufs. Ignore the last one I sent. Any ideas? - James This is straight out of NVRAM; it halts early: >>>>>> Linux version 2.4.0-test1 (jimi@yellow) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #41 SMP Fri Jun 16 11:38:58 MDT 2000. BIOS-provided physical RAM map:. e820: 000000000009f000 @ 0000000000000000 (usable). e820: 0000000003e00000 @ 0000000000100000 (usable). James: Generating my own MP Floating Pointer table kmem_alloc: NULL ptr (name=unknown). On node 0 totalpages: 16128. zone(0): 4096 pages.. zone(1): 12032 pages.. zone(2): 0 pages.. Intel MultiProcessor Specification v1.4. Virtual Wire compatibility mode.. Default MP configuration #5. Processor #0 Pentium(tm) Pro APIC version 16. Floating point unit present.. Machine Exception supported.. 64 bit compare & exchange supported.. Processor #1 Pentium(tm) Pro APIC version 16. Floating point unit present.. Machine Exception supported.. 64 bit compare & exchange supported.. Bus #0 is ISA . Bus #1 is PCI . I/O APIC #2 Version 16 at 0xFEC00000.. Int: type 0, pol 0, trig 0, bus 0, IRQ 00, APIC ID 2, APIC INT 02. Int: type 0, pol 0, trig 0, bus 0, IRQ 01, APIC ID 2, APIC INT 01. Int: type 0, pol 0, trig 0, bus 0, IRQ 03, APIC ID 2, APIC INT 03. Int: type 0, pol 0, trig 0, bus 0, IRQ 04, APIC ID 2, APIC INT 04. Int: type 0, pol 0, trig 0, bus 0, IRQ 05, APIC ID 2, APIC INT 05. Int: type 0, pol 0, trig 0, bus 0, IRQ 06, APIC ID 2, APIC INT 06. Int: type 0, pol 0, trig 0, bus 0, IRQ 07, APIC ID 2, APIC INT 07. Int: type 0, pol 0, trig 0, bus 0, IRQ 08, APIC ID 2, APIC INT 08. Int: type 0, pol 0, trig 0, bus 0, IRQ 09, APIC ID 2, APIC INT 09. Int: type 0, pol 0, trig 0, bus 0, IRQ 0a, APIC ID 2, APIC INT 0a. Int: type 0, pol 0, trig 0, bus 0, IRQ 0b, APIC ID 2, APIC INT 0b. Int: type 0, pol 0, trig 0, bus 0, IRQ 0c, APIC ID 2, APIC INT 0c. Int: type 0, pol 0, trig 0, bus 0, IRQ 0d, APIC ID 2, APIC INT 0d. Int: type 0, pol 0, trig 0, bus 0, IRQ 0e, APIC ID 2, APIC INT 0e. Int: type 0, pol 0, trig 0, bus 0, IRQ 0f, APIC ID 2, APIC INT 0f. Int: type 3, pol 0, trig 0, bus 0, IRQ 00, APIC ID 2, APIC INT 00. Lint: type 3, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 00. Lint: type 1, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 01. Processors: 2. James: a) 1 b) 3 c) 16 d) 16 e) fee00000. mapped APIC to ffffe000 (fee00000). mapped IOAPIC to ffffd000 (fec00000). Enabling extended fast FPU save and restore ... done.. Enabling KNI unmasked exception support ... done.. Kernel command line: root=/dev/hda1 ide0=reset. Initializing CPU#0. Detected 497445265 Hz processor.. Console: colour dummy device 80x25. Calibrating delay loop... 989.59 BogoMIPS. Memory: 61860k/64512k available (643k kernel code, 2264k reserved, 82k data, 180k init, 0k highmem). Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes). Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes). Page-cache hash table entries: 16384 (order: 4, 65536 bytes). kmem_create: Poisoning requested, but con given - bdev_cache. Inode-cache hash table entries: 4096 (order: 3, 32768 bytes). kmem_create: Poisoning requested, but con given - inode_cache. CPU serial number disabled.. Checking 386/387 coupling... OK, FPU using exception 16 error reporting.. Checking 'hlt' instruction... OK.. POSIX conformance testing by UNIFIX. mtrr: v1.36 (20000221) Richard Gooch (rgooch(a)atnf.csiro.au). CPU serial number disabled.. CPU0: Intel Pentium III (Katmai) stepping 03. per-CPU timeslice cutoff: 0.00 usecs.. weird, boot CPU (#15) not listed by the BIOS.. Getting VERSION: ffffffff. Getting VERSION: ffffffff. Getting LVT0: ffffffff. Getting LVT1: ffffffff. masked ExtINT on CPU#0. ESR value before enabling vector: ffffffff. ESR value after enabling vector: ffffffff. CPU present map: 8003. Booting processor 1/0 eip 2000. Setting warm reset code and vector.. 1.. 2.. 3.. Asserting INIT.. Waiting for send to finish.... ++++++++++++++++++++++++++ Deasserting INIT.. Waiting for send to finish.... ++++++++++++++++++++++++++ #startup loops: 2.. Sending STARTUP #1.. After apic_write.. Startup point 1.. Waiting for send to finish.... ++++++++++++++++++++++++++ After Startup.. APIC never delivered???. APIC delivery error (ef).. phys CPU #0 not responding - cannot use it.. Booting processor 1/1 eip 2000. Setting warm reset code and vector.. 1.. 2.. 3.. Asserting INIT.. Waiting for send to finish.... ++++++++++++++++++++++++++ Deasserting INIT.. Waiting for send to finish.... ++++++++++++++++++++++++++ #startup loops: 2.. Sending STARTUP #1.. After apic_write.. Startup point 1.. Waiting for send to finish.... ++++++++++++++++++++++++++ After Startup.. APIC never delivered???. APIC delivery error (ef).. phys CPU #1 not responding - cannot use it.. Before bogomips.. Error: only one processor found.. Boot done.. ENABLING IO-APIC IRQs. ...changing IO-APIC physical APIC ID to 2 ... Kernel panic: could not set ID!. . In idle task - not syncing This is after a BIOS boot via LILO. It works (up until the disk panic, but that is OK). >>>>>> Linux version 2.4.0-test1 (jimi@yellow) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #41 SMP Fri Jun 16 11:38:58 MDT 2000. BIOS-provided physical RAM map:. e820: 000000000009f800 @ 0000000000000000 (usable). e820: 0000000000000800 @ 000000000009f800 (reserved). e820: 0000000000018000 @ 00000000000e8000 (reserved). e820: 000000000fef0000 @ 0000000000100000 (usable). e820: 000000000000fc00 @ 000000000fff0000 (ACPI data). e820: 0000000000000400 @ 000000000ffffc00 (ACPI NVS). e820: 0000000000010000 @ 00000000fec00000 (reserved). e820: 0000000000001000 @ 00000000fee00000 (reserved). e820: 0000000000080000 @ 00000000fff80000 (reserved). James: Generating my own MP Floating Pointer table kmem_alloc: NULL ptr (name=unknown). On node 0 totalpages: 65520. zone(0): 4096 pages.. zone(1): 61424 pages.. zone(2): 0 pages.. Intel MultiProcessor Specification v1.4. Virtual Wire compatibility mode.. Default MP configuration #5. Processor #0 Pentium(tm) Pro APIC version 16. Floating point unit present.. Machine Exception supported.. 64 bit compare & exchange supported.. Internal APIC present.. Processor #1 Pentium(tm) Pro APIC version 16. Floating point unit present.. Machine Exception supported.. 64 bit compare & exchange supported.. Internal APIC present.. Bus #0 is ISA . Bus #1 is PCI . I/O APIC #2 Version 16 at 0xFEC00000.. Int: type 0, pol 0, trig 0, bus 0, IRQ 00, APIC ID 2, APIC INT 02. Int: type 0, pol 0, trig 0, bus 0, IRQ 01, APIC ID 2, APIC INT 01. Int: type 0, pol 0, trig 0, bus 0, IRQ 03, APIC ID 2, APIC INT 03. Int: type 0, pol 0, trig 0, bus 0, IRQ 04, APIC ID 2, APIC INT 04. Int: type 0, pol 0, trig 0, bus 0, IRQ 05, APIC ID 2, APIC INT 05. Int: type 0, pol 0, trig 0, bus 0, IRQ 06, APIC ID 2, APIC INT 06. Int: type 0, pol 0, trig 0, bus 0, IRQ 07, APIC ID 2, APIC INT 07. Int: type 0, pol 0, trig 0, bus 0, IRQ 08, APIC ID 2, APIC INT 08. Int: type 0, pol 0, trig 0, bus 0, IRQ 09, APIC ID 2, APIC INT 09. Int: type 0, pol 0, trig 0, bus 0, IRQ 0a, APIC ID 2, APIC INT 0a. Int: type 0, pol 0, trig 0, bus 0, IRQ 0b, APIC ID 2, APIC INT 0b. Int: type 0, pol 0, trig 0, bus 0, IRQ 0c, APIC ID 2, APIC INT 0c. Int: type 0, pol 0, trig 0, bus 0, IRQ 0d, APIC ID 2, APIC INT 0d. Int: type 0, pol 0, trig 0, bus 0, IRQ 0e, APIC ID 2, APIC INT 0e. Int: type 0, pol 0, trig 0, bus 0, IRQ 0f, APIC ID 2, APIC INT 0f. Int: type 3, pol 0, trig 0, bus 0, IRQ 00, APIC ID 2, APIC INT 00. Lint: type 3, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 00. Lint: type 1, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 01. Processors: 2. James: a) 1 b) 3 c) 16 d) 16 e) fee00000. mapped APIC to ffffe000 (fee00000). mapped IOAPIC to ffffd000 (fec00000). Enabling extended fast FPU save and restore ... done.. Enabling KNI unmasked exception support ... done.. Kernel command line: BOOT_IMAGE=james ro root=301. Initializing CPU#0. Detected 497444516 Hz processor.. Console: colour dummy device 80x25. Calibrating delay loop... 992.87 BogoMIPS. Memory: 255944k/262080k available (643k kernel code, 5748k reserved, 82k data, 180k init, 0k highmem). Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes). Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes). Page-cache hash table entries: 65536 (order: 6, 262144 bytes). kmem_create: Poisoning requested, but con given - bdev_cache. Inode-cache hash table entries: 16384 (order: 5, 131072 bytes). kmem_create: Poisoning requested, but con given - inode_cache. CPU serial number disabled.. Checking 386/387 coupling... OK, FPU using exception 16 error reporting.. Checking 'hlt' instruction... OK.. POSIX conformance testing by UNIFIX. mtrr: v1.36 (20000221) Richard Gooch (rgooch(a)atnf.csiro.au). CPU serial number disabled.. CPU0: Intel Pentium III (Katmai) stepping 03. per-CPU timeslice cutoff: 1428.64 usecs.. Getting VERSION: 40011. Getting VERSION: 40011. Getting LVT0: 700. Getting LVT1: 400. enabled ExtINT on CPU#0. ESR value before enabling vector: 00000000. ESR value after enabling vector: 00000000. CPU present map: 3. Booting processor 1/0 eip 2000. Setting warm reset code and vector.. 1.. 2.. 3.. Asserting INIT.. Waiting for send to finish.... +Deasserting INIT.. Waiting for send to finish.... +#startup loops: 2.. Sending STARTUP #1.. After apic_write.. Startup point 1.. Waiting for send to finish.... Initializing CPU#1. +CPU#1 (phys ID: 0) waiting for CALLOUT. Sending STARTUP #2.. After apic_write.. Startup point 1.. Waiting for send to finish.... +After Startup.. Before Callout 1.. After Callout 1.. CALLIN, before setup_local_APIC().. masked ExtINT on CPU#1. ESR value before enabling vector: 00000000. ESR value after enabling vector: 00000000. Calibrating delay loop... 992.87 BogoMIPS. Stack at about c148dfbc. CPU serial number disabled.. OK.. CPU1: Intel Pentium III (Katmai) stepping 03. CPU has booted.. Before bogomips.. Total of 2 processors activated (1985.74 BogoMIPS).. Before bogocount - setting activated=1.. Boot done.. ENABLING IO-APIC IRQs. ...changing IO-APIC physical APIC ID to 2 ... ok.. Synchronizing Arb IDs.. init IO_APIC IRQs. IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected.. ..TIMER: vector=49 pin1=2 pin2=0. activating NMI Watchdog ... done.. number of MP IRQ sources: 16.. number of IO-APIC #2 registers: 24.. testing the IO APIC........................ . IO APIC #2....... .... register #00: 02000000. ....... : physical APIC id: 02. .... register #01: 00170011. ....... : max redirection entries: 0017. ....... : IO APIC version: 0011. .... register #02: 00000000. ....... : arbitration: 00. .... IRQ redirection table:. NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: . 00 000 00 1 0 0 0 0 0 0 00. 01 003 03 0 0 0 0 0 1 1 39. 02 003 03 0 0 0 0 0 1 1 31. 03 003 03 0 0 0 0 0 1 1 41. 04 003 03 0 0 0 0 0 1 1 49. 05 003 03 0 0 0 0 0 1 1 51. 06 003 03 0 0 0 0 0 1 1 59. 07 003 03 0 0 0 0 0 1 1 61. 08 003 03 0 0 0 0 0 1 1 69. 09 003 03 0 0 0 0 0 1 1 71. 0a 003 03 0 0 0 0 0 1 1 79. 0b 003 03 0 0 0 0 0 1 1 81. 0c 003 03 0 0 0 0 0 1 1 89. 0d 000 00 1 0 0 0 0 0 0 00. 0e 003 03 0 0 0 0 0 1 1 91. 0f 003 03 0 0 0 0 0 1 1 99. 10 000 00 1 0 0 0 0 0 0 00. 11 000 00 1 0 0 0 0 0 0 00. 12 000 00 1 0 0 0 0 0 0 00. 13 000 00 1 0 0 0 0 0 0 00. 14 000 00 1 0 0 0 0 0 0 00. 15 000 00 1 0 0 0 0 0 0 00. 16 000 00 1 0 0 0 0 0 0 00. 17 000 00 1 0 0 0 0 0 0 00. IRQ to pin mappings:. IRQ0 -> 2. IRQ1 -> 1. IRQ3 -> 3. IRQ4 -> 4. IRQ5 -> 5. IRQ6 -> 6. IRQ7 -> 7. IRQ8 -> 8. IRQ9 -> 9. IRQ10 -> 10. IRQ11 -> 11. IRQ12 -> 12. IRQ13 -> 13. IRQ14 -> 14. IRQ15 -> 15. .................................... done.. calibrating APIC timer ... . ..... CPU clock speed is 497.4372 MHz.. ..... host bus clock speed is 99.4872 MHz.. cpu: 0, clocks: 994872, slice: 331624. CPU0<C0:994864,C:663232,D:8,S:331624,C:994872>. cpu: 1, clocks: 994872, slice: 331624. CPU1<C0:994864,C:331616,D:0,S:331624,C:994872>. checking TSC synchronization across CPUs: passed.. Setting commenced=1, go go go. PCI: Using configuration type 1. PCI: Probing PCI hardware. PCI: Discovered primary peer bus ff [IRQ]. PCI: Using IRQ router PIIX [8086/122e] at 00:12.0. Linux NET4.0 for Linux 2.3. Based upon Swansea University Computer Society NET3.039. kmem_create: Poisoning requested, but con given - skbuff_head_cache. Starting kswapd v1.6. VFS: Cannot open root device "301" or 03:01. Please append a correct "root=" boot option. Kernel panic: VFS: Unable to mount root fs on 03:01 - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

[Fwd: Information on TIARA project]
by Ollie Lho 16 Jun '00

16 Jun '00

1 0

[Fwd: Information on TIARA project]
by Ollie Lho 16 Jun '00

16 Jun '00

1 0

Project Status?
by Neil Padgett 15 Jun '00

15 Jun '00

Where can I find information about the status of the project? I looked at the website, but I didn't see much there. Specifically, how far along is handling of FCODE? Thanks, Neil

1 0

Bye the way
by James Hendricks 15 Jun '00

15 Jun '00

Any suggestions on SMP bootup would be appreciated; I think I can get it, but.. I believe I just have to setup arch/i386/smp.c correctly to go without a BIOS. - James - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 1

Yea, You did a GREAT job, Ronald
by Ollie Lho 13 Jun '00

13 Jun '00

Ron, Today we can enter multiuser mode for the first time, thanks to your new kernel patch. The system boots so fast and works as fine as in the traditional BIOS way. One question, how is your current implementation to pass kernel parameter and PCI configuration ?? what are you plan to do to support any kernel without patch ? BTW, I am going to resume doing the devbios driver, hope we can flash the image without the programmer in the near furure. P.S. I will send you the romimage that works on our board. Ollie - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Current Status in SiS Side
by Ollie Lho 12 Jun '00

12 Jun '00

Ron, We can use matroxfb to boot linuxbios on SiS 630 to the point of patittion check. For cold boot, the kernel panic about unable to mount root file system. For warm reboot, the kernel Oops. Why ?? Does this exist on you side ?? I also tried to update the kernel, but it seems that the patch in CVS only works on 2.3.99pre5. Even 2.3.99pre6 fail to turn on the monitor, what's wrong ? Ollie - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 2

SMP Bootup
by James Hendricks 12 Jun '00

12 Jun '00

> All the code I've seen requires that you build either an ACPI table or > an Intel MP 1.x table. I'll assume you meant APIC (Advanced Programmable Interrupt Controller) instead of ACPI. (Isn't that Advanced Computer Power Interface?) Or is ACPI something different? (too many acronyms) Looks like I have to build both APIC and Intel MP tables; I am not too excited about that. I guess I'll just printk() everything and hardwire everything in to start with. I don't even think I need to store the information where the bios would; I just need to assign variables. I have no idea how we are going to do autodetection.. I am working with kernel 2.4.0-test1; the only file I believe I need to edit is mpparse.c. Does this sound right to everybody? - James - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

3 2

[OT] modification of libraries
by Janusz Mlodzianowski 11 Jun '00

11 Jun '00

Hi, Sorry this is slightly off topic. I need to modify standard Turbo C run time libraries made by tlib (cx.lib). All what I need is a change of standard segment names e.g CODE->MY_CODE and TEXT->MY_TEXT. Are there any free tools available? Alternatively, where can I find the information about internal format for Borland lib files? Thanks for any suggestions, janusz - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

linuxbios status
by Ronald G Minnich 10 Jun '00

10 Jun '00

1) we're booting on two machines from power up: SiS 630 (procomp bst1b mainboard) and L440GX+. No intervention needed, they just come up. 2) we've got a first cut at parameter passing from linuxbios to linux. We're passing memory size and are working on cmdline now. cmdline is being placed in the right place. We're gradually removing the #ifdef LINUXBIOS code from our 2.3.99-pre5 kernel. In the limit we should be able to boot any linux. 3) we're working on nvram writes and SMP startup on the L440GX I'm out for the next week so checkins will quiet down. I'm going to check in the tree as of its current state. I'll be watching email, so if you hit a problem let me know. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

keybord.c
by Edwin Rhodes 08 Jun '00

08 Jun '00

hi, what do i have to change in: /usr/src/linux/drivers/char/keyboard.c to make the Numlock come on automatically every time i boot my pc? i've set the bios to put numlock on at boot but every time linux boots i re-initalises the keyboard and turns numlock off.. this is a real pain as i have to keep on remembering to turn it on. thanks edwin

1 0

Re: [fb-d] hda fix
by James Hendricks 08 Jun '00

08 Jun '00

We have jammed the HD controller on; it now works completely from powerup on the Intel and the SiS.. Next steps: 1) Figure out how to write to NVRAM from Linux on the 440 -- this may take a while. 2) Get SCSI up (which means fixing the PCI setup, I believe). 3) Getting CirrusFB to work without a VGA BIOS.. This will be a pain.. 4) Get the Alpha up. 5) Get the ServerWorks (Dell PowerEdge 2450) board up. 6) Get NT to boot (I know everyone hates it, but...) 7) Figure out how to set IDE registers to make it do more than PIO mode. 8) Get parameter passing from LinuxBIOS to Linux so you can boot any Linux Kernel. 9) SMP support. Anything else? This will go onto the web page. Yippee. - James On Thu, 8 Jun 2000, Ronald G Minnich wrote: > For now, we're going a primitive fix to make the kernel wait for hda. > > There's some reference in ide-probe.c to a way to make cmdline args cause > the kernel to wait for the drive to spin up. Anybody know what the arg > is? It's not root=/dev/hda1 .... > > thanks > > ron > > > _______________________________________________ > Freebios-devel mailing list > Freebios-devel(a)lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/freebios-devel > - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

It's there.
by Ronald G Minnich 08 Jun '00

08 Jun '00

you should now see a working SDRAM init for L440gx+ ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

L440GX+ SDRAM
by Ronald G Minnich 08 Jun '00

08 Jun '00

works. James Hendricks and I worked out the last problem today. We'll verify it more tomorrow but it's looking good. I'm updating the cvs tree in a few minutes. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

sis 630 boots to multiuser from nvram from power-on
by Ronald G Minnich 07 Jun '00

07 Jun '00

As of today, for the first time, we're booting to multiuser linux from a power-on. This is on the sis 630. The BIOS is dead! caveats: 1) the sisfb code is not working yet, we're using a matrox again. SiS is working hard on this one. 2) from power on, linux boots so fast that our ide hard disk is not ready, so does not show as present. The cdrom doesn't have such a problem. So you have to hit reset :-( This is going to mean a kernel repair possibly. Not sure. I don't want to handle this in the traditional sleep(3) fashion. There's way too much of that nonsense in Linux already, esp. in /etc/rc.d/* 3) It's only going to use 64M of ram, no matter what you put in there. We're working on that. I've figured out how to have linuxbios pass params to the kernel. Hint: it's not something mentioned on this list yet :-) The image at the sourceforge can be used to generate the romimage that works. The bootup really is shockingly fast, it's quite fun. unrelated news: james hendricks may have fixed SDRAM on the L440GX. Memory seems to be working from power-up. We may have two different machines working by Friday. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 2

VGA BIOS for SiS 630
by Ollie Lho 07 Jun '00

07 Jun '00

Hello Guys, Finally, the vga bios guys provided us their "trimmed" version of VGA BIOS for 630/300. The source code is in MASM and intended to be used for "Standard BIOS" enviroment. Some hard work is necessary for FreeBIOS and LinuxBIOS project. Jeff, Please take a (deep) look at it. We are going to begin another round of sending out M/B since now it is much easier to make things sync with CVS now. Yes, you will get one, I am counting on you to figure those VGA stuff out ;-) Ollie

1 0

boot times on sis630
by Ronald G Minnich 06 Jun '00

06 Jun '00

Linuxbios: 35 seconds. A fraction of a second of this time is linux, the rest is the rc.d scripts. Next job is to fix this mess. BIOS: 87 seconds. 35 seconds as above, plus 52 seconds for the bios to to its thing. such fun. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

SiS 630 Status Udpate
by Ollie Lho 04 Jun '00

04 Jun '00

Ron, Could you please give us the status update on those topic ? DRAM SIZING Could intel_sis630ram.S work on your M/B, does it get corrrect value for ALL three DIMM with Signle/Double sided DRAM ?? SiS' status: yes, all three DIMM and single/double sided DRAM combination ares O.K. Keyboard Can your keybord controller works properly ?? have you monitor port 0x60 to see the scan code you type on keyboard ?? SiS' status: yes, we got correct scan code every time we press the keyboard. Frame Buffer Device Can you use SiSFB or MatroxFB to show the message on monitor ?? If the answer is yes, which Frame Buffer Device are you using ?? How and What is the EXACT procedure to do it ?? SiS' status: no, we can not make SiSFB work under current romimage. We are pushing VGA BIOS group very hard to release the code ASAP. For the moment, we are considering using Matrox FB instead of SiSFB, if you are succeeded in setting up MatroxFB. (We will be back on SiS FB once VGA BIOS provide enough information). PCI configuration (PCI IDE and etc.) Can you init the PCI devices ?? especially PCI IDE ?? since we need PCI IDE to mount root filesystem. CVS configureation What is the progression you and Jeff made in putting LinuxBIOS on FreeBIOS CVS ?? Other things Do you have another thing you want to know ?? What else do you want to sync with us ?? P.S We are having a long weekend this week. K.M. and I will not here until June 7, but we will keep monitoring the maillist. Ollie - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

4 4

Current States of LinuxBios on SiS 630
by Ollie Lho 03 Jun '00

03 Jun '00

Ron, We can boot the kernel from power-on now. With the romimage which will be sent to you seperately, we can reach the point of kernel_thread(init,...); in arch/i386/kernel/setup.c which means that everything is ready and we are going to load/execute scripts in rc.d. We are using kernel-2.3.99pre5 with the patch in export.tgz. If you can monitor port 0x80 with debug card you can get 0xed at the end. We don't experience the keyboard problem you described, does that happen after the kernel_thread() ?? After initrc are executed ?? The frame buffer device driver is included in 2.4.0-test1 and later kernel. There is some bug in Config.in which makes the option absent when make config, but it is really easy to fix. I think we should move to 2.4.0 now since we are going to need fbdev real soon. Finally, could you please put your source to the FreeBIOS CVS ?? Usually we are unsure if our version matches yours, you know, things like this make a lot of trouble. BTW, we are asking VGA BIOS group to release more information/source code. I hope we can turn on the monitor ASAP, using ICE and debug card is really a pain in the ass. P.S. Jeff, could you review the sisfb for us ?? What are we missing from the driver for this special purpose ?? Ollie - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

6 19

linuxbios build for L440GX
by Ronald G Minnich 02 Jun '00

02 Jun '00

this also works. You need two links: 1) ln -s <your-linux-tree> freebios/linuxbios/L440GX/linux 2) ln -s <intel-flash-disk> freebios/linuxbios/intel_flash_disk ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

linuxbios checked in to sourceforge, and it is buildable
by Ronald G Minnich 02 Jun '00

02 Jun '00

I just did a checkout of freebios from sourceforge, and was able to bash-2.01$ cd freebios/linuxbios/SIS630/ bash-2.01$ ln -s ~/src/bios/linux . bash-2.01$ make cc -I../../chip/intel -I ../../include -I. -O2 -DSIS630 -Di686 -Di586 -DINTEL_BRIDGE_CONFIG -DSIS630_NVRAM -DINTEL_PPRO_MTRR -DSIS630_KEYBOARD -c crt0.S cc -I ../../include -I. -O2 -DSIS630 -Di686 -Di586 -DINTEL_BRIDGE_CONFIG -DSIS630_NVRAM -DINTEL_PPRO_MTRR -DSIS630_KEYBOARD -c ../inflate/main.c ../inflate/main.c:187: warning: conflicting types for built-in function `memset'../inflate/main.c:198: warning: conflicting types for built-in function `memcpy'cc -I ../../include -I. -O2 -DSIS630 -Di686 -Di586 -DINTEL_BRIDGE_CONFIG -DSIS630_NVRAM -DINTEL_PPRO_MTRR -DSIS630_KEYBOARD -c ../../chip/intel/intel_main.c cc -I ../../include -I. -O2 -DSIS630 -Di686 -Di586 -DINTEL_BRIDGE_CONFIG -DSIS630_NVRAM -DINTEL_PPRO_MTRR -DSIS630_KEYBOARD -c ../../chip/intel/intel_subr.c cc -I ../../include -I. -O2 -DSIS630 -Di686 -Di586 -DINTEL_BRIDGE_CONFIG -DSIS630_NVRAM -DINTEL_PPRO_MTRR -DSIS630_KEYBOARD -I ../../include -I. -O2 -DSIS630 -Di686 -Di586 -DINTEL_BRIDGE_CONFIG -DSIS630_NVRAM -DINTEL_PPRO_MTRR -DSIS630_KEYBOARD -c fill_inbuf.c -o fill_inbuf.o cc -I ../../include -I. -O2 -DSIS630 -Di686 -Di586 -DINTEL_BRIDGE_CONFIG -DSIS630_NVRAM -DINTEL_PPRO_MTRR -DSIS630_KEYBOARD -c ../../chip/intel/pci.c objcopy -O binary -R .note -R .comment -S linux/vmlinux vmlinux.bin gzip -f -3 vmlinux.bin ld -T ldscript.ld -o linuxbios crt0.o main.o intel_main.o intel_subr.o fill_inbuf.o pci.o nm -n linuxbios > linuxbios.map objcopy -O binary -R .note -R .comment -S linuxbios linuxbios.strip cc -o mkrom ../../mkrom/mkrom.c ./mkrom -s 64 -f -o linuxbios.rom linuxbios.strip dd conv=sync bs=448k if=vmlinux.bin.gz of=vmlinux.bin.gz.block 0+1 records in 1+0 records out cat vmlinux.bin.gz.block linuxbios.rom > romimage cp romimage /tmp bash-2.01$ Works as far as I can tell. For those of you with commit. Be very very careful, please. If you can't test something then don't commit it. It's very easy to screw this up, esp. when it's out of ROM. I'm close to being able to test without the Arium and I'd like to keep it that way :-) For now until I get some more FLASH ram back I can't test anything. This is a snap of my last know good code. I will be putting the SiS keyboard fix in soon. I also worked out a trivial fix for parameters. Try it out if you can (especially you SiS folks :-) ) ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

sis630 problem temporary resolution.
by Ronald G Minnich 02 Jun '00

02 Jun '00

There's no current standard way to communicate memory size info from linuxbios boot code to the kernel. My kernel was dying because of a hard-coded size in arch/i386/kernel/setup.c: ALT_MEM_K = 254*1024; The quick fix for now: ALT_MEM_K = 62*1024; I was about to test this when my flash ram stopped programming, I am now waiting on an order for more. Try it on your version. We need a standard way to get PARAM to the kernel, now that the BIOS is no longer there to do it. The 0x90000 PARAM won't work, since that set of locations is managed in code we don't even run (from arch/i386/boot). Ideas welcome. ron p.s. I'd appreciate seeing 'make' errors from anybody. Please remember though that for linuxbios you have to: cd freebios/linuxbios/<mainboard-name>, e.g. cd freebios/linuxbios/SIS630 Then type make Make from the top level of freebios does not work. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

4 7

Keyboard O.K. On SiS 630
by Ollie Lho 02 Jun '00

02 Jun '00

Ron, We got keyboard working properly on SiS 630 with the pseduo code we sent to you. Again, we can reach kernel_thread(init, ...) and beyond. The C source code and rom image will ge sent in a seperate mail. You mentioned in a post that you can get monitor on ?? Which frame buffer device did you use ?? sisfb ?? How did you do that ? Ollie - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

3 5

SiS 630 booting Linux from power on.
by Ronald G Minnich 31 May '00

31 May '00

We're not up to multiuser, because we have a keyboard hang problem. But we think we'll get that soon. Getting there! ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

question for the experts on PII vs. Celeron startup
by Ronald G Minnich 25 May '00

25 May '00

I have been having trouble getting PII to work with memory from powerup. I just now realized that I'm seeing basically the same problem on the Intel and SiS motherboards. Engineers at SiS, using the same linuxbios romimage as I am using, has no troubles on the motherboard BUT: they are using Celeron. (see the linuxbios web page: I can still get the intel motherboard up with linuxbios, but I have to let the flash recovery code run first by twiddling the jumper). The symptom is that during memory init, at some point the processor seems to take a trap during a memory write. It is as though some piece of hardware between the processor and memory is unhappy :-) I'm working with SiS to try a different motherboard. But: I'm now wondering if I'm encountering some kind of PII L2 Cache init problem on the Slot 1 cards I'm using here. I'm very suspicious that I'm seeing a particular kind of problem on my Slot 1 PII systems that SiS is not seeing using a Celeron, and that I'm seeing the same kind of problem on both Intel and SiS mainboards. Any comments on this? Any thoughts? Anyone know if anything special happens for L2 cache on a Slot 1 card at powerup? It would probably look like an IN or OUT to an undocumented address (undocumented since this is Intel we're talking about here). ron p.s. linuxbios: http://www.acl.lanl.gov/linuxbios - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

3 5

Programming ROMS
by Edwin Rhodes 24 May '00

24 May '00

Hi, I've managed to obtain some 486 and 386 ROM's that I would like to program. I would like to replace the current ROM code with that of the linux bios code. unfortunately I don't think that the boards support flash update?? how do I go about re-programming them??? what hardware and software is required to re-write the bios?? would I be able to get away with a hot-swap??? or do i need a proper rom programmer, if so which one would you recommend. thanks, Edwin ps. well done for getting so far with linux bios. if there is anything I can do to help let me know. :)

2 1

RE: [OpenBIOS] Programming ROMS
by Jessen, Per 24 May '00

24 May '00

> -----Original Message----- > From: Edwin Rhodes [mailto:edwin_rhodes@hotmail.com] > Sent: 24 May 2000 15:18 > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: [OpenBIOS] Programming ROMS > > > Hi, I've managed to obtain some 486 and 386 ROM's that I > would like to program. I would like to replace the current > ROM code with that of the linux bios code. unfortunately I > don't think that the boards support flash update?? how do I > go about re-programming them??? what hardware and software is Assuming they are indeed EPROMs, you need to determine the type of EPROM (make, code - e.g. AMD27Cxxxx and so on). Retrieve the datasheet from the manufacturers website, then determine how to program them. > required to re-write the bios?? would I be able to get away > with a hot-swap??? or do i need a proper rom programmer, if > so which one would you recommend. If the EPROMs are not flashable, simply go for a burner that supports the type of chip(s) you have. I'm not sure what you mean by 'hot-swap' ? regards, Per Jessen - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Programming ROMS
by Edwin Rhodes 24 May '00

24 May '00

Hi, I've managed to obtain some 486 and 386 ROM's that I would like to program. I would like to replace the current ROM code with that of the linux bios code. unfortunately I don't think that the boards support flash update?? how do I go about re-programming them??? what hardware and software is required to re-write the bios?? would I be able to get away with a hot-swap??? or do i need a proper rom programmer, if so which one would you recommend. thanks, Edwin ps. well done for getting so far with linux bios. if there is anything I can do to help let me know. :)

1 0

Mixing 16 and 32 bits code
by Ollie Lho 22 May '00

22 May '00

Ronald, It seems that you made some mistake in mixing 16 and 32 bits code in the intel_start32.S: _realstart: cli movw %cs, %eax movw %eax, %es xor %eax, %eax mov %eax, %cr3 /* Invalidate TLB*/ .byte 0x66 /* prefix */ .byte 0x26 .byte 0x0f, 0x01, 0x16 /* lgdt [es:offset]*/ .word 0x02 /* offset in segment */ movl %cr0, %eax andl $0x7FFAFFD1, %eax /* PG,AM,WP,NE,TS,EM,MP = 0*/ orl $1, %eax movl %eax, %cr0 data32 ljmp $0x10, $.Lprotected Before _realstart there was a .code16 directive, so it should be in 16 bits mode, so how could those 32 bits (long) operation works ?? This bugs seems breaks gas 2.9.5 also. Ollie - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

5 7

latest snapshot
by Ronald G Minnich 08 May '00

08 May '00

The latest snapshot of the linuxbios is at http://www.acl.lanl.gov/linuxbios. This is the one that boots multiuser. I included a linux/.config so you have our config. It also includes romimages (I didn't do a make clean, in other words ...) problems to me. We're starting an alpha port next week sometime. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

linuxbios: I can now login
by Ronald G Minnich 05 May '00

05 May '00

Just got the keyboard working, thanks to a few hints from the openbios guys. So I can now log in. You can hit reset on the box, and before you know it you're seeing linux boot messages ... still lots to do, but this is a big step. Logging in is always a good idea :-) One cool thing: I still have not had to reproduce the "steenking bios" code from boot/setup.S. Linux is handling most hardware init tasks just fine. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

next problem: keyboard.
by Ronald G Minnich 05 May '00

05 May '00

so, no keyboard I/O. But I am setting the bit in the PIIX4E register to enable KBBCS#. The new hunt begins .... ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

3 9

more pci info
by Ronald G Minnich 05 May '00

05 May '00

lspci for this motherboard shows: lspci -v 00:00.0 Host bridge: Intel Corporation 440GX - 82443GX Host bridge Flags: bus master, medium devsel, latency 64 Memory at f8000000 (32-bit, prefetchable) Capabilities: [a0] AGP version 1.0 00:01.0 PCI bridge: Intel Corporation 440GX - 82443GX AGP bridge Flags: bus master, 66Mhz, medium devsel, latency 64 Bus: primary=00, secondary=01, subordinate=02, sec-latency=64 I/O behind bridge: 0000f000-00000fff Memory behind bridge: fff00000-000fffff Prefetchable memory behind bridge: fff00000-000fffff 00:09.0 Non-VGA unclassified device: Unknown device 14c1:8043 (rev 03) Subsystem: Unknown device 103c:106b Flags: bus master, stepping, 66Mhz, slow devsel, latency 64, IRQ 19 Memory at f5000000 (64-bit, prefetchable) 00:0c.0 SCSI storage controller: Adaptec 7896 Subsystem: Unknown device 9005:080f Flags: bus master, medium devsel, latency 64, IRQ 19 BIST result: 00 I/O ports at 1400 Memory at f4100000 (64-bit, non-prefetchable) Capabilities: [dc] Power Management version 1 00:0c.1 SCSI storage controller: Adaptec 7896 Subsystem: Unknown device 9005:080f Flags: bus master, medium devsel, latency 64, IRQ 19 BIST result: 00 I/O ports at 1800 Memory at f4101000 (64-bit, non-prefetchable) Capabilities: [dc] Power Management version 1 00:0e.0 Ethernet controller: Intel Corporation 82557 (rev 08) Subsystem: Unknown device 8086:3000 Flags: bus master, medium devsel, latency 64, IRQ 21 Memory at f4102000 (32-bit, non-prefetchable) I/O ports at 1080 Memory at f4000000 (32-bit, non-prefetchable) Capabilities: [dc] Power Management version 2 00:12.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) Flags: bus master, medium devsel, latency 0 00:12.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) (prog-if 80) Flags: bus master, medium devsel, latency 64 I/O ports at 1050 00:12.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) Flags: bus master, medium devsel, latency 64, IRQ 21 I/O ports at 1060 00:12.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) Flags: medium devsel 00:14.0 VGA compatible controller: Cirrus Logic GD 5480 (rev 23) Subsystem: Unknown device 8086:3430 Flags: bus master, VGA palette snoop, medium devsel, latency 64 Memory at f6000000 (32-bit, prefetchable) Memory at f4103000 (32-bit, non-prefetchable) 01:0f.0 PCI bridge: Digital Equipment Corporation: Unknown device 0023 (rev 06) Flags: bus master, fast Back2Back, 66Mhz, medium devsel, latency 240 Bus: primary=01, secondary=02, subordinate=02, sec-latency=68 I/O behind bridge: 0000f000-00000fff Memory behind bridge: fff00000-000fffff Prefetchable memory behind bridge: 00000000fff00000-0000000000000000 Here's what's weird. The lspci shows the devices on bus 0. my probe found the bus 0 devices on bus 1 *and* bus 0. So what am I doing wrong? anybody have a clue as to what the DEC PCI bridge is doing on there? is this a bridge to the 64-bit slot or something? weird. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

It works! It works! It works! It works!
by Ronald G Minnich 04 May '00

04 May '00

Just booted to multiuser with a full video display! Thanks to everyone, esp. Jeff Garzik! This is so cool! I'll put up the diffs as soon as I get they keyboard to go too! Ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

3 3

Re: [fb-d] closer ...
by Jeff Garzik 03 May '00

03 May '00

James wrote: > > > Also trying to get cl gd5480 up. Jeff, turns out on the L440GX if you plug > > in a PCI video card the bios will execute a HLT. Yep, can't have two video > > cards. Wonder why Intel did this? > > I love Intel. > > Ron, more seriously, there is a "VGA Disable" or "Video Disable" on the > L440GX+ or whatever that mainboard was we were working on earlier; that > should allow you to plug in a second PCI video card. > > Or: Many ATI cards that I've seen have a "BIOS disable" jumper on > themselves (I would presume Matrox cards would do this too so you can run > multiheaded). If you short that, the PC BIOS won't see the ATI card at > all. > > Either of these solutions will be easier than getting the Cirrus up; I > would suggest flipping the motherboard jumper. > > I think Intel designed it like that because there is a single space where > all the video card stuff goes, but I'm not sure... Yep, sounds like you are right on the money. Since the GD5480 is built into the motherboard, you have to disable it before you can use a PCI video card. For the Intel BIOS, there should be a switch somewhere in BIOS setup typically. If it's an older motherboard, there is probably a jumper. For linuxbios/freebios, simply avoiding the Cirrus video BIOS init should be sufficient I would think. (though make sure to disable the Cirrus's PCI MMIO and I/O regions) Jeff -- Jeff Garzik | Nothing cures insomnia like the Building 1024 | realization that it's time to get up. MandrakeSoft, Inc. | -- random fortune - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 2

Re: [fb-d] closer ...
by Ronald G Minnich 03 May '00

03 May '00

On Wed, 3 May 2000, James wrote: > Ron, more seriously, there is a "VGA Disable" or "Video Disable" on the > L440GX+ or whatever that mainboard was we were working on earlier; that > should allow you to plug in a second PCI video card. I can't find any disable. Any better hints? > Or: Many ATI cards that I've seen have a "BIOS disable" jumper on > themselves (I would presume Matrox cards would do this too so you can run > multiheaded). If you short that, the PC BIOS won't see the ATI card at > all. I'll check that too. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

closer ...
by Ronald G Minnich 03 May '00

03 May '00

the problem with the linux kernel fault is that I have to bzero the PARAM stuff when I start, and some missing piece of that is causing init to die when it tries to exec /sbin/init. What's interesting is the mount goes, and it looks like the lookup() is ok, but the binprm() step dies. So I'm missing something I need in PARAM .... still working .... Also trying to get cl gd5480 up. Jeff, turns out on the L440GX if you plug in a PCI video card the bios will execute a HLT. Yep, can't have two video cards. Wonder why Intel did this? ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

Now mounting root
by Ronald G Minnich 03 May '00

03 May '00

Thanks to your help, I am now mounting root: Mounted root (ext2 filesystem) readonly <4>Freeing unused kernel memory: 52k freed <4>Warning: unable to open an initial console Part of the problem was in my PCI config, another problem was I had to enable the IDE in Linux, as follows: #define LINUXBIOS #ifndef LINUXBIOS if (e->reg && (pci_read_config_byte(dev, e->reg, &tmp) || (tmp & e->mask) != e->val)) continue; /* port not enabled */ #else /* force 'em on! */ if (e->reg) { pci_read_config_byte(dev, e->reg, &tmp); tmp |= e->val; pci_write_config_byte(dev, e->reg, tmp); printk("%s: LINUXBIOS, so Jammed the enable on!\n", d->name); } #endif So in the LINUXBIOS case you know that no BIOS was there to do things, so you just turn the IDE on. I die on opening the initial console. That's the next barrier to multiuser boot. Any hints welcome .... I've attached my .config and the command line I'm using is: command_line="root=/dev/hda1 serial=1,9600n8 console=ttyS1,9600"; I have to go back and look, But I think it should be: command_line="root=/dev/hda1 serial=0,9600n8 console=ttyS0,9600"; Please let me know if you know ... I'm putting a snapshot on the web page in a few minutes. ron

2 5

OK, sercons is not the problem
by Ronald G Minnich 03 May '00

03 May '00

It's dying when it tries to run /sbin/init. Since I have no support for executables in this kernel I'm not surprised. I'll let you know how it goes when I add it in. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Two logs from pci startup
by Ronald G Minnich 02 May '00

02 May '00

First log is from my linuxbios startup, for a copy go to www.acl.lanl.gov/linuxbios. Second is from 2.3.99 startup with pci debugging turned on. Strange stuff on boot, comments about 64-bit addresses (?? set smoething wrong in memory attributes in BAR?) etc. See what you think. If we can get this one licked we're going to boot!! Note the bogomips and mhz numbers actually make sense. This is good. Also the APIC support in 2.3.99 seems to work on uniprocessors, yee ha. ron

2 6

Re: [OpenBIOS] current ugly pci config code.
by Colin Jensen 02 May '00

02 May '00

On Tue, 25 Apr 2000, Ronald G Minnich wrote: > It also thinks IDE is disabled, even though the debug prints show that I'm > turning on the relevant bits. Did you enable Memory, IO, and Bus Master on the IDE? You need Mem and IO enabled even if there are no memory regions associated with the device -- I'm assuming that if I possessed the PCI IDE spec, it would tell me that a PCI IDE device receives ISA bus cycles or some crazy thing like that. Sorry I can't explain WHY it needs these -- I don't know :-). But when I was programming the bus for my project, I found I needed them. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

3 5

OK, version -1 is there.
by Ronald G Minnich 26 Apr '00

26 Apr '00

www.acl.lanl.gov/linuxbios, just suck down the link in the latest news (in 10-15 minutes or so ... it gets copied out via crond). A few notes: 1) Don't even bother getting it unless you are comfortable with assembly code and hardware 2) I only support two motherboards. PLEASE read the notes in bios/freebios. To make a linuxbios for one of the two supported motherboards, you: cd bios/freebios/linuxbios/L440GX make or cd bios/freebios/linuxbios/SIS630 make Now, for L440GX, it can build a set of files to be loaded onto the Intel phlash disk. You need to get that disk first. You need to learn now to 'recovery load' a bios. If you don't have an Arium or other ICE, you're dead! For the SIS630, it builds a 512K rom image that you burn with a burner. In each directory there are ROOTDOIT scripts to show you what happens next. Please follow this structure! It makes it simpler to host multiple motherboards. There are some subtleties in places, feel free to ask questions. linuxbios is now hosted from majordomo(a)lanl.gov, and is open to all to join. Feel free to join if your main interest in this is linuxbios. questions to me. Current issues: SDRAM config on L440GX and SIS630. PCI config. But it is *close*. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 2

PCI config code.
by Ronald G Minnich 25 Apr '00

25 Apr '00

I know I asked this already, but I'm checking again. I'm close to mounting root but Linux PCI config code is just not able to handle memory space access when no BIOS has set it. Does anyone have pci config code they can donate to the cause. Thanks ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

3 4

linuxbios release
by Ronald G Minnich 25 Apr '00

25 Apr '00

OK, I got the release today. I have to put copyright notices in some things and then I can put it on the web page. I am going to put out the "very pre-alpha" version. This is clearly not ready for prime-time use, and you really need to have an ICE to get work done. But I believe getting something on the page is better than any more waiting. Please don't mess with this thing unless you're set up to do so. You need a way to burn the NVRAM, you need an ICE, and you need some expertise -- this isn't a red hat install! I was hoping to put out a full booting version but PCI is being a pain. I want to get it configured in a way that works long term. It really does seem that 2.3.99pre5 is just about there in being able to set up pci, but it has a few bugs yet. I am pursuing fixing those bugs. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

dead link?
by Edwin Rhodes 18 Apr '00

18 Apr '00

hi i just tried to access: http://www.acl.lanl.gov/linuxbios/www.sourceforge.net and i get a page cannot be found error. dead link??? well done anyway! edwin ps. is there anything i can do to help?

3 2

got it!
by Ronald G Minnich 15 Apr '00

15 Apr '00

OK, I've got linuxbios up and running under freebios. I've made the changes to freebios that I outlined earlier, to wit: 10 instructions, and you're in protected mode using the NVRAM-based gdt. 30 lines of macros, DRAM is up and you jump to C. In C, you turn on caching, set things in the PIIX4E so it's right, set up minimal MTRRs so that caching is *really* on, etc., etc. and then gunzip linux and jump to it. Then linux fails to boot as I have no SMP tables :-) I have to yank these off a running system. I may take a break from this miserable intel mainboard and cut over to SiS for a few days, once I get a flash burner that is ... Man is this nice. I recommend openbios folks look at freebios structure, because: NO MORE ASSEMBLY! ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

SMP BIOS
by Konstantin Zhidkov 13 Apr '00

13 Apr '00

Hello Ron, I plan to implement version 1.1 of the MP Specification, including initialization of the APICs. I got dual CPU MB for this, and this was an L440GX+. Could post your lastest hardware-related code (i.e. drivers)? This may save some keystrokes for me... Konstantin - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

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

08 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 07 Apr '00

07 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 05 Apr '00

05 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

linuxbios performance
by Ronald G. Minnich 29 Mar '00

29 Mar '00

just enabling mtrr's and then setting up one mtrr as per the VOL III manual makes things fast. Boy, am I ever happier. 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 Marcus Gossner 29 Mar '00

29 Mar '00

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(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

9 17

Re: [OpenBIOS] PCI setup code
by James 28 Mar '00

28 Mar '00

> > If anyone could repost the links to PCI support code I would appreciate > > it. Linux PCI_DIRECT is not up to snuff at present. > > Have you looked at 2.3.x? It is MUCH more up to date. > > What problems exactly are you having in PCI setup? I've been messing > around in that area lately and can help... Hey Jeff, I'll be here at the ACL for a week. Below is what we get on bootup. NOTES: Calibrating delay loop... 4.25 BogoMIPS Cache isn't enabled correctly, so the chip runs at ~ 1/100 its speed. Sigh. This makes gunzipping slow. PCI: 00:60 [9005/005f], irq 0x0 This is the SCSI controller, hence this line is repeated. Note how all the IRQs are 0x0. Continue down the printout and note how all the mbases are 00000000 when the cards initialize. I am going to try to make code to assign IRQs; I don't really know where to start; I take it PCI devices each get an IRQ of 9, 10, 11, 12, 14, or 15, and they can share? Ron says he knows how to fix the mbases problem. Any comments/suggestions would be greatly appreciated (no, I do not know what I am doing). - James >>>>>> Contents of 0018:C01DD140 (we don't have video yet) Linux version 2.2.10 (rminnich@mini) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #13 Mon Mar 27 12:43:40 MST 2000. Detected 497449471 Hz processor.. Calibrating delay loop... 4.25 BogoMIPS. Memory: 309004k/313472k available (752k kernel code, 412k reserved, 3276k data, 28k init). Pentium-III serial number disabled.. CPU: Intel 00/07 stepping 03. Checking 386/387 coupling... OK, FPU using exception 16 error reporting.. Checking 'hlt' instruction... OK.. POSIX conformance testing by UNIFIX. mtrr: v1.35 (19990512) Richard Gooch (rgooch(a)atnf.csiro.au). PCI: Using configuration type 1. PCI: Probing PCI hardware. pci_scan_bus for bus 0. pci_scan_bus: bus 0, max is 0. irq is 0x0. base 0, val 0x8. base 1, val 0x0. base 2, val 0x0. base 3, val 0x0. base 4, val 0x0. base 5, val 0x0. PCI: 00:00 [8086/71a0],irq 0x0. base 0, val 0x0. base 1, val 0x0. PCI: 00:08 [8086/71a1],irq 0x0. irq is 0x0. base 0, val 0x1. base 1, val 0x4. base 3, val 0x0. base 4, val 0x0. base 5, val 0x0. PCI: 00:60 [9005/005f],irq 0x0. irq is 0x0. base 0, val 0x1. base 1, val 0x4. base 3, val 0x0. base 4, val 0x0. base 5, val 0x0. PCI: 00:61 [9005/005f],irq 0x0. irq is 0x0. base 0, val 0x0. base 1, val 0x1. base 2, val 0x0. base 3, val 0x0. base 4, val 0x0. base 5, val 0x0. PCI: 00:70 [8086/1229],irq 0x0. irq is 0x0. base 0, val 0x0. base 1, val 0x0. base 2, val 0x0. base 3, val 0x0. base 4, val 0x0. base 5, val 0x0. PCI: 00:90 [8086/7110],irq 0x0. irq is 0x0. base 0, val 0x0. base 1, val 0x0. base 2, val 0x0. base 3, val 0x0. base 4, val 0x1. base 5, val 0x0. PCI: 00:91 [8086/7111],irq 0x0. irq is 0x0. base 0, val 0x0. base 1, val 0x0. base 2, val 0x0. base 3, val 0x0. base 4, val 0x1. base 5, val 0x0. PCI: 00:92 [8086/7112],irq 0x0. irq is 0x0. base 0, val 0x0. base 1, val 0x0. base 2, val 0x0. base 3, val 0x0. base 4, val 0x0. base 5, val 0x0. PCI: 00:93 [8086/7113],irq 0x0. irq is 0x0. base 0, val 0x8. base 1, val 0x0. base 2, val 0x0. base 3, val 0x0. base 4, val 0x0. base 5, val 0x0. PCI: 00:a0 [1013/00bc],irq 0x0. pci_scan_bus for bus 1. pci_scan_bus: bus 1, max is 1. base 0, val 0x0. base 1, val 0x0. PCI: 01:78 [1011/0023],irq 0x0. pci_scan_bus for bus 2. pci_scan_bus: bus 2, max is 2. PCI: pci_scan_bus returning with max=02. PCI: pci_scan_bus returning with max=02. PCI: pci_scan_bus returning with max=02. PCI: Assigning I/O space 5800-58ff to device 00:60. PCI: Enabling I/O for device 00:60. PCI: Assigning I/O space 5900-59ff to device 00:61. PCI: Enabling I/O for device 00:61. PCI: Assigning I/O space 5a00-5a3f to device 00:70. PCI: Enabling I/O for device 00:70. PCI: Assigning I/O space 5a40-5a4f to device 00:91. PCI: Assigning I/O space 5a60-5a7f to device 00:92. PCI: Enabling I/O for device 00:92. Linux NET4.0 for Linux 2.2. Based upon Swansea University Computer Society NET3.039. NET4: Unix domain sockets 1.0 for Linux NET4.0.. NET4: Linux TCP/IP 1.0 for NET4.0. IP Protocols: ICMP, UDP, TCP. Starting kswapd v 1.5 . Serial driver version 4.27 with no serial options enabled. Floppy drive(s): fd0 is 1.44M. floppy0: no floppy controllers found. Found an aci. pdev shows irq at 0x0. aic7xxx: <Adaptec AIC-7896/7 Ultra2 SCSI host adapter> at PCI 12/0. aci7xxx: base 00005800, mbase 00000000, irq 0x0. aic7xxx: Controller disabled by BIOS, ignoring.. Found an aci. pdev shows irq at 0x0. aic7xxx: <Adaptec AIC-7896/7 Ultra2 SCSI host adapter> at PCI 12/1. aci7xxx: base 00005900, mbase 00000000, irq 0x0. aic7xxx: Controller disabled by BIOS, ignoring.. scsi : 0 hosts.. scsi : detected total.. The PCI BIOS has not enabled this device! Updating PCI command 0001->0005.. PCI latency timer (CFLT) is unreasonably low at 0. Setting to 32 clocks.. eth0: Intel EtherExpress Pro 10/100 at 0x5a00, 00:90:27:E0:34:A2, IRQ 0.. Receiver lock-up bug exists -- enabling work-around.. Board assembly 000000-000, Physical connectors present: RJ45. Primary interface chip i82555 PHY #1.. General self-test: passed.. Serial sub-system self-test: passed.. Internal registers self-test: passed.. ROM checksum self-test: passed (0x04f4518b).. VFS: Cannot open root device 08:01....... - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

PCI setup code
by Ronald G. Minnich 28 Mar '00

28 Mar '00

If anyone could repost the links to PCI support code I would appreciate it. Linux PCI_DIRECT is not up to snuff at present. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

USB and I440BX
by Janusz Mlodzianowski 27 Mar '00

27 Mar '00

Hi, I am embarking on a small project in which I would like to use USB. I understand that Intel 440BX chipset (PIIX) PCI-ISA bridge has built in USB circuitry. Are there any examples of BIOS like routines controling this chip. I will not use OS like Windows and VxDs or Linux, just DOS and ROM based software. I also do not care (just for now..) about full blown USB protocol. All what I intend to do is to hook-up two motherboards and transfer via USB raw bytes from one to another. The next step will be a dedicated USB peripherial. What sort of USB chip would you suggest? I looked into NS USBN9602 It seems OK but I would rather use DIL or PLCC chips. Janusz - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

yeeee ha!
by Ronald G. Minnich 24 Mar '00

24 Mar '00

(from the web page ...) --- New as of 3/20/00: Success! We're now booting linux out of NVRAM. It gets to the point of wanting to mount a disk, and since I have no disk attached to the motherboard it naturally dies. It seems to properly configure the PCI bus, and finds the Ethernet and other devices and configures them. So now I need to go grab an IDE disk and get it the rest of the way up ... --- Oen remaining problem is speed. I have caching enabled but it takes a very long time to get the gunzip done. I figure there is some other bit I need to set ... I'll do that one later. For now, it's time to attach an IDE disk and see how it goes. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

7 20

interest
by Ronald G. Minnich 22 Mar '00

22 Mar '00

If any students out there are interested in coming to Los Alamos to work this summer on linuxbios you should get in touch with me. I need help with other motherboards and we want to look at the Alpha. Thanks ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

3 2

Re: [GENERAL] Re: spontaneous reboots FreeBSD 3.x and 4.0-stable (fwd)
by Ronald G. Minnich 21 Mar '00

21 Mar '00

Here's why we need to KILL the BIOS ron ---------- Forwarded message ---------- Date: Tue, 21 Mar 2000 09:52:57 -0800 From: Arthur M. Kang <arthur(a)levelogic.com> To: Jim Mercer <jim(a)reptiles.org> Cc: "[iso-8859-1] Pawe� Dubin" <paweld(a)suimed.tpnet.pl>, hackers(a)FreeBSD.ORG, pgsql-general(a)postgresql.org Subject: Re: [GENERAL] Re: spontaneous reboots FreeBSD 3.x and 4.0-stable Had this rebooting problem before for a while and it drove me NUTZ! Installed RedHat and FreeBSD and both rebooted periodically. Don't know if my solution will help or not, but what was causing my reboots was the system BIOS. The options for Power Management in the system BIOS should have some settings for the monitor as well as the hard drive. I was finding that the spinning down of the hard drive caused the machine to reboot. No traces in any error logs or anything... Hope that helps somebody...somewhere... :) - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Intel USB Controller 82371FB (PIIX3)
by Ross 21 Mar '00

21 Mar '00

Hi, Guys does anyone know how I can test the USB controller on the intel 82371FB (PIIX3) chipset or know of a web site that has source code in assembly language that will acomplish this. //Ross

8 14

Re: [OpenBIOS] Openbios site at sourceforge.net
by Ross 17 Mar '00

17 Mar '00

Hi, I went to the link below and was asked for a security certificate and could not log. How do you log on to: https://sourceforge.net/project/?group_id=3423 ? //Ross ---------- > From: Chris Davis <cjdavis(a)computer.org> > To: Openbios mailing list <openbios(a)elvis.informatik.uni-freiburg.de> > Subject: [OpenBIOS] Openbios site at sourceforge.net > Date: Friday, March 17, 2000 12:55 PM > > 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

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 06 Mar '00

06 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 06 Mar '00

06 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 04 Mar '00

04 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 04 Mar '00

04 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 04 Mar '00

04 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

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. > > is any plan to get hardware init and drivers? it has future plans on open bios to support mutilpe os loader? regards, jaime dias - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

3 2

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

02 Mar '00

Jeff, can you please send me a copy of this file that I can unzip with winuzip for windoze 95. Thank you. //Ross ---------- > From: Jeff Garzik <jgarzik(a)mandrakesoft.com> > To: openbios(a)elvis.informatik.uni-freiburg.de > Cc: Linux Kernel List <linux-kernel(a)vger.rutgers.edu> > Subject: [OpenBIOS] STPC BIOS sources posted > Date: Wednesday, March 01, 2000 9:57 AM > > free bios hackers-- > > Johan Rydberg has kindly allowed me to posted his GPL's STPC BIOS > sources. The code is early work and incomplete, but may be useful to > people here... > > I have been hacking on this instead of OpenBIOS lately, as it seems > easier to use these stpc source to create a BIOS for the i430FX. > > Download from http://gtf.org/garzik/bios/ > > Jeff > > > > (copied to linux-kernel as there has been quite a bit of interest in > BIOS sources there too) > > -- > 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

4 5

Re: [OpenBIOS] opening tgz and Tar files with winzip95 7.0
by Ross 02 Mar '00

02 Mar '00

Thanks ron. //Ross ---------- > From: Ronald G. Minnich <rminnich(a)lanl.gov> > To: openbios <openbios(a)elvis.informatik.uni-freiburg.de> > Subject: Re: [OpenBIOS] opening tgz and Tar files with winzip95 7.0 > Date: Thursday, March 02, 2000 7:03 AM > > On Thu, 2 Mar 2000, Ross wrote: > > > Help Anyone: > > > > I get the following error message when using > > winzip95 version 7.0 when trying to unzip the following file > > stpc-bios-0.1.42..1.tgz (Error Reading After Processing 0 Entries) > > can someone out there help me out with this one. Winzip95 say's > > that it can handle these file but its not. > > > go grab the cygwin32 tools and use the 'tar' that's in there. much easier. > > ron > > - > To unsubscribe: send mail to majordomo(a)freiburg.linux.de > with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] opening tgz and Tar files with winzip95 7.0
by Ross 02 Mar '00

02 Mar '00

I have tried GUNZIP for dos and reloaded WinZip 7.0 SR-1 and still come up with the error stpc-bios-0.1.42..1.tgz (Error Reading After Processing 0 Entries) gzip -d creates a file called taz from tgz? /Ross ---------- > From: Marcus Gossner <mgossner(a)inova-computers.de> > To: 'openbios(a)freiburg.linux.de' <openbios(a)elvis.informatik.uni-freiburg.de> > Subject: RE: [OpenBIOS] opening tgz and Tar files with winzip95 7.0 > Date: Thursday, March 02, 2000 6:10 AM > > > >Help Anyone: > > > > > >I get the following error message when using > > >winzip95 version 7.0 when trying to unzip the following file > > >stpc-bios-0.1.42..1.tgz (Error Reading After Processing 0 Entries) > > >can someone out there help me out with this one. Winzip95 say's > > >that it can handle these file but its not. > > >//Ross > > > I unpacked it with WinZip 7.0 SR-1 (1285g) without > any problems (german version of WinZip). > > Marcus > > > > > > > - > To unsubscribe: send mail to majordomo(a)freiburg.linux.de > with 'unsubscribe openbios' in the body of the message

1 0

opening tgz and Tar files with winzip95 7.0
by Ross 02 Mar '00

02 Mar '00

Help Anyone: I get the following error message when using winzip95 version 7.0 when trying to unzip the following file stpc-bios-0.1.42..1.tgz (Error Reading After Processing 0 Entries) can someone out there help me out with this one. Winzip95 say's that it can handle these file but its not. //Ross

2 1

RE: [OpenBIOS] opening tgz and Tar files with winzip95 7.0
by Marcus Gossner 02 Mar '00

02 Mar '00

>Help Anyone: > > > >I get the following error message when using > >winzip95 version 7.0 when trying to unzip the following file > >stpc-bios-0.1.42..1.tgz (Error Reading After Processing 0 Entries) > >can someone out there help me out with this one. Winzip95 say's > >that it can handle these file but its not. > >//Ross > I unpacked it with WinZip 7.0 SR-1 (1285g) without any problems (german version of WinZip). Marcus - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

AW: [OpenBIOS] opening tgz and Tar files with winzip95 7.0
by Winter Jörg 02 Mar '00

02 Mar '00

>Help Anyone: >I get the following error message when using >winzip95 version 7.0 when trying to unzip the following file >stpc-bios-0.1.42..1.tgz (Error Reading After Processing 0 Entries) Just tried it on my Win with winzip7.0sr1. Works fine. Maybe you must re-install win (like always)? or have a corrupt file? got it via ftp? had "bin" switch on?? BTW: gnu unzip and tar are available for DOS on alot of linux distr. CD´s pick one an dump winzip ... - 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 Ross 02 Mar '00

02 Mar '00

Hi, jeff: I get the following error message when using winzip95 version 7.0 when trying to unzip the STPC BIOS sources. (Error Reading Reader Processing 0 Entries) I konw you are a great hacker. We are here to help each other wether the problem is big or small. //Ross ---------- > From: Jeff Garzik <jgarzik(a)mandrakesoft.com> > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: Re: [OpenBIOS] STPC BIOS sources posted > Date: Wednesday, March 01, 2000 9:23 PM > > Ross wrote: > > > > Jeff, can you please send me a copy of this > > file that I can unzip with winuzip for windoze > > 95. Thank you. > > winzip will unpack tar.gz files. beyond that, you're on your own. > > you should really be able to figure this stuff out, if you want to hack > on a BIOS.. :) > > -- > 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] asm code
by Edwin Rhodes 01 Mar '00

01 Mar '00

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

3 2

Fw: aros screen problem on x86/native
by Jaime Dias 01 Mar '00

01 Mar '00

> > hi, > we are having problem to put aros on native x86 i want to know if someone > here could help. > > > You cannot see workbench screen yet because its size is 800x600 so it's > impossible to show it on vga screen (max 640x480) unless we add some > parameters passed to LateIntuiInit. Besides there are still some problems > with vga.hidd - it still hangs during OpenWindow. Aah! And there are some > problems with workbench background. My hidd in PutPixel (or DrawPixel I > don't remember now which is correct) puts color 0 (black) on the screen > instead of the one from bitmap (don't know why - screenbar is show as it > should). > > vga.hidd is a layer between the hardware idependent and the hardware > dependent code > > anyhow to get the 800x600 booting generic svga cards on x86? > > thanks in advance, > jaime dias - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

(some help) Fw: [AROS-Dev] i386/native status
by Jaime Dias 01 Mar '00

01 Mar '00

hi, sorry in advance, but we have only one person on aros team (www.aros.org) that is handle the x86 port, and it apears some trouble now, it's not polite to invite developers on other projects, but i read this list for a while and maybe there is someone who here who could help us in this issue. port aros to x86 is very important for the project, thats why i am posting this mail. (ggi on gfx handle side and openbios on how treat the hardware and gfx on other side) > > But we still don't have the most important (and easy to write > indeed) thing - ide.hidd (ide.device scsi.device....) so we are anable to > start system - we can add dos.library to residentlist but it will not see > any drives. Besides vga.hidd is either buggy or missing some methods so it > can't work propertly at this moment. It do draw point but it don't show a > window (on the other hand it can open screen and alloc colors propertly). > > The most important thing we are missing is TIME (true for me). My last > update was due to my 1.5 week long vacation. Sitting whole nights > (well.. not whole - only to 5 AM) at my PC, fighting with bugs and reading > the hardware books - that's how I spend this time. I know many more than > one month ago but now what I need is time. Without it I can't work. > > > Tell me what the bus.hidd should do and then I'll try to write it. I have > many hardware references at home so I can work (time, time, > time....). irq.hidd would be very easy to write (most of it is placed now > in exec.library, just look at config/i386-native/exec/irq.S and other .S > files) but what we need is ready and well-described idea of it. > > > If you could find something about DMA mode in all new harddrives it would > be great... One could help Frederic with ide.device - working alone is > much slower. > sorry bother, jaime dias - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: AW: [OpenBIOS] Aladdin V chipset
by dave＠denial.force9.co.uk 01 Mar '00

01 Mar '00

Burl Nyswonger <burl(a)watchguard.com> wrote: > 2) high-level (ie: C and Forth) -- It would be nice if there > could be some way to abstract the chipset "advanced" features > into the OpenFirmware device tree. If not, this is still > where I think the "performance" related chipset initialization > should happen. Ugh, no. I spent some time moving the PCI optimisation from the kernel to userspace (see http://linux.powertweak.com). Moving this to BIOS space would not make much sense. The BIOS should contain enough code to get the system into a sane enough state to boot a kernel, and nothing more. Another problem with PCI tweaking, is that some options are motherboard specific. You have no way of detecting if that option is going to work. When a motherboard manufacturer licenses a BIOS from a vendor, they get source with #defines to tell them how certain parts of the board work. How the data/address lines are decoded for example.. Asides from the mobo manufacturer, no-one is going to know how a memory bank has been wired on their board, so they won't know the order in which certain things have to be performed. The only way you can offer this to users is in a 'try and see' approach. Such a tactic does NOT belong in BIOS land. regards, -- Dave. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

STPC BIOS sources posted
by Jeff Garzik 01 Mar '00

01 Mar '00

free bios hackers-- Johan Rydberg has kindly allowed me to posted his GPL's STPC BIOS sources. The code is early work and incomplete, but may be useful to people here... I have been hacking on this instead of OpenBIOS lately, as it seems easier to use these stpc source to create a BIOS for the i430FX. Download from http://gtf.org/garzik/bios/ Jeff (copied to linux-kernel as there has been quite a bit of interest in BIOS sources there too) -- 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

Aladdin V chipset
by Burl Nyswonger 01 Mar '00

01 Mar '00

I have begun to hack on OpenBIOS and am looking to add support for x86 and the Aladdin V chipset (ie: Super Socket7, Asus P5A, etc...). If anyone else has started work on this, or plans to, it would be nice to talk. -- Burl. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

6 11

Re: [OpenBIOS] PCI enumeration?
by dave＠denial.force9.co.uk 29 Feb '00

29 Feb '00

Chong Chee Yong <catz(a)silvermoon.com.sg> wrote: > > (this is all defined in the PCI spec) To scan the PCI bus, you > > basically iterate through each slot, reading the device and vendor ids. > > If the slot is empty you get a nonexistent value (either 0 or 0xffff I > > think). There can also be bridges on the PCI bus, so you must > > recursively descending into those, and scan their devices, as well. > > Haven't read the PCI bridges specs, but it seems that it is possible > for two unconnected PCI bus since the algorithm suggested in revision 2.2 > Chapter 6.1 is to scan all possible slots. I believe that this (or something similar) has been implemented on some newer Compaq servers. There are a number of workarounds in the kernel PCI code. If someone has access to one of these, an lspci -xxx output would make interesting reading. regards, -- Dave. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

piix4e "minimal" setup
by Ronald G. Minnich 29 Feb '00

29 Feb '00

any hints on what to do just to get timer interrupts going are most welcome :-) geez, this is getting close! ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

linuxbios: getting there
by Ronald G. Minnich 29 Feb '00

29 Feb '00

I'm now in linux main. I was right at trap_init then the WinDB debugger program exploded. I love it. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] Aladdin V chipset
by Ronald G. Minnich 29 Feb '00

29 Feb '00

On Mon, 28 Feb 2000, Burl Nyswonger wrote: > > when you say super socket 7 chipsets -- does this include AMD? > > edwin > I meant "Super Socket 7 boards" in general -- ie: the Asus P5 series, Acer > boards (obviously), etc... When I say "Aladdin V Chipset", I am referring OK, this brings up an interesting issue for the OpenBIOS community. At least one Socket 7 motherboard will support either alpha or pentium in the socket. So it's the same motherboard with a different processor. All startup tasks for the motherboard are pretty much the same. I had an interesting set of discussions with vendors at extreme linux last week. There's a lot of interest in linuxbios -- from Alpha motherboards too (the alpha bios'es all have sucked very badly -- dec never got it right). As things stand openbios is too pentium-specific. So I'd like to propose an idea. 1) get into protected mode early 2) get rid of as much assembly as possible there's a lot that can move to C so we change the layout a bit. It's still early in the game, we can do this. A possible layout: bios/arch/i386/{poweron.s,protected_mode.s,memory.s,motherboard.c,boot.c} bios/arch/alpha/{poweron.s,protected_mode.s,memory.s,motherboard.c,boot.c} bios/payload/{your c files here} poweron.s is the very first set of things you do on poweron -- should be a few instructions. protected_mode.s bumps you into protected mode. On the pentium this is a few instructions. memory.s turns on memory -- this is *much* easier on the pentium in protected mode. memory.s should set up a stack and jump to C code. Motherboard.c does anything that has to be done to further use the motherboard. Boot.c gunzips the payload (either a bios-compatible code or Linux or FreeBSD or whatever) and jumps to it. I'm talking to a commercial company that is going to do something like this -- they don't want much assembly long-term, so they're recrafting openbios. I don't think most people want to do assembly. If we do this, we're not just for pentiums any more. That would be wonderful! Any interest? ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

7 11

PCI enumeration?
by Brian Hurt 29 Feb '00

29 Feb '00

Is anyone else out there working on adding PCI enumeration to OpenBIOS? Any one have any pointers to code I can theft, er, reuse? I'm looking at the function pci_scan_bus() in the linux source code (drivers/pci/pci.c), but that looks like it just reads the results of an already-enummerated PCI bus. Help would be greatly appreciated. Brian - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

5 7

Cool project
by Daniel Haglund 29 Feb '00

29 Feb '00

Hi! I just read about your project. Really cool! Ofcourse you wan't to boot linux as fast as possible. My friend David and I have spent a few hours surfing around for a BIOS able to boot FAST. We'd like to use it for the fuel injection system we're building for my car. The computer should not only control fuel delivery and ignition but also play mp3. Preferably controlled using Sony's CD-changer protocol, but that is far away. Anyway, if you BIOS is able boot linux / rtlinux fast it would be great! That's all we need. We don't want the slow code BIOS manifacturers put in for DOS and other stuff. I'll check your news page to see your progress. Keep up the good work. Daniel Haglund dhaglund(a)mail.uccs.edu - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

wish me luck
by Ronald G. Minnich 28 Feb '00

28 Feb '00

I am now successfully gunzipping the kernel into ram. At some point this will finish (yow it's slow under the debugger I'm using!) and I'll jump to it, say in another 15 minutes :-) we'll see. The fixes I mentioned to inflate.c are essential. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

initialized arrays in inflate.c
by Ronald G. Minnich 28 Feb '00

28 Feb '00

These should be declared with attribute 'const', which puts them into the .rodata segment, which means they're in the nvram. This fixes a big problem. I'm ansi-fying inflate.c now, to find other issues. 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 enumeration?
by Wallace I. Kroeker 28 Feb '00

28 Feb '00

Hello, I posted this a little earlier: As for PCI initialization stuff you may want to check out the Ralf Brown page. He has a very nice piece of software that finds all your PCI devices with lots of information on the devices. http://www.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/WWW/files.html This has his interrupt list AND "RBpciv1.19 - PCI device info program". Wallace > -----Original Message----- > From: Brian Hurt [SMTP:bhurt@talkware.net] > Sent: Saturday, February 26, 2000 2:44 PM > To: OpenBios Mailing List > Subject: [OpenBIOS] PCI enumeration? > > Is anyone else out there working on adding PCI enumeration to OpenBIOS? > Any one have any pointers to code I can theft, er, reuse? I'm looking at > the function pci_scan_bus() in the linux source code (drivers/pci/pci.c), > but that looks like it just reads the results of an already-enummerated > PCI bus. > > Help would be greatly appreciated. > > Brian > > > - > 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] Aladdin V chipset
by Marcus Gossner 28 Feb '00

28 Feb '00

We are using Aladdin 4 chipset here, but the south bridge (1543C A1) maybe is the same. If you need some help in setup the configuration registers for that, feel free to contact me. Marcus > -----Original Message----- > From: Burl Nyswonger > Sent: Saturday, February 26, 2000 6:30 PM > To: openbios(a)wesley.informatik.uni-freiburg.de > Subject: [OpenBIOS] Aladdin V chipset > > > I have begun to hack on OpenBIOS and am looking to add support for x86 and > the Aladdin V chipset (ie: Super Socket7, Asus P5A, etc...). If anyone > else has started work on this, or plans to, it would be nice to talk. > > -- Burl. > > > > - > 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

A problem with the gunzip stuff.
by Ronald G. Minnich 28 Feb '00

28 Feb '00

There are initialized arrays in the inflate code. These get compiled to initialized data. The problem is, when the openbios scripts relink the code32.o stuff, this init data is relocated to 0x90000. Well, guess what ... who's going to initialize that after a reset? It's all zero's! This is kind of standard embedded processor hassle, the old 'how to init' thing. There is some sort of gcc or ld switch to say 'put init const data in with text', and I'll try that out first (it works for char strings now, so I know it's doable). If it fails, I'm turning initialize stuff into functions. That should do the trick. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Via BIOS source code
by Frank Tagliano 25 Feb '00

25 Feb '00

Via bios code on public ftp: ftp://ftp.via.com.tw/public/sw/ ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

9 17

Extended BIOS Data Area (EBDA)
by Jeff Garzik 23 Feb '00

23 Feb '00

It seems the Phoenix BIOS page doesn't have info on EBDA, so I hit google :) (generic info, grep -i 'ebda') http://www.sot.com/ftp/laitteet/bios/mr_FAQ.html (specific format?, grep -in ebda) http://mvmpc9.ciw.uni-karlsruhe.de/d:/public/helppc/tables.txt (more format, grep -in 'extended bios') http://magic.hurrah.com/~sabre/os/S1Booting/BIOS_SEG.txt [CC'd to the OpenBIOS list as this might be helpful to some there, too.] Regards, Jeff -- Jeff Garzik | Building 1024 | Viva la open source! MandrakeSoft, Inc. | - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

well, I'm gunzipping allright
by Ronald G. Minnich 22 Feb '00

22 Feb '00

and there's a bug in the inflate, it is screwing up. arg! ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

RE: [OpenBIOS] Video (particularly 440GX)
by Marcus Gossner 22 Feb '00

22 Feb '00

> >> so, i gather that this dedicated pci bus connects to the graphics chipset. >> and since it appears as another pci device, it must implement the pci >> configuration space, and thus it has an expansion ROM base address >> register which we can determine if a BIOS exist or not. If it has one, >> then it is likely that the initialization of the graphics chip is done by >> the this BIOS instead of the system BIOS. > >Unfortunately it may not be that simple on motherboards with integrated >graphics. There is only one NVRAM chip. This NVRAM is owned by the PIIX4E >bridge. I am not sure how they would do the expansion ROM base address for >the AGP stuff. > >But it is certainly worth a look. If there is only one NVRAM the Video BIOS must be included in the system BIOS. Maybe you can do the following: - start with your original BIOS - copy the Video BIOS to a file (it starts at 0xC0000) - include the file into your BIOS - move the Video BIOS to 0xC0000 - start it I think that should work. Marcus - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

3 3

Re: [OpenBIOS] Video (particularly 440GX)
by Ronald G. Minnich 22 Feb '00

22 Feb '00

On Tue, 22 Feb 2000, Chong Chee Yong wrote: > If the system BIOS has to initialise the graphics chipset using codes from > itself (instead of the usual call to the graphics chipset BIOS), then the > system BIOS becomes less generic, probably customised for the > motherboard-graphics chip combination. I'm not sure if this would be the > usual case as it seems less cost-effective, because everytime the > graphics chip changes architecturally, the system BIOS has to change. The system bios is a bit different for every motherboard type. There are lots of subtle differences between these motherboards and each one requires tweaks. Example: the c440gx and l440gx+ motherboards are incredibly similar (check them out on intel.com). They have different BIOSes. Thanks for the ROM base address info. This could be useful. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] Video (particularly 440GX)
by Ronald G. Minnich 22 Feb '00

22 Feb '00

On Tue, 22 Feb 2000, Chong Chee Yong wrote: > so, i gather that this dedicated pci bus connects to the graphics chipset. > and since it appears as another pci device, it must implement the pci > configuration space, and thus it has an expansion ROM base address > register which we can determine if a BIOS exist or not. If it has one, > then it is likely that the initialization of the graphics chip is done by > the this BIOS instead of the system BIOS. Unfortunately it may not be that simple on motherboards with integrated graphics. There is only one NVRAM chip. This NVRAM is owned by the PIIX4E bridge. I am not sure how they would do the expansion ROM base address for the AGP stuff. But it is certainly worth a look. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

Re: [OpenBIOS] Video
by Ronald G. Minnich 22 Feb '00

22 Feb '00

the second device on the bridge is in essence a dedicated pci bus for the graphics hardware. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

asm code
by Edwin Rhodes 22 Feb '00

22 Feb '00

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 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. edwin

3 2

RE: [OpenBIOS] Video
by Wallace I. Kroeker 21 Feb '00

21 Feb '00

There has been great discussion on video here so I decided to see how the video was handled in the linux kernel. Sure enough they use "int 0x10" to handle the video setup etc. The code does detection of the video type (e.g. looks for EGA/VGA) and sets things up appropriately and then continues to use the "int 0x10" calls to actually output some of the fine linux boot messages. As for the use of the full 256K region I suspect we will run into a lot of other conflicts with cards other than video cards. The bios that is built into these cards (video, m-systems disk on a chip) expect that they will live in the C0000 to C8000 region (from what I've read). Someone can correct me if I'm wrong but we have to avoid using this area if we want things to work with these different cards. As for PCI initialization stuff you may want to check out the Ralf Brown page. He has a very nice piece of software that finds all your PCI devices with lots of information on the devices. http://www.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/WWW/files.html This has his interrupt list AND "RBpciv1.19 - PCI device info program". We should be able to use some parts of this code to enumerate the PCI for setting up the information on the attached devices. Also, the following book is very good and worth purchasing: PCI Hardware and Software, 4th Ed. by Edward Solari and George Willse ISBN 0-929392-59-0 http://www.annabooks.com/fx020064.htm I am starting to look into the System Management Bus to determine memory size. If anyone has any code that is doing this already that would be appreciated. My status: I have my the OpenBIOS booting the 440BX with a set amount of memory but haven't got a small enough linux payload which would fit in the legal BIOS area of my machine. The video and serial is working to allow me to interact with the basic openbios. I am looking at implementing enough of the BIOS floppy to at least do a load from floppy for the time being. I have tried this in a minimal system but am waiting for another flash chip so that I can do some live testing. I compared my memory setup with the code that Ron provided and they are basically identical although I haven't confirmed this with total boot from a flashed bios (later this week hopefully). Wallace > -----Original Message----- > From: Ronald G. Minnich [SMTP:rminnich@lanl.gov] > Sent: Monday, February 21, 2000 11:13 AM > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: Re: [OpenBIOS] Video > > the second device on the bridge is in essence a dedicated pci bus for the > graphics hardware. > > 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

2 1

Re: [OpenBIOS] Video
by Jeff Garzik 21 Feb '00

21 Feb '00

Chong Chee Yong wrote: > > how is it supported directly by the 440gx bridge? > or do you mean it is connected directly instead of via > the usual agp/pci slot? > > On Sun, 20 Feb 2000, Ronald G. Minnich wrote: > > > yes indeed it does. It is in fact supported in a very direct way by the > > 440gx bridge chip. Now that I have the docs on it I'm going to see how > > hard it is to bring up ... Most integrated video chips are connected directly BUT are configured either via the VGA registers and/or the PCI config registers... -- Jeff Garzik | Building 1024 | Viva la open source! 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] Video
by Ronald G. Minnich 21 Feb '00

21 Feb '00

On Sat, 19 Feb 2000, Chong Chee Yong wrote: > not familiar with this, but does the integrated graphics chip appear as > another PCI device? yes indeed it does. It is in fact supported in a very direct way by the 440gx bridge chip. Now that I have the docs on it I'm going to see how hard it is to bring up ... ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

Assembler
by Burt A1C Jesse M 21 Feb '00

21 Feb '00

Hi folks, I'm sorry if it was mentioned somewhere already, but I was just curious...in some of the messages, one posts some snippets of asm.. what assembler is this, gas? nasm? Thanks.. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

Re: [OpenBIOS] Video
by Jeff Garzik 19 Feb '00

19 Feb '00

Chong Chee Yong wrote: > not familiar with this, but does the integrated graphics chip appear as > another PCI device? I dunno about the 440GX specifically.... If the motherboard supports PCI the graphics chip will a PCI device 99.9% of the time :) Embedded controllers are a bit different though... > On Fri, 18 Feb 2000, Ronald G. Minnich wrote: > > the thing is, as long as you depend on vga bios support, you're never > > going to be openbios. One reason is that graphics are increasingly a chip > > on the motherboard, with the vga bios in the motherboard nvram. There > > isn't room for linux and that vga bios in the nvram. Second is, until you > > get all the secrets out, we're locked in to braindead bios'es. -- Jeff Garzik | The ultimate Windows 98 keyboard: Building 1024 | Ctrl, Alt + Del on one big key! MandrakeSoft, Inc. | - another cute fortune - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

openbios source code
by Ross 19 Feb '00

19 Feb '00

Can somone send me a copy of the openbios source code I can not get the copy from the openbios page to unzip under windows 95. //Ross

1 0

Re: [OpenBIOS] code
by Ross 18 Feb '00

18 Feb '00

Can somone send me a copy of the openbios source code I can not get the copy from the openbios page to unzip under windows 95. //Ross ---------- > From: Ronald G. Minnich <rminnich(a)lanl.gov> > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: Re: [OpenBIOS] code > Date: Thursday, February 17, 2000 6:52 AM > > On Thu, 17 Feb 2000, Marcel Wijlaars wrote: > > I tried it at home last night and compiled just fine but didn't word > > because of the scsi thing. > > I use a rather old linux distribution at work, maybe thats why it did not > > work. > > I'll try again at work with a new linux distibution and a ide disk. > > > > great, if you can tell me what's up with scsi bootparams I'll try to fix > it at my end. Or, even better, if you fix it i'll take your patch :-) > > ron > > - > To unsubscribe: send mail to majordomo(a)freiburg.linux.de > with 'unsubscribe openbios' in the body of the message

2 1

Re: stripkernel??
by Ronald G. Minnich 18 Feb '00

18 Feb '00

I am *very* sorry about this missing piece. Thanks for noticing it. This is it. #!/bin/sh objcopy -O binary -R .note -R .comment -S $1 $2 All this does is strip the kernel down to a binary for lobos usage. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] bootloader
by Jaime Dias 18 Feb '00

18 Feb '00

---------- > From: Edwin Rhodes <edwin_rhodes(a)hotmail.com> > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: [OpenBIOS] bootloader > Date: Quarta-feira, 16 de Fevereiro de 2000 22:55 > > why dont you just use the traditional method of booting an os and forget > about using a multibootloader. ps also, will you support all the traditional > bios calls? i think that it would be a very good idea to otherwise you would > be at a compatibility disadvantage from the viewpoint that only os's that > dont call on the bios would work. > anyway keep up the good work. ps is the source availiable +the image? also > will it work on a non intel pci chipset, ie. isa 386 board. > edwin > all the source (as snapshots, so it's not stable) can be found at ftp.aros.org thanks in advance, jaime dias

1 0

question for this list
by Ronald G. Minnich 17 Feb '00

17 Feb '00

Would anyone object if I advised people interested in linuxbios just to join this list? It seems we have a lot in common. If that's a problem, I'll start a linuxbios list Many thanks ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

proposed changes
by Ronald G. Minnich 17 Feb '00

17 Feb '00

I think life would be much easier in OpenBIOS if we did the following: 1) reduce the amount of 16-bit assembly so we need less nasm 2) reduce the amount of 32-bit assembly so we need less as 3) get to protected mode as soon as we can This is important, since initializing sdram requires that you be able to use 32-bit addresses 4) maximize the amount of C Since we aren't just for pentiums To get here, all we need to do is this: 1) in 16-bit mode, lgdt with the in-NVRAM gdt, switch to protected, and jump to 32-bit 2) in 32-bit, turn on memory, and call main() That's about all it takes. I haven't seen anything in the 16 and 32-bit init that we can't do in C, and that includes ins and outs. If I'm missing something let me know. I'm probably going to start to take my snapshot in this direction anyway -- I'm sick of nasm ... ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

3 2

success on l440gx+ ram
by Ronald G. Minnich 17 Feb '00

17 Feb '00

I forgot to put a 0x17 in reg 0x76 after the mode set command. Sheesh. dram is now working fine. I am actually in protected mode in the 32-bit openbios startup, getting ready to gunzip linux and jump to it. Now the trick is to figure out why I have no display :-) All I want for now is a vga-compatible thing, very limited in scope. So I want the absolute minimum hardware only. Any hints would be welcome. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

6 8

New Homepage
by Daniele Frijia 17 Feb '00

17 Feb '00

See http://www.freiburg.linux.de/openbios for the new homepage. Regards, Daniele - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

AROS
by Jaime Dias 17 Feb '00

17 Feb '00

Hi, does Open Bios will catch the i386 irq handles? if it will, i would ask what is the best path to make AROS (www.aros.org) to run as standalone OS on i386 and maybe use the Open Bios as background to all the boot sequence? PS: i have visited the open bios HP, but i am little confused about what is beeing coded (on what they are working now)

3 3

Documentation on 0xcfe IO port?
by Wallace I. Kroeker 16 Feb '00

16 Feb '00

Hello Ron, You put up the following code and I am wondering about the CFE port, in particular where is there some documentation on this. generic_init: PORT_80 0xd0 ; now the fun begins. ; turn on the dram and wait a while (this from the intel book) mov dx, 0xcf8 mov eax, 0x80000074 out dx, eax mov dx, 0xcfe ; turn power and and set the nop bit too. mov al, 0x30 out dx, al I have the interrupt and port information from Ron Brown and there is a reference to PORT 0CF8-0CFF as being used for PCI Configuration Mechanism 1. When I look through all the Intel documentation I only see 0CF8 and 0CFC referenced. Do you have some more documentation on this? Thanks Wallace - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

Problem with 256K BIOS build
by Wallace I. Kroeker 16 Feb '00

16 Feb '00

Hello, I have the OpenBIOS working for both 64K and 128K builds. However, when I try to do the 256K I get nothing. I came across some documentation that claims that "32KB of BIOS expansion range from 0C0000H to 0C8000H is typically reserved for the video BIOS expansion ROM" (source is M-Systems DiskOnChip 2000 data sheet). If this is true then how do you fit the 256K bios in the system as we will need the range from C0000H all the way up to FFFFH and manage to avoid a collision with the video BIOS expansion ROM. I am using loadbios for testing and have sucked out the BIOS that comes with my system. This works fine. However, the OpenBIOS build of 256 doesn't. Any ideas on what we need to do? Wallace - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

RE: [OpenBIOS] success on l440gx+ ram
by Stawnyczy, Evan 16 Feb '00

16 Feb '00

i used to program for interplay, vga hardware was my specialty... what do you mean by vga thing? -----Original Message----- From: Ronald G. Minnich [mailto:rminnich@lanl.gov] Sent: February 15, 2000 9:18 Pm To: openbios(a)elvis.informatik.uni-freiburg.de Subject: [OpenBIOS] success on l440gx+ ram I forgot to put a 0x17 in reg 0x76 after the mode set command. Sheesh. dram is now working fine. I am actually in protected mode in the 32-bit openbios startup, getting ready to gunzip linux and jump to it. Now the trick is to figure out why I have no display :-) All I want for now is a vga-compatible thing, very limited in scope. So I want the absolute minimum hardware only. Any hints would be welcome. 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

2 1

Re: [OpenBIOS] probably the last questions
by Ronald G. Minnich 16 Feb '00

16 Feb '00

On Wed, 16 Feb 2000, Kent Nyberg wrote: > Are you just trying to put a Linux kernel in the bios, or will you put > an advanced bootloader there? Or will you put both there (bootloader and > kernel)? I am putting linux there. I have no interest in anything else on our cluster -- linux is what we run. > How much code can you put in the bios? 1 MByte. > Since not much seem to have changed on the bios front the last 10 years > i don't think they can be that big... ? They're huge. The phoenix bios is over 1/2M. For all that size what it gets you is a not very useful piece of code. Do you want 1/2M of phoenix bios or 1/2M of linux image :-) > Oh, i have noticed that some linux mailinglist seem to NOT like if one > write alot on the mailinglists.. is it the same here? Please write a lot and ask questions. Also, if you want to help, that would be good too. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Some VGA set up that seems to work on a 440BX with a PCI (Rage II I card)
by Wallace I. Kroeker 16 Feb '00

16 Feb '00

Hello, Ron was asking about this and here is the code snippets that managed to get things working for me. Of course, I had the interrupt incorrect as it is int 10h ... sorry. The following goes in boot/boot16/start.asm (I put it right after the FPU reset): ;;************* ;; set up the VGA into text mode mov ah, 0x00 mov al, 0x07 ; a MDA type mode int 10h PAUSE ; delays are always good when you are counting on other devices to set up ;; load a character set ... the card usually have a few predefined mov ah, 0x11 mov al,0x01 ; 8x14 ;; *** mov al, 0x02 ; this is for 8x8 mov bl, 0x00 ; load it into a character table (0 or 1) in this case 1 int 10h PAUSE ;; Activate the character set 0 mov ah, 0x11 mov al, 0x03 mov bl, 0x00 ;; activate character table 0 int 10h PAUSE ;;; Just for a test you can try to output a character now ;; mov ah, 0x0A ;; mov al, 0x55 ; a character ;; mov bh, 0x00 ; video page number ;; mov bl, 0x00 ; foreground color of character for graphics mode ;; mov cx, 0x01 ; repeat factor ;;********** The following changes need to be made in the VIDEO.H #define VIDEO_MDA 1 #define VIDEO_CGA 2 #define VIDEO_EGA 3 #define VIDEO_VGA 4 CONSOLE.C in the console_init: have_video = video_init( VIDEO_VGA ); VGA.H // #define VGA_FBBASE 0xb8000 #define VGA_FBBASE 0xb0000 // this is the MDA area Hope this helps getting things going for you. Wallace > -----Original Message----- > From: Ronald G. Minnich [SMTP:rminnich@lanl.gov] > Sent: Tuesday, February 15, 2000 7:18 PM > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: [OpenBIOS] success on l440gx+ ram > > I forgot to put a 0x17 in reg 0x76 after the mode set command. Sheesh. > > dram is now working fine. I am actually in protected mode in the 32-bit > openbios startup, getting ready to gunzip linux and jump to it. > > Now the trick is to figure out why I have no display :-) > > All I want for now is a vga-compatible thing, very limited in scope. So I > want the absolute minimum hardware only. Any hints would be welcome. > > 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] success on l440gx+ ram
by Wallace I. Kroeker 16 Feb '00

16 Feb '00

The trick is to setup the VGA BIOS. One of the links off the OpenBIOS site has a list of Interrupts and Ports. You need to look at kicking the VGA BIOS via Interrupt 11h (I think that is the correct one). There was a complete section that described the VGA BIOS. I will put the code up here a little later today (I am out of the office and the code right now). You need to set the mode (07 is MDA mode) and then get it to load one of the VGA BIOS character tables and then activate that character set. I put this code into the boot16/start.asm right after the MDA and CDA init code. The basic form is: ;; set up register (I think AX was used) for init int 11h ;; set up for character set load int 11h ... Now the only other trick is that the MDA address range is different than the typical VGA so you need to change this in firmware/init/VGA.h . Also, call video_init in firmware/init/main.c (or is it console.c? ...). The MDA is 0 and VGA is 4 (I set up some defines). So now you should get the OpenBIOS logo to print out. Sorry for not giving you the code snippets but I will get them to you later. > -----Original Message----- > From: Ronald G. Minnich [SMTP:rminnich@lanl.gov] > Sent: Tuesday, February 15, 2000 7:18 PM > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: [OpenBIOS] success on l440gx+ ram > > I forgot to put a 0x17 in reg 0x76 after the mode set command. Sheesh. > > dram is now working fine. I am actually in protected mode in the 32-bit > openbios startup, getting ready to gunzip linux and jump to it. > > Now the trick is to figure out why I have no display :-) > > All I want for now is a vga-compatible thing, very limited in scope. So I > want the absolute minimum hardware only. Any hints would be welcome. > > 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] success on l440gx+ ram
by James 16 Feb '00

16 Feb '00

> Now the trick is to figure out why I have no display :-) > > All I want for now is a vga-compatible thing, very limited in scope. Ron, I bet you need to initialize the hardware with a call to the video bios, so the card knows to display what is on B800. I don't know exactly what happens, but I know that in the display functions I wrote for you we display by writing straight to B800. I think the video bios resides somewhere between A000 and C800 (but not in the areas it uses for scratch space, like B800-C000 for color displays or B000-B800 (I think) for monochrome -- there may be more). Could you step through until it does that call? > getting ready to gunzip linux and jump to it. Also, why doesn't it gunzip linux and jump to it? - James - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

RE: [OpenBIOS] Starting linux aint much easy ?
by Attarian, Gary 16 Feb '00

16 Feb '00

Oops, this was my bad. after looking back at your previous posts, Jörg, I think Ronald is correct. Which brings me back to an earlier question. Namely are you loading a zImage or a bzImage? If you carefully look through the head.S code, you will notice it deciding whether the kernel is loaded high or low. I believe it does this by checking a value generated at compile time. Anyway, my understanding is that the big (bzImage) kernels are loaded high 0x101000 and the smaller (zImage) kernels are loaded into low memory at 0x1000. Assuming OpenBIOS puts the processor into protected mode with a 4g address space (a good bet as Ronald has already confirmed this), all you should have to do is jump to the kernel. If you already have access to the 4g address space while you are loading the kernel from flash this should be the case. One last question though, did you say you were loading a vmlinux image (uncompressed) into memory? If so, head.S assumes the image is compressed and trys to uncompress it. Gary > -----Original Message----- > From: Ronald G. Minnich [SMTP:rminnich@lanl.gov] > Sent: Tuesday, February 15, 2000 12:56 PM > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: Re: [OpenBIOS] Starting linux aint much easy ? > > I don't think you should fall back into real mode. There's no good reason > to. I think you should look at how LOBOS does its thing, which is to boot > linux entirely in protected mode, and emulate that in your bios. > > Falling into real mode is a mess. Also, once you drop to real mode, you > can't address 0x100000 any more. This is probably not what you want, since > your code is at 0x101000. > > ron > > - > To unsubscribe: send mail to majordomo(a)freiburg.linux.de > with 'unsubscribe openbios' in the body of the message

2 1

Re: [OpenBIOS] good question.
by Ronald G. Minnich 16 Feb '00

16 Feb '00

On Tue, 15 Feb 2000, Stefan Reinauer wrote: > Niklas Ekstr�m wrote a program some time ago, loadbios, which loads a bios > from a file to the memory from 0xe0000 to 0xfffff on some intel pcisets. > It can easily be adopted to other chipsets and it's quite small. > we used this invaluable program in the early stages. At some point we found a need to write the nvram, since we need a completely dead environment to make sure we can get things to work. But loadbios is a great help. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

code for starting up 440gx memory
by Ronald G. Minnich 15 Feb '00

15 Feb '00

here we go. caveats: this was generated by a script, using a linux system, to dump register values. Except for register 76, which was done from the programming manuals. I need to get a macro in here, I know. If you find this useless let me know and I'll try to do the macro. here goes. First, though: 1) set reg 76 to 30 (power + nop), delay 200 us 2) set up the other regs 3) set up reg 76 to 50, then the other values as shown. generic_init: PORT_80 0xd0 ; now the fun begins. ; turn on the dram and wait a while (this from the intel book) mov dx, 0xcf8 mov eax, 0x80000074 out dx, eax mov dx, 0xcfe ; turn power and and set the nop bit too. mov al, 0x30 out dx, al ; delay 200 us mov ecx, 0x20000 .loop: loop .loop ; First, set registers we can set once to reasonable values ; note -- this code auto-generated ... ; note -- we need to grab the nice macro from the other chipset file. ; set it for sdram, 31 microsecond refresh (? ok? ) ; should we be doing this just yet? who knows? mov dx, 0xcf8 mov eax, 0x80000054 out dx, eax mov dx, 0xcff mov al, 0x12 out dx, al mov dx, 0xcf8 mov eax, 0x80000058 out dx, eax mov dx, 0xcfd mov al, 0x0 out dx, al mov dx, 0xcf8 mov eax, 0x80000060 out dx, eax mov dx, 0xcfc mov al, 0x10 out dx, al mov dx, 0xcf8 mov eax, 0x80000060 out dx, eax mov dx, 0xcfd mov al, 0x20 out dx, al mov dx, 0xcf8 mov eax, 0x80000060 out dx, eax mov dx, 0xcfe mov al, 0x30 out dx, al mov dx, 0xcf8 mov eax, 0x80000060 out dx, eax mov dx, 0xcff mov al, 0x40 out dx, al mov dx, 0xcf8 mov eax, 0x80000064 out dx, eax mov dx, 0xcfc mov al, 0x50 out dx, al mov dx, 0xcf8 mov eax, 0x80000064 out dx, eax mov dx, 0xcfd mov al, 0x60 out dx, al mov dx, 0xcf8 mov eax, 0x80000064 out dx, eax mov dx, 0xcfe mov al, 0x70 out dx, al mov dx, 0xcf8 mov eax, 0x80000064 out dx, eax mov dx, 0xcff mov al, 0x80 out dx, al mov dx, 0xcf8 mov eax, 0x80000068 out dx, eax mov dx, 0xcfd mov al, 0x0 out dx, al mov dx, 0xcf8 mov eax, 0x80000068 out dx, eax mov dx, 0xcfe mov al, 0x0 out dx, al mov dx, 0xcf8 mov eax, 0x80000068 out dx, eax mov dx, 0xcff mov al, 0x0 out dx, al mov dx, 0xcf8 mov eax, 0x8000006c mov dx, 0xcfc mov al, 0x0 out dx, al mov dx, 0xcf8 mov eax, 0x8000006c out dx, eax mov dx, 0xcfd mov al, 0x0 out dx, al mov dx, 0xcf8 mov eax, 0x8000006c out dx, eax mov dx, 0xcfe mov al, 0x0 out dx, al mov dx, 0xcf8 mov eax, 0x80000074 out dx, eax mov dx, 0xcfc mov al, 0x22 out dx, al mov dx, 0xcf8 mov eax, 0x80000074 out dx, eax mov dx, 0xcfd mov al, 0x22 out dx, al mov dx, 0xcf8 mov eax, 0x80000078 out dx, eax mov dx, 0xcfc mov al, 0x7 out dx, al mov dx, 0xcf8 mov eax, 0x80000078 out dx, eax mov dx, 0xcfd mov al, 0x55 out dx, al mov dx, 0xcf8 mov eax, 0x800000c8 out dx, eax mov dx, 0xcfe mov al, 0x0 out dx, al mov dx, 0xcf8 mov eax, 0x800000c8 out dx, eax mov dx, 0xcff mov al, 0x0 out dx, al mov dx, 0xcf8 mov eax, 0x800000c8 out dx, eax mov dx, 0xcff mov al, 0x0 out dx, al mov dx, 0xcf8 mov eax, 0x800000cc out dx, eax mov dx, 0xcfc mov al, 0x1e out dx, al ; standard init of sdram at this point: ; it is on and the bridge is configured for 256M dimms. ; now we have to do a precharge all (see the pc100 sdram book mov dx, 0xcf8 mov eax, 0x80000074 out dx, eax ; now we stick to reg 76, so no more of that mov dx, 0xcfe ; we're going to use es to ref dram xor eax, eax mov es, eax ; do the nop cycle mov eax, [es:0x400] ; now we have to kick the dram to do this? so what, I guess we hit it, ; but we're not in bigreal, wonder what will happen. Just to bank 0 for ; now. A10 has to be high. (pc100 sdram book) ; this should be a Precharge all mov al, 0x50 out dx, al ; meaningless delay PORT_80 0xdf mov [es:0x400], eax ; now we do the eight CBRs mov al, 0x90 out dx, al PORT_80 0xdf mov eax, [es:0x400] mov eax, [es:0x400] mov eax, [es:0x400] mov eax, [es:0x400] mov eax, [es:0x400] mov eax, [es:0x400] mov eax, [es:0x400] mov eax, [es:0x400] ; now a mode register set mov al, 0x70 out dx, al PORT_80 0xdf ; we have to do a memory reference that sets things up. ; ok -- we go with burst length 4 (?) wrap type 0, ltmode 3 ; ltmod 3 matches the other mode in the bridge. This is slow, ; we fix later if possible ; now we reference the dram to issue the mrs mov eax, 0x32 mov [es:0x00], eax ; well, maybe it is working now. mov ax, cs mov ss, ax mov sp, .stack --------------------- anyways, i can store and load, but I'm only seeing an 8-byte memory. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

memory is on
by Ronald G. Minnich 15 Feb '00

15 Feb '00

memory appears to be working on my 440gx. Next step is gunzipping linux to high memory ... then jump to it. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

4 4

RE: [OpenBIOS] Starting linux aint much easy ?
by Attarian, Gary 15 Feb '00

15 Feb '00

Well, I still think you are almost there. I went through this same frustration a few months ago so I feel your pain :) >From the code you sent, I gather that you get the "i" out the serial port. But that it fails to get to the start_kernel routine. This is just what I encountered. I spent several days pulling out my hair until I discovered that I did not have the protected mode of the processor set up correctly. The problem I found was that I had not set the code segment to the proper value. Well after all that hair pulling (of course) I found the kernel/arch/i386/boot/setup.S file. This is the code which jumps to Linux from a floppy boot. Take a look in there especially the code preceding the code32: label. Your jump to 0x101000 has to have the 0x66 prefix or the last bit of protected mode will not truly be set up. What that means essentially, is that the code segment register will not be pointing to the appropriate location in the GDT. While some of the code may run, as soon as head.S trys to jump to another segment the processor will generate a GPF. I hope this helps. The explanation in the setup.S file is more eloquent that I. There is also a book "Protected Mode Software Architecture" by Tom Shanley published by Addison Wesley. I don't own a copy yet, but I have heard it contains much information about this issue. Most importantly, don't panic I still think you are 3/4 of the way there! Good luck. Gary P.S. I don't want to panic you, but does your system use the PCI bus? Have you properly set that up yet?

2 1

RE: [OpenBIOS] ram on l440gx+
by Stawnyczy, Evan 15 Feb '00

15 Feb '00

please do forward your code... -----Original Message----- From: Ronald G. Minnich [mailto:rminnich@lanl.gov] Sent: February 15, 2000 2:38 Pm To: openbios(a)elvis.informatik.uni-freiburg.de Subject: [OpenBIOS] ram on l440gx+ oops. While I am powering it up I'm doing something write. Writes always fail. I think it may be a refresh problem but ... who knows. I'm looking. All ideas welcome. I can forward my code to this list if anyone wants a look. 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

memory on 440GX+
by Ronald G. Minnich 15 Feb '00

15 Feb '00

OK, I forgot to set reg. 57 on the bridge chip. I set it to 0x12, which is normal (not registered) sdram and 31 microsecond refresh. Life is *much* better, save my SDRAM is only 8 bytes (yes, bytes) in extent. On to the next problem ... ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Starting linux aint much easy ?
by Winter Jörg 15 Feb '00

15 Feb '00

> I'm not sure how far you've gotten since saturday, but it sound to me like > you are almost there. I have set up a system to boot Linux from a flash. > From your descriptions, I believe you are on the right track. Before > jumping to Linux at 0x1000 for ..... Not far! I still have seveere trouble in starting the kernel ... from the firmware/init/main.c I am loading a vmlinux (1.2megs, uncompressed) image into my memory at 0x100000. I found out that the code in head.S is at offset 0x1000 inside the image. So I jump to 0x101000. That works. I modified the file: kernel/head.S: to notify me if I reached the head code: /* this is my dummycode ... to see if kernel starts .asciz "This is the kernel image entry point\n" << I used this to verify that I dont load garbage into RAM ... Fallback from Protected mode into Realmode, CLR PE1 */ movl %cr0,%eax andl $0xfffffffe,%eax movl %eax,%cr0 jmp flush flush: mov $0x3f8,%dx //here i give a char out to the uart (cause I dont have anything else to talk) mov $0x59,%al out %al ,%dx >>>>> until here everything works fine. but then ... cld movl $(__KERNEL_DS),%eax movl %ax,%ds movl %ax,%es movl %ax,%fs movl %ax,%gs #ifdef __SMP__ orw %bx,%bx jz 1f ... ... a bit later it should do: (same file) xorl %eax,%eax lldt %ax cld # gcc2 wants the direction flag cleared at all times call SYMBOL_NAME(start_kernel) L6: jmp L6 # main should never return here, but # just in case, we know what happens. ... therefore I expected to see the message i have put in /usr/src/linux/init/main.c : start_kernel(void) asmlinkage void __init start_kernel(void) { char * command_line; int i; #ifdef __SMP__ static int boot_cpu = 1; /* "current" has been set up, we need to load it now */ if (!boot_cpu) initialize_secondary(); boot_cpu = 0; #endif /* * Interrupts are still disabled. Do necessary setups, then * enable them say that were here already ... */ outb(0x58,0x03f8); for (i=0; i<0x0fff; i++); printk(linux_banner); .... .... but somewhere inbetween the machine stops. I cannot see my second char on the uart. I dont have an in-circuit debugger and since I´m not the prophet I dont know why and where it crashes ... Any ideas on that ?? btw. sorry for the lots of code i sent, but like that it was easier to show where I got stuck ... greetings, Jake. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

ram on l440gx+
by Ronald G. Minnich 15 Feb '00

15 Feb '00

oops. While I am powering it up I'm doing something write. Writes always fail. I think it may be a refresh problem but ... who knows. I'm looking. All ideas welcome. I can forward my code to this list if anyone wants a look. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

RE: [OpenBIOS] suggestion on ordering things
by Marcus Gossner 15 Feb '00

15 Feb '00

Hi, this is the POST code order of my Phoenix BIOS: 02 c8 c9 24 04 06 18 07 08 c4 11 0e 0c 16 17 28 3a 2a 2c 2e 2f 38 20 29 33 c1 09 0a 0b 0f 10 14 1a 1c 22 32 67 69 6b 3c 3d 42 46 45 47 49 c6 c5 48 4a 4c 24 59 cc 55 52 54 76 58 41 4b 4e 50 51 9d 5a 5b 5c 60 62 64 66 68 6a 6c 6e 70 72 4f 7c 7d 7e 80 ca 88 8a 81 87 85 82 84 86 83 89 8c cb cd 90 8b 95 92 b6 98 93 9c c7 9e a0 a2 a4 c3 ba c3 a8 aa ac ae b0 b2 b4 b5 be b6 bc b7 bd bf 8f 91 9f 97 99 b1 b9 c0 Marcus > -----Original Message----- > From: David Christensen > Sent: Monday, February 14, 2000 6:26 PM > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: RE: [OpenBIOS] suggestion on ordering things > > If you're looking for an idea on what to do during BIOS power-on self-test > (POST) you may start with this link: > http://www.phoenix.com/pcuser/userman.pdf > > Starting on page 35 you'll get a listing of POST codes and approximately > what occurs at each code. Unfortunately the codes are listed in numerical > order, not the order that they occur, but you should be able to figure out > which codes require RAM and which don't. Memory sizing occurs at POST > code > 28h, then you probably want to initialize RAM very soon afterwards by > writing a known value to every memory location to clear up any parity/ECC > errors that may be present because the contents of DRAM are not known at > power-up. > > Dave > > -----Original Message----- > From: owner-openbios(a)elvis.informatik.uni-freiburg.de > [mailto:owner-openbios@elvis.informatik.uni-freiburg.de]On Behalf Of > Ronald G. Minnich > Sent: Monday, February 14, 2000 7:37 AM > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: [OpenBIOS] suggestion on ordering things > > > I think memory startup should happen first or early. On the new machines > you can't use ram til you power on memory. > > 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 - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

RE: [OpenBIOS] Exception 13 ?
by Attarian, Gary 14 Feb '00

14 Feb '00

I'm not sure how far you've gotten since saturday, but it sound to me like you are almost there. I have set up a system to boot Linux from a flash. >From your descriptions, I believe you are on the right track. Before jumping to Linux at 0x1000 for zImages and 0x10000 for bzImages you have to have the system set up the same way a standard POST would have. That is, all of the peripherals need to be active and any machine dependant initializations need to have occured. Finally you need to put the processor into a quasi protected mode (I've heard it called unreal mode but I'm not sure if there is an official name). Basically this means you need to set up a GDT which alows access to all memory. And finally you need to jump to the Linix kernel with a far jump using the 32 bit address override. The code which linux loads ont a floppy to do just this stuff is in the file kernel/arch/i386/boot/setup.S. It has a lot of moving the kernel code which I believe you've already got. But then it does some setup stuff (and explains it better than I can) that you need. Once you've got this stuff I think you shold be able to boot the linux image you've loaded. :) Let me know how it goes and good luck! Gary > -----Original Message----- > From: Winter Jörg [SMTP:joerg.winter@disch-gmbh.de] > Sent: Saturday, February 12, 2000 12:56 AM > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: [OpenBIOS] Exception 13 ? > > > James: (jvh(a)uclink4.berkeley.edu): Thanks for the hint on loading a > Kernel, > but: > > Now I have a verified routine that loads the kernel (block by block) from > my > ATA-Disk into memory (at whatever I like. Currently at 0x00010000). I´m > loading a zImage at 0x00010000, the bootsect at 0x9000, > the setupsectors (4) at 0x9200. It´s just like the other loaders do it > ...he? > > I have the code like: static void (*v)() =(void *)KERNEL_START; > > I start like: v(); > > and the machine (the openbios) throws me an exception 13. (general > Protection Fault errorcode 0). > > I tried nearly any combination of stack-location, entry-adress and > kerneltype ... all fails ... > I now read alot about descriptors and segments and so cause I suspect the > problem is somewhere there ... > > But I just dont get the point. What am I doing wrong now ?? I thought the > kernel would just set up and start? > > I figured out that already the jump done with the v(); is the one that > causes the exception, no matter if there is a kernel or just dummy code > (like: jmp $). > > There must be something I misunderstood completely !! Help, I´m lost ... > > greetinx, J.Winter > > - > To unsubscribe: send mail to majordomo(a)freiburg.linux.de > with 'unsubscribe openbios' in the body of the message

1 0

suggestion on ordering things
by Ronald G. Minnich 14 Feb '00

14 Feb '00

I think memory startup should happen first or early. On the new machines you can't use ram til you power on memory. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

3 3

Exception 13 ?
by Winter Jörg 14 Feb '00

14 Feb '00

James: (jvh(a)uclink4.berkeley.edu): Thanks for the hint on loading a Kernel, but: Now I have a verified routine that loads the kernel (block by block) from my ATA-Disk into memory (at whatever I like. Currently at 0x00010000). I´m loading a zImage at 0x00010000, the bootsect at 0x9000, the setupsectors (4) at 0x9200. It´s just like the other loaders do it ...he? I have the code like: static void (*v)() =(void *)KERNEL_START; I start like: v(); and the machine (the openbios) throws me an exception 13. (general Protection Fault errorcode 0). I tried nearly any combination of stack-location, entry-adress and kerneltype ... all fails ... I now read alot about descriptors and segments and so cause I suspect the problem is somewhere there ... But I just dont get the point. What am I doing wrong now ?? I thought the kernel would just set up and start? I figured out that already the jump done with the v(); is the one that causes the exception, no matter if there is a kernel or just dummy code (like: jmp $). There must be something I misunderstood completely !! Help, I´m lost ... greetinx, J.Winter - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

4 3

Newbie question about the FAQ
by Kervin Low 13 Feb '00

13 Feb '00

Hi, I have been trying to retrieve the FAQ from the OpenBIOS homepage for the past couple of days. The server holding the document seems to be down. Has anyone else encountered this problem? Is there a mirror somewhere where I could get hold of this? Thanks. Kervin - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

openbios on nvram on l440gx+
by Ronald G. Minnich 12 Feb '00

12 Feb '00

well, I have my first cut, and it failed. It got to the sdram init and died. such is life ... you can see the story at www.acl.lanl.gov/linuxbios ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

5 5

"OpenBIOS" from AOpen
by Daniele Frijia 12 Feb '00

12 Feb '00

Hiho... Please take a look at: http://www.aopen.com.tw/company/news/1999/openbios.htm and tell me something about this kind of product. Are we still able to use the word "OpenBIOS"? Regards, Daniele - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

4 3

RE: [OpenBIOS] Exception 13 ?
by Winter Jörg 12 Feb '00

12 Feb '00

Yeah, thanks, but that still doesnt tell me anything about the exception problem. (I´m having my eyes open now since 27 hours and still no idea whats wrong with the code ... thats annoying) greetings to u, J. Winter - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

code for linux booting linux
by Ronald G. Minnich 11 Feb '00

11 Feb '00

I was asked to announce this again, so here goes. At www.acl.lanl.gov/linuxbios, at the top, there are links to the following: 1) A context-diff to 2.2.13 to implement the lobos system call. Lobos stands for Linux OS Boots OS, and it provides the pieces to allow a kernel to read a file in, overlay the current kernel with the file, and boot the new kernel. NO BIOS support is needed, so the whole thing takes about .5 second on my 600E laptop. Also, the log buffer is preserved across boots -- handy. 2) S00 modified to check for /lobos. If /lobos exists then S00reboot calls a program to call the lobos system call 3) The script command (/usr/bin/lobos) that is essentially a reboot command to make lobos happen 4) finally, a simple .c program that invokes the system call. Also included on this web page is a paper on how it all works. Let me know if you have questions, comments, or improvements. BTW, I'm going to plug openbios into the nvram on my l440gx today using the intel iflash utility. If this works, next step is booting linux out of nvram. Wish me luck! ron

1 0

it's there.
by Ronald G. Minnich 11 Feb '00

11 Feb '00

linux booting linux is there. It should stay there too. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

code
by Ronald G. Minnich 11 Feb '00

11 Feb '00

at www.acl.lanl.gov/linuxbios I've placed the code to let linux boot linux. questions, comments, fixes to me. Ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 8

RE: [OpenBIOS] PC-CMOS memory..
by David Christensen 11 Feb '00

11 Feb '00

The de-facto standard for most south bridges is to use 0x72 and 0x73, some will even use 0x74 and 0x75. You'll need to check that the PIIX4 has the second bank of CMOS enabled and unlocked but otherwise it's fairly straight forward. And you don't have to worry about bit 7 like you do when accessing 0x70 and 0x71. Dave -----Original Message----- From: owner-openbios(a)elvis.informatik.uni-freiburg.de [mailto:owner-openbios@elvis.informatik.uni-freiburg.de]On Behalf Of Stefan Reinauer Sent: Thursday, February 10, 2000 7:32 AM To: openbios(a)elvis.informatik.uni-freiburg.de Subject: RE: [OpenBIOS] PC-CMOS memory.. -----BEGIN PGP SIGNED MESSAGE----- Hi Dave, > The short answer is no, you can't use this memory. The PC BIOS assumes > exclusive ownership of this hardware. Unless you want to go to the effort > of mapping the CMOS usage for a particular platform (which is complicated by > the fact that some BIOS vendors rearrange their CMOS usage between each > version of their ROM!). You may find that some hardware platforms have > totally unused CMOS (for example, the PIIX4 has 256 bytes of CMOS, but many > platforms will only use the first 128 bytes) which you can take advantage of > but this is a hardware specific implementation and varies between platform > vendors. Is there a secure way to access anything in the CMOS over 128 bytes? I wrote some patches for the Linux nvram driver a long time ago to access not only ,64 bytes, but 128 bytes. I read somewhere that everything over 128 bytes has to be accessed over io registers 0x72 and 0x73 instead of 0x70 and 0x71. Has anyone information on that issue? Regards, Stefan -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOKK+0iu+zKndEmP5AQE4QAf9FeBFJ6FbRJf8dkjn/yrPvxBvZ6+5z2mK OoCqcGpvHEKoZ4AnwfS2LNsLg/BCz/J1/Y0M6F81GBxza+rGqeQnM6AcDW7lpgoq 7i7qmiEHbXg6swciGWl9OEJlHWpgYpko/w6ODg+gJKw2ZAYiGC0Kvb0bBelwoqqT EPQCWHXi9QNpR2Td92WlBqj2b300MN6Wvvr6zHqSKkynvv39Vj1LBA9ski3SPajh sx0HgzxnYXvi/PD4Np+uN6EU1fwU9HU92HE8x7wAgrBzGmadQU8uAkZTwChiFvO3 IE5fOmYs8WSrEBx7pQPeIJwaYPL6FMdRTOimi0etlg5/CpSMz6mf/g== =mjkg -----END PGP SIGNATURE----- - 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

A talk with Intel on the L440gx+
by Ronald G. Minnich 11 Feb '00

11 Feb '00

They are polite and unyielding. "We don't tell people how to do that, except under strict NDA, and we don't tell them anyway. You could hook up a tracer and watch what our BIOS does, but we frown on that". As of now, I'm frowning on further use of Intel products ... It's clear that there are hidden, undocumented registers in the PIIX4E that make FLASH update work. And Intel doesn't want its customers to know how they work. Which means Intel customers are stuck booting DOS to upgrade BIOSes. Oh, yeah, this also leaves FreeDOS in the cold: you guys have the same problem. So, if we're going to figure this out, we need to find a virus that writes to the bios on an L440GX+, and then reverse engineer that. I doubt the virus writers would go after us. The intel person did allow as how he thought upgrading devbios to work with an l440gx+ was a really great idea; he just made it clear that Intel was not willing to help. fooey. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

Re: [OpenBIOS] PC-CMOS memory..
by Steve and Sue 10 Feb '00

10 Feb '00

----- Original Message ----- From: Stefan Reinauer <stepan(a)suse.de> To: <openbios(a)elvis.informatik.uni-freiburg.de> Sent: 10 February 2000 15:32 Subject: RE: [OpenBIOS] PC-CMOS memory.. > Is there a secure way to access anything in the CMOS over 128 bytes? I wrote > some patches for the Linux nvram driver a long time ago to access not only ,64 > bytes, but 128 bytes. > I read somewhere that everything over 128 bytes has to be accessed over > io registers 0x72 and 0x73 instead of 0x70 and 0x71. Has anyone information on > that issue? I'm not sure what you mean by 'secure', do you mean consistent? 0x72 and 0x73 do seem to be the method for accessing the upper 128-bytes of CMOS but I'm not aware of any 'standard'. These days the CMOS is often on the South Bridge of the chipset so you need to check the individual data sheets, (its a while since I programmed a discrete NVRAM), some of the chipsets have locks and other enables so it is wise to check the data. Steve - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

RE: [OpenBIOS] l440gx+ nvram writing ... the BUD
by Wallace I. Kroeker 10 Feb '00

10 Feb '00

Ron, You may be well along this path anyway but this may be of some use. So after wandering through the documentation abyss this is what I've gleaned so far: >From a product spec. in this case "Enterprise Server Group Intel N440BX Server Technical Product Specification" (I think I saw a similar one for a 440gx based product ...) there is a BUD. They have a FLASH_PE_L GPO24 (General Purpose Output from the PIIX4) and DIS_NON_FLASH_SMI GPO25. If you look at the inputs to the BUD the DIS_NON_FLASH_SMI goes into pin 8 on the BUD and seems to control the secure FLASH programming. While looking there you can see that there is a EN_SMI_L line that goes into the BUD this enables SMI generation (you would want to disable this before trying to write to the FLASH again). The EN_SMI_L is driven by GPIO bit 9. Also on the BUD, pin 48 is driven by the FLASH_PE_L (if you don't disable SMI generation I suspect you just get another SMI...). So it would seem that for THIS system once you are in the SMI interrupt that should be able to set various IO signals on the PIIX4 to disable SMI and enable writing to the Flash. Now I would suspect that your motherboard would be similar to one like this but then this is Intel we're talking about ... Wallace > -----Original Message----- > From: Ronald G. Minnich [SMTP:rminnich@lanl.gov] > Sent: Tuesday, February 08, 2000 12:09 PM > To: 'openbios(a)freiburg.linux.de' > Subject: RE: [OpenBIOS] l440gx+ nvram writing ... > > On Tue, 8 Feb 2000, Wallace I. Kroeker wrote: > > > Ron, > > Have a look at this ( I had to do a search of all the intel site) but it > > does give a description of how > > their Flash works (flow charts etc). It also give references to source > code > > but I'm not sure if this is freely available or not. > > Professional I/O Application > > Developer's Kit > > User's Manual > > August 1998 > > Yup, I've got that. It's worth getting. Where we're stopped at present is > the BUD on the l440gx+, though. > > thanks > > 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

3 4

Re: [OpenBIOS] PC-CMOS memory..
by Petazzoni Thomas 10 Feb '00

10 Feb '00

> Is there a secure way to access anything in the CMOS over 128 bytes? I wrote > some patches for the Linux nvram driver a long time ago to access not only ,64 > bytes, but 128 bytes. > I read somewhere that everything over 128 bytes has to be accessed over > io registers 0x72 and 0x73 instead of 0x70 and 0x71. Has anyone information on > that issue? for all those kind of considerations i recommend you "The Indispensable PC Hardware Book - Third Edition". but if you need the informations now, i can copy part of this book.... it's up 2 u ! bye -- PETAZZONI Thomas Web : http://kos.enix.org thomas.petazzoni(a)enix.org ICQ : 34937744 - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

RE: [OpenBIOS] PC-CMOS memory..
by Maciej W. Rozycki 10 Feb '00

10 Feb '00

On Thu, 10 Feb 2000, Stefan Reinauer wrote: > Is there a secure way to access anything in the CMOS over 128 bytes? I wrote > some patches for the Linux nvram driver a long time ago to access not only ,64 > bytes, but 128 bytes. > I read somewhere that everything over 128 bytes has to be accessed over > io registers 0x72 and 0x73 instead of 0x70 and 0x71. Has anyone information on > that issue? You need to check datasheets of particular chips (for example look at Dallas Semiconductor's site for specs of DS12887) to see how to access the extra space (IIRC, DS12887 uses banking). For PC machines, bit #7 at 0x70 is used to drive an external NMI mask latch. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro(a)ds2.pg.gda.pl, PGP key available + - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

BOUNCE openbios@freiburg.linux.de: Admin request of type /^\s*which\s*$/i at line 9
by owner-openbios＠freiburg.linux.de 09 Feb '00

09 Feb '00

>From stepan(a)freiburg.linux.de Wed Feb 9 10:30:01 2000 Received: from avalon.informatik.uni-freiburg.de (avalon.informatik.uni-freiburg.de [132.230.150.1]) by wesley.informatik.uni-freiburg.de (8.8.8/8.8.8) with ESMTP id KAA01906 for <openbios(a)elvis.informatik.uni-freiburg.de>; Wed, 9 Feb 2000 10:30:01 +0100 Received: from mailgateway1.uni-freiburg.de (mailgateway1.uni-freiburg.de [132.230.1.6]) by avalon.informatik.uni-freiburg.de (8.9.0/8.9.0) with SMTP id KAA20273 for <openbios(a)elvis.informatik.uni-freiburg.de>; Wed, 9 Feb 2000 10:29:58 +0100 (MET) Received: from cyclone.stortek.com [129.80.22.130] by mailgateway1.uni-freiburg.de with esmtp (Exim 1.82 #3) id 12ITRc-0007N1-00; Wed, 9 Feb 2000 10:29:56 +0100 Received: from cyclone.stortek.com (localhost [127.0.0.1]) by cyclone.stortek.com (8.9.3/8.9.3) with ESMTP id CAA20643 for <openbios(a)elvis.informatik.uni-freiburg.de>; Wed, 9 Feb 2000 02:24:56 -0700 (MST) Received: from vinson-atm6.stortek.com (root(a)vinson.stortek.com [129.80.120.134]) by cyclone.stortek.com (8.9.3/8.9.3) with ESMTP id CAA20639 for <openbios(a)elvis.informatik.uni-freiburg.de>; Wed, 9 Feb 2000 02:24:55 -0700 (MST) Received: from eur-bridge.europe.stortek.com (eur-bridge.stortek.com [129.80.178.149]) by vinson-atm6.stortek.com (8.9.3/8.9.3) with ESMTP id CAA12205 for <openbios(a)elvis.informatik.uni-freiburg.de>; Wed, 9 Feb 2000 02:25:08 -0700 (MST) Received: by eur-bridge.europe.stortek.com with Internet Mail Service (5.5.2650.21) id <1SB7DV5G>; Wed, 9 Feb 2000 09:24:24 -0000 Message-ID: <465C3B178FD4D21192B40008C79FD87E878699(a)ehqmsg01.europe.stortek.com> From: "Jessen, Per" <JesseP(a)europe.stortek.com> To: "'openbios'" <openbios(a)elvis.informatik.uni-freiburg.de> Subject: flashing AMD EPROMs under Linux (possibly off-topic) Date: Wed, 9 Feb 2000 09:23:50 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" All, this is probably off-topic on this list, so my apologies in advance. But considering the recent debate on the flashing of BIOS'es, I figured this might be the right place to ask - I'm trying to flashwrite to an AMD29F010A - 128K flash EPROM. It's sitting at 0xC000 as a video-ROM. I've got a module (kernel 2.2.14) doing this, which initially caused some problems, but it's more or less working now. It's the "more or less" bit that's causing problems :-) If I leave the 2 first bytes of the ROM-image as 0xFFFF (instead of 0xAA55) I can flash the EPROM with no problems. If I leave them in, the system appears to get stuck/hung. No way out, except reset. If I use 0xFFFF at first, then subsequently try to write 0xAA55, the system again appears to locks up. Prior to a new write, I erase the entire EPROM (not necessary, I know, but ...) So, what I don't understand is what is the importance of the 0xAA55 to Linux ? I can flash the EPROM using a DOS utility with absolutely no problems. If this is the wrong place to ask, could someone point me in the right direction ? MTIA regards, Per Jessen

1 0

RE: [OpenBIOS] l440gx+ nvram writing ...
by Wallace I. Kroeker 08 Feb '00

08 Feb '00

Ron, Have a look at this ( I had to do a search of all the intel site) but it does give a description of how their Flash works (flow charts etc). It also give references to source code but I'm not sure if this is freely available or not. Professional I/O Application Developer's Kit User's Manual August 1998 Wallace - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

Floppy driver
by Petazzoni Thomas 08 Feb '00

08 Feb '00

Hi there, does somebody can help me to debug my beginning of floppy driver ? i don't want to write all my questions if nobody's can help me ! thx -- PETAZZONI Thomas Web : http://kos.enix.org thomas.petazzoni(a)kos.enix.org ICQ : 34937744 - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 2

RE: [OpenBIOS] l440gx+ nvram writing ...
by Wallace I. Kroeker 08 Feb '00

08 Feb '00

Hello Ron, Here is my take after reading the documentation (the documentation seems to be identical for the 440bx). Intel (or some other BIOS maker) write a BIOS. This BIOS has the SMI handler in it. The SMI handler has a signature that it expects from the Flash software (written by the said BIOS maker). The signature is something that they won't want to divulge to keep people from inadvertently (maliciously) flashing BIOS. So how can you get around this? The following steps seem logical: 1. Write your own BIOS that has an SMI handler with your own signature. 2. Use the Flash update utility for your Board to flash your BIOS into place 3. Write your own Flash update utility which supplies your signature to your BIOS Or the following sequence of steps: 1. Write your own BIOS that has an SMI handler with your own signature. 2. Use LoadBios to put your BIOS in place (NOTE: you will be redefining the SMI handler at this point to be your own) 3. Proceed to write your BIOS to FLASH Now that sounds simple enough but I suspect the tricky part is the SMI handler. I really don't think the signature is that magical but rather a hand-shaking/security feature. Wallace > -----Original Message----- > From: Ronald G. Minnich [SMTP:rminnich@lanl.gov] > Sent: Monday, February 07, 2000 4:32 PM > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: Re: [OpenBIOS] l440gx+ nvram writing ... > > On Mon, 7 Feb 2000, Edwin Rhodes wrote: > > > Well if thats the case, lets hope to god that freedos will do the trick! > :) > > not that simple. You'll still have to solve the problem for freedos of > unlocking the key. > > Go to intel and get doc # 245141-001 of 3/1999. Check page 19, para 2.3.2 > We need to see how that is handled. I've got requests in to Intel and > VALinux now. We'll see how it goes. > > 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

2 1

RE: [OpenBIOS] Floppy driver
by Wallace I. Kroeker 08 Feb '00

08 Feb '00

I have been looking into this and would be interested in helping out. So you should post your questions. > -----Original Message----- > From: Petazzoni Thomas [SMTP:peta@club-internet.fr] > Sent: Tuesday, February 08, 2000 1:04 AM > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: [OpenBIOS] Floppy driver > > Hi there, > > does somebody can help me to debug my beginning of floppy driver ? > i don't want to write all my questions if nobody's can help me ! > > thx > -- > PETAZZONI Thomas Web : http://kos.enix.org > thomas.petazzoni(a)kos.enix.org ICQ : 34937744 > - > 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

l440gx+ nvram writing ...
by Ronald G. Minnich 08 Feb '00

08 Feb '00

more. You can enable/disable smi_l in the bios. I'm going to check that today. If smi_l is disabled, your OS will never know that the BUD asserted an interruptt when you tried to write the BIOS> The remaining question, of course, is what you're supposed to do with that interrupt, but that's next. it's rather amazing, but intel is shipping a server motherboard that REQUIRES DOS to be upgraded. You have to wonder sometimes, what are people thinking? The only exisiting SMI_L interrupt handler is in the BIOS! ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

3 4

RE: [OpenBIOS] l440gx+ nvram writing ...
by Wallace I. Kroeker 07 Feb '00

07 Feb '00

I found this in the P6 Hardware Developer's Manual A.1.49 SMI# (I) The SMI# (System Management Interrupt) signal is asserted asynchronously by system logic. On accepting a System Management Interrupt, processors save the current state and enter System Management Mode (SMM). An SMI Acknowledge transaction is issued, and the processor begins program execution from the SMM handler. I am guessing SMI_L is a system management Interrupt and the SMI Acknowledge is what you will be trying to do. More digging required. Wallace > -----Original Message----- > From: Ronald G. Minnich [SMTP:rminnich@lanl.gov] > Sent: Monday, February 07, 2000 11:40 AM > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: [OpenBIOS] l440gx+ nvram writing ... > > more. > > You can enable/disable smi_l in the bios. I'm going to check that today. > If smi_l is disabled, your OS will never know that the BUD asserted an > interruptt when you tried to write the BIOS> > > > The remaining question, of course, is what you're supposed to do with that > interrupt, but that's next. > > it's rather amazing, but intel is shipping a server motherboard that > REQUIRES DOS to be upgraded. You have to wonder sometimes, what are people > thinking? The only exisiting SMI_L interrupt handler is in the BIOS! > > 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

3 2

VGA card and screen output
by Wallace I. Kroeker 07 Feb '00

07 Feb '00

Hello, I FINALLY managed to get the screen output working. (A side benefit is that I now know a lot more about the 440BX chipset as I assumed this was not being initialized properly) The card that I have in my system is an ATI Rage III PCI. I finally added some code in START.ASM to initialize the VGA BIOS (from the reading I've done the VGA cards have their own Video BIOS). This required the following: * Initialization into 07h mode (monochrome 80 x 25 ... MDA mode) * Loading of a Character set (the cards come with a few predefined) * Activate the Character set that was loaded * Now the VGA base has to be 0xB0000 (MDA location actually) in Firmware/init/vga.h OR configure the video to be MDA The actual initialization was done using INT 10h in start.asm. If anyone has suggestions on other ways to do this let me know. I am currently working on getting the floppy enabled. (The idea being to have a minimum BIOS that can actually be put into the BIOS flash but still allow boot from disk for debugging or re-flashing) Has anyone already started this? Glad to hear Ron managed to get around his NVRAM write issue. Wallace - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

l440gx write to NVRAM: ah ha!
by Ronald G. Minnich 07 Feb '00

07 Feb '00

such fun. There is a PAL (or PLD) on the motherboard called a BUD. The bud is a chunk of glue that takes care of stuff not in the various chipsets. The BUD has two interrupt lines it controls, one called SMI_L. IF you write to the NVRAM, BUD yanks SMI_L and the interrupt handler (in this case in the BIOS) is tasked with responding with a magic word or having put a magic word at some magic place in memory. This is the 'key'. No key, no write. Tough for you. This little detail is only documented in the l440gx+ baseboard tps, #245151-001, version 1.0, march 1999, and not in any of the other five manuals I have on this chipset! Security through obscurity, I guess. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Flashing the BIOS ...
by Wallace I. Kroeker 01 Feb '00

01 Feb '00

Ron, As I have been reading the documentation on my chipset there is mention of disabling certain features when the BIOS is to perform different functions. As I was and checking out the BIOS update for my board (an ABIT BM6) and was reading through the instructions and they mention disabling the following: 1. CPU Internal Cache 2. CPU External Cache 3. Video BIOS Cacheable 4. Video BIOS Shadow prior to running the Award flash program. So you might want to have a check in your documentation for issues relating to these features and the update of your BIOS. If I come across the documentation comments again (they didn't seem relevant when I read them the first time :-) ) I will pass them along. Wallace - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

RE: [OpenBIOS] linuxbios web page is there.
by Wallace I. Kroeker 01 Feb '00

01 Feb '00

Hello Ron, I'm not sure if you have looked into this but I took a look at the NVRAM (read FLASH ) from the perspective of building the board. If you look at the Design Specifications (I downloaded both the 440gx and 440bx and they are identical on this topic) and look at how they recommend implementing the memory they describe how you should implement BIOS memory. For the Flash BIOS it all eventually comes down to hardware control of the memory chips so you can actually write to them. The recommended schematic shows the PIIX4E BIOSCS# signal going out the Flash CE#. So what the heck is the BIOSCS# and how do I deal with it? I followed this in the 440BX to "PCI to ISA/EIO Bridge Register Description document" http://developer.intel.com/design/intarch/techinfo/440bx/bridgreg.htm The "XBCS-X-Bus Chip Select Register (Function 0)" seems to be the thing you are looking for. I couldn't find similar documentation for the 440gx There are a couple other flags in this register that may pertain to this. If you can get hold of the manufacturers schematics you should be able to tell if they have some special hardware config. (as mentioned by someone earlier). Wallace > -----Original Message----- > From: Ronald G. Minnich [SMTP:rminnich@lanl.gov] > Sent: Tuesday, February 01, 2000 8:55 AM > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: Re: [OpenBIOS] linuxbios web page is there. > > On Tue, 1 Feb 2000, Daniele Frijia wrote: > > > > I figure that we're taking a slightly different direction than > openbios so > > > I've set up the linuxbios web page, www.acl.lanl.gov/linuxbios. We'll > use > > > openbios and help out where we can. I'll be posting the 'linux boots > > > linux' code there this week as well as anything we've done to openbios > to > > > make it go. > > > > We shoudl we work against each other? > > No, I have no intention of working against anyone. It seems that the focus > of this list is replacing the BIOS with a plug-compatible equivalent, or > doing Open Firmware instead. My focus is much simpler: I want to get just > enough OpenBIOS working to boot linux, and we're almost there. Supporting > FreeDOS and other 16-bit OSes is quite neat, but is not a concern of mine. > I have no need for INT 12 support, for example. > > So we'll help all we can with OpenBIOS, but past a point our needs and > interests will diverge. I certainly will let you all know if I ever figure > out how to write NVRAM -- if I can't do that, then I'm dead in the water. > > Thanks > > 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

Boot loader program
by Ross 01 Feb '00

01 Feb '00

Does anyone on this list have a program that can write a file to a floppy disk that does not have a DOS OS on it. Just a plain formatted floppy disk.The program must be able to write a file that is bigger than 64K to the PC floppydisk then load the program into the PC main memory for example; at 0000:0000 to 0000:7fff. This will allow the program I have designed to allow faster development with chipset based motherboards without the use of any os's or the need of a rom emulator. I have developed a program that will only do smaller programs but need help on getting a 256k program from a plain formatted non-dos floppy into the pc memory. Help!!!!! //Ross

2 1

linuxbios web page is there.
by Ronald G. Minnich 01 Feb '00

01 Feb '00

I figure that we're taking a slightly different direction than openbios so I've set up the linuxbios web page, www.acl.lanl.gov/linuxbios. We'll use openbios and help out where we can. I'll be posting the 'linux boots linux' code there this week as well as anything we've done to openbios to make it go. It would be great if anyone out there can unlock the secret of the flash ram. This is driving me nutz. If I get there I'll let you know. Thanks ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 2

ROM-Emulators
by Winter Jörg 01 Feb '00

01 Feb '00

> ---------- > Von: Edwin Rhodes[SMTP:edwin_rhodes@hotmail.com] > Antwort an: openbios(a)freiburg.linux.de > Gesendet: Montag, 31. Januar 2000 02:26 > An: openbios(a)elvis.informatik.uni-freiburg.de > Betreff: Re: [OpenBIOS] Fine. > > can i have a copy of this rom-emulator? > thanks edwin > ----- Original Message ----- > From: Winter Jörg <joerg.winter(a)disch-gmbh.de> > To: <openbios(a)elvis.informatik.uni-freiburg.de> > Sent: Friday, January 28, 2000 10:50 AM > Subject: [OpenBIOS] Fine. > I´m sorry, but a copy of my ROM-Emulator would not be what you expext ... I was not talking about Software. The Emulator is a little piece of Hardware that I bought. It is intended to be inserted into a standard 32 Pin Jedec-Memory Socket. Then you download a 64k image via the parallel port of any PC into this Hardware. You press reset at the board and it boots ... well sometimes ... If you are interested in such an Hardware try th e following urls as a start: www.hed.de (they make tools for embedded and microcontrol. I once talked to their Boss and got the impression that they are really good!) www.embedded-tools.de (they have a modular Emulator called PromJet. Its able to act like rom/ram/flash up to 16Mbit and 32Bit Words. Furthermore it can handle operating voltages from 2 to 5V. It also has an ethernet plug ...) Well this is not an advertisement ... I did not test these devices but they seem interesting to me ... > eMail: mailto:Joerg.Winter@Disch-GmbH.de > > - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

4 5

IDE and IRQ's
by Jaime Dias 31 Jan '00

31 Jan '00

I have read openBios mail for a while, and i want to know if there is any kind of code to the ide chips and to irq handlers, cause it could be useful for the AROS team (www.aros.org) , if anyone can help i would apreciate. best regards, Jaime Dias

1 0

RE: [OpenBIOS] Starting Linux from the C environment
by Stawnyczy, Evan 31 Jan '00

31 Jan '00

then is OpenBIOS going to include a bootloader? -----Original Message----- From: Matthew Sullivan [mailto:matthew@netscape.com] Sent: January 31, 2000 1:20 Pm To: openbios(a)elvis.informatik.uni-freiburg.de Subject: Re: [OpenBIOS] Starting Linux from the C environment Hi, "Stawnyczy, Evan" wrote: > well this was my argument in the begining, we should allow this BIOS to > support "REAL" bios calls like int 13 and int 10... if you include basic > BIOS functionality, you can allow any "decent" operating system to > startup... including LILO Ahh but if I remember back at the beginning of the list the point of openBIOS was to get rid of the BIOS calls and boot 32bit OS's in 32bit mode, the though being that most OS's don't use the BIOS calls, except when first booting..... Of course that concept can deliver a whole new selection of problems... I'll leave the rest to you .. ;-) -- Yours Matthew -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- More Computer Terminology -=-=-=-=-=-=-=-=-=-=-=-=- Booting (as in: the computer): applying a size 16 Doc Martins to the system unit after it keeps telling you there is not enough memory to open the application. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

RE: [OpenBIOS] where I'm at with the 440gx and reading nvram
by Wallace I. Kroeker 31 Jan '00

31 Jan '00

Ron, No I am just running it in RAM (Shadow ROM) right now. This uses the Loadbios (actually a modified version that checks the size and automatically adapts to the various possible image sizes... I hope to post that here next week after a little cleanup ). I was going to look into just using one of the flash programs for our chipset but someone had mentioned they had source for doing this. I will be looking into that in the next week or so and will keep you posted. Wallace > -----Original Message----- > From: Ronald G. Minnich [SMTP:rminnich@lanl.gov] > Sent: Monday, January 31, 2000 8:10 AM > To: 'openbios(a)freiburg.linux.de' > Subject: RE: [OpenBIOS] where I'm at with the 440gx and reading nvram > > On Fri, 28 Jan 2000, Wallace I. Kroeker wrote: > > I am working with the 440BX chipset and have it hobbling along. > > I am having problems with the MDA getting any screen output. > > I am able to get beeps out for different keys on the keyboard > > but no character display. (Of course, this could be just the situation > to > > use Morse code :-). > > are you actually getting it to write the BIOS FLASH? what code are you > using to do that? > > thanks > 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] Starting Linux from the C environment
by Stawnyczy, Evan 31 Jan '00

31 Jan '00

well this was my argument in the begining, we should allow this BIOS to support "REAL" bios calls like int 13 and int 10... if you include basic BIOS functionality, you can allow any "decent" operating system to startup... including LILO -----Original Message----- From: Winter Jörg [mailto:joerg.winter@disch-gmbh.de] Sent: January 31, 2000 10:54 Am To: openbios(a)elvis.informatik.uni-freiburg.de Subject: [OpenBIOS] Starting Linux from the C environment > ---------- > Von: Stawnyczy, Evan[SMTP:EStawnyczy@geo-logistics.com] > Antwort an: openbios(a)freiburg.linux.de > Gesendet: Montag, 31. Januar 2000 15:48 > An: openbios(a)elvis.informatik.uni-freiburg.de > Betreff: RE: [OpenBIOS] Fine. > > my understanding of lilo is that if you place it on the boot sector, you > can > load the boot sector to a point in memory (I cannot recall exactly where > right now, you can email me farther if you need to) and simply jmp to it. > Actually all boot sectors work the same way... > Basicly you are right. But lilo makes extensive use of *real* BIOS functions like int13, int10, int16, and some strange int15-shift-this-memory-to-ems function that I forgot the functioncode of. I´d rather do this in C and burn a barebone Kernel onto my Disk ... But I´m not sure if I kill my own running environment by copying a Kernel to mem at 0x10000. Furthermore I have no idea if the segment-deskriptor-setup is suitable for an immediate start of a kernel image ... I´ll try this tomorrow and keep you up to date if I succeed on this ... > eMail: mailto:Joerg.Winter@Disch-GmbH.de > > - 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

3 2

RE: [OpenBIOS] ROM-Emulators
by Stawnyczy, Evan 31 Jan '00

31 Jan '00

the 64K limit... i'm not exactly sure what you mean, but I think you may mean real mode... not protected mode. you can look up the source code for p-mode on ftp://ftp.cdrom.com/pub/programming/pmode <ftp://ftp.cdrom.com/pub/programming/pmode> and look through the "jump to protected mode" portion. -----Original Message----- From: Ross [mailto:rossio@hoeftd.reno.nv.us] Sent: January 31, 2000 10:55 Am To: openbios(a)elvis.informatik.uni-freiburg.de Subject: Re: [OpenBIOS] ROM-Emulators Do anyone out there know how I can get around the 64k limit of a self booting floopy disk? I know up to 40k of data on the floppy. ---------- > From: Winter Jörg <joerg.winter(a)disch-gmbh.de> > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: [OpenBIOS] ROM-Emulators > Date: Monday, January 31, 2000 1:05 AM > > > > > ---------- > > Von: Edwin Rhodes[SMTP:edwin_rhodes@hotmail.com] > > Antwort an: openbios(a)freiburg.linux.de > > Gesendet: Montag, 31. Januar 2000 02:26 > > An: openbios(a)elvis.informatik.uni-freiburg.de > > Betreff: Re: [OpenBIOS] Fine. > > > > can i have a copy of this rom-emulator? > > thanks edwin > > ----- Original Message ----- > > From: Winter Jörg <joerg.winter(a)disch-gmbh.de> > > To: <openbios(a)elvis.informatik.uni-freiburg.de> > > Sent: Friday, January 28, 2000 10:50 AM > > Subject: [OpenBIOS] Fine. > > > I´m sorry, but a copy of my ROM-Emulator would not be what you expext ... > > I was not talking about Software. The Emulator is a little piece of Hardware > that I bought. It is intended to be inserted into a standard 32 Pin > Jedec-Memory Socket. Then you download a 64k image via the parallel port of > any PC into this Hardware. You press reset at the board and it boots ... > well sometimes ... > > If you are interested in such an Hardware try th e following urls as a > start: > > www.hed.de (they make tools for embedded and microcontrol. I once talked to > their Boss and got the impression that they are really good!) > > www.embedded-tools.de (they have a modular Emulator called PromJet. Its able > to act like rom/ram/flash up to 16Mbit and 32Bit Words. Furthermore it can > handle operating voltages from 2 to 5V. It also has an ethernet plug ...) > > Well this is not an advertisement ... I did not test these devices but they > seem interesting to me ... > > > eMail: mailto:Joerg.Winter@Disch-GmbH.de > > > > > - > To unsubscribe: send mail to majordomo(a)freiburg.linux.de > with 'unsubscribe openbios' in the body of the message

1 0

my sources ?
by Johan Rydberg 31 Jan '00

31 Jan '00

Hi! Did my sources arive to the list ? -- Johan Rydberg johan.rydberg(a)netinsight.net Net Insight AB, Sweden direct: +46-8-685 04 17 http://www.netinsight.net phone: +46-8-685 04 00 fax: +46-8-685 04 20 - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

RE: [OpenBIOS] where I'm at with the 440gx and reading nvram
by Wallace I. Kroeker 31 Jan '00

31 Jan '00

I am working from the OpenBIOS-0.0.2. The beep code in /Firmware/init/timer.c I modified the print code to output a different number of beeps (2 of 'a' and 6 for 'z'). The OpenBIOS code (as is) boots and then sits in a loop waiting for a character of input. Once the character arrives it trys to print it out. I have some assembler code which also produces a beep. I used it for the initial debugging of /boo/boot16/start.asm. Are you interested in this? I know someone else was asking earlier where to start in with this so here is what I've found out so far (someone can correct me if I'm wrong): 1. Download OpenBIOS.0.0.2pre1 2. Make sure you have the nasm assembler (www.web-sites.co.uk/nasm to get the latest) and Gnu C (this came with Linux) 3. At the root directory type "make config" this will make the configuration and step you through the selections for Processor, Chipset, etc. (if you go with the defaults it seems to come up for some 486 board ... this sort of seemed to work for my machine to get things started) 4. Now type make and it should make everything. Leaving you with a ROM.bin So now that you can actually get it to build you can download the LoadBIOS program and try out your BIOS from RAM (as has been discussed in other messages). The documentation directory has a very brief description of the internal structure. How about adding a new chipset? 1. Everything starts in /boot/boot16/start.asm. There is an include of chipset.inc. When you ran the configuration make you specify which chipset which is actually telling the make which directories to find things such as chipset.inc 2. First create a new chipset directory in /drivers/chipset. ( I copied ali_M1511 to create a new chipset (440BX) directory.) Comment everything out as you will eventually have to modify this for your own chipset. 3. Modify the .config to allow selection of your new chipset. 4. Modify /drivers/Config.mak and add your chipset for the make process 5. Now run make .config and make to rebuild it. It should now be using your new chipset definition. To confirm that you are compiling the correct code put in a deliberate error in your chipset assembler file. If everything is correct then you should get an error showing up in the build. You follow the same approach for your superio. Helpful books. PC Intern by Michael Tischer, Brun Jennrich The Programmer's PC Sourcebook by Thom Hogan (Seems to be of print but you might get your hands on a copy ) Hope this is of some use. Wallace > -----Original Message----- > From: James [SMTP:jvh@uclink4.berkeley.edu] > Sent: Friday, January 28, 2000 6:39 PM > To: 'openbios(a)freiburg.linux.de' > Subject: RE: [OpenBIOS] where I'm at with the 440gx and reading nvram > > > I am working with the 440BX chipset and have it hobbling along. > > I am having problems with the MDA getting any screen output. > > I am able to get beeps out for different keys on the keyboard > > but no character display. (Of course, this could be just the situation > to > > use Morse code :-). > > What is the code to get it to beep? > - 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

2 1

RE: [OpenBIOS] where I'm at with the 440gx and reading nvram
by Stawnyczy, Evan 31 Jan '00

31 Jan '00

to my understanding, they're just using a rom emulator right now. -----Original Message----- From: Ronald G. Minnich [mailto:rminnich@lanl.gov] Sent: January 31, 2000 10:10 Am To: 'openbios(a)freiburg.linux.de' Subject: RE: [OpenBIOS] where I'm at with the 440gx and reading nvram On Fri, 28 Jan 2000, Wallace I. Kroeker wrote: > I am working with the 440BX chipset and have it hobbling along. > I am having problems with the MDA getting any screen output. > I am able to get beeps out for different keys on the keyboard > but no character display. (Of course, this could be just the situation to > use Morse code :-). are you actually getting it to write the BIOS FLASH? what code are you using to do that? thanks 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] ROM-Emulators
by Ross 31 Jan '00

31 Jan '00

Do anyone out there know how I can get around the 64k limit of a self booting floopy disk? I know up to 40k of data on the floppy. ---------- > From: Winter Jörg <joerg.winter(a)disch-gmbh.de> > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: [OpenBIOS] ROM-Emulators > Date: Monday, January 31, 2000 1:05 AM > > > > > ---------- > > Von: Edwin Rhodes[SMTP:edwin_rhodes@hotmail.com] > > Antwort an: openbios(a)freiburg.linux.de > > Gesendet: Montag, 31. Januar 2000 02:26 > > An: openbios(a)elvis.informatik.uni-freiburg.de > > Betreff: Re: [OpenBIOS] Fine. > > > > can i have a copy of this rom-emulator? > > thanks edwin > > ----- Original Message ----- > > From: Winter Jörg <joerg.winter(a)disch-gmbh.de> > > To: <openbios(a)elvis.informatik.uni-freiburg.de> > > Sent: Friday, January 28, 2000 10:50 AM > > Subject: [OpenBIOS] Fine. > > > I´m sorry, but a copy of my ROM-Emulator would not be what you expext ... > > I was not talking about Software. The Emulator is a little piece of Hardware > that I bought. It is intended to be inserted into a standard 32 Pin > Jedec-Memory Socket. Then you download a 64k image via the parallel port of > any PC into this Hardware. You press reset at the board and it boots ... > well sometimes ... > > If you are interested in such an Hardware try th e following urls as a > start: > > www.hed.de (they make tools for embedded and microcontrol. I once talked to > their Boss and got the impression that they are really good!) > > www.embedded-tools.de (they have a modular Emulator called PromJet. Its able > to act like rom/ram/flash up to 16Mbit and 32Bit Words. Furthermore it can > handle operating voltages from 2 to 5V. It also has an ethernet plug ...) > > Well this is not an advertisement ... I did not test these devices but they > seem interesting to me ... > > > eMail: mailto:Joerg.Winter@Disch-GmbH.de > > > > > - > To unsubscribe: send mail to majordomo(a)freiburg.linux.de > with 'unsubscribe openbios' in the body of the message

1 0

Starting Linux from the C environment
by Winter Jörg 31 Jan '00

31 Jan '00

> ---------- > Von: Stawnyczy, Evan[SMTP:EStawnyczy@geo-logistics.com] > Antwort an: openbios(a)freiburg.linux.de > Gesendet: Montag, 31. Januar 2000 15:48 > An: openbios(a)elvis.informatik.uni-freiburg.de > Betreff: RE: [OpenBIOS] Fine. > > my understanding of lilo is that if you place it on the boot sector, you > can > load the boot sector to a point in memory (I cannot recall exactly where > right now, you can email me farther if you need to) and simply jmp to it. > Actually all boot sectors work the same way... > Basicly you are right. But lilo makes extensive use of *real* BIOS functions like int13, int10, int16, and some strange int15-shift-this-memory-to-ems function that I forgot the functioncode of. I´d rather do this in C and burn a barebone Kernel onto my Disk ... But I´m not sure if I kill my own running environment by copying a Kernel to mem at 0x10000. Furthermore I have no idea if the segment-deskriptor-setup is suitable for an immediate start of a kernel image ... I´ll try this tomorrow and keep you up to date if I succeed on this ... > eMail: mailto:Joerg.Winter@Disch-GmbH.de > > - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

ANNOUNCE: Collecting OpenBIOS patches
by Jeff Garzik 31 Jan '00

31 Jan '00

I've been on this mailing list for about a year, and very little movement has occurred during that time. Since there is still interest in this project, I would like to start collecting patches against OpenBIOS 0.0.2-pre1, hopefully leading up to a new [unofficial] release. I am currently working on getting the Intel 430TX (Triton I) low-end Pentium chipset working with OpenBIOS. My goal is to be able to boot either an MS-DOS or Linux OS, just like a regular BIOS. After that, I will probably tackle the Intel 430FX chipset, or a newer Via-based chipset like the VT82C686A. So if you have patched to OpenBIOS, please "diff" them against the current release on the Web site, 0.0.2-pre1, and post them to the mailing list. (or e-mail directly me to if the patches are large) I will integrate all these patches and roll a new tarball, probably sometime around Valentine's Day (Feb 14th). Input, comments, and/or patches are greatly appreciated! I think OpenBIOS is a great project, especially for all the older PCs out there with no BIOS updates since 1995 or so.... Jeff -- Jeff Garzik | Andre the Giant has a posse. Building 1024 | MandrakeSoft, Inc. | - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

6 7

RE: [OpenBIOS] Fine.
by Stawnyczy, Evan 31 Jan '00

31 Jan '00

my understanding of lilo is that if you place it on the boot sector, you can load the boot sector to a point in memory (I cannot recall exactly where right now, you can email me farther if you need to) and simply jmp to it. Actually all boot sectors work the same way... -----Original Message----- From: Edwin Rhodes [mailto:edwin_rhodes@hotmail.com] Sent: January 30, 2000 8:27 Pm To: openbios(a)elvis.informatik.uni-freiburg.de Subject: Re: [OpenBIOS] Fine. can i have a copy of this rom-emulator? thanks edwin ----- Original Message ----- From: Winter Jörg <joerg.winter(a)disch-gmbh.de> To: <openbios(a)elvis.informatik.uni-freiburg.de> Sent: Friday, January 28, 2000 10:50 AM Subject: [OpenBIOS] Fine. I´ve just completed an small piece of Hardware. Only a 486 16mb EDO an UART. Everything put together on a small pcb-board. Then modified Openbios a little bit, loaded it into a ROM-emulator and go! *COOL*! The machine boots, complains about the missing RTC (who needs an rtc?), tests the mem ... and then executes : for (;;); Ok for that. - but can somebody tell me what I have to do to get a Linuxkernel loaded ? I intend to put an 16bit latch on the isabus and connect a flashdisk there ... I could write C code to load the kernel image from the first, say, 1k blocks of the disk. But where do I put this image and how I´m gonna start it ? Please someone gimme a hint on that. I´ll submit the loadcode Ive done then back to this group ... maybe someone wants to use it ? Regards, Jake Ah. By the way, this mail was done by Exchange - locked inside a virtual machine that runs under Linux. (Thats the place where it should be ;-)). eMail: mailto:Joerg.Winter@Disch-GmbH.de - 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

RE: [OpenBIOS] where I'm at with the 440gx and reading nvram
by Wallace I. Kroeker 29 Jan '00

29 Jan '00

Ron, I am working with the 440BX chipset and have it hobbling along. I am having problems with the MDA getting any screen output. I am able to get beeps out for different keys on the keyboard but no character display. (Of course, this could be just the situation to use Morse code :-). Do you have any thoughts as to what might be the problem? Could I get your 440gx chipset and superio components as a reference? Thanks Wallace > -----Original Message----- > From: Ronald G. Minnich [SMTP:rminnich@lanl.gov] > Sent: Tuesday, January 25, 2000 10:43 AM > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: RE: [OpenBIOS] where I'm at with the 440gx and reading nvram > > I'm actually getting somewhere now via a different path. > > I have mmaped 0xffe00000 from /dev/mem and I can see the BIOS. I'm not > looking at what's in it, but the contents of 0xf0000 and 0xffe00000 do > match. > > This also revealed a bug in the linux do_mmap code: it doesn't correctly > handle the case of mmap'ing the tail end of memory ... > > Now to try to kick the nvram a little. This will require setting a write > enable bit in the bridge, which I do know is not set normally. No big > deal. It's still a mystery to me why the darn thing was not visible > in-kernel, but oh well: I prefer user-mode code for this sort of thing > anyway. > > 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

3 2

None
by Edwin Rhodes 29 Jan '00

29 Jan '00

i think that it is probably a good idea that we do not run away from supporting other operating systems not just support linux, sure enough linux is the best but to make open bios an alternative to ami bios and award we have to support at least freedos! :) edwin ps. i tried that open bios dos loader program, it returned the error message "cant find intel pci bridge" or somthing like that, weird cos its an intel clone motherboard with pci bridge on it! its gon an AMD cpu in it though. does open bios support the AMD chip? edwin

4 3

Fine.
by Winter Jörg 28 Jan '00

28 Jan '00

I´ve just completed an small piece of Hardware. Only a 486 16mb EDO an UART. Everything put together on a small pcb-board. Then modified Openbios a little bit, loaded it into a ROM-emulator and go! *COOL*! The machine boots, complains about the missing RTC (who needs an rtc?), tests the mem ... and then executes : for (;;); Ok for that. - but can somebody tell me what I have to do to get a Linuxkernel loaded ? I intend to put an 16bit latch on the isabus and connect a flashdisk there ... I could write C code to load the kernel image from the first, say, 1k blocks of the disk. But where do I put this image and how I´m gonna start it ? Please someone gimme a hint on that. I´ll submit the loadcode Ive done then back to this group ... maybe someone wants to use it ? Regards, Jake Ah. By the way, this mail was done by Exchange - locked inside a virtual machine that runs under Linux. (Thats the place where it should be ;-)). eMail: mailto:Joerg.Winter@Disch-GmbH.de - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

4 3

Open Bios
by James Gilmore 27 Jan '00

27 Jan '00

Where can I find a good primer on assembly? I would very much like to contribute something useful to this project. I admit a lack of skills, but the best way to learn is to get involved. From what I have seen so far, just to put things in perspective, is: Everyone has thier own ideas where they want this project to go. Most everyone is working on a different platform. Some people want a spartan bios, very streamlined, while others want a more robust bios. So we should attack this from a different angle. We should choose an OS (I recommend FreeDOS) as a startpoint, then build a BIOS configurator, menu driven, that allows the person to select the options he/she wants. Then the program would detect the architecture of the system, (possibly by reading current BIOS version?),prompt the user to confirm/correct what it detects, and compile an image to be flashed. I realize that is asking alot. But it is not beyond the scope of feasibility. Most systems now days have the option to boot from a cd. So if we make an iso of the whole package, it could then be burned on a CD, and thus be bootable. Otherwise one could copy it to a partition and configure thier bootloader to look for it. Rather than FreeDOS we might consider hacking a very minimal OS that would work on basically any platform. Consider, the only major requirements are disk access, and the ability to load our software. It would not be a major undertaking if we took a look at what's already out there. It seems to me that there are a lot of people interested in this project but no one knows exactly how to contribute. This would give the project some structure, and allow everyone to pick an area to work on toward a more tangible goal. I realize that this is way beyond the scope that most of you were contemplating. But there are many of us interestedin OpenBIOS, and it would keep us from each reinventing the wheel as we go. With many hands, we can move mountains. More than that, the end product would be *darn* attractive to basically everybody.

2 1