coreboot

coreboot@coreboot.org

12 participants
39779 discussions

Re: Random comments on LinuxBIOS
by Deepak Kotian 17 Apr '03

17 Apr '03

I think, the paper at this link is also good http://www.lysator.liu.se/upplysning/fa/linuxbios.pdf A newbie would like to read this first .. May like to add it or update more on this and put it somewhere in linuxbios site. Regards Deepak ----- Original Message ----- From: "McMechan, James W CIV" <james.mcmechan(a)navy.mil> To: <linuxbios(a)clustermatic.org> Sent: Thursday, April 17, 2003 3:11 AM Subject: Random comments on LinuxBIOS > Here is what I wrote while trying to catch up to list, though there is a FAQ I produced this while working my way through the emails perhaps some of it could be added to the FAQ > > LinuxBIOS is a project to replace the original BIOS on motherboards with open source. > It appears that the two most common uses for LinuxBIOS are for Supercomputer clusters and embedded systems. > > LinuxBIOS no longer always uses a real OS to load the OS. > > LinuxBIOS currently can boot several payloads including: > 1 Linux which is what started all this, hence the name. > 2 Plan9 Ron Minnich seems to like this one. > 3 VxWorks Felix Radensky said he had success with a older boot method > 4 EtherBoot which despite its name can also boot from IDE hard disks with a patch or the dev branch > 5 ADLO is a shim to allow the Boch emulator's BIOS to be used on top of LinuxBIOS to boot some versions of that other OS or to run VGA controller ROMs which seem to assume that a BIOS is present. > ? > > The Supercomputer people appear to want remote control, remote booting and fast boot times without user interaction. For example "Press F2" is a very inconvenient task on a system with 100 computers > > The embedded people appear to want full control of the boot process and very fast boot times. For example who wants to watch a memory test go by on their VCR/MP3 player or see "Press F2" without a keyboard. > > LinuxBIOS is installed into the flash ROM in place of the original BIOS. > > Most flash ROMs are currently 2 Megabits in size, i.e. a 29SF020 which is only 256 Kilobytes of storage, or some might be 4 Mbit ROM which provides 512 Kbytes and so could allow for very squeezed down Linux kernel to also be included in the ROM, though I don't know of a useful kernel that small. > It would be nice to add a larger flash ROM but many motherboards do not connect enough address lines to the Flash ROM socket, for even the 4 Mbit part or they solder the chip down. > > Another popular if grumbled about option is the disk on a chip the DoC Millennium which is a paged flash part that can have LinuxBIOS in the first part and up to 8 Mbytes of other data on other pages of the chip. Very short ~3-10 seconds boot times should be possible with this method. > > The BIOS Flash can usually be programmed in place by either just reflashing the original BIOS or by the hotswap method also known as the dental floss method, referring to putting dental floss under a PLCC chip to make it easy to remove without requiring metal tools in a powered on system. The hotswap method is not for the faint of heart but not all that difficult either, the system is booted with a working ROM which is then pulled out and the ROM to be programmed inserted in its place, then the ROM flashing program is run, and when done a reboot can be tried, this does not require a programmer as it uses the motherboards ability to update its BIOS as the programmer, if the reboot fails the original ROM is reinserted and the system rebooted again, all this requires, is some spare flash ROMs it is a good idea to make and label a couple backups incase something goes wrong, I have put ROMs in DIP sockets backwards destroying the ROMs, and ESD is a worry even if it is not a commo! > n problem. > > Some people also use a very nice device called the BIOS savior which allows for two BIOS ROMS to be switched by the user with a switch. > > Compact Flash IDE adaptors appear to be popular as the CF does not need the spin up time of a real hard disk. Very short boot times of ~3-10 seconds are claimed for this configuration also. > > Each model of motherboard currently needs its own build information due to a lack of standards in how the circuitboards are laid out between models and manufactures. > > If you have a motherboard that is not listed, a "lspci" will show what chipsets are in use and you can then check to see if they are in the LinuxBIOS tree, if not some research may be needed to get the documentation for that chipset. > > The kexec patches date back to the original LinuxBIOS with the Linux kernel in the BIOS ROM and allowed for new kernels to be loaded and executed without rebooting back to the BIOS this would allow for a minimal kernel in the BIOS and a full featured kernel to be loaded by the first kernel. Also the BIOS ROMs have a limited programming life and limited space so a small unchanging kernel that then loads the final kernel from something else prolongs the useful life of the ROMs. > > Ron Minnich at LANL uses similar feature called "two kernel monte" http://sourceforge.net/projects/monte/ > > LinuxBIOS now has the ability to make use of the CMOS space for fallback/normal boot image selection, serial port baud rates, and boot order for Etherboot, Ron Minnich also used it authentication information for a Plan9 cluster. See the cmos.layout files for information. > > Steven James had nice comments on Normal/Fallback images: > LinuxBIOS for that board (and many others) supports two copies of > LinuxBIOS, fallback and primary. The fallback image is intended to be old > and stable and it's purpose is to act as a sort of rescue image. The > primary image is the one that gets updated to the latest and greatest, and > is meant to be more versatile and complete. > > The fallback image is loaded at the top of the flash, and always receives > control at power on or reset. It does very minimal setup (switch to 32bit > flat memory protected mode), checks and clears the CMOS boot bit, and if > it was set, jumps to the primary image. This way, if the primary fails, > hitting reset will boot from the fallback image alone. > > From your config, you were building a primary image. the missing bytes are > for the fallback image to be appended. It didn't work because you didn't > have a fallback image at the top of the flash (the end of the image file). > > Ron Minnich expanded on fallback vs. primary: > > You need to build TWO linuxbioses, a fallback and a primary. The fallback > is 64k. The primary is (romsize-64k). > > To build a romimage, you build the fallback, build the primary, then: > > cat primary/romimage fallback/romimage > final_romimage > > flash_rom final_romimage > > Steve Gehlbach wrote about using BOOT_IDE: > See pcchips787.config in util/config for complete configuration. > > option BOOT_IDE=1 > This enables booting from IDE, the file to use is linux.bin.gz: > > option IDE_BOOT_DRIVE=2 > If you do not use drive 0 (default), then you can set which drive to > boot; (0,1,2,3) are the four standard PC drives: > > option ONE_TRACK=32 > The linux.bin.gz file is put in raw form at partition 1, ie, the first > partition on the disk. This is located just past the partition table. > The partition table size varies, it is "one track" from the beginning of > the disk. "one track" in c/h/s notation is "s" or the number of sectors > per track. ONE_TRACK is in sectors, the software multiplies by 512. > Most disks are 63 sectors per track (the default), but my CF is 32 > sectors per track. eg, the partion table is 63x512 or 32x512 bytes. > > You can partition your disk as you want, but Linux goes raw in partition > 1; just make sure partition 1 is big enough, not a problem on today's > disks. You could put the Linux root file system on partition 2, for > example. In pcchips787.config, I put the Linux root file system on IDE > 0, partition 2 (I was experimenting with Linux in partition 1), but I > eventually put Linux on drive 2 using CF. You are right, copying of > linux.bin.gz raw to the partition is dangerous, and something like "cat > linux.bin.gz > /dev/hda1" will definitely screw the disk if you put the > wrong disk or partition. I recommend a shell script, fingers cannot be > trusted. You can also use "dd" but "cat" works. > > Greg Watsons had some good comments on on the boot process and file layout: > There seem to be two main parts to linuxbios. The first is > arch/{arch}/config/ctr0.base which does the very low level > initialization, like turning on memory, etc. The second is > arch/{arch}/lib/c_start.S which does whatever else is necessary to > call the C function hardwaremain(). hardwaremain() then does whatever > else is necessary to load Linux. > > c_start.S is linked with linuxbios.a, a library containing generic > support routines (those found in the lib directory) and anything > specified using the 'object' directive in a Config file (and other > stuff). The resultant 'executable' is called linuxbios_c. The loader > script used to link linuxbios_c is config/linuxbios_c.ld, and is > configured to be loaded relative to _RAMBASE. > > crt0.base is not linked against anything. Any additional assembly > routines you need must be specified using the 'mainboardinit' > directive in a Config file. This causes the specified assembly file > to be added to "crt0_includes.h" which is in turn included at the > start of crt0.base (or at the end in the case of the ppc version). > The loader script used to link crt0.base is in > arch/{arch}/config/ldscript.base. The resultant 'executable' is > called linuxbios and will be loaded at _ROMBASE. The tricky thing is > that this loader script will also load the linuxbios_c 'executable' > at a location called _payload in this file. The main task of > crt0.base is then to initialize enough hardware so that this payload > can be copied from ROM into ram (which may also involve uncompressing > code). Then control is transferred to _start, which is the first > location in linuxbios_c. > > To get an idea of how crt0.base works, look at the following files. > This is the order of execution specified by the configuration file > for sis735. > > cpu/i386/entry16.inc > cpu/i386/entry32.inc > superio/sis/950/setup_serial.inc > pc80/serial.inc > arch/i386/lib/console.inc > cpu/k7/earlymtrr.inc > northsouthbridge/sis/735/raminit.inc > arch/i386/config/crt0.base > > Next look at c_start.S which will show you what happens once control > is transferred to _start. Finally, look at > arch/{arch}/lib/hardwaremain.c to see what other stuff is done to get > Linux loaded. > > Most other files are specific to particular hardware, so it can be > pretty confusing to just browse the tree. > > Hope this helps, > > Greg > > _______________________________________________ > Linuxbios mailing list > Linuxbios(a)clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

RE: Random comments on LinuxBIOS
by McMechan, James W CIV 17 Apr '03

17 Apr '03

> From: ron minnich [mailto:rminnich@lanl.gov] ... > On 16 Apr 2003, Eric W. Biederman wrote: > > > This is where I expect Ron to chime in... The answers are all in my > > head but have not found paper yet. > > it's on the web page and out of data. I have a ton of email > to add faq > entries. Our web server went away and it's been much less > easy to edit the > web page since that happened. > > ron > > Do you have a bundle of these emails? In what way is it hard to edit? Are the web pages just plain html not generated from some other source format? Would you like patches to the html or just a new version of the document?

1 0

Re: Random comments on LinuxBIOS
by ebiederman＠lnxi.com 17 Apr '03

17 Apr '03

"McMechan, James W CIV" <james.mcmechan(a)navy.mil> writes: > Here is what I wrote while trying to catch up to list, though there is a FAQ I > produced this while working my way through the emails perhaps some of it could > be added to the FAQ Would you be interested in maintaining or helping to maintain the FAQ? You seem to have a nack for putting the information together. > LinuxBIOS is a project to replace the original BIOS on motherboards with open > source. > > It appears that the two most common uses for LinuxBIOS are for Supercomputer > clusters and embedded systems. > > > LinuxBIOS no longer always uses a real OS to load the OS. That is not quite correct. LinuxBIOS requires a real OS, or at least a piece of software that can run standalone without any OS or BIOS services on the bare hardware. Which is essentially the definition of a real OS though it is not the definition of a general purpose OS. In the case of ADLO, ADLO can be considered a special purpose OS that mimics the syscall interface of a standard BIOS. > > LinuxBIOS currently can boot several payloads including: > 1 Linux which is what started all this, hence the name. > 2 Plan9 Ron Minnich seems to like this one. > 3 VxWorks Felix Radensky said he had success with a older boot method > 4 EtherBoot which despite its name can also boot from IDE hard disks with a > patch or the dev branch > > 5 ADLO is a shim to allow the Boch emulator's BIOS to be used on top of > LinuxBIOS to boot some versions of that other OS or to run VGA controller ROMs > which seem to assume that a BIOS is present. > > ? > > The Supercomputer people appear to want remote control, remote booting and fast > boot times without user interaction. For example "Press F2" is a very > inconvenient task on a system with 100 computers > > > The embedded people appear to want full control of the boot process and very > fast boot times. For example who wants to watch a memory test go by on their > VCR/MP3 player or see "Press F2" without a keyboard. In addition there is some background work on secure/trusted booting. I don't know if anything has really happened with that yet, but ADLO grow out of the interest in trusted booting. > LinuxBIOS is installed into the flash ROM in place of the original BIOS. > > Most flash ROMs are currently 2 Megabits in size, i.e. a 29SF020 which is only > 256 Kilobytes of storage, or some might be 4 Mbit ROM which provides 512 Kbytes > and so could allow for very squeezed down Linux kernel to also be included in > the ROM, though I don't know of a useful kernel that small. > > It would be nice to add a larger flash ROM but many motherboards do not connect > enough address lines to the Flash ROM socket, for even the 4 Mbit part or they > solder the chip down. For LPC flash parts the address line count is not a real issue, new boards have them and they current are up to 8Mbit in size, but do not have a theoretical limit. > Another popular if grumbled about option is the disk on a chip the DoC > Millennium which is a paged flash part that can have LinuxBIOS in the first part > and up to 8 Mbytes of other data on other pages of the chip. Very short ~3-10 > seconds boot times should be possible with this method. > > > The BIOS Flash can usually be programmed in place by either just reflashing the > original BIOS or by the hotswap method also known as the dental floss method, > referring to putting dental floss under a PLCC chip to make it easy to remove > without requiring metal tools in a powered on system. The hotswap method is not > for the faint of heart but not all that difficult either, the system is booted > with a working ROM which is then pulled out and the ROM to be programmed > inserted in its place, then the ROM flashing program is run, and when done a > reboot can be tried, this does not require a programmer as it uses the > motherboards ability to update its BIOS as the programmer, if the reboot fails > the original ROM is reinserted and the system rebooted again, all this requires, > is some spare flash ROMs it is a good idea to make and label a couple backups > incase something goes wrong, I have put ROMs in DIP sockets backwards destroying > the ROMs, and ESD is a worry even if it is not a commo! > > n problem. > > Some people also use a very nice device called the BIOS savior which allows for > two BIOS ROMS to be switched by the user with a switch. > > > Compact Flash IDE adaptors appear to be popular as the CF does not need the spin > up time of a real hard disk. Very short boot times of ~3-10 seconds are claimed > for this configuration also. > > > Each model of motherboard currently needs its own build information due to a > lack of standards in how the circuitboards are laid out between models and > manufactures. > > > If you have a motherboard that is not listed, a "lspci" will show what chipsets > are in use and you can then check to see if they are in the LinuxBIOS tree, if > not some research may be needed to get the documentation for that chipset. > > > The kexec patches date back to the original LinuxBIOS with the Linux kernel in > the BIOS ROM and allowed for new kernels to be loaded and executed without > rebooting back to the BIOS this would allow for a minimal kernel in the BIOS and > a full featured kernel to be loaded by the first kernel. Also the BIOS ROMs have > a limited programming life and limited space so a small unchanging kernel that > then loads the final kernel from something else prolongs the useful life of the > ROMs. > > > Ron Minnich at LANL uses similar feature called "two kernel monte" > http://sourceforge.net/projects/monte/ > > > LinuxBIOS now has the ability to make use of the CMOS space for fallback/normal > boot image selection, serial port baud rates, and boot order for Etherboot, Ron > Minnich also used it authentication information for a Plan9 cluster. See the > cmos.layout files for information. > > > Steven James had nice comments on Normal/Fallback images: > LinuxBIOS for that board (and many others) supports two copies of > LinuxBIOS, fallback and primary. The fallback image is intended to be old > and stable and it's purpose is to act as a sort of rescue image. The > primary image is the one that gets updated to the latest and greatest, and > is meant to be more versatile and complete. And after the most recent update the ``hair trigger'' problem has been solved. In particular it now requires several boot failures in a row before LinuxBIOS switches into fallback mode. Generally this is 3 successive failures. > The fallback image is loaded at the top of the flash, and always receives > control at power on or reset. It does very minimal setup (switch to 32bit > flat memory protected mode), checks and clears the CMOS boot bit, and if > it was set, jumps to the primary image. This way, if the primary fails, > hitting reset will boot from the fallback image alone. The mechanism has been updated to keep a failure count in the CMOS and only when the failure count crosses a threshold is the boot bit cleared. The counter is reset after LinuxBIOS has successfully loaded an image like etherboot. Etherboot now implements a similar scheme to allow two images on the disk. One at the start one at the end, but installing an image at the end of the disk still requires some work. > >From your config, you were building a primary image. the missing bytes are > for the fallback image to be appended. It didn't work because you didn't > have a fallback image at the top of the flash (the end of the image file). > > Ron Minnich expanded on fallback vs. primary: > > You need to build TWO linuxbioses, a fallback and a primary. The fallback > is 64k. The primary is (romsize-64k). > > To build a romimage, you build the fallback, build the primary, then: > > cat primary/romimage fallback/romimage > final_romimage > > flash_rom final_romimage > > Steve Gehlbach wrote about using BOOT_IDE: > See pcchips787.config in util/config for complete configuration. Note significant pieces of this information are not using the ELF bootloader, and so describes a deprecated feature. But it will not be removed in the 1.0.x stable series. In the development series the code will not be added. > option BOOT_IDE=1 > This enables booting from IDE, the file to use is linux.bin.gz: > > option IDE_BOOT_DRIVE=2 > If you do not use drive 0 (default), then you can set which drive to > boot; (0,1,2,3) are the four standard PC drives: > > option ONE_TRACK=32 > The linux.bin.gz file is put in raw form at partition 1, ie, the first > partition on the disk. This is located just past the partition table. > The partition table size varies, it is "one track" from the beginning of > the disk. "one track" in c/h/s notation is "s" or the number of sectors > per track. ONE_TRACK is in sectors, the software multiplies by 512. > Most disks are 63 sectors per track (the default), but my CF is 32 > sectors per track. eg, the partion table is 63x512 or 32x512 bytes. > > You can partition your disk as you want, but Linux goes raw in partition > 1; just make sure partition 1 is big enough, not a problem on today's > disks. You could put the Linux root file system on partition 2, for > example. In pcchips787.config, I put the Linux root file system on IDE > 0, partition 2 (I was experimenting with Linux in partition 1), but I > eventually put Linux on drive 2 using CF. You are right, copying of > linux.bin.gz raw to the partition is dangerous, and something like "cat > linux.bin.gz > /dev/hda1" will definitely screw the disk if you put the > wrong disk or partition. I recommend a shell script, fingers cannot be > trusted. You can also use "dd" but "cat" works. > > Greg Watsons had some good comments on on the boot process and file layout: > There seem to be two main parts to linuxbios. The first is > arch/{arch}/config/ctr0.base which does the very low level > initialization, like turning on memory, etc. The second is > arch/{arch}/lib/c_start.S which does whatever else is necessary to > call the C function hardwaremain(). hardwaremain() then does whatever > else is necessary to load Linux. > > c_start.S is linked with linuxbios.a, a library containing generic > support routines (those found in the lib directory) and anything > specified using the 'object' directive in a Config file (and other > stuff). The resultant 'executable' is called linuxbios_c. The loader > script used to link linuxbios_c is config/linuxbios_c.ld, and is > configured to be loaded relative to _RAMBASE. > > crt0.base is not linked against anything. Any additional assembly > routines you need must be specified using the 'mainboardinit' > directive in a Config file. This causes the specified assembly file > to be added to "crt0_includes.h" which is in turn included at the > start of crt0.base (or at the end in the case of the ppc version). > The loader script used to link crt0.base is in > arch/{arch}/config/ldscript.base. The resultant 'executable' is > called linuxbios and will be loaded at _ROMBASE. The tricky thing is > that this loader script will also load the linuxbios_c 'executable' > at a location called _payload in this file. The main task of > crt0.base is then to initialize enough hardware so that this payload > can be copied from ROM into ram (which may also involve uncompressing > code). Then control is transferred to _start, which is the first > location in linuxbios_c. > > To get an idea of how crt0.base works, look at the following files. > This is the order of execution specified by the configuration file > for sis735. > > cpu/i386/entry16.inc > cpu/i386/entry32.inc > superio/sis/950/setup_serial.inc > pc80/serial.inc > arch/i386/lib/console.inc > cpu/k7/earlymtrr.inc > northsouthbridge/sis/735/raminit.inc > arch/i386/config/crt0.base > > Next look at c_start.S which will show you what happens once control > is transferred to _start. Finally, look at > arch/{arch}/lib/hardwaremain.c to see what other stuff is done to get > Linux loaded. > > Most other files are specific to particular hardware, so it can be > pretty confusing to just browse the tree. > > Hope this helps, It Looks like a very good summary. Eric

8 24

Newbie question on
by Mark Williamson 17 Apr '03

17 Apr '03

Dear List, I've just been looking through the mail archive for this list at http://www.clustermatic.org/pipermail/linuxbios/ and throught the CVS code for the project. I am sorry to spam the list, but I am still unsure if my motherboard is supported; [root@machine root]# lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev 42) 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Mobile South] (rev 11) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586B PIPC Bus Master IDE (rev 06) 00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 05) 00:07.3 Host bridge: VIA Technologies, Inc. VT82C596 Power Management (rev 20) 00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 00:0b.0 Network controller: Standard Microsystems Corp [SMC] SMC2602W EZConnect / Addtron AWA-100 (rev 02) 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 01) If any further details are required, please email and I will put the verbose response(s) on a url somewhere and just link to it, to keep the spam level down :) Best regards, Mark

2 1

Re: Random comments on LinuxBIOS
by ebiederman＠lnxi.com 17 Apr '03

17 Apr '03

"McMechan, James W CIV" <james.mcmechan(a)navy.mil> writes: > > > Here is what I wrote while trying to catch up to list, > > though there is a FAQ I > > > produced this while working my way through the emails > > perhaps some of it could > > > be added to the FAQ > > > > Would you be interested in maintaining or helping to maintain the FAQ? > > You seem to have a nack for putting the information together. > > > I would be willing, I don't have fast CVS access due to firewall issues but I > can get a dial up account. > > Where is the FAQ located? Is it just the html or is it backed by some source > format? it is fairly easy to read as html. This is where I expect Ron to chime in... The answers are all in my head but have not found paper yet. > > > LinuxBIOS no longer always uses a real OS to load the OS. > > > > That is not quite correct. > > > > LinuxBIOS requires a real OS, or at least a piece of software > > that can run standalone without any OS or BIOS services on > > the bare hardware. Which is essentially the definition of > > a real OS though it is not the definition of a general purpose > > OS. > > > > In the case of ADLO, ADLO can be considered a special purpose > > OS that mimics the syscall interface of a standard BIOS. > > > I am willing to argue the other way, we no longer "always" need to load a full > OS we can load elf payloads that are obviously (to users) not OSs, but merely > boot loaders that don't require BIOS. Even the smallest micro-kernels do a lot > more than memtest86 for example. True I guess I just want the distinction to be present that the LinuxBIOS core does not support callbacks so whatever you run it must be able to stand up on it's own. Which is quite rare. > > In addition there is some background work on secure/trusted > > booting. I don't > > know if anything has really happened with that yet, but ADLO > > grow out of > > the interest in trusted booting. > > > "grew out of" I assume, but still "trusted booting" has not been discussed much > recently. Perhaps I was thinking of Ron's built in VGA ROM stuff, I may have > also been the first person to suggest bochs as a GPL compatible bios example > quite a while back. It appears that plex86 is hibernating though Kevin and some > useful bits of the design have made it over to the bochs project recently. If you look up the Adams who worked on ADLO trusted booting is their research area. I am totally mystified why we have not seen more direct feedback but I think it is a very interesting area for LinuxBIOS to expand into. The topic came up not too long ago on the etherboot developers list. Still just discussion, but all of the hooks are in the code. > ... > > > It would be nice to add a larger flash ROM but many > > motherboards do not connect > > > enough address lines to the Flash ROM socket, for even the > > 4 Mbit part or they > > > solder the chip down. > > > > For LPC flash parts the address line count is not a real > > issue, new boards > > have them and they current are up to 8Mbit in size, but do > > not have a theoretical > > limit. > > > LPC parts are usually soldered down right? I have usually seen them in an LPC socketed and in a LPC form factor. > I have not yet seen one, I thought > they were part of Intel's new firmware hubs, and most boards I have seen still > have DIP or PLCC which is why I said "but many motherboards" and should add that > "new boards with LPC ROMs do not have the pin count limitation." Newer AMD boards like the AMD760MPX also have it. Intel's firmware hub is a variation on the same them. The difference is which commands are actually used on the LPC bus. The firmware hubs have special commands so it is easier to support multiple devices. The pure LPC devices don't bother and can just be strapped to live at the appropriate address. > > > Steven James had nice comments on Normal/Fallback images: > ... > > And after the most recent update the ``hair trigger'' problem has been > > solved. In particular it now requires several boot failures in a row > > before LinuxBIOS switches into fallback mode. Generally this > > is 3 successive > > failures. > > > I was wondering about that I realized that it had gone in but had not seen where > people were hitting the hair trigger, is it part of the problem with those > watchdog timers that keep resetting on people? A typical problem is when you are installing hardware or other times you are booting a board and you turn it on and then say darn I was not yet ready to boot yet. The result of little issues like that is I was seeing an unacceptably high number of systems running in fallback. It did not cause show stopper problems because my fallback and normal images are not yet asymmetrical. But if you can't trust a machine to only be in fallback when it needs rescue recovery the scheme falls apart. So basically there was a hair trigger to get into fallback mode, and now it is some harder. > ... > > > hitting reset will boot from the fallback image alone. > > > I was copying verbatim his email it seem like a nice explanation Right and that was the way the code worked until I updated it recently. > > The mechanism has been updated to keep a failure count in the > > CMOS and only > > when the failure count crosses a threshold is the boot bit > > cleared. The > > counter is reset after LinuxBIOS has successfully loaded an image like > > etherboot. > > > > Etherboot now implements a similar scheme to allow two images > > on the disk. > > One at the start one at the end, but installing an image at the end of > > the disk still requires some work. > > > I had not seen any messages about etherboot having this. Spiffy On the documentation side it is also worth nothing the boot order options. I can currently specify which class of device to try first second and third. In addition I can specify which device of the first type tried to boot from. A lot of this was done to support Pink and MCR and now that the code works I am willing to talk about it. There was a little mention of it during the design phaze but mostly there was not much feedback. And the discussion really would have occurred on the etherboot list. Which is another reason you might have missed it. > ... > > > Steve Gehlbach wrote about using BOOT_IDE: > > > See pcchips787.config in util/config for complete configuration. > > > > Note significant pieces of this information are not using the ELF > > bootloader, and so describes a deprecated feature. But it will > > not be removed in the 1.0.x stable series. In the development series > > the code will not be added. > > > I was thinking that it was the clearest explanation I have yet seen on it. > It could be a elf payload I suppose but currently it is built in. > Hum, making it into a elf payload would duplicate some of the LinuxBIOS but that > would not be a problem. > > Also for a elf payload IDE boot I would just suggest Etherboot as the payload. The case where IDE_BOOT and an linux kernel comes into play is if you have a system with compact flash and that is the only location large enough to put it. But yes, in most instances I would suggest etherboot as well. > ... > > > > > > Hope this helps, > > > > It Looks like a very good summary. > > > > Eric > > > > > Glad you liked it, I was reading a couple weeks worth of LinuxBIOS email at once > and was bothered by the questions that had, what I thought were obvious answers, > so I started typing as I was reading then I checked the FAQ and dropped a few > comments and wrote some more. Now just to figure out how to get this incorporated into the FAQ. However it gets maintained I am certain from this email that it really should be posted to the list periodically so people just reading their email will see it and we can point out places it needs corrections just by replying... If nothing else it is a good way to draw answers out of my head... Eric

2 1

Re: Random comments on LinuxBIOS
by ron minnich 17 Apr '03

17 Apr '03

nice job. The one thing I'd add is it can be useful to make tags then vi -t hardwaremain (or emacs equivalent) and walk the source. Is there someplace on the web page you'd like to see this go? ron

1 0

RE: Random comments on LinuxBIOS
by McMechan, James W CIV 16 Apr '03

16 Apr '03

> > Here is what I wrote while trying to catch up to list, > though there is a FAQ I > > produced this while working my way through the emails > perhaps some of it could > > be added to the FAQ > > Would you be interested in maintaining or helping to maintain the FAQ? > You seem to have a nack for putting the information together. > I would be willing, I don't have fast CVS access due to firewall issues but I can get a dial up account. Where is the FAQ located? Is it just the html or is it backed by some source format? it is fairly easy to read as html. > > LinuxBIOS no longer always uses a real OS to load the OS. > > That is not quite correct. > > LinuxBIOS requires a real OS, or at least a piece of software > that can run standalone without any OS or BIOS services on > the bare hardware. Which is essentially the definition of > a real OS though it is not the definition of a general purpose > OS. > > In the case of ADLO, ADLO can be considered a special purpose > OS that mimics the syscall interface of a standard BIOS. > I am willing to argue the other way, we no longer "always" need to load a full OS we can load elf payloads that are obviously (to users) not OSs, but merely boot loaders that don't require BIOS. Even the smallest micro-kernels do a lot more than memtest86 for example. ... > In addition there is some background work on secure/trusted > booting. I don't > know if anything has really happened with that yet, but ADLO > grow out of > the interest in trusted booting. > "grew out of" I assume, but still "trusted booting" has not been discussed much recently. Perhaps I was thinking of Ron's built in VGA ROM stuff, I may have also been the first person to suggest bochs as a GPL compatible bios example quite a while back. It appears that plex86 is hibernating though Kevin and some useful bits of the design have made it over to the bochs project recently. ... > > It would be nice to add a larger flash ROM but many > motherboards do not connect > > enough address lines to the Flash ROM socket, for even the > 4 Mbit part or they > > solder the chip down. > > For LPC flash parts the address line count is not a real > issue, new boards > have them and they current are up to 8Mbit in size, but do > not have a theoretical > limit. > LPC parts are usually soldered down right? I have not yet seen one, I thought they were part of Intel's new firmware hubs, and most boards I have seen still have DIP or PLCC which is why I said "but many motherboards" and should add that "new boards with LPC ROMs do not have the pin count limitation." > > Steven James had nice comments on Normal/Fallback images: ... > And after the most recent update the ``hair trigger'' problem has been > solved. In particular it now requires several boot failures in a row > before LinuxBIOS switches into fallback mode. Generally this > is 3 successive > failures. > I was wondering about that I realized that it had gone in but had not seen where people were hitting the hair trigger, is it part of the problem with those watchdog timers that keep resetting on people? ... > > hitting reset will boot from the fallback image alone. > I was copying verbatim his email it seem like a nice explanation > The mechanism has been updated to keep a failure count in the > CMOS and only > when the failure count crosses a threshold is the boot bit > cleared. The > counter is reset after LinuxBIOS has successfully loaded an image like > etherboot. > > Etherboot now implements a similar scheme to allow two images > on the disk. > One at the start one at the end, but installing an image at the end of > the disk still requires some work. > I had not seen any messages about etherboot having this. Spiffy ... > > Steve Gehlbach wrote about using BOOT_IDE: > > See pcchips787.config in util/config for complete configuration. > > Note significant pieces of this information are not using the ELF > bootloader, and so describes a deprecated feature. But it will > not be removed in the 1.0.x stable series. In the development series > the code will not be added. > I was thinking that it was the clearest explanation I have yet seen on it. It could be a elf payload I suppose but currently it is built in. Hum, making it into a elf payload would duplicate some of the LinuxBIOS but that would not be a problem. Also for a elf payload IDE boot I would just suggest Etherboot as the payload. ... > > > > Hope this helps, > > It Looks like a very good summary. > > Eric > > Glad you liked it, I was reading a couple weeks worth of LinuxBIOS email at once and was bothered by the questions that had, what I thought were obvious answers, so I started typing as I was reading then I checked the FAQ and dropped a few comments and wrote some more.

1 0

Random comments on LinuxBIOS
by McMechan, James W CIV 16 Apr '03

16 Apr '03

Here is what I wrote while trying to catch up to list, though there is a FAQ I produced this while working my way through the emails perhaps some of it could be added to the FAQ LinuxBIOS is a project to replace the original BIOS on motherboards with open source. It appears that the two most common uses for LinuxBIOS are for Supercomputer clusters and embedded systems. LinuxBIOS no longer always uses a real OS to load the OS. LinuxBIOS currently can boot several payloads including: 1 Linux which is what started all this, hence the name. 2 Plan9 Ron Minnich seems to like this one. 3 VxWorks Felix Radensky said he had success with a older boot method 4 EtherBoot which despite its name can also boot from IDE hard disks with a patch or the dev branch 5 ADLO is a shim to allow the Boch emulator's BIOS to be used on top of LinuxBIOS to boot some versions of that other OS or to run VGA controller ROMs which seem to assume that a BIOS is present. ? The Supercomputer people appear to want remote control, remote booting and fast boot times without user interaction. For example "Press F2" is a very inconvenient task on a system with 100 computers The embedded people appear to want full control of the boot process and very fast boot times. For example who wants to watch a memory test go by on their VCR/MP3 player or see "Press F2" without a keyboard. LinuxBIOS is installed into the flash ROM in place of the original BIOS. Most flash ROMs are currently 2 Megabits in size, i.e. a 29SF020 which is only 256 Kilobytes of storage, or some might be 4 Mbit ROM which provides 512 Kbytes and so could allow for very squeezed down Linux kernel to also be included in the ROM, though I don't know of a useful kernel that small. It would be nice to add a larger flash ROM but many motherboards do not connect enough address lines to the Flash ROM socket, for even the 4 Mbit part or they solder the chip down. Another popular if grumbled about option is the disk on a chip the DoC Millennium which is a paged flash part that can have LinuxBIOS in the first part and up to 8 Mbytes of other data on other pages of the chip. Very short ~3-10 seconds boot times should be possible with this method. The BIOS Flash can usually be programmed in place by either just reflashing the original BIOS or by the hotswap method also known as the dental floss method, referring to putting dental floss under a PLCC chip to make it easy to remove without requiring metal tools in a powered on system. The hotswap method is not for the faint of heart but not all that difficult either, the system is booted with a working ROM which is then pulled out and the ROM to be programmed inserted in its place, then the ROM flashing program is run, and when done a reboot can be tried, this does not require a programmer as it uses the motherboards ability to update its BIOS as the programmer, if the reboot fails the original ROM is reinserted and the system rebooted again, all this requires, is some spare flash ROMs it is a good idea to make and label a couple backups incase something goes wrong, I have put ROMs in DIP sockets backwards destroying the ROMs, and ESD is a worry even if it is not a common problem. Some people also use a very nice device called the BIOS savior which allows for two BIOS ROMS to be switched by the user with a switch. Compact Flash IDE adaptors appear to be popular as the CF does not need the spin up time of a real hard disk. Very short boot times of ~3-10 seconds are claimed for this configuration also. Each model of motherboard currently needs its own build information due to a lack of standards in how the circuitboards are laid out between models and manufactures. If you have a motherboard that is not listed, a "lspci" will show what chipsets are in use and you can then check to see if they are in the LinuxBIOS tree, if not some research may be needed to get the documentation for that chipset. The kexec patches date back to the original LinuxBIOS with the Linux kernel in the BIOS ROM and allowed for new kernels to be loaded and executed without rebooting back to the BIOS this would allow for a minimal kernel in the BIOS and a full featured kernel to be loaded by the first kernel. Also the BIOS ROMs have a limited programming life and limited space so a small unchanging kernel that then loads the final kernel from something else prolongs the useful life of the ROMs. Ron Minnich at LANL uses similar feature called "two kernel monte" http://sourceforge.net/projects/monte/ LinuxBIOS now has the ability to make use of the CMOS space for fallback/normal boot image selection, serial port baud rates, and boot order for Etherboot, Ron Minnich also used it authentication information for a Plan9 cluster. See the cmos.layout files for information. Steven James had nice comments on Normal/Fallback images: LinuxBIOS for that board (and many others) supports two copies of LinuxBIOS, fallback and primary. The fallback image is intended to be old and stable and it's purpose is to act as a sort of rescue image. The primary image is the one that gets updated to the latest and greatest, and is meant to be more versatile and complete. The fallback image is loaded at the top of the flash, and always receives control at power on or reset. It does very minimal setup (switch to 32bit flat memory protected mode), checks and clears the CMOS boot bit, and if it was set, jumps to the primary image. This way, if the primary fails, hitting reset will boot from the fallback image alone. >From your config, you were building a primary image. the missing bytes are for the fallback image to be appended. It didn't work because you didn't have a fallback image at the top of the flash (the end of the image file). Ron Minnich expanded on fallback vs. primary: You need to build TWO linuxbioses, a fallback and a primary. The fallback is 64k. The primary is (romsize-64k). To build a romimage, you build the fallback, build the primary, then: cat primary/romimage fallback/romimage > final_romimage flash_rom final_romimage Steve Gehlbach wrote about using BOOT_IDE: See pcchips787.config in util/config for complete configuration. option BOOT_IDE=1 This enables booting from IDE, the file to use is linux.bin.gz: option IDE_BOOT_DRIVE=2 If you do not use drive 0 (default), then you can set which drive to boot; (0,1,2,3) are the four standard PC drives: option ONE_TRACK=32 The linux.bin.gz file is put in raw form at partition 1, ie, the first partition on the disk. This is located just past the partition table. The partition table size varies, it is "one track" from the beginning of the disk. "one track" in c/h/s notation is "s" or the number of sectors per track. ONE_TRACK is in sectors, the software multiplies by 512. Most disks are 63 sectors per track (the default), but my CF is 32 sectors per track. eg, the partion table is 63x512 or 32x512 bytes. You can partition your disk as you want, but Linux goes raw in partition 1; just make sure partition 1 is big enough, not a problem on today's disks. You could put the Linux root file system on partition 2, for example. In pcchips787.config, I put the Linux root file system on IDE 0, partition 2 (I was experimenting with Linux in partition 1), but I eventually put Linux on drive 2 using CF. You are right, copying of linux.bin.gz raw to the partition is dangerous, and something like "cat linux.bin.gz > /dev/hda1" will definitely screw the disk if you put the wrong disk or partition. I recommend a shell script, fingers cannot be trusted. You can also use "dd" but "cat" works. Greg Watsons had some good comments on on the boot process and file layout: There seem to be two main parts to linuxbios. The first is arch/{arch}/config/ctr0.base which does the very low level initialization, like turning on memory, etc. The second is arch/{arch}/lib/c_start.S which does whatever else is necessary to call the C function hardwaremain(). hardwaremain() then does whatever else is necessary to load Linux. c_start.S is linked with linuxbios.a, a library containing generic support routines (those found in the lib directory) and anything specified using the 'object' directive in a Config file (and other stuff). The resultant 'executable' is called linuxbios_c. The loader script used to link linuxbios_c is config/linuxbios_c.ld, and is configured to be loaded relative to _RAMBASE. crt0.base is not linked against anything. Any additional assembly routines you need must be specified using the 'mainboardinit' directive in a Config file. This causes the specified assembly file to be added to "crt0_includes.h" which is in turn included at the start of crt0.base (or at the end in the case of the ppc version). The loader script used to link crt0.base is in arch/{arch}/config/ldscript.base. The resultant 'executable' is called linuxbios and will be loaded at _ROMBASE. The tricky thing is that this loader script will also load the linuxbios_c 'executable' at a location called _payload in this file. The main task of crt0.base is then to initialize enough hardware so that this payload can be copied from ROM into ram (which may also involve uncompressing code). Then control is transferred to _start, which is the first location in linuxbios_c. To get an idea of how crt0.base works, look at the following files. This is the order of execution specified by the configuration file for sis735. cpu/i386/entry16.inc cpu/i386/entry32.inc superio/sis/950/setup_serial.inc pc80/serial.inc arch/i386/lib/console.inc cpu/k7/earlymtrr.inc northsouthbridge/sis/735/raminit.inc arch/i386/config/crt0.base Next look at c_start.S which will show you what happens once control is transferred to _start. Finally, look at arch/{arch}/lib/hardwaremain.c to see what other stuff is done to get Linux loaded. Most other files are specific to particular hardware, so it can be pretty confusing to just browse the tree. Hope this helps, Greg

1 0

Via VT82C686B southbridge
by Jarmo Tulonen 16 Apr '03

16 Apr '03

Hello I'm trying to get Linuxbios work on a Wincomm WPC-660 mainboard having VT82C686B southbridge and VT8601A northbridge (both from Via). Basically I've just copied the Via Epia code, replacing the VT8231-southbridge code with the VT82C686-code. So far the only sign of life is flashing of the keyboard lights after reset, so it's not totally dead. The serial port, however, does not work. Has anyone actually used this southbridge code ? Any ideas how to try to get it work ? Jarmo

2 1

support for 82801AA southbridge
by Shubhangi Jadhav 16 Apr '03

16 Apr '03

Hi, Does LinuxBIOS support the 82801AA southbridge? The code in southbridge\82801 directory is for the 82801AB chip. However in one of the posts to the mailing list I read that the 82801AA southbridge is supported. Could someone guide me please. Am I missing something. Thanks, Shubhangi

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot