OpenBIOS February 2000

openbios@openbios.org

43 participants
83 discussions

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

← Newer
1
2
3
4
5
6
7
8
9
Older →