coreboot

coreboot@coreboot.org

10 participants
39711 discussions

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

Re: OpenFirmware and interrupt-map (fwd)
by ron minnich 03 Feb '04

03 Feb '04

This is the easiest way to handle the spam. Sorry Tarl i'm the moderator and I'm dealing with several hundred spams a week, so real messages don't always get through. ron ---------- Forwarded message ---------- Date: Tue, 03 Feb 2004 17:23:30 -0500 From: Tarl Neustaedter <Tarl.Neustaedter(a)sun.com> To: ron minnich <rminnich(a)lanl.gov> Cc: Eric W. Biederman <ebiederman(a)lnxi.com>, LinuxBIOS <linuxbios(a)clustermatic.org> Subject: Re: OpenFirmware and interrupt-map > I don't expect the cards to come with fcode any time soon, if ever. Agreed. Sun's been doing IEEE 1275 for well over a decade, and only once did I ever deal with a vendor who even knew what FCode was. The essence is if you need FCode on the cards, you need to have a plan on how to get it there yourself. [ I don't know if this will make it to the alias; the last message I sent got a return saying "being held waiting for moderator".] tarl

1 0

ASUS A7M266-D
by Christian Zoffoli 02 Feb '04

02 Feb '04

Hi to all. Does anyone know how to make that mobo work with linuxbios? ...I can't cleanly build a linuxbios image. here is first error ------------------- gcc -x assembler-with-cpp -DASSEMBLY -E ... crt0.S > crt0.s gcc ... -o crt0.o crt0.s /linuxbios/freebios/src/sdram/generic_dump_spd.inc: Assembler messages: /linuxbios/freebios/src/sdram/generic_dump_spd.inc:4: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_dump_spd.inc:5: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_dump_spd.inc:6: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_dump_spd.inc:7: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_dump_spd.inc:8: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_dump_spd.inc:9: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_dump_spd.inc:10: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_dump_spd.inc:11: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_dump_spd.inc:12: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_dump_spd.inc:13: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_dump_spd.inc:18: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_dump_spd.inc:19: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_dump_spd.inc:23: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_dump_spd.inc:24: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_dump_spd.inc:31: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_dump_spd.inc:32: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/northbridge/amd/amd76x/raminit.inc:1484: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_sdram.inc:13: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_sdram.inc:15: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_sdram.inc:22: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_sdram.inc:23: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_sdram.inc:31: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_sdram.inc:37: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_sdram.inc:42: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_sdram.inc:50: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_sdram.inc:53: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_sdram.inc:60: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_zero_ecc_sdram.inc:9: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_zero_ecc_sdram.inc:59: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_zero_ecc_sdram.inc:85: Error: invalid character '_' in mnemonic /linuxbios/freebios/src/sdram/generic_zero_ecc_sdram.inc:104: Error: invalid character '_' in mnemonic crt0.S:47: Error: invalid character '_' in mnemonic crt0.S:154: Error: invalid character '_' in mnemonic crt0.S:156: Warning: indirect jmp without `*' make: *** [crt0.o] Error 1 ------------------- Any suggestion? Thanks, Christian

2 3

Interesting HOWTO
by Pedro M. 01 Feb '04

01 Feb '04

I have seen an interesting HOWTO about BIOS and Booting . http://www.freewebs.com/tsj/bootingUSB_ldp_v0.1.htm Regards.

8 16

AGP 3.0 bus analyzer
by ron minnich 31 Jan '04

31 Jan '04

I'm looking for an AGP 3.0 interposer bus analyzer along the lines of what vmetro supplies. If anyone knows of such a thing, let me know. This AGP debug is a real pain without an analyzer. We're losing lots of time because it is hard to tell what signals are making it to AGP and what are not. thanks ron

2 3

EPIA + SST39SF020A
by Surjan Singh 30 Jan '04

30 Jan '04

Hello all, Just wanted to highlight a website I found that actually sells the same BIOS chips that are used in the bog standard EPIA board (http://www.viavpsd.com/product/epia_mini_itx_spec.jsp?motherboardId=21). Try this: http://progshop.com/shop/eproms/index.shtml#39SF I had to enable cross-site cookies to actually place an order, but I changed it back straight after. I've had all sorts of problems with BIOS Savior and other chips that were supposed to be a drop-in replacement. Surj

2 1

EPIA-M HW graphics slow under linuxbios
by Dmitry Borisov 30 Jan '04

30 Jan '04

Hi, I have taken freebios from CVS and applied the patch from here http://www.clustermatic.org/pipermail/linuxbios/2003-July/004046.html to enable VGA. It works perfect. Exactly what I need. The major problem with such a build is that directfb( it uses HW accelaration extensively ) works 2 times slower. Even though it still uses it as without acceleration it runs 10 times slower... I'm wondering what could cause such a slow performance ? Does anyone have any suggestions ? ( It seems all other pure memory/disk programs are not affected ) Dmitry/

3 6

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