coreboot April 2003

coreboot@coreboot.org

68 participants
177 discussions

Start a nNew thread

RE: Support for supermicro 7501 based boards and issues with 3ware raid cards
by Schafer, Christopher L 18 Apr '03

18 Apr '03

The device is hardware raid upto 12 drives. Presents a SCSI device to the driver/kernel.

2 1

RE: Re[2]: Error ...
by marc.miller＠amd.com 18 Apr '03

18 Apr '03

Forgive my ignorance, but can we simply ask the lm_sensors developers to fix lm_sensors? -----Original Message----- From: Alexander Amelkin [mailto:spirit@reactor.ru] Sent: Friday, April 18, 2003 2:00 PM To: Ron Minnich Subject: Re[2]: Error ... Hello ron, Friday, April 18, 2003, 11:42:29 PM, you wrote: rm> On 18 Apr 2003, Denis Pilon wrote: >> If I run lm_sensors and initialize the chips, the node will not reboot. >> It gives me a no memory error at boot. rm> consider getting rid of lm_sensors first. Personally, I'd prefer LinuxBIOS to be compatible with lm_sensors. It's very pity to miss such a nice part of hardware as monitoring. What's the problem with supporting it? With best regards, Alexander mailto:spirit@reactor.ru _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

3 2

Re[2]: Random comments on LinuxBIOS
by Alexander Amelkin 18 Apr '03

18 Apr '03

Hello James, Friday, April 18, 2003, 1:16:54 AM, you wrote: MJWC> ... >> > Compact Flash IDE adaptors appear to be popular as the CF >> does not need the spin up time of a real hard disk. >> Is there some kind of patch available for the kernel which >> can be applied to >> achieve the above point. MJWC> Using any one of the IDE boot methods should just plain work. MJWC> What were you wanting to patch? I think Deepak wants a patch for disabling the LinuxBIOS hard-coded IDE spinup delay. I issued a patch for that some time ago. You may want to search the archive. With best regards, Alexander mailto:spirit@reactor.ru

2 1

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

17 Apr '03

On Thu, 17 Apr 2003, McMechan, James W CIV wrote: > Do you have a bundle of these emails? I will send you the inbox. You will need to work out the questions and answers from the text, but it is pretty obvious. > In what way is it hard to edit? mbox format. > Are the web pages just plain html not generated from some other source format? hand-edited html. > Would you like patches to the html or just a new version of the document? whatever you prefer. ron

2 1

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

17 Apr '03

... > > 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. > > > > Is there some kind of patch available for the kernel which > can be applied to > achieve the above point. > I am using 2.4.18-3 kernel, please let me know. > > Regards > Deepak > I am not quite clear on what you are asking. The Compact Flash in a CF->IDE adaptor should look exactly like a very very fast hard disk that does not require spinup time. Using any one of the IDE boot methods should just plain work. What were you wanting to patch? The boot process after the kernel is loaded and running can be speeded up with better boot scripts "serel" from www.fastboot.org has been mentioned as helping RedHat style startup scripts.

1 0

Stable storage of BIOS parameters...
by ebiederman＠lnxi.com 17 Apr '03

17 Apr '03

Currently I have implemented code to store BIOS options in the cmos, and the layout of the options is reported by the LinuxBIOS table. Going forward there are going to be options that we cannot store in the cmos. Either because of size or because of unreliability of the cmos. I think I want to setup a small jffs2 filesystem in the rom chip, for maintaining and manipulating those options. The concern I have is that this sucks up a lot of flash blocks (at least two), because of the size of the information. The one piece of information I do not feel comfortable storing there is the cmos boot count and normal/failsafe settings. Because LinuxBIOS must set those and _reliably_ writing to a flash chip appears to be a non-trivial exercise. By using jffs2 other people can manipulate the stable store as well. My big question is how should I encode the options that LinuxBIOS utilizes. This is a piece I have not implemented yet, but that looks increasing useful especially as a store of various bits of persistent data. Especially when things like cryptographic keys get involved. Eric

2 5

1.1 development release targets.
by ebiederman＠lnxi.com 17 Apr '03

17 Apr '03

Development in the current LinuxBIOS tree is starting to get difficult because of the sheer number of backward compatible interfaces we retain even when better code is introduced into the tree. For the 1.1.x development branch leading to the stable 2.0.x series it is my intention remove all of the old interfaces and put LinuxBIOS back together using the current best of breed techniques. - Use the elf bootloader - Use romcc so we can remove most of the assembly. - Use the generic pci setup mechanism. It needs a little work to make initialization as easy as the superio case but it should work for everything. - Make hardwaremain architecture independent. - Native interrupt routing. (We don't have code but...) - Documented interfaces (I suck at doing this but it needs to happen)... I am still in the final stages of prototyping the cleanups to hardwaremain. But my first draft is below. The function that still needs things worked out is enumerate static devices. One or two boards need to be ported and the issues worked out before everything else comes along. The goal is a hardwaremain() function that does not change. Once there is a stable port in the 1.1. development branch my goal is to call that enough development make it the 2.0 branch and any future disruptive work needs to go on a new development branch. When the 2.0 branch can continue to accumulate working ports. To implement this I have started a freebios2 tree at sourceforge and I will gradually populating this tree. I am taking the expedient of copying old code over as needed. Leaving old code for now unneeded functionality to just fade away. It is the only easy incremental way I can see to make the sweeping changes I want to see in the LinuxBIOS tree. I am going to start with the Hammer port and possibly with the p4dpr, to seed the tree and work out most of the issues with the new infrastructure. After that it is moving to 2.0 and collecting additional ports, I suspect. Eric void hardwaremain(int boot_complete) { /* Processor ID of the BOOT cpu (i.e. the one running this code) */ unsigned long boot_cpu; int boot_index; /* the order here is a bit tricky. We don't want to do much of * anything that uses config registers until after PciAllocateResources * since that function also figures out what kind of config strategy * to use (type 1 or type 2). * so we turn on cache, then worry about PCI setup, then do other * things, so that the other work can use the PciRead* and PciWrite* * functions. */ struct mem_range *mem, *tmem; unsigned long totalmem; // we don't call post code for this one -- since serial post could cause real // trouble. outb(0x38, 0x80); /* displayinit MUST PRECEDE ALL PRINTK! */ displayinit(); post_code(0x39); printk_notice("LinuxBIOS-%s%s %s %s...\n", linuxbios_version, linuxbios_extra_version, linuxbios_build, (boot_complete)?"rebooting":"booting"); post_code(0x40); /* If we have already booted attempt a hard reboot */ if (boot_complete) { hard_reset(); } // pick how to scan the bus. This is first so we can get at memory size. printk_info("Finding PCI configuration type.\n"); pci_set_method(); post_code(0x5f); enumerate_static_devices(); pci_enumerate(); post_code(0x66); // Now do the real bus // we round the total ram up a lot for thing like the SISFB, which // shares high memory with the CPU. pci_configure(); post_code(0x88); pci_enable(); pci_initialize(); post_code(0x89); mem = get_ramsize(); post_code(0x70); totalmem = 0; for(tmem = mem; tmem->sizek; tmem++) { totalmem += tmem->sizek; } printk_info("totalram: %ldM\n", (totalmem + 512) >> 10); /* Round to the nearest meg */ /* Fully initialize the cpu before configuring the bus */ boot_cpu = cpu_initialize(mem); boot_index = processor_index(boot_cpu); printk_spew("BOOT CPU is %d\n", boot_cpu); processor_map[boot_index] = CPU_BOOTPROCESSOR|CPU_ENABLED; /* Now start the other cpus initializing * The sooner they start the sooner they stop. */ post_code(0x75); startup_other_cpus(processor_map); post_code(0x77); /* make certain we are the only cpu running in linuxBIOS */ wait_for_other_cpus(); /* Now that we have collected all of our information * write our configuration tables. */ write_tables(mem); elfboot(streams, get_lb_mem()); }

4 13

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

17 Apr '03

> 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. > Is there some kind of patch available for the kernel which can be applied to achieve the above point. I am using 2.4.18-3 kernel, please let me know. Regards Deepak

1 0

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

← Newer
1
...
7
8
9
10
11
12
13
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2003