coreboot February 2004

coreboot@coreboot.org

43 participants
63 discussions

EPIA-M linuxbios reset button does not work
by "Dmitry Borisov=?koi8-r?Q?=22=20?= 05 Feb '04

05 Feb '04

Hi, I just realized that besides the performance problems of video subsystem on my EPIA-M I have another small one. When I use regular BIOS my linux can identify that reset or power button was pressed and do some actions accrodingly. In case of linuxbios it cannot. Does anyone have any suggestions what needs to be implemented in linuxbios to support these features ? Appreciate any pointers, references or so. Thanks, Dmitry/

2 1

list of BIOSes supporting booting from USB flash disk
by Jing S. Tang 05 Feb '04

05 Feb '04

Hi, I've written a linux HOWTO on how to create a Linux bootable flash disk: http://www.freewebs.com/tsj/bootingUSB_ldp_v0.1.htm I'd like to put a list of BIOSes which support booting from the USB flash disk (USB keydrives) in my document. Could some experts at linuxbios please provide this kind of list? Thanks in advance! Jing S. Tang _________________________________________________________ Do You Yahoo!? 完全免费的雅虎电邮，马上注册获赠额外60兆网络存储空间 http://cn.rd.yahoo.com/mail_cn/tag/?http://cn.mail.yahoo.com

2 1

new linuxbios v1 mainboard added
by ron minnich 05 Feb '04

05 Feb '04

chaintech 7kjd. I didn't do it, and I just forgot the name of the guy who did, but I hope he will pop in and comment on it. This seems like a neat little board. ron

1 0

Re: OpenFirmware and interrupt-map
by YhLu 05 Feb '04

05 Feb '04

SCSI card option rom may do several thing: 1. download FW from other address in the Option rom or BIOS into SCSI Controller, then start the controller. 2. Booting OS from SCSI disk. Some SCSI addon card has another EEPROM for FW, and the controller will work after power is on. For onboard SCSI, may spare that EEPROM and need option rom to download fw into it. The other thing for Option ROM is providing booting from SCSI disk or CDROM. If the System is boot from Network or other media, You may don't need this booting feature. Actually the FW download and controller starting can be done by Linux kernel driver. YH. -----邮件原件----- 发件人: ron minnich [mailto:rminnich@lanl.gov] 发送时间: 2004年2月4日 15:39 收件人: Eric W. Biederman 抄送: Stefan Reinauer; Tarl Neustaedter; LinuxBIOS 主题: Re: OpenFirmware and interrupt-map On 4 Feb 2004, Eric W. Biederman wrote: > Interesting. I do know that the RAID/SCSI x86 option roms in general > were not needed on the Alpha. Do you know of any RAID/SCSI cards that > actually need their option ROM to be run? > > Every one I have research it is a non issue. I forget which card it was, but we did have a problem here at one point with a card that really needed that scsi bios to be run. We junked the card. ron _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

3 2

Motherboard for LinuxBIOS & DOC
by Eric BENARD / Free 05 Feb '04

05 Feb '04

Hi, A few year ago I've been using a Matsonic MS7308E with a 8 MB Disc On Chip (DIP32) and LinuxBios. The Linux filesystem (jffs2) was embedded in the DOC and everything was booting in less than 1 or 2 seconds. I would like to setup the same configuration but the only thing I have is the DOC as the motherboard has burned :-( Which motherboard / chipset would you advise me to use with a DOC - an actual motherboard if possible ? Many thanks and best regards Eric

1 0

Build problem - %rdx used with `l' suffix
by Tarl Neustaedter 05 Feb '04

05 Feb '04

Back in september, there was a message about a fix to romcc for AMD64, which would cure the error: /tmp/ccLriZXb.s:243: Error: Incorrect register `%rdx' used with `l' suffix As it happens, I'm getting that error building arima/hdama from an Opteron (it was suggested as a good starting point for a working prom that I could branch off from). It looks like the code in romcc has changed enough that the fix doesn't directly apply, and there was some doubt as to whether that was the necessary fix. Is there something else I should be doing to avoid this error? For the record, my versions of gcc, as and linux: wgs94-112% gcc -v Reading specs from /usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=x86_64-redhat-linux Thread model: posix gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-20) wgs94-112% as -v GNU assembler version 2.14.90.0.4 (x86_64-redhat-linux) using BFD version 2.14.90.0.4 20030523 wgs94-112% uname -a Linux wgs94-112 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:32:58 EDT 2003 x86_64 x86_64 x86_64 GNU/Linux

3 2

Handling interrupt routing cleanly...
by ebiederman＠lnxi.com 04 Feb '04

04 Feb '04

For random reasons I have been reading through the Open Firmware specifications. One in particular caught my attention the interrupt mapping specification. I really liked the basic structure, although I don't think the details themselves will map cleanly to LinuxBIOS. The basic structure was: Each device has it's interrupt. Each device has an interrupt parent. If not specified explicitly the interrupt parent is simply up the device tree but that was not required. An interrupt parent can have an interrupt mapping table that maps interrupts maps device#/interrupt pairs to ids consumed by devices up the interrupt tree. The interrupt mapping table can have a mask to reduce the size of the mapping table needed. It is a very clean structure and it maps well to the LinuxBIOS device tree. There are few interesting complications that we need to handle like ACPI mode versus legacy PIC mode but those details should not be too difficult. Once that infrastructure is implemented we should be able to auto generate pci-irq tables, mptables, acpi interrupt tables, and open firmware tables (Assuming we manage to export it all cleanly from the LinuxBIOS table). Stefan how close is the open firmware code that we could test a port to generic LinuxBIOS. With the LinuxBIOS table providing this information? Eric

3 10

Re: OpenFirmware and interrupt-map
by ebiederman＠lnxi.com 04 Feb '04

04 Feb '04

There are some interesting points of comparing experience between Open firmware and LinuxBIOS so I am copying the list. Tarl Neustaedter <Tarl.Neustaedter(a)sun.com> writes: > Eric W. Biederman wrote: > > Tarl Neustaedter <Tarl.Neustaedter(a)sun.com> writes: > > > >>If you have any specific questions about OpenFirmware, I'd be > >>delighted to provide assistance. I've been doing IEEE 1275 since > >>1996, and was at one time a voting member of that committee (since > >>pretty much defunct). The specs are engraved upon my skull by now. > > > > Cool. Stefan Reinauer <stepan(a)suse.de> is more likely to ask > > questions as he is the primary implementor of OpenBIOS. Which > > is a payload from the LinuxBIOS context. As a standard for running > > code in options roms it does not look too > > bad. > > The main problem is that cards don't usually come with IEEE 1275 FCode > on them. We've pretty much had to write all of ours, and have gotten > tired of it - we're actually looking at LinuxBIOS as a way to get > out of that business, and just build in the drivers we care to in the > Linux kernel on the prom. But I can answer questions any questions > about writing FCode, it's most of what I've done in recent years. Interesting. The observation that powerful firmware eventually becomes an OS so you might as well use an OS, seems true :) The one problem with using Linux so far has been size constraints. The primary interim solution has been to use etherboot. You have to port the Linux drivers to it but it close enough you don't have to rewrite them from scratch, and it is small. 16K-32K is typical with one network driver and a IP stack. 128K when you build in all the network drivers. I have recently found some kernel patches that start to shrink the Linux kernel by allowing you to compile out unnecessary pieces so I about ready to make a foray into using Linux as our bootloader again. But until I have squeezed a lot of the size bloat out I won't be convinced it is the way to go. The location where option roms come into play in the pc world are scsi adapters, raid controllers, and video. For scsi adapters and raid controllers every case I have looked at the linux drivers are good enough that you don't need the option roms. Video drivers are still problematic. How has sun coped with getting video drivers for high end video cards. I know Apple seems to have succeeded in working with NVIDIA. I suspect that is with open firmware side but I don't know. Eric

6 18

Config language progress/issues...
by ebiederman＠lnxi.com 04 Feb '04

04 Feb '04

At some point in the past Greg gave me a version of config.g to test. I reported success but it never got merged, but I have been using it... Earlier tonight I ran into some silly stupid problems where defaults were overriding options and now that those are fixed I have committed the working config.g There is still one huge remaining bug though. If statements are evaluated too early. In particular the following options must be placed in the outermost Config.lb because their if statements reside in src/config/Config.lb which is processed before src/mainboard/.../.../Config.lb. The problem is that is too soon to know the if condition unless everything is set in the top level config file. option HAVE_OPTION_TABLE=1 option HAVE_FALLBACK_BOOT=1 Eric

2 2

[Fwd: Re: OpenFirmware and interrupt-map]
by Tarl Neustaedter 04 Feb '04

04 Feb '04

[ re-send, hopefully having fixed subscription issues ] > Interesting. The observation that powerful firmware eventually > becomes an OS so you might as well use an OS, seems true :) One benefit we're hoping for is to not have to write multiple drivers every time we go to a new technology (e.g., infiniband). Right now, we're facing the possibility of needing to write a Solaris driver, a Linux driver, an IEEE-1275 FCode driver, and a real-mode BIOS driver. All for one technology, and with the probability of having to repeat for the next i/o technology to come along, since we are going forward with both SPARC and Opteron-based systems. With LinuxBIOS, it looks like it should be possible to re-use the Linux driver in the PROM. If so, it would mean that a new platform based on a particular i/o technology could contain the drivers for that particular technology (e.g., for Infiniband, IPoIB and SRP drivers), and not have to worry about option ROMs. If it saves us several engineer-years in development, that's good. > The one problem with using Linux so far has been size constraints. I can believe it. My task right now is to determine if LinuxBIOS is feasible, and if so, at what size. We have some flexibility in that we design our own boards, so if we can justify a large PROM, we could get it in. Better if we can fit it in a 1MB prom, however. > I have recently found some kernel patches that start to shrink the > Linux kernel by allowing you to compile out unnecessary pieces so > I about ready to make a foray into using Linux as our bootloader > again. But until I have squeezed a lot of the size bloat out I won't > be convinced it is the way to go. I'll be [very] interested in this. > The location where option roms come into play in the pc world are > scsi adapters, raid controllers, and video. For scsi adapters and > raid controllers every case I have looked at the linux drivers are > good enough that you don't need the option roms. Video drivers are > still problematic. > > How has sun coped with getting video drivers for high end video > cards. I know Apple seems to have succeeded in working with > NVIDIA. I suspect that is with open firmware side but I don't know. A Sun video card comes with an OpenFirmware driver. That means that Sun has either designed and built the card itself, or has signed a deal with a vendor to re-sell their video cards after writing a driver and putting it on the option ROM. The usual arrangement is that this driver is still intellectual property of the video card vendor, so that he can maintain secrecy on how to use his card. Don't know why. To some extent, cards can be moved between Suns, Apples, IBM PowerPC platforms and some HP systems, all of which use the IEEE 1275 standard. Each implementation has slightly diverged from each other, and now that the 1275 committee isn't meeting any more, quirks are tending cause further divergence. Note that an openfirmware video driver isn't particularly feature-rich. It primarily provides a dumb scrolling ascii text window. There are definitions for fancier capabilities (cursor positioning, color, character insertion), but I've never seen anyone use them - or even know if these capabilities work in our drivers. Regards, Tarl Neustaedter, CST Firmware, Sun Microsystems

4 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot February 2004