From ts1 at tsn.or.jp Sun Feb 1 09:14:01 2004 From: ts1 at tsn.or.jp (Takeshi Sone) Date: Sun Feb 1 09:14:01 2004 Subject: Interesting HOWTO In-Reply-To: References: <401942C5.4080901@telefonica.net> <20040129163820.GA31181@suse.de> <40194E81.7050907@telefonica.net> <20040129173806.GA14412@suse.de> <1075508708.6342.761.camel@eddie> Message-ID: <20040201142708.GA8487@tsn.or.jp> Steven, thank you for the great work. I really want to incorporate your USB code to FILO. However, I'm busy with real life for now and I can't seem to find time to work on it.. -- Takeshi From merlin at studiobz.it Sun Feb 1 18:37:01 2004 From: merlin at studiobz.it (Christian Zoffoli) Date: Sun Feb 1 18:37:01 2004 Subject: ASUS A7M266-D Message-ID: <401D90A7.7070301@studiobz.it> 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 From ebiederman at lnxi.com Sun Feb 1 18:44:01 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Sun Feb 1 18:44:01 2004 Subject: Handling interrupt routing cleanly... Message-ID: 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 From ebiederman at lnxi.com Sun Feb 1 19:04:01 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Sun Feb 1 19:04:01 2004 Subject: ASUS A7M266-D In-Reply-To: <401D90A7.7070301@studiobz.it> References: <401D90A7.7070301@studiobz.it> Message-ID: Christian Zoffoli writes: > Hi to all. > > Does anyone know how to make that mobo work with linuxbios? ...I can't cleanly > build a linuxbios image. That port never fully worked. It was checked in because it had parts that were close but the SPD never worked. As to while it no longer compiles is an interesting question. I'd suggest looking through the assembly error messages and see what definition is missing. Eric From ebiederman at lnxi.com Sun Feb 1 19:13:00 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Sun Feb 1 19:13:00 2004 Subject: Handling interrupt routing cleanly... In-Reply-To: References: Message-ID: ebiederman at lnxi.com (Eric W. Biederman) writes: > 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. Thinking about this a little more open firmware defines one single root for it's interrupt tree, even if it must be purely virtual. A simple extension of that idea is to have one root for each interrupt processing mode. And each node should be able to define multiple interrupt parents. That should be sufficient to handle the LinuxBIOS case. That leaves a lot of details to handle but it should work. Eric From stepan at suse.de Sun Feb 1 19:50:00 2004 From: stepan at suse.de (Stefan Reinauer) Date: Sun Feb 1 19:50:00 2004 Subject: Handling interrupt routing cleanly... In-Reply-To: References: Message-ID: <20040202010208.GA30394@suse.de> * Eric W. Biederman [040202 00:59]: > Stefan how close is the open firmware code that we could > test a port to generic LinuxBIOS. With the LinuxBIOS table > providing this information? I don't read the LinuxBIOS table yet, but support should be easy to implement. OpenBIOS has been running on LinuxBIOS and grub on x86 and amd64. It can also be used in MacOnLinux (MOL) to boot macos and Linux. Find the latest tree on bitkeeper: bk clone bk://openbios.bkbits.net/unstable Stefan From ebiederman at lnxi.com Mon Feb 2 02:22:01 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Feb 2 02:22:01 2004 Subject: Handling interrupt routing cleanly... In-Reply-To: <20040202010208.GA30394@suse.de> References: <20040202010208.GA30394@suse.de> Message-ID: Stefan Reinauer writes: > * Eric W. Biederman [040202 00:59]: > > Stefan how close is the open firmware code that we could > > test a port to generic LinuxBIOS. With the LinuxBIOS table > > providing this information? > > I don't read the LinuxBIOS table yet, but support should be easy to > implement. OpenBIOS has been running on LinuxBIOS and grub on x86 and > amd64. It can also be used in MacOnLinux (MOL) to boot macos and Linux. Cool so you are getting close. > Find the latest tree on bitkeeper: > > bk clone bk://openbios.bkbits.net/unstable Is there any other way. I'm not allowed to use the free version of bk. Eric From stepan at suse.de Mon Feb 2 09:55:01 2004 From: stepan at suse.de (Stefan Reinauer) Date: Mon Feb 2 09:55:01 2004 Subject: Handling interrupt routing cleanly... In-Reply-To: References: <20040202010208.GA30394@suse.de> Message-ID: <20040202145124.GB6154@suse.de> * Eric W. Biederman [040202 08:38]: > > I don't read the LinuxBIOS table yet, but support should be easy to > > implement. OpenBIOS has been running on LinuxBIOS and grub on x86 and > > amd64. It can also be used in MacOnLinux (MOL) to boot macos and Linux. > > Cool so you are getting close. Indeed. Nonetheless some things are missing: * there is no interrupt handling code doing the things you described * the ide driver is not fully working yet * boot support is incomplete on x86 and amd64 * there is no pci driver/device node yet * there is no linuxbios table parsing yet * lots of things with less priority > > Find the latest tree on bitkeeper: > > > > bk clone bk://openbios.bkbits.net/unstable > > Is there any other way. I'm not allowed to use the free > version of bk. I've enabled a snapshot to be created every 4h at http://www.openbios.org/snapshots/ for now. There will probably be an arch repository for openbios soon. Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From merlin at studiobz.it Mon Feb 2 16:06:01 2004 From: merlin at studiobz.it (Christian Zoffoli) Date: Mon Feb 2 16:06:01 2004 Subject: ASUS A7M266-D In-Reply-To: References: <401D90A7.7070301@studiobz.it> Message-ID: <401EBECC.60103@studiobz.it> Eric W. Biederman wrote: > Christian Zoffoli writes: > > >>Hi to all. >> >>Does anyone know how to make that mobo work with linuxbios? ...I can't cleanly >>build a linuxbios image. > > > That port never fully worked. It was checked in because it > had parts that were close but the SPD never worked. As to while > it no longer compiles is an interesting question. > > I'd suggest looking through the assembly error messages and see > what definition is missing. I desperatly need make 4 Asus A7M266-D work with linuxbios ...so I'll start working on the code at the end of February ...I hope that the list could point me in the right direction :) Christian From ebiederman at lnxi.com Mon Feb 2 17:29:00 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Feb 2 17:29:00 2004 Subject: ASUS A7M266-D In-Reply-To: <401EBECC.60103@studiobz.it> References: <401D90A7.7070301@studiobz.it> <401EBECC.60103@studiobz.it> Message-ID: Christian Zoffoli writes: > Eric W. Biederman wrote: > > Christian Zoffoli writes: > > > >>Hi to all. > >> > >>Does anyone know how to make that mobo work with linuxbios? ...I can't cleanly > > >>build a linuxbios image. > > That port never fully worked. It was checked in because it > > had parts that were close but the SPD never worked. As to while > > it no longer compiles is an interesting question. > > I'd suggest looking through the assembly error messages and see > > what definition is missing. > > I desperatly need make 4 Asus A7M266-D work with linuxbios ...so I'll start > working on the code at the end of February ...I hope that the list could point > me in the right direction :) If you can find what logic is multiplexing the smbus you can likely succeed in a port. A less beautiful option is to hard code the SPD information for a particular set of DIMMs. That was the big bottleneck as I recall it from ages ago. Eric From ebiederman at lnxi.com Tue Feb 3 13:51:01 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Feb 3 13:51:01 2004 Subject: OpenFirmware and interrupt-map In-Reply-To: <401FE325.4010104@sun.com> References: <401EE302.7070201@sun.com> <401FE325.4010104@sun.com> Message-ID: There are some interesting points of comparing experience between Open firmware and LinuxBIOS so I am copying the list. Tarl Neustaedter writes: > Eric W. Biederman wrote: > > Tarl Neustaedter 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 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 From rminnich at lanl.gov Tue Feb 3 17:04:00 2004 From: rminnich at lanl.gov (ron minnich) Date: Tue Feb 3 17:04:00 2004 Subject: OpenFirmware and interrupt-map In-Reply-To: Message-ID: On 3 Feb 2004, Eric W. Biederman wrote: > > 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 :) I don't expect the cards to come with fcode any time soon, if ever. Four reasons: first, the market is more or less zero, and the all the non-x86 systems support x86 emulators to support the x86 option roms; second, if they support two option roms (fcode, x86) that makes for lots more work; third, the PC market will probably never go to fcode; and fourth, I bet they (naively) think that fcode would make reverse engineering easier. ron From rminnich at lanl.gov Tue Feb 3 17:21:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Tue Feb 3 17:21:01 2004 Subject: OpenFirmware and interrupt-map (fwd) Message-ID: 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 To: ron minnich Cc: Eric W. Biederman , LinuxBIOS 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 From Tarl.Neustaedter at sun.com Tue Feb 3 18:52:00 2004 From: Tarl.Neustaedter at sun.com (Tarl Neustaedter) Date: Tue Feb 3 18:52:00 2004 Subject: [Fwd: Re: OpenFirmware and interrupt-map] Message-ID: <40203761.9050101@sun.com> [ 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 From rminnich at lanl.gov Tue Feb 3 19:26:00 2004 From: rminnich at lanl.gov (ron minnich) Date: Tue Feb 3 19:26:00 2004 Subject: [Fwd: Re: OpenFirmware and interrupt-map] In-Reply-To: <40203761.9050101@sun.com> Message-ID: On Tue, 3 Feb 2004, Tarl Neustaedter wrote: > 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. You've just described the entire case for linuxbios we started with years ago :-) So I am very happy to see it might make some sense :-) > 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. ow. ow. ow. Not with Infiniband, at least not yet ... Is the price difference really that big? ron From ebiederman at lnxi.com Tue Feb 3 21:27:01 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Feb 3 21:27:01 2004 Subject: OpenFirmware and interrupt-map In-Reply-To: References: Message-ID: ron minnich writes: > I don't expect the cards to come with fcode any time soon, if ever. Four > reasons: first, the market is more or less zero, and the all the non-x86 > systems support x86 emulators to support the x86 option roms; For video. Does any one support anything else? RAID cards? > second, > if they support two option roms (fcode, x86) that makes for lots more > work; third, the PC market will probably never go to fcode; and fourth, I > bet they (naively) think that fcode would make reverse engineering easier. Yes, there are reasons it is unlikely to happen and those are reasons I really have not done much. Stefan believes in it so I think it makes a good test case of what we can support in LinuxBIOS. Mostly this is if I had to support the interface it would not suck to support :) What I am actually thinking is the long term solution is to just use everyones driver disks (or the equivalent) for linux and if the BIOS does not contain the drivers you need it is just a rebuild of your boot loader away. Yes this means you have to boot your system once to load the driver for your new cool boot device but that should always be possible. Eric From ebiederman at lnxi.com Tue Feb 3 21:30:01 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Feb 3 21:30:01 2004 Subject: [Fwd: Re: OpenFirmware and interrupt-map] In-Reply-To: References: Message-ID: ron minnich writes: > On Tue, 3 Feb 2004, Tarl Neustaedter wrote: > > 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. > > ow. ow. ow. Not with Infiniband, at least not yet ... I can believe that reflects anything but the poor quality of the IB stack and IB drivers. Rom how big are the drivers you are using. And how big is that with compression? > Is the price difference really that big? It is difficult to obtain larger than 1 megabyte. 2 Megabyte parts are advertised but they are difficult to get. And multiple parts lead to more complexity. Eric From ebiederman at lnxi.com Tue Feb 3 21:38:01 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Feb 3 21:38:01 2004 Subject: [Fwd: Re: OpenFirmware and interrupt-map] In-Reply-To: <40203761.9050101@sun.com> References: <40203761.9050101@sun.com> Message-ID: Tarl Neustaedter writes: > [ 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. Sounds right. There is still some development needed to get the core kernel nice and tight. And in cases like Infiniband someone needs to write some good drivers... > > 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. 1MB should be doable. Look at the 2.6 kernel tiny patch it really helps get the size down. My target is something usable in 512KB. For sake of doing calculations figure LinuxBIOS takes 128K (with two copies) in the rom chip. Look at the MTD drivers for flashing the prom. Look at kexec for loading a new kernel. > > 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. See above for the pieces I have found so far. I am in the middle of bringing up a board so I don't know what kind of time frame I really have to work with on the bootloader stuff. > 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. Yes the secrecy aspect of the video card manufacturers how to cope and then how to over come it is one of our more interesting hurdles. > 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. Ouch. Although it is good to see that so many people actually played with open firmware. > 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. Right. Usually video card vendors leave off the little bit to actually turn on their cards out of the Linux drivers so any little driver that gets the thing working is enough for the linux drivers to take it the rest of the way. Eric From rminnich at lanl.gov Tue Feb 3 22:36:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Tue Feb 3 22:36:01 2004 Subject: OpenFirmware and interrupt-map In-Reply-To: Message-ID: On 3 Feb 2004, Eric W. Biederman wrote: > For video. Does any one support anything else? RAID cards? Not sure on PPC. The Alpha doesn't matter any more but my memory says that if you put a card with an option rom on the Alpha it would run the ROM. But that's very old memory. ron From ebiederman at lnxi.com Wed Feb 4 04:08:00 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 4 04:08:00 2004 Subject: Config language progress/issues... Message-ID: 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 From stepan at suse.de Wed Feb 4 08:40:01 2004 From: stepan at suse.de (Stefan Reinauer) Date: Wed Feb 4 08:40:01 2004 Subject: Handling interrupt routing cleanly... In-Reply-To: References: Message-ID: <20040204135340.GA4954@suse.de> * Eric W. Biederman [040202 01:28]: > Thinking about this a little more open firmware defines one > single root for it's interrupt tree, even if it must be purely > virtual. > > A simple extension of that idea is to have one root for each > interrupt processing mode. And each node should be able to define > multiple interrupt parents. That should be sufficient to handle > the LinuxBIOS case. > > That leaves a lot of details to handle but it should work. I'm not sure if I get you right... is this because the available interrupts can be spread over all the busses and IOAPICs? Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From stepan at suse.de Wed Feb 4 09:19:01 2004 From: stepan at suse.de (Stefan Reinauer) Date: Wed Feb 4 09:19:01 2004 Subject: OpenFirmware and interrupt-map In-Reply-To: References: <401EE302.7070201@sun.com> <401FE325.4010104@sun.com> Message-ID: <20040204143134.GD4954@suse.de> CCing the OpenBIOS mailinglist. * Eric W. Biederman [040203 20:07]: > Tarl Neustaedter writes: > > > Eric W. Biederman wrote: > > > Tarl Neustaedter 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. :-) That is good to know. There will be a lot of things to clarify when the base implementation of OpenBIOS is complete and operable. > > 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. One big problem in the picture is that there is a certain amount of hardware that assumes firmware did a job before running the linux driver. So basically there is no real way around having an x86 option rom. It seems. Intel is trying to break out and move firmware developers to their EFI bytecode, which does the same thing OpenFirmware FCode does, just with the need of 4*8MBit Flash to store all of the virtual machine in (An OpenBIOS+LinuxBIOS solution easily fits in 2MBit) I've dropped the illusion of getting convinced some day that EFI is the way to go, but if there's a wave of change now anyway, it's high time for some educational advertising of using "long term industry proven standards" instead of KUAI-Implementations. I don't see it all that negative for FCode firmware in option roms. It's just not going to happen in small numbers. For this to happen, there have to be _many_many_many_ machines with an IEEE 1275 compliant boot firmware. Such a system could for example still use expansion cards with x86 pcbios compliant option roms - Generating the needed OpenFirmware wrapper nodes based on the device type (display, block, ... ) is no magic once the initialization of the device itself is done. This would allow to use such cards in an open firmware environment while the OS can rely on the fact that there is a device that can be operated using the Open Firmware interface. > Interesting. The observation that powerful firmware eventually > becomes an OS so you might as well use an OS, seems true :) If you use EFI, you even get all the old DOS tools. > 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. OpenBIOS is currently only reusing filesystem drivers from grub, but an interface for network booting so that etherboot drivers can be used should not overtop the fs efforts a lot. > 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. This is not true for many Opteron boards, ie those coming with the LSI 1020/1030 scsi controllers. There might be a fix for this on the horizon, but it only solves the problem for this specific controller. If there is a way to clean out these issues generically without having to think in terms of single controller or video cards, we should definitely provide this as an option. > 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. Apple succeeded by putting all of the actual driver code in a special property of the device node, and have the fcode rom not initialize the device but just create the device node. A good example of how _not_ to do it. Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From stepan at suse.de Wed Feb 4 09:32:00 2004 From: stepan at suse.de (Stefan Reinauer) Date: Wed Feb 4 09:32:00 2004 Subject: OpenFirmware and interrupt-map In-Reply-To: References: Message-ID: <20040204143831.GE4954@suse.de> * ron minnich [040203 22:46]: > I don't expect the cards to come with fcode any time soon, if ever. Four > reasons: first, the market is more or less zero, and the all the non-x86 > systems support x86 emulators to support the x86 option roms; second, > if they support two option roms (fcode, x86) that makes for lots more > work; third, the PC market will probably never go to fcode; and fourth, I > bet they (naively) think that fcode would make reverse engineering easier. I fully agree that using ndisasm is by no means more complicated than using my fcode detokenizer detok. All x86/efi option rom discussion sounds rather like a game of not stepping on the others' toes rather than technologically driven reasoning. OpenBIOS can be used on top of a PC BIOS as well, thus it could allow to use any Open Firmware compliant pci card in a machine that still has different firmware in rom. This is one step towards the great unification.. If the concept of having a diversity of hardware architectures available is going to survive, there has to be a generic solution to the early initialization issues. Best regards, Stefan Reinauer -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From stepan at suse.de Wed Feb 4 09:42:01 2004 From: stepan at suse.de (Stefan Reinauer) Date: Wed Feb 4 09:42:01 2004 Subject: OpenFirmware and interrupt-map In-Reply-To: References: Message-ID: <20040204145242.GC17814@suse.de> * ron minnich [040204 04:49]: > On 3 Feb 2004, Eric W. Biederman wrote: > > > For video. Does any one support anything else? RAID cards? > > Not sure on PPC. The Alpha doesn't matter any more but my memory says that > if you put a card with an option rom on the Alpha it would run the ROM. > But that's very old memory. Yes, the Alpha was able to initialize RAID/SCSI x86 option roms. SRM was even defining an os callback to execute intXX calls from a running operating system. Unfortunately it was never implemented. Best regards, Stefan Reinauer -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From stepan at suse.de Wed Feb 4 10:38:00 2004 From: stepan at suse.de (Stefan Reinauer) Date: Wed Feb 4 10:38:00 2004 Subject: [Fwd: Re: OpenFirmware and interrupt-map] In-Reply-To: References: Message-ID: <20040204154218.GE17814@suse.de> * Eric W. Biederman [040204 03:47]: > > Is the price difference really that big? > > It is difficult to obtain larger than 1 megabyte. 2 Megabyte parts > are advertised but they are difficult to get. And multiple parts > lead to more complexity. Not to talk about the problems we've seen with some 8MBit parts.. Best regards, Stefan Reinauer -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From rminnich at lanl.gov Wed Feb 4 12:10:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Wed Feb 4 12:10:01 2004 Subject: OpenFirmware and interrupt-map In-Reply-To: <20040204143831.GE4954@suse.de> Message-ID: On Wed, 4 Feb 2004, Stefan Reinauer wrote: > If the concept of having a diversity of hardware architectures available > is going to survive, there has to be a generic solution to the early > initialization issues. I agree completely. It is sad that the generic solution so far is x86 instructions. We can hope this improves, but I am pessimistic. ron From rminnich at lanl.gov Wed Feb 4 12:12:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Wed Feb 4 12:12:01 2004 Subject: [Fwd: Re: OpenFirmware and interrupt-map] In-Reply-To: <20040204154218.GE17814@suse.de> Message-ID: I am told that the big consumers of flash parts are MP3 players. The market there demands ever bigger parts. This was the reason why in 1999 we hoped that FLASH parts would grow. The big "make flash grow" driver in the PC world is the desire to for DRM in the bios. So we may still get those big BIOS parts, for reasons we don't like. ron From Tarl.Neustaedter at sun.com Wed Feb 4 12:32:01 2004 From: Tarl.Neustaedter at sun.com (Tarl Neustaedter) Date: Wed Feb 4 12:32:01 2004 Subject: [Fwd: Re: OpenFirmware and interrupt-map] In-Reply-To: References: Message-ID: <40212FAF.10803@sun.com> ron minnich wrote: > [...] Better if we can fit it in a 1MB prom, however. > > ow. ow. ow. Not with Infiniband, at least not yet ... > > Is the price difference really that big? The issue is usually one of part availability and square millimeters. On the SPARC platforms, we've usually gotten larger proms than PCs would have, but it's been a struggle with the hardware team every time - we (firmware) always want more code space, the hardware team al. With the Opteron-based systems, there is a good chance we'll be using LPC-type parts, and nobody is bothering to manufacture large PROMs in that technology yet. As for infiniband drivers, I lead the team which wrote the OpenFirmware drivers for sun, and they aren't that large. FCode is a *very* compact programming language. To give you an idea, the driver for the HCA is 35K, the driver for SRP (disk over infiniband) is 16K (both values are compressed, but with old-fashioned "compress"). The IPoIB driver was added as an integral part of the obptftp driver, and that's 20K total. I don't have comparable information about the Linux binaries yet. We have Solaris drivers we wrote in-house, but they are tied into SVR4's streams and Sun's DDI interfaces, and not easily portable to Linux. We are likely to use an external vendor's Linux drivers, and I'll probably know their sizes fairly soon - giving me my first pass at feasability numbers. [ Stefan Reinauer, on divergence of vendor's OpenFirmware ] > With Hypertransport, Infiniband and other technologies, there might > awake some demand for new supplements. Competing with EFI, Open Firmware > should have at least recommendations on how to cope with this divergence > (which is a natural fact looking at the number of contributors) Yah. We're continuing the write these kinds of documents (e.g., I wrote the IEEE 1275/Infiniband binding), but we no longer really have a forum in which to share them between companies. The last one I wrote that got published was the 1394 (Firewire) binding, which was several years ago. There had been interest expressed by from HP and IBM in the infiniband bindings, but it's been years since I heard any further - and nowadays I'd probably have to check with Sun Legal before exporting such a document. Sigh. We haven't written an IEEE-1275/Hypertransport binding, largely because we haven't had HT on a SPARC. The Opteron stuff is quite recent (I recall we announced the alliance with AMD last november), and not all the implications have finished dribbling through our engineering organizations. From kevin at koconnor.net Wed Feb 4 13:31:01 2004 From: kevin at koconnor.net (Kevin O'Connor) Date: Wed Feb 4 13:31:01 2004 Subject: OpenFirmware and interrupt-map In-Reply-To: References: <20040204143831.GE4954@suse.de> Message-ID: <20040204184405.GA2801@arizona.localdomain> On Wed, Feb 04, 2004 at 10:23:17AM -0700, ron minnich wrote: > On Wed, 4 Feb 2004, Stefan Reinauer wrote: > > > If the concept of having a diversity of hardware architectures available > > is going to survive, there has to be a generic solution to the early > > initialization issues. > > I agree completely. It is sad that the generic solution so far is x86 > instructions. Actually, I think the generic solution has been to not use option roms at all. :-) After all, most cards don't use them (VGA being the notable exception). Frankly, if I had any pull with manufactures or vendors, I'd try to convince them to avoid option roms instead of trying to convince them to support a different option rom format. Having cards that conform to standards (or can emulate them during bootup) will be a lot more productive IMO, then a cross platform byte code. -Kevin -- --------------------------------------------------------------------- | Kevin O'Connor "BTW, IMHO we need a FAQ for | | kevin at koconnor.net 'IMHO', 'FAQ', 'BTW', etc. !" | --------------------------------------------------------------------- From Tarl.Neustaedter at sun.com Wed Feb 4 13:56:01 2004 From: Tarl.Neustaedter at sun.com (Tarl Neustaedter) Date: Wed Feb 4 13:56:01 2004 Subject: OpenFirmware and interrupt-map In-Reply-To: <20040204143134.GD4954@suse.de> References: <401EE302.7070201@sun.com> <401FE325.4010104@sun.com> <20040204143134.GD4954@suse.de> Message-ID: <40214364.4030507@sun.com> Stefan Reinauer wrote: [...] > So basically there is no real way around having an x86 option rom. It > seems. Intel is trying to break out and move firmware developers to > their EFI bytecode, which does the same thing OpenFirmware FCode does, > just with the need of 4*8MBit Flash to store all of the virtual machine Actually, my understanding is that the multi-megabyte flash is only required for the IA-64 implementation. The IA-32 implementation of EFI from some vendors is reported to fit comfortably in 1MB. One thing we've discovered recently is that the x86 firmware world is rife in rumors, FUD, and propaganda. It's pretty startling. > I've dropped the illusion of getting convinced some day that EFI is the > way to go, It certainly looks good; they seem to have learned a bunch of lessons from the OpenFirmware experience. Unfortunately, we got stopped by license issues - to go any further than just the basic spec, there is a "click to agree" license button on the web page which our legal team told us not to click. > I don't see it all that negative for FCode firmware in option roms. It's > just not going to happen in small numbers. For this to happen, there > have to be _many_many_many_ machines with an IEEE 1275 compliant boot > firmware. Sun pushed for this for many years; the IEEE 1275 specification and firmworks.com were both funded by Sun exporting technology they had developed in the early '90s, with an eye to moving the industry along in this direction. It sputtered along with minimal industry acceptance and largely fizzled out before 2000. The specification (IEEE 1275-1994) is now obsolete; it's supposed to be renewed every five years, and there just wasn't the funding and interest level to get it done. We still use the specification in our day-to-day operations, but I don't think IEEE will even sell copies any more. If you can revive interest in OpenFirmware, I'll be delighted. My personal opinion is that it's a sisyphean task, but don't let that stop you :-) Tarl Neustaedter From Tarl.Neustaedter at sun.com Wed Feb 4 14:01:00 2004 From: Tarl.Neustaedter at sun.com (Tarl Neustaedter) Date: Wed Feb 4 14:01:00 2004 Subject: Handling interrupt routing cleanly... In-Reply-To: <20040204135340.GA4954@suse.de> References: <20040204135340.GA4954@suse.de> Message-ID: <402144B6.5020404@sun.com> Stefan Reinauer wrote: > * Eric W. Biederman [040202 01:28]: > >>Thinking about this a little more open firmware defines one >>single root for it's interrupt tree, even if it must be purely >>virtual. I seem to be dropping into this conversation late; What do you mean that there is a single root for the interrupt tree? The interrupt-map stuff can point to interrupt owners anywhere in the tree; The common case I've run into is a system which has on-board devices with the interrupts routed to an interrupt controller on a PCI bridge. Since the on-board devices are frequently either children of a different PCI bus or occasionally not under a PCI bus at all, we need to use the interrupt-map property to say "use interrupt #17 under that chip over there". From Tarl.Neustaedter at sun.com Wed Feb 4 14:25:00 2004 From: Tarl.Neustaedter at sun.com (Tarl Neustaedter) Date: Wed Feb 4 14:25:00 2004 Subject: Handling interrupt routing cleanly... In-Reply-To: <402144B6.5020404@sun.com> References: <20040204135340.GA4954@suse.de> <402144B6.5020404@sun.com> Message-ID: <40214A32.9060809@sun.com> > I seem to be dropping into this conversation late; What do you > mean that there is a single root for the interrupt tree? Ah. Never mind, I found it: Eric W. Biederman wrote: [...] > Each device has it's interrupt. Plural. We have a number of devices which generate multiple interrupts. On PCI, that usually means being constrained to four interrupts, but for on-board devices we can deal with whole bunches of interrupt lines per device. > Each device has an interrupt parent. > If not specified explicitly the interrupt parent is simply up > the device tree but that was not required. Device-tree parent is default, but 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. It allows routing interrupts to anywhere else in the device tree. This construct was added explicitly because of hardware engineer's tendency to build boards which route interrupts differently than the datapaths, and we needed some way to deal with it. Since they weren't going to constrain themselves to a hierarchical structure for interrupts, we couldn't constrain the interrupt-map, either. From rminnich at lanl.gov Wed Feb 4 14:29:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Wed Feb 4 14:29:01 2004 Subject: OpenFirmware and interrupt-map In-Reply-To: <20040204184405.GA2801@arizona.localdomain> Message-ID: On Wed, 4 Feb 2004, Kevin O'Connor wrote: > Frankly, if I had any pull with manufactures or vendors, I'd try to > convince them to avoid option roms instead of trying to convince them to > support a different option rom format. True. But vendors often hide hardware bug fixes in option roms. Just FYI, we just now got an Nvidia agp card to initialize and work much better with the emulator, in the agp slot, on the tyan s2885. We get the little nvidia startup message, and then the vga console works. We have a bit of fixup to do now in linuxbios for the things we found, including some MTRR and northbridge stuff. But it is nice to see it getting that far. ron From rminnich at lanl.gov Wed Feb 4 14:32:00 2004 From: rminnich at lanl.gov (ron minnich) Date: Wed Feb 4 14:32:00 2004 Subject: OpenFirmware and interrupt-map In-Reply-To: <40214364.4030507@sun.com> Message-ID: On Wed, 4 Feb 2004, Tarl Neustaedter wrote: > Actually, my understanding is that the multi-megabyte flash is only > required for the IA-64 implementation. The IA-32 implementation of EFI > from some vendors is reported to fit comfortably in 1MB. that may change when people start to use it, not sure. Some of the Intel boards we got recently had really large flash parts. > One thing we've discovered recently is that the x86 firmware world > is rife in rumors, FUD, and propaganda. It's pretty startling. it's pretty weird. I've gotten all kinds of strange stuff from different places :-) > It certainly looks good; they seem to have learned a bunch of lessons > from the OpenFirmware experience. Unfortunately, we got stopped by > license issues - to go any further than just the basic spec, there is a > "click to agree" license button on the web page which our legal team > told us not to click. and that's the way it will stay, I'm told. I'm unhappy with a bios that needs CHKDSK in any event. ron From rminnich at lanl.gov Wed Feb 4 14:49:00 2004 From: rminnich at lanl.gov (ron minnich) Date: Wed Feb 4 14:49:00 2004 Subject: vga emulator new version Message-ID: I've got the newest working version of the emulator for anyone who wants to try it. This won't work on K8 systems minus some hacks, due to K8 differences, contact me if interested. ron From rminnich at lanl.gov Wed Feb 4 15:11:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Wed Feb 4 15:11:01 2004 Subject: Config language progress/issues... In-Reply-To: Message-ID: On 4 Feb 2004, Eric W. Biederman wrote: > 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 I think there is a simpler fix to that. We had talked about making all options deferred evaluation, i.e. not evaluted until used. I think this might have helped with many of these problems. > 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. I see your point. Part of this is different thinking about the role of the various files. As the tool evolved we somehow ended up with lots of stuff in the target file (you call it the outermost config file) which is not really ideal. To me, the right place for most of the stuff is the mainboard file. That's actually how the earlier config tool ended up working. Target files represent a specialization of the mainboard file, and some options may change, but as we have all seen putting it all in the target file is high maintenance, since a simple change to a mainboard propagates through all the target files. The present of an 'if' in Config.lb is something interesting, which I admit I had not anticipated. OK, more looking. I know you have advocated a 2-pass tool, and you know I am not convinced for the need; I figure if Pascal and Modula-X can run one-pass, a simple Config tool should be able to as well. But we'll talk more here. ron From rminnich at lanl.gov Wed Feb 4 15:18:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Wed Feb 4 15:18:01 2004 Subject: [Fwd: Re: OpenFirmware and interrupt-map] In-Reply-To: Message-ID: On 3 Feb 2004, Eric W. Biederman wrote: > Rom how big are the drivers you are using. And how big is > that with compression? Old data, from last year, showed our mvapi drivers on a mellanox blade system at several Mbytes. > It is difficult to obtain larger than 1 megabyte. 2 Megabyte parts > are advertised but they are difficult to get. cell phones, mpeg players :-) ron From prl at peterlister.co.uk Wed Feb 4 18:19:00 2004 From: prl at peterlister.co.uk (Peter Lister) Date: Wed Feb 4 18:19:00 2004 Subject: OpenFirmware and interrupt-map In-Reply-To: <20040204143134.GD4954@suse.de> References: <401EE302.7070201@sun.com> <401FE325.4010104@sun.com> <20040204143134.GD4954@suse.de> Message-ID: <1075937554.10050.1065.camel@eddie> On Wed, 2004-02-04 at 14:31, Stefan Reinauer wrote: > OpenBIOS is currently only reusing filesystem drivers from grub, but > an interface for network booting so that etherboot drivers can be used > should not overtop the fs efforts a lot. Digressing slightly, please note that Etherboot is more than just the drivers - there is a significant amount of network code (now even TCP if one wants it), and it would benefit us all to share as much as possible; there is, for instance, an NFS client already. For some reason best known to themselves, the GRUB developers decided to use only Etherboot's drivers and brew their own network code. The result is that GRUB netboot is now lagging noticeably behind Etherboot in functionality, drivers etc - GRUB people now discuss "porting" Etherboot drivers, which is disappointing (have a look at the GRUB support forum and FAQ to see how little help there is on the network code compared to disk and fs). It would have made far more sense to co-operate on an open firmware network API, but hey ho... I'd like to see this happening fairly soon, so that any driver created for Etherboot immediately works with GRUB. So I encourage OpenBIOS to peacefully co-exist with GRUB and Etherboot rather than fork which is not a good way to encourage driver writers. BTW, there is work now on implementing PXE on top of Etherboot - pxelinux has already been demonstrated on top of Etherboot. This may force the issue somewhat, since even if PXE isn't the API one wants, it will at least help focus people into deciding what APIs they *do* want. From ebiederman at lnxi.com Wed Feb 4 18:21:39 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 4 18:21:39 2004 Subject: Config language progress/issues... In-Reply-To: References: Message-ID: ron minnich writes: > On 4 Feb 2004, Eric W. Biederman wrote: > > > 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 > > I think there is a simpler fix to that. We had talked about making all > options deferred evaluation, i.e. not evaluted until used. I think this > might have helped with many of these problems. Right, and the version I have and I just committed to the public tree does delayed evaluation for everything but if statements. I think delayed evaluation is a fine technique. > > 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. > > I see your point. Part of this is different thinking about the role of the > various files. > > As the tool evolved we somehow ended up with lots of stuff in the target > file (you call it the outermost config file) which is not really ideal. To > me, the right place for most of the stuff is the mainboard file. > That's actually how the earlier config tool ended up > working. Target files represent a specialization of the mainboard > file, and some options may change, but as we have all seen putting > it all in the target file is high maintenance, since a simple > change to a mainboard propagates through all the target files. That is how I view the configuration files as well. The problem is that there are some options I can't move. > The present of an 'if' in Config.lb is something interesting, which I > admit I had not anticipated. To be clear the are in generic configuration files included by Config.lb but the behaviour is the same. > OK, more looking. I know you have advocated a 2-pass tool, and you know I > am not convinced for the need; I figure if Pascal and Modula-X can run > one-pass, a simple Config tool should be able to as well. But we'll talk > more here. The delayed evaluation is fine with me. But Pascal and Modual-X use delayed evaluation in the one pass model. They don't actually run the program they compile in that first pass :) Even C can be compiled in a single pass. Right now everything works but if statements. The parser could easily pass the conditionals into the statements that are conditional on if's. The challenge is simply manipulating those constants. If if statements did not nest it would be a much simpler problem. Eric From ebiederman at lnxi.com Wed Feb 4 18:25:01 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 4 18:25:01 2004 Subject: OpenFirmware and interrupt-map In-Reply-To: <20040204145242.GC17814@suse.de> References: <20040204145242.GC17814@suse.de> Message-ID: Stefan Reinauer writes: > * ron minnich [040204 04:49]: > > On 3 Feb 2004, Eric W. Biederman wrote: > > > > > For video. Does any one support anything else? RAID cards? > > > > Not sure on PPC. The Alpha doesn't matter any more but my memory says that > > if you put a card with an option rom on the Alpha it would run the ROM. > > But that's very old memory. > > Yes, the Alpha was able to initialize RAID/SCSI x86 option roms. SRM was > even defining an os callback to execute intXX calls from a running > operating system. Unfortunately it was never implemented. 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. Eric From rminnich at lanl.gov Wed Feb 4 18:26:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Wed Feb 4 18:26:01 2004 Subject: OpenFirmware and interrupt-map In-Reply-To: Message-ID: 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 From ebiederman at lnxi.com Wed Feb 4 18:28:01 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 4 18:28:01 2004 Subject: OpenFirmware and interrupt-map In-Reply-To: <20040204184405.GA2801@arizona.localdomain> References: <20040204143831.GE4954@suse.de> <20040204184405.GA2801@arizona.localdomain> Message-ID: "Kevin O'Connor" writes: > Actually, I think the generic solution has been to not use option roms at > all. :-) After all, most cards don't use them (VGA being the notable > exception). Agreed. > Frankly, if I had any pull with manufactures or vendors, I'd try to > convince them to avoid option roms instead of trying to convince them to > support a different option rom format. Yes. There are cases where multiple vendors need some input on what the firmware is doing and in those cases option roms come into play. So for high enough volumes the firmware simply can't be solely controlled by the board vendors. This does not make option roms the only business solution but one of them. > Having cards that conform to standards (or can emulate them during bootup) > will be a lot more productive IMO, then a cross platform byte code. That is the one place where it is the hardest. Usually hardware can be put into an emulation mode but only after it is initialized. I believe one of the important functions of an option roms on video cards is to turn on the memory for the video card. Eric From ebiederman at lnxi.com Wed Feb 4 18:35:01 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 4 18:35:01 2004 Subject: OpenFirmware and interrupt-map In-Reply-To: <40214364.4030507@sun.com> References: <401EE302.7070201@sun.com> <401FE325.4010104@sun.com> <20040204143134.GD4954@suse.de> <40214364.4030507@sun.com> Message-ID: Tarl Neustaedter writes: > Stefan Reinauer wrote: > [...] > > So basically there is no real way around having an x86 option rom. It > > seems. Intel is trying to break out and move firmware developers to > > their EFI bytecode, which does the same thing OpenFirmware FCode does, > > just with the need of 4*8MBit Flash to store all of the virtual machine > > Actually, my understanding is that the multi-megabyte flash is only > required for the IA-64 implementation. The IA-32 implementation of EFI > from some vendors is reported to fit comfortably in 1MB. The EFI guys have been working really hard to get their footprint down. IA-64 native code gives you an automatic 3x code bloat so it trivially requires 3x more rom space. > One thing we've discovered recently is that the x86 firmware world > is rife in rumors, FUD, and propaganda. It's pretty startling. > > I've dropped the illusion of getting convinced some day that EFI is the > > way to go, > > It certainly looks good; they seem to have learned a bunch of > lessons from the OpenFirmware experience. Unfortunately, we > got stopped by license issues - to go any further than just the > basic spec, there is a "click to agree" license button on the > web page which our legal team told us not to click. They missed the simplicity part. But they did at least spec something that did not use interrupts. OF was not picked at least in part because they did not want to dilute ACPI. Eric From ebiederman at lnxi.com Wed Feb 4 18:43:01 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 4 18:43:01 2004 Subject: Handling interrupt routing cleanly... In-Reply-To: <40214A32.9060809@sun.com> References: <20040204135340.GA4954@suse.de> <402144B6.5020404@sun.com> <40214A32.9060809@sun.com> Message-ID: Tarl Neustaedter writes: > > I seem to be dropping into this conversation late; What do you > > mean that there is a single root for the interrupt tree? > > Ah. Never mind, I found it: > > Eric W. Biederman wrote: > [...] > > Each device has it's interrupt. > > Plural. We have a number of devices which generate multiple interrupts. > On PCI, that usually means being constrained to four interrupts, but > for on-board devices we can deal with whole bunches of interrupt lines > per device. That part I could not quite understand when reading the OF spec. How you can have multiple values per property. Base address registers seemed to have the same problem. > > Each device has an interrupt parent. > > If not specified explicitly the interrupt parent is simply up > > the device tree but that was not required. > > Device-tree parent is default, but not required. What I was saying. > > 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. > > It allows routing interrupts to anywhere else in the device > tree. This construct was added explicitly because of hardware > engineer's tendency to build boards which route interrupts > differently than the datapaths, and we needed some way to > deal with it. Since they weren't going to constrain themselves > to a hierarchical structure for interrupts, we couldn't > constrain the interrupt-map, either. Right, and the same applies to today boards until everyone transitions to pci express and hypertransport exclusively. The only interesting thing I have is that in when using APICs interrupts are routed differently than when using the legacy x86 PIC. I think we can use two intertwined interrupt trees to model this. Eric From ebiederman at lnxi.com Wed Feb 4 18:44:01 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 4 18:44:01 2004 Subject: vga emulator new version In-Reply-To: References: Message-ID: ron minnich writes: > I've got the newest working version of the emulator for anyone who wants > to try it. > > This won't work on K8 systems minus some hacks, due to K8 differences, > contact me if interested. This will or won't work on K8 systems? Eric From stepan at suse.de Wed Feb 4 18:59:00 2004 From: stepan at suse.de (Stefan Reinauer) Date: Wed Feb 4 18:59:00 2004 Subject: OpenFirmware and interrupt-map In-Reply-To: References: <20040204145242.GC17814@suse.de> Message-ID: <20040205000523.GB30735@suse.de> * Eric W. Biederman [040205 00:39]: > > Yes, the Alpha was able to initialize RAID/SCSI x86 option roms. SRM was > > even defining an os callback to execute intXX calls from a running > > operating system. Unfortunately it was never implemented. > > 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? I think the DAC960 was one of those. It even needed a special firmware version to run through the CPU emulation iirc. Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From ebiederman at lnxi.com Wed Feb 4 19:00:01 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 4 19:00:01 2004 Subject: OpenFirmware and interrupt-map In-Reply-To: <1075937554.10050.1065.camel@eddie> References: <401EE302.7070201@sun.com> <401FE325.4010104@sun.com> <20040204143134.GD4954@suse.de> <1075937554.10050.1065.camel@eddie> Message-ID: Peter Lister writes: > On Wed, 2004-02-04 at 14:31, Stefan Reinauer wrote: > > > OpenBIOS is currently only reusing filesystem drivers from grub, but > > an interface for network booting so that etherboot drivers can be used > > should not overtop the fs efforts a lot. > > Digressing slightly, please note that Etherboot is more than just the > drivers - there is a significant amount of network code (now even TCP if > one wants it), and it would benefit us all to share as much as possible; > there is, for instance, an NFS client already. Regardless the etherboot driver model and the open firmware driver model are essentially the same. (Independently derived though). The big difference is I believe OF drivers can have multiple cards working at once. > For some reason best known to themselves, the GRUB developers decided to > use only Etherboot's drivers and brew their own network code. The result > is that GRUB netboot is now lagging noticeably behind Etherboot in > functionality, drivers etc - GRUB people now discuss "porting" Etherboot > drivers, which is disappointing (have a look at the GRUB support forum > and FAQ to see how little help there is on the network code compared to > disk and fs). It would have made far more sense to co-operate on an open > firmware network API, but hey ho... I'd like to see this happening > fairly soon, so that any driver created for Etherboot immediately works > with GRUB. So I encourage OpenBIOS to peacefully co-exist with GRUB and > Etherboot rather than fork which is not a good way to encourage driver > writers. After seeing the GRUB code the amazing part is that it works. The problem is totally GRUB, the etherboot core is much more powerful. Some pieces of GRUB at the periphery are OK, like the FS drivers but the rest is not even worth thinking about. There is a reason GRUB has never been ported to run under LinuxBIOS. > BTW, there is work now on implementing PXE on top of Etherboot - > pxelinux has already been demonstrated on top of Etherboot. This may > force the issue somewhat, since even if PXE isn't the API one wants, it > will at least help focus people into deciding what APIs they *do* want. I've already implemented the API I do want. Open source and no callbacks. Eric From Tarl.Neustaedter at sun.com Wed Feb 4 19:14:00 2004 From: Tarl.Neustaedter at sun.com (Tarl Neustaedter) Date: Wed Feb 4 19:14:00 2004 Subject: Handling interrupt routing cleanly... In-Reply-To: References: <20040204135340.GA4954@suse.de> <402144B6.5020404@sun.com> <40214A32.9060809@sun.com> Message-ID: <40218DF6.3040800@sun.com> Eric W. Biederman wrote: >>Plural. We have a number of devices which generate multiple interrupts. >>On PCI, that usually means being constrained to four interrupts, but >>for on-board devices we can deal with whole bunches of interrupt lines >>per device. > > > That part I could not quite understand when reading the OF spec. How > you can have multiple values per property. Base address registers > seemed to have the same problem. Ah. In the case of interrupts, where it's usually a single-cell value per interrupt, a trivial case is encoded as: h# 17 encode-int " interrupts" property In the case of a PCI slot where we (OpenFirmware) don't know what the device is, but have to allow for all four interrupts being used, we'll do something like: h# 1 encode-int h# 2 encode-int encode+ \ encode+ concatenates two encoded properties h# 3 encode-int encode+ h# 4 encode-int encode+ " interrupts" property When retrieving the property, you always get a address/length pair. It's up to the consumer to know what the base length of the item is, to know whether it's one or more items. In the above particular case: {2} ok " interrupts" get-property {2} ok .s \ Show what stack has; address length false f00da140 10 0 {2} ok drop dump \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef f00da140 00 00 00 01 00 00 00 02 00 00 00 03 00 00 00 04 ................ This shows four (4-byte) cells, containing 1,2,3 and 4. The "reg" property is more of the same, but it's almost always got multiple entries. E.g., for a PCI device, we'll have a reg property with 5 cells for each entry (three address and two size), and at least two entries: reg 00000800 00000000 00000000 00000000 00000000 02000810 00000000 00000000 00000000 00200000 The first line describes config space for a device, in this case for a device on pci address 1, function 0. The next four cells aren't relevant for config-space entries. The second line describes a BAR; in this case, a memory addressable BAR at offset 10, which describes 200000 bytes of address space. Since this bar is relocateable, the 2nd and 3d cells are not filled in (are zeroes). > The only interesting thing I have is that in when using > APICs interrupts are routed differently than when using > the legacy x86 PIC. Ah. That I missed. I'd never thought of interrupts being routed differently depending on something else. Assuming Linux is only going to use APICs, I wouldn't bother describing the legacy PIC, unless I'm missing something about interrupt configuration requiring that information anyway. Tarl From Tarl.Neustaedter at sun.com Wed Feb 4 19:32:00 2004 From: Tarl.Neustaedter at sun.com (Tarl Neustaedter) Date: Wed Feb 4 19:32:00 2004 Subject: Build problem - %rdx used with `l' suffix Message-ID: <40219239.6030301@sun.com> 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 From YhLu at tyan.com Wed Feb 4 20:25:01 2004 From: YhLu at tyan.com (YhLu) Date: Wed Feb 4 20:25:01 2004 Subject: OpenFirmware and interrupt-map Message-ID: <3174569B9743D511922F00A0C9431423041D1DCA@TYANWEB> 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 at 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 at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From ebiederman at lnxi.com Wed Feb 4 22:01:00 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 4 22:01:00 2004 Subject: Build problem - %rdx used with `l' suffix In-Reply-To: <40219239.6030301@sun.com> References: <40219239.6030301@sun.com> Message-ID: Tarl Neustaedter writes: > Back in september, there was a message about a fix to romcc for AMD64, > which would cure the error: -m32 if you are compiling on a 64bit system. I think that is the problem. So far LinuxBIOS is 32bit, and this is certainly a 32bit versus 64bit issue. I don't recognize the symptoms. > /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? The filenames are wrong for this to be something generated with romcc. romcc is just for the code that runs before we have memory. Keeping everything in registers is a pain, but it is very convenient to be able to do it all in C. Eric From ebiederman at lnxi.com Wed Feb 4 22:08:00 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 4 22:08:00 2004 Subject: Handling interrupt routing cleanly... In-Reply-To: <40218DF6.3040800@sun.com> References: <20040204135340.GA4954@suse.de> <402144B6.5020404@sun.com> <40214A32.9060809@sun.com> <40218DF6.3040800@sun.com> Message-ID: Tarl Neustaedter writes: > Eric W. Biederman wrote: > > The only interesting thing I have is that in when using > > APICs interrupts are routed differently than when using > > the legacy x86 PIC. > > Ah. That I missed. I'd never thought of interrupts being > routed differently depending on something else. Assuming > Linux is only going to use APICs, I wouldn't bother > describing the legacy PIC, unless I'm missing something > about interrupt configuration requiring that information > anyway. The APICs are not always present, and UP kernels tend not to use them. For the Opteron in 64bit mode you could probably not worry about it though. It has come up too many times in the past that I need to support both that ignoring the legacy PIC in the design is just silly. We currently can describe both the tables are just a hack and don't adjust when things like pci bus numbers change, or hypertransport unitids change. Eric From rminnich at lanl.gov Wed Feb 4 22:21:00 2004 From: rminnich at lanl.gov (ron minnich) Date: Wed Feb 4 22:21:00 2004 Subject: vga emulator new version In-Reply-To: Message-ID: On 4 Feb 2004, Eric W. Biederman wrote: > > This won't work on K8 systems minus some hacks, due to K8 differences, > > contact me if interested. > > This will or won't work on K8 systems? What we've found so far: - K8 mtrr settings are incorrect for the fixed MTRRs for VGA. There are extension bits that are more or less random that we need to fix in linuxbios. - Previously mentioned routing stuff needs to be set in the K8 northbridge - GART table settings are not correct, so GART is not yet there. But we're still pretty close. We have shell scripts and a quick hack to linuxbios and the cards are *almost* there. Once we get all the bits, we can start to get linuxbios set up correctly. ron From ebiederman at lnxi.com Wed Feb 4 22:27:01 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 4 22:27:01 2004 Subject: OpenFirmware and interrupt-map In-Reply-To: <3174569B9743D511922F00A0C9431423041D1DCA@TYANWEB> References: <3174569B9743D511922F00A0C9431423041D1DCA@TYANWEB> Message-ID: YhLu writes: > 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. Right. And my experience has been that the linux driver usually does all of that. So I think I have come up with a decent short term strategy. 1) Support all of the architectural hardware in small bootloaders like etherboot and FILO. This can be used as the bootloader of the fallback image because it will be small. 2) Support all of the weird hardware with hardware with a Linux kernel. If something needs to be run before the Linux driver that can easily be done with a user space emulators. So except for USB step one is done. Step 2 getting the kernel up to speed as a bootloader is going to be interesting. Eric From stepan at suse.de Thu Feb 5 02:29:01 2004 From: stepan at suse.de (Stefan Reinauer) Date: Thu Feb 5 02:29:01 2004 Subject: Build problem - %rdx used with `l' suffix In-Reply-To: <40219239.6030301@sun.com> References: <40219239.6030301@sun.com> Message-ID: <20040205074308.GA13254@suse.de> * Tarl Neustaedter [040205 01:45]: > 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? If you add the following two lines to your target Makefile it should work: uses CC option CC="gcc -m32" Building a 64bit image is not (yet) supported, LinuxBIOS/AMD64 is 32bit. Best regards, Stefan Reinauer -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From tangshanjing at yahoo.com.cn Thu Feb 5 02:42:00 2004 From: tangshanjing at yahoo.com.cn (=?gb2312?q?Jing=20S.=20Tang?=) Date: Thu Feb 5 02:42:00 2004 Subject: list of BIOSes supporting booting from USB flash disk Message-ID: <20040205075548.57116.qmail@web14812.mail.yahoo.com> 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 From ebenard at free.fr Thu Feb 5 04:19:00 2004 From: ebenard at free.fr (Eric BENARD / Free) Date: Thu Feb 5 04:19:00 2004 Subject: Motherboard for LinuxBIOS & DOC Message-ID: <200402051032.19828.ebenard@free.fr> 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 From carl at bookmanassociates.com Thu Feb 5 08:07:00 2004 From: carl at bookmanassociates.com (Carl Peto) Date: Thu Feb 5 08:07:00 2004 Subject: Upload to generic Message-ID: <002f01c3ebea$cf1a0750$0c00a8c0@bookmanheadoffice.co.uk> I am new to LinuxBIOS but have years of Linux experience. I would like to upgrade my test PC to LinuxBIOS but do not want to replace the existing motherboard. Is it possible to "flash" LinuxBIOS into a standard motherboard, like mine. I have an ASUS motherboard K7A or something like that. Also if I do this and it goes wrong, can I undo it or do I have to go to the manufacturer and pretend that I don't know how it broke? :) Thanks, Carl Peto From stepan at suse.de Thu Feb 5 09:46:01 2004 From: stepan at suse.de (Stefan Reinauer) Date: Thu Feb 5 09:46:01 2004 Subject: OpenFirmware and interrupt-map In-Reply-To: <3174569B9743D511922F00A0C9431423041D1DCA@TYANWEB> References: <3174569B9743D511922F00A0C9431423041D1DCA@TYANWEB> Message-ID: <20040205145938.GD27598@suse.de> * YhLu [040205 02:39]: > 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. From rminnich at lanl.gov Thu Feb 5 10:30:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Thu Feb 5 10:30:01 2004 Subject: new linuxbios v1 mainboard added Message-ID: 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 From pmacv at telefonica.net Thu Feb 5 10:56:01 2004 From: pmacv at telefonica.net (Pedro M.) Date: Thu Feb 5 10:56:01 2004 Subject: list of BIOSes supporting booting from USB flash disk In-Reply-To: <20040205075548.57116.qmail@web14812.mail.yahoo.com> References: <20040205075548.57116.qmail@web14812.mail.yahoo.com> Message-ID: <402278D5.4040304@telefonica.net> Jing S. Tang wrote: > 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 > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > This list is very important. You can see the spanish translation at http://www.aulir.com/tavi/index.php?page=COMO+ArrancarUSB Regards. From ollie at lanl.gov Thu Feb 5 12:06:01 2004 From: ollie at lanl.gov (Li-Ta Lo) Date: Thu Feb 5 12:06:01 2004 Subject: vga emulator new version In-Reply-To: References: Message-ID: <1076001605.3957.90.camel@exponential.lanl.gov> On Wed, 2004-02-04 at 20:34, ron minnich wrote: > On 4 Feb 2004, Eric W. Biederman wrote: > > > > This won't work on K8 systems minus some hacks, due to K8 differences, > > > contact me if interested. > > > > This will or won't work on K8 systems? > > What we've found so far: > - K8 mtrr settings are incorrect for the fixed MTRRs for VGA. > There are extension bits that are more or less random that we need to > fix in linuxbios. > - Previously mentioned routing stuff needs to be set in the K8 northbridge > - GART table settings are not correct, so GART is not yet there. > > But we're still pretty close. We have shell scripts and a quick hack to > linuxbios and the cards are *almost* there. Once we get all the bits, we > can start to get linuxbios set up correctly. > It is done. We have AGP 8x and HW 3D acceleration now. We can even run tuxracer ;-). Ollie From stuge-linuxbios at cdy.org Thu Feb 5 12:32:01 2004 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Thu Feb 5 12:32:01 2004 Subject: vga emulator new version In-Reply-To: <1076001605.3957.90.camel@exponential.lanl.gov> References: <1076001605.3957.90.camel@exponential.lanl.gov> Message-ID: <20040205174549.GD5900@foo.birdnet.se> On Thu, Feb 05, 2004 at 10:20:05AM -0700, Li-Ta Lo wrote: > It is done. We have AGP 8x and HW 3D acceleration > now. We can even run tuxracer ;-). Great work! Does it automagically work with many different cards? :p //Peter From ollie at lanl.gov Thu Feb 5 12:44:00 2004 From: ollie at lanl.gov (Li-Ta Lo) Date: Thu Feb 5 12:44:00 2004 Subject: vga emulator new version In-Reply-To: <20040205174549.GD5900@foo.birdnet.se> References: <1076001605.3957.90.camel@exponential.lanl.gov> <20040205174549.GD5900@foo.birdnet.se> Message-ID: <1076003890.3957.95.camel@exponential.lanl.gov> On Thu, 2004-02-05 at 10:45, Peter Stuge wrote: > On Thu, Feb 05, 2004 at 10:20:05AM -0700, Li-Ta Lo wrote: > > It is done. We have AGP 8x and HW 3D acceleration > > now. We can even run tuxracer ;-). > > Great work! > > Does it automagically work with many different cards? :p > > Not yet. The bios on Nvidia card has a specific feature to not calling itself by intX. Other cards like ATI want to install the intX handlers and then call them. Currently the emulator can not handle this but it is very simple to add this. Of course, we need to try on more vendor/models. Ollie From rminnich at lanl.gov Thu Feb 5 12:56:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Thu Feb 5 12:56:01 2004 Subject: vga emulator new version In-Reply-To: <20040205174549.GD5900@foo.birdnet.se> Message-ID: On Thu, 5 Feb 2004, Peter Stuge wrote: > Great work! > > Does it automagically work with many different cards? :p it's still held together with rubber bands, there is work to do now to get linuxbios to do the right things. What you have to do right now by hand (wrmsr, setpci, etc.) - get a video bios image - Do some msr writes to correctly set fixed msr with extensions - get the base address for gart (read vga card for this) - set IORR1, and some other K8 northbridge settings based on gart base - run testbios (newest one) I think that's about it. ron From ollie at lanl.gov Thu Feb 5 13:01:00 2004 From: ollie at lanl.gov (Li-Ta Lo) Date: Thu Feb 5 13:01:00 2004 Subject: vga emulator new version In-Reply-To: References: Message-ID: <1076004916.3957.97.camel@exponential.lanl.gov> On Thu, 2004-02-05 at 11:09, ron minnich wrote: > On Thu, 5 Feb 2004, Peter Stuge wrote: > > > Great work! > > > > Does it automagically work with many different cards? :p > > it's still held together with rubber bands, there is work to do now to get > linuxbios to do the right things. > > What you have to do right now by hand (wrmsr, setpci, etc.) > - get a video bios image > - Do some msr writes to correctly set fixed msr with extensions > - get the base address for gart (read vga card for this) Should it be from AGP bridge ?? > - set IORR1, and some other K8 northbridge settings based on gart base > - run testbios (newest one) > Ollie From rminnich at lanl.gov Thu Feb 5 13:06:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Thu Feb 5 13:06:01 2004 Subject: vga emulator new version In-Reply-To: <1076004916.3957.97.camel@exponential.lanl.gov> Message-ID: On Thu, 5 Feb 2004, Li-Ta Lo wrote: > Should it be from AGP bridge ?? oops, yes it should. ron From stepan at suse.de Thu Feb 5 13:17:00 2004 From: stepan at suse.de (Stefan Reinauer) Date: Thu Feb 5 13:17:00 2004 Subject: vga emulator new version In-Reply-To: <1076003890.3957.95.camel@exponential.lanl.gov> References: <1076001605.3957.90.camel@exponential.lanl.gov> <20040205174549.GD5900@foo.birdnet.se> <1076003890.3957.95.camel@exponential.lanl.gov> Message-ID: <20040205182849.GC22055@suse.de> * Li-Ta Lo [040205 18:58]: > Not yet. The bios on Nvidia card has a specific feature > to not calling itself by intX. Other cards like ATI > want to install the intX handlers and then call them. > Currently the emulator can not handle this but it is > very simple to add this. Cool. If this works, SCSI option roms could also be used to boot from after they installed an int13 handler... Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From ollie at lanl.gov Thu Feb 5 13:21:00 2004 From: ollie at lanl.gov (Li-Ta Lo) Date: Thu Feb 5 13:21:00 2004 Subject: vga emulator new version In-Reply-To: <20040205182849.GC22055@suse.de> References: <1076001605.3957.90.camel@exponential.lanl.gov> <20040205174549.GD5900@foo.birdnet.se> <1076003890.3957.95.camel@exponential.lanl.gov> <20040205182849.GC22055@suse.de> Message-ID: <1076006080.3957.103.camel@exponential.lanl.gov> On Thu, 2004-02-05 at 11:28, Stefan Reinauer wrote: > * Li-Ta Lo [040205 18:58]: > > Not yet. The bios on Nvidia card has a specific feature > > to not calling itself by intX. Other cards like ATI > > want to install the intX handlers and then call them. > > Currently the emulator can not handle this but it is > > very simple to add this. > > Cool. If this works, SCSI option roms could also be used to boot from > after they installed an int13 handler... > Actually, I suspect that this has already been implemented in the original XFree86 version. Ron has removed/disgarded some good things when porting it to LB. Ollie From jbors at mail.ru Thu Feb 5 14:05:01 2004 From: jbors at mail.ru (=?koi8-r?Q?=22?=Dmitry Borisov=?koi8-r?Q?=22=20?=) Date: Thu Feb 5 14:05:01 2004 Subject: EPIA-M linuxbios reset button does not work Message-ID: 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/ From rminnich at lanl.gov Thu Feb 5 14:22:00 2004 From: rminnich at lanl.gov (ron minnich) Date: Thu Feb 5 14:22:00 2004 Subject: vga emulator new version In-Reply-To: <20040205182849.GC22055@suse.de> Message-ID: On Thu, 5 Feb 2004, Stefan Reinauer wrote: > Cool. If this works, SCSI option roms could also be used to boot from > after they installed an int13 handler... that makes my brain hurt :-) ron From rminnich at lanl.gov Thu Feb 5 14:23:00 2004 From: rminnich at lanl.gov (ron minnich) Date: Thu Feb 5 14:23:00 2004 Subject: vga emulator new version In-Reply-To: <1076006080.3957.103.camel@exponential.lanl.gov> Message-ID: On Thu, 5 Feb 2004, Li-Ta Lo wrote: > Actually, I suspect that this has already been implemented in the > original XFree86 version. Ron has removed/disgarded some good things > when porting it to LB. yes, I sure did, there was stuff in there I did not like but it turns out we need it :=( ron From stepan at suse.de Thu Feb 5 14:39:01 2004 From: stepan at suse.de (Stefan Reinauer) Date: Thu Feb 5 14:39:01 2004 Subject: EPIA-M linuxbios reset button does not work In-Reply-To: References: Message-ID: <20040205195219.GA9454@suse.de> * "Dmitry Borisov" [040205 20:19]: > 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, Some ACPI stuff is missing. You can sit with acpidmp from pmtools and look at what the ACPI code for epia-m does.. Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From dwh at lanl.gov Thu Feb 5 16:43:00 2004 From: dwh at lanl.gov (Hendricks David W.) Date: Thu Feb 5 16:43:00 2004 Subject: Upload to generic In-Reply-To: <002f01c3ebea$cf1a0750$0c00a8c0@bookmanheadoffice.co.uk> Message-ID: Yes, that is possible. However, Asus sometimes does some weird stuff with their SMbus, so it might not be possible to make a port for your mainboard without some documentation from Asus. On Thu, 5 Feb 2004, Carl Peto wrote: > I am new to LinuxBIOS but have years of Linux experience. > > I would like to upgrade my test PC to LinuxBIOS but do not want to replace > the existing motherboard. > > Is it possible to "flash" LinuxBIOS into a standard motherboard, like mine. > I have an ASUS motherboard K7A or something like that. > > Also if I do this and it goes wrong, can I undo it or do I have to go to the > manufacturer and pretend that I don't know how it broke? :) > > Thanks, > Carl Peto > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From carl at bookmanassociates.com Fri Feb 6 07:15:01 2004 From: carl at bookmanassociates.com (Carl Peto) Date: Fri Feb 6 07:15:01 2004 Subject: Upload to generic References: Message-ID: <001a01c3ecac$d6a196b0$0c00a8c0@bookmanheadoffice.co.uk> Thank you. Is there a FAQ or HOWTO for how to flash like this or is it just straightforward and easily picked up from the LinuxBIOS documentation? Also I think I'd better have some option to get the old BIOS back, especially if I'm going to ask ASUS how to do all this - otherwise their likely answer will be "if you do this you break your board and we will not fix it for you - you'll need to get a new one". I don't know if there's some standard way to get a PC to "revert to factory BIOS" with a key combination on bootup or something? ----- Original Message ----- From: "Hendricks David W." To: "Carl Peto" Cc: "LinuxBIOS" Sent: Thursday, February 05, 2004 9:57 PM Subject: Re: Upload to generic > Yes, that is possible. However, Asus sometimes does some weird stuff with > their SMbus, so it might not be possible to make a port for your > mainboard without some documentation from Asus. > > On Thu, 5 Feb 2004, Carl Peto wrote: > > > I am new to LinuxBIOS but have years of Linux experience. > > > > I would like to upgrade my test PC to LinuxBIOS but do not want to replace > > the existing motherboard. > > > > Is it possible to "flash" LinuxBIOS into a standard motherboard, like mine. > > I have an ASUS motherboard K7A or something like that. > > > > Also if I do this and it goes wrong, can I undo it or do I have to go to the > > manufacturer and pretend that I don't know how it broke? :) > > > > Thanks, > > Carl Peto > > > > _______________________________________________ > > Linuxbios mailing list > > Linuxbios at clustermatic.org > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > From rsmith at bitworks.com Fri Feb 6 19:01:00 2004 From: rsmith at bitworks.com (Richard Smith) Date: Fri Feb 6 19:01:00 2004 Subject: vga emulator new version In-Reply-To: References: Message-ID: <40242DE9.1000306@bitworks.com> I'd like a copy of the latest version. I'll run it against our ATI M1 bios -- Richard A. Smith rsmith at bitworks.com From rminnich at lanl.gov Fri Feb 6 19:10:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Fri Feb 6 19:10:01 2004 Subject: vga emulator new version In-Reply-To: <40242DE9.1000306@bitworks.com> Message-ID: I sent it to Richard. I am putting the scripts we use here for info. ron jotun root # cat FIXGART.sh #!/bin/sh insmod /usr/src/linux/arch/i386/kernel/msr.o # fix the fixed MTRR /root/wrmsr 0xC0010010 0x1e0601 0 /root/wrmsr 0x259 0 0 #fix the IORR1 crap on BOTH northbridges /root/rdmsr 0xC0010018 /root/wrmsr 0xC0010018 0xd0000000 0xff /root/rdmsr 0xC0010019 /root/wrmsr 0xC0010019 0xd8000000 0xff # set up 0xd in the whatever setpci -s 0:18.3 94.l setpci -s 0:18.3 94.l=68 setpci -s 0:18.3 94.l setpci -s 0:18.3 90.b setpci -s 0:18.3 90.b=3 setpci -s 0:18.3 90.b setpci -s 0:19.3 94.l setpci -s 0:19.3 94.l=68 setpci -s 0:19.3 94.l setpci -s 0:19.3 90.b setpci -s 0:19.3 90.b=3 setpci -s 0:19.3 90.b # 8151 setpci -s 1:1.0 10.l # setpci -s 1:1.0 10.l=f0000008 # setpci -s 1:1.0 10.l setpci -s 1:1.0 b4.l # setpci -s 1:1.0 b4.l=00010f20 # setpci -s 1:1.0 b4.l jotun root # cat DO_GEFORCEFX.sh #! /bin/sh #insmod /usr/src/linux/arch/i386/kernel/msr.o #/root/wrmsr 0xC0010010 0x1e0601 0 #/root/wrmsr 0x259 0 0 /root/vgabios//testbios --abseg /dev/mem -s 65536 /root/nvbios.bin 2>&1 > /tmp/out modprobe nvidia NVreg_EnableAGPSBA=1 NVreg_EnableAGPFW=1 #modprobe agpgart agp_try_unsupported=1 modprobe agpgart jotun root # From dwh at lanl.gov Fri Feb 6 19:24:00 2004 From: dwh at lanl.gov (Hendricks David W.) Date: Fri Feb 6 19:24:00 2004 Subject: vga emulator new version In-Reply-To: Message-ID: It should have modprobe agpgart agp_try_unsupported=1 uncommented. I had difficulty loading the module with agp_try_unsupported in kernel 2.6.2, looking into it further right now... On Fri, 6 Feb 2004, ron minnich wrote: > I sent it to Richard. > > I am putting the scripts we use here for info. > > ron > jotun root # cat FIXGART.sh > #!/bin/sh > insmod /usr/src/linux/arch/i386/kernel/msr.o > # fix the fixed MTRR > /root/wrmsr 0xC0010010 0x1e0601 0 > /root/wrmsr 0x259 0 0 > > #fix the IORR1 crap on BOTH northbridges > > /root/rdmsr 0xC0010018 > /root/wrmsr 0xC0010018 0xd0000000 0xff > /root/rdmsr 0xC0010019 > /root/wrmsr 0xC0010019 0xd8000000 0xff > > # set up 0xd in the whatever > setpci -s 0:18.3 94.l > setpci -s 0:18.3 94.l=68 > setpci -s 0:18.3 94.l > setpci -s 0:18.3 90.b > setpci -s 0:18.3 90.b=3 > setpci -s 0:18.3 90.b > setpci -s 0:19.3 94.l > setpci -s 0:19.3 94.l=68 > setpci -s 0:19.3 94.l > setpci -s 0:19.3 90.b > setpci -s 0:19.3 90.b=3 > setpci -s 0:19.3 90.b > # 8151 > setpci -s 1:1.0 10.l > # setpci -s 1:1.0 10.l=f0000008 > # setpci -s 1:1.0 10.l > setpci -s 1:1.0 b4.l > # setpci -s 1:1.0 b4.l=00010f20 > # setpci -s 1:1.0 b4.l > jotun root # cat DO_GEFORCEFX.sh > #! /bin/sh > #insmod /usr/src/linux/arch/i386/kernel/msr.o > #/root/wrmsr 0xC0010010 0x1e0601 0 > #/root/wrmsr 0x259 0 0 > /root/vgabios//testbios --abseg /dev/mem -s 65536 /root/nvbios.bin 2>&1 > > /tmp/out > modprobe nvidia NVreg_EnableAGPSBA=1 NVreg_EnableAGPFW=1 > #modprobe agpgart agp_try_unsupported=1 > modprobe agpgart > jotun root # > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From dwh at lanl.gov Fri Feb 6 20:43:01 2004 From: dwh at lanl.gov (Hendricks David W.) Date: Fri Feb 6 20:43:01 2004 Subject: vga emulator new version In-Reply-To: Message-ID: For anyone using the S2885 or another mainboard with the 8151, there seems to be a problem with the agpgart driver in 2.6 kernels. Further description is here: http://www.x86-64.org/lists/discuss/msg04393.html . I could only get Linux agpgart to detect the AMD 8151 when compiled statically into the 2.6.1 kernel with the patch from x86-64.org. This problem also seems to exist in 2.6.2. Using our current approach, agpgart is loaded as a module after Linux is booted and we've run testbios. Looks like 2.6 users might have to wait for Ron to get the aforementioned fixes into LinuxBIOS so we can get run the VGA BIOS before the kernel tries to boot. On Fri, 6 Feb 2004, Hendricks David W. wrote: > It should have modprobe agpgart agp_try_unsupported=1 uncommented. I had > difficulty loading the module with agp_try_unsupported in kernel 2.6.2, > looking into it further right now... > > On Fri, 6 Feb 2004, ron minnich wrote: > > > I sent it to Richard. > > > > I am putting the scripts we use here for info. > > > > ron > > jotun root # cat FIXGART.sh > > #!/bin/sh > > insmod /usr/src/linux/arch/i386/kernel/msr.o > > # fix the fixed MTRR > > /root/wrmsr 0xC0010010 0x1e0601 0 > > /root/wrmsr 0x259 0 0 > > > > #fix the IORR1 crap on BOTH northbridges > > > > /root/rdmsr 0xC0010018 > > /root/wrmsr 0xC0010018 0xd0000000 0xff > > /root/rdmsr 0xC0010019 > > /root/wrmsr 0xC0010019 0xd8000000 0xff > > > > # set up 0xd in the whatever > > setpci -s 0:18.3 94.l > > setpci -s 0:18.3 94.l=68 > > setpci -s 0:18.3 94.l > > setpci -s 0:18.3 90.b > > setpci -s 0:18.3 90.b=3 > > setpci -s 0:18.3 90.b > > setpci -s 0:19.3 94.l > > setpci -s 0:19.3 94.l=68 > > setpci -s 0:19.3 94.l > > setpci -s 0:19.3 90.b > > setpci -s 0:19.3 90.b=3 > > setpci -s 0:19.3 90.b > > # 8151 > > setpci -s 1:1.0 10.l > > # setpci -s 1:1.0 10.l=f0000008 > > # setpci -s 1:1.0 10.l > > setpci -s 1:1.0 b4.l > > # setpci -s 1:1.0 b4.l=00010f20 > > # setpci -s 1:1.0 b4.l > > jotun root # cat DO_GEFORCEFX.sh > > #! /bin/sh > > #insmod /usr/src/linux/arch/i386/kernel/msr.o > > #/root/wrmsr 0xC0010010 0x1e0601 0 > > #/root/wrmsr 0x259 0 0 > > /root/vgabios//testbios --abseg /dev/mem -s 65536 /root/nvbios.bin 2>&1 > > > /tmp/out > > modprobe nvidia NVreg_EnableAGPSBA=1 NVreg_EnableAGPFW=1 > > #modprobe agpgart agp_try_unsupported=1 > > modprobe agpgart > > jotun root # > > > > > > _______________________________________________ > > Linuxbios mailing list > > Linuxbios at clustermatic.org > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From jbors at mail.ru Sat Feb 7 17:07:00 2004 From: jbors at mail.ru (Dmitry Borisov) Date: Sat Feb 7 17:07:00 2004 Subject: EPIA-M HW graphics slow under linuxbios [PMX:#] References: Message-ID: <018d01c3edc8$bd2163b0$0300a8c0@amr.corp.intel.com> Dave, Ron, Any progress on joining versions for EPIA-M ? I'm going to make changes to include ACPI, PCX splash support and resolve problems with graphics speed. Can you please sync up so I can proceed ? Dmitry/ ----- Original Message ----- From: "ron minnich" To: "Dave Ashley" Cc: Sent: Thursday, January 29, 2004 7:02 PM Subject: Re: EPIA-M HW graphics slow under linuxbios [PMX:#] > Dave, I will try to get your patch in next week. Sorry I keep dropping the > ball. > > ron > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From rminnich at lanl.gov Sat Feb 7 19:56:00 2004 From: rminnich at lanl.gov (ron minnich) Date: Sat Feb 7 19:56:00 2004 Subject: EPIA-M HW graphics slow under linuxbios [PMX:#] In-Reply-To: <018d01c3edc8$bd2163b0$0300a8c0@amr.corp.intel.com> Message-ID: On Sat, 7 Feb 2004, Dmitry Borisov wrote: > Any progress on joining versions for EPIA-M ? dave sent me a box and I will try to do this soon. I have been consumed with VGA BIOS support for the last 3 weeks, but I think that is under control. ron From bjm_ at bellsouth.net Sat Feb 7 21:45:01 2004 From: bjm_ at bellsouth.net (bjm_ at bellsouth.net) Date: Sat Feb 7 21:45:01 2004 Subject: LinuxBIOS....on desktop PCs? Message-ID: <20040208025946.TMZP17141.imf22aec.mail.bellsouth.net@mail.bellsouth.net> Is it possible to have LinuxBIOS on desktop PCs? Was wondering...if so, I'd like to use it :) From rsmith at bitworks.com Sat Feb 7 23:32:00 2004 From: rsmith at bitworks.com (Richard Smith) Date: Sat Feb 7 23:32:00 2004 Subject: vga emulator new version In-Reply-To: References: Message-ID: <4025BEDF.7000408@bitworks.com> ron minnich wrote: Ok.. No change for me. A slight update is that I now know what all those int15 calls are and what they do. Except I can't tell cause its NDA stuff. I can tell you that I added that support into int15.c and it didn't make any differnce. Somthing is still not quite right with the emulation since both under ADLO and IDT mode I can get a VSYNC but not with the emulator. I'm going to try and add my int15 stuff to ADLO and IDT and see what happens. Oh and Ron would it be too much trouble to enable/disable all your extra printfs of ins and outs with the -DDEBUG or perhaps a command line switch. Took me awhile to find that they weren't part of the DEBUG setup. -- Richard A. Smith rsmith at bitworks.com From rsmith at bitworks.com Sun Feb 8 00:05:01 2004 From: rsmith at bitworks.com (Richard Smith) Date: Sun Feb 8 00:05:01 2004 Subject: /dev/bios for 2.6 In-Reply-To: <20031210213555.GB9144@suse.de> References: <3174569B9743D511922F00A0C943142303990D22@TYANWEB> <20031210213555.GB9144@suse.de> Message-ID: <4025C6DC.6060501@bitworks.com> Any chance of getting devbios updated to 2.6? I get Invalid module format trying to load. Or perhaps someone will tell me if the MTD drivers support a AMD29f040b. The MTD webpage dosen't have any info and I build and inserted lots of different mtd modules but nothing indicated they did anything. -- Richard A. Smith rsmith at bitworks.com From rminnich at lanl.gov Sun Feb 8 11:20:00 2004 From: rminnich at lanl.gov (ron minnich) Date: Sun Feb 8 11:20:00 2004 Subject: LinuxBIOS....on desktop PCs? In-Reply-To: <20040208025946.TMZP17141.imf22aec.mail.bellsouth.net@mail.bellsouth.net> Message-ID: On Sat, 7 Feb 2004 bjm_ at bellsouth.net wrote: > Is it possible to have LinuxBIOS on desktop PCs? Was wondering...if so, > I'd like to use it :) I think it is, if only because we keep finding it does a bit better job of configuring the platform, which is only a 10% gain but what the heck ... ron From rminnich at lanl.gov Sun Feb 8 11:20:56 2004 From: rminnich at lanl.gov (ron minnich) Date: Sun Feb 8 11:20:56 2004 Subject: vga emulator new version In-Reply-To: <4025BEDF.7000408@bitworks.com> Message-ID: On Sat, 7 Feb 2004, Richard Smith wrote: > Oh and Ron would it be too much trouble to enable/disable all your extra > printfs of ins and outs with the -DDEBUG or perhaps a command line > switch. Took me awhile to find that they weren't part of the DEBUG setup. yeah, sorry, a very quick hack I forgot to take out. I'll take it out. ron From dwh at lanl.gov Mon Feb 9 16:51:00 2004 From: dwh at lanl.gov (Hendricks David W.) Date: Mon Feb 9 16:51:00 2004 Subject: LinuxBIOS....on desktop PCs? In-Reply-To: <20040208025946.TMZP17141.imf22aec.mail.bellsouth.net@mail.bellsouth.net> Message-ID: Yes, depending on which mainboard you're running. And with the recent revelations in VGA support (It works :)), I think LinuxBIOS is well underway for use in the desktop market. Did you have anything specific in mind? If you're looking for a mainboard, check out the Epia or perhaps the Chaintech 7KJD if you're looking for an Athlon platform. On Sat, 7 Feb 2004 bjm_ at bellsouth.net wrote: > Is it possible to have LinuxBIOS on desktop PCs? Was wondering...if so, I'd like to use it :) > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From rsmith at bitworks.com Mon Feb 9 17:28:00 2004 From: rsmith at bitworks.com (Richard Smith) Date: Mon Feb 9 17:28:00 2004 Subject: ATI gets a clue. In-Reply-To: References: Message-ID: <40280CDD.4040803@bitworks.com> Wonderfull news... I got this back today from ATI. Looks like someone with some clout there finally gets it. So I'm about to start porting some biosless init code I received over to Linux. Then work it into linux bios. I take back everything I said bad about ATI. *grin* Tell all your OEM buddies that ATI Mobility M1 video chips are about to become LinuxBIOS friendly in the near future. ------- Sorry for the lengthy delay. There is a lot of detail here. Basically, you can develop code with our documentation, and then release it under GPL - no issues there. If you want to produce a biosless chip init procedure, you can use the documentation I pointed you to. If you have any questions, feel free to email me about those documents. --------- -- Richard A. Smith rsmith at bitworks.com From dwh at lanl.gov Mon Feb 9 17:46:00 2004 From: dwh at lanl.gov (Hendricks David W.) Date: Mon Feb 9 17:46:00 2004 Subject: ATI gets a clue. In-Reply-To: <40280CDD.4040803@bitworks.com> Message-ID: Woohoo! Does this also apply to their latest R3xx core Radeons such as the 8500 and up? Or only their old crummy ones? On Mon, 9 Feb 2004, Richard Smith wrote: > Wonderfull news... I got this back today from ATI. Looks like someone > with some clout there finally gets it. > > So I'm about to start porting some biosless init code I received over to > Linux. Then work it into linux bios. > > I take back everything I said bad about ATI. *grin* > > Tell all your OEM buddies that ATI Mobility M1 video chips are about to > become LinuxBIOS friendly in the near future. > > ------- > Sorry for the lengthy delay. There is a lot of detail here. Basically, > you can develop code with our documentation, and then release it under > GPL - no issues there. > > If you want to produce a biosless chip init procedure, you can use the > documentation I pointed you to. If you have any questions, feel free to > email me about those documents. > --------- > > From r3pek at r3pek.homelinux.org Mon Feb 9 17:47:00 2004 From: r3pek at r3pek.homelinux.org (Carlos Silva) Date: Mon Feb 9 17:47:00 2004 Subject: ATI gets a clue. In-Reply-To: <40280CDD.4040803@bitworks.com> References: <40280CDD.4040803@bitworks.com> Message-ID: <50668.213.22.30.185.1076367714.squirrel@webmail.r3pek.homelinux.org> Really nice news... i'll keep dreaming that nvidia will do the same. > Wonderfull news... I got this back today from ATI. Looks like someone > with some clout there finally gets it. > > So I'm about to start porting some biosless init code I received over to > Linux. Then work it into linux bios. > > I take back everything I said bad about ATI. *grin* > > Tell all your OEM buddies that ATI Mobility M1 video chips are about to > become LinuxBIOS friendly in the near future. > > ------- > Sorry for the lengthy delay. There is a lot of detail here. Basically, > you can develop code with our documentation, and then release it under > GPL - no issues there. > > If you want to produce a biosless chip init procedure, you can use the > documentation I pointed you to. If you have any questions, feel free to > email me about those documents. > --------- > > -- > Richard A. Smith > rsmith at bitworks.com > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From dwh at lanl.gov Mon Feb 9 17:51:01 2004 From: dwh at lanl.gov (Hendricks David W.) Date: Mon Feb 9 17:51:01 2004 Subject: ATI gets a clue. In-Reply-To: <50668.213.22.30.185.1076367714.squirrel@webmail.r3pek.homelinux.org> Message-ID: We don't need to with nVidia, we can run their VGA BIOS using testbios. Though in the perfect world, they'd be more forthcoming with specs so that someone can make an LB port for their nForce boards. On Mon, 9 Feb 2004, Carlos Silva wrote: > Really nice news... i'll keep dreaming that nvidia will do the same. > > > > Wonderfull news... I got this back today from ATI. Looks like someone > > with some clout there finally gets it. > > > > So I'm about to start porting some biosless init code I received over to > > Linux. Then work it into linux bios. > > > > I take back everything I said bad about ATI. *grin* > > > > Tell all your OEM buddies that ATI Mobility M1 video chips are about to > > become LinuxBIOS friendly in the near future. > > > > ------- > > Sorry for the lengthy delay. There is a lot of detail here. Basically, > > you can develop code with our documentation, and then release it under > > GPL - no issues there. > > > > If you want to produce a biosless chip init procedure, you can use the > > documentation I pointed you to. If you have any questions, feel free to > > email me about those documents. > > --------- > > > > -- > > Richard A. Smith > > rsmith at bitworks.com > > > > > > _______________________________________________ > > Linuxbios mailing list > > Linuxbios at clustermatic.org > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From r3pek at r3pek.homelinux.org Mon Feb 9 17:57:01 2004 From: r3pek at r3pek.homelinux.org (Carlos Silva) Date: Mon Feb 9 17:57:01 2004 Subject: ATI gets a clue. In-Reply-To: References: <50668.213.22.30.185.1076367714.squirrel@webmail.r3pek.homelinux.org> Message-ID: <50929.213.22.30.185.1076368314.squirrel@webmail.r3pek.homelinux.org> that was what am was talking about. i have a nForce2 and i would love to have LinuxBIOS on my PC.... but the only think i can do is w8 :( > We don't need to with nVidia, we can run their VGA BIOS using testbios. > > Though in the perfect world, they'd be more forthcoming with specs so that > someone can make an LB port for their nForce boards. > > On Mon, 9 Feb 2004, Carlos Silva wrote: > >> Really nice news... i'll keep dreaming that nvidia will do the same. >> >> >> > Wonderfull news... I got this back today from ATI. Looks like someone >> > with some clout there finally gets it. >> > >> > So I'm about to start porting some biosless init code I received over >> to >> > Linux. Then work it into linux bios. >> > >> > I take back everything I said bad about ATI. *grin* >> > >> > Tell all your OEM buddies that ATI Mobility M1 video chips are about >> to >> > become LinuxBIOS friendly in the near future. >> > >> > ------- >> > Sorry for the lengthy delay. There is a lot of detail here. >> Basically, >> > you can develop code with our documentation, and then release it under >> > GPL - no issues there. >> > >> > If you want to produce a biosless chip init procedure, you can use the >> > documentation I pointed you to. If you have any questions, feel free >> to >> > email me about those documents. >> > --------- >> > >> > -- >> > Richard A. Smith >> > rsmith at bitworks.com >> > >> > >> > _______________________________________________ >> > Linuxbios mailing list >> > Linuxbios at clustermatic.org >> > http://www.clustermatic.org/mailman/listinfo/linuxbios >> > >> >> _______________________________________________ >> Linuxbios mailing list >> Linuxbios at clustermatic.org >> http://www.clustermatic.org/mailman/listinfo/linuxbios >> > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From terry at langri.demon.co.uk Mon Feb 9 18:02:00 2004 From: terry at langri.demon.co.uk (Terry Blunt) Date: Mon Feb 9 18:02:00 2004 Subject: ATI gets a clue. In-Reply-To: References: Message-ID: "Hendricks David W." wrote: > We don't need to with nVidia, we can run their VGA BIOS using testbios. > > Though in the perfect world, they'd be more forthcoming with specs so that > someone can make an LB port for their nForce boards. > > On Mon, 9 Feb 2004, Carlos Silva wrote: > > > Really nice news... i'll keep dreaming that nvidia will do the same. Maybe I'm missing something, but I can never understand hardware manufacturers being cagey about their specs. I would have thought it would save them a lot of hassle if they *didn't* have to write drivers themselves. If they made the information available with suggestions and worked examples, the software industry would do it all for them. To forestall one argument, I really don't see anyone being able to reverse engineer the *hardware* from the overall specs. -- Terry Blunt Car sign: Adult on board... not necessarily in charge. From rsmith at bitworks.com Mon Feb 9 18:03:00 2004 From: rsmith at bitworks.com (Richard Smith) Date: Mon Feb 9 18:03:00 2004 Subject: ATI gets a clue. In-Reply-To: References: Message-ID: <402814CC.8000303@bitworks.com> Hendricks David W. wrote: > Woohoo! Does this also apply to their latest R3xx core Radeons such as the > 8500 and up? Or only their old crummy ones? > Bitworks's agreement only covers the Rage Mobility M1 which is several years old and Mach64 based. I don't know about the new cores. Probally not as they are not trying to sell those into the embedded market. -- Richard A. Smith rsmith at bitworks.com From vincent at ulyssis.org Mon Feb 9 18:14:01 2004 From: vincent at ulyssis.org (Vincent Touquet) Date: Mon Feb 9 18:14:01 2004 Subject: ATI gets a clue. In-Reply-To: <40280CDD.4040803@bitworks.com> References: <40280CDD.4040803@bitworks.com> Message-ID: <20040209232845.GE21648@lea.ulyssis.org> On Mon, Feb 09, 2004 at 04:42:37PM -0600, Richard Smith wrote: >Wonderfull news... I got this back today from ATI. Looks like someone >with some clout there finally gets it. This is great news :) I remain in awe at what has been achieved in the time I have been lurking on this list. congrats to everyone working on linuxbios, v From dwh at lanl.gov Mon Feb 9 18:35:01 2004 From: dwh at lanl.gov (Hendricks David W.) Date: Mon Feb 9 18:35:01 2004 Subject: ATI gets a clue. In-Reply-To: Message-ID: From rminnich at lanl.gov Mon Feb 9 18:49:00 2004 From: rminnich at lanl.gov (ron minnich) Date: Mon Feb 9 18:49:00 2004 Subject: ATI gets a clue. In-Reply-To: Message-ID: On Mon, 9 Feb 2004, Hendricks David W. wrote: > We don't need to with nVidia, we can run their VGA BIOS using testbios. > > Though in the perfect world, they'd be more forthcoming with specs so that > someone can make an LB port for their nForce boards. We'll have to see how big this all gets. The one good thing about running the BIOS on the board is that linuxbios doesn't get too big, i.e you don't need code in linuxbios to initiate a particular board. The size is the emulator code -- no more. If we put in code for every card, how big will it get? How big is the ATI Radeon code? I still like this a lot, however. Certainly for boards with ATI glued on this is a huge win. ron From rminnich at lanl.gov Mon Feb 9 18:51:00 2004 From: rminnich at lanl.gov (ron minnich) Date: Mon Feb 9 18:51:00 2004 Subject: ATI gets a clue. In-Reply-To: Message-ID: On Mon, 9 Feb 2004, Terry Blunt wrote: > Maybe I'm missing something, but I can never understand hardware > manufacturers being cagey about their specs. I would have thought it would > save them a lot of hassle if they *didn't* have to write drivers themselves. 2 reasons. First, somebody might steal their ideas. Evidently this happens. The second is really complicated, but works like this. Suppose you create and design feature X into your chipset. You might find, via a lawsuit, that feature X is patented by company Y. I've talked to vendors who would like to open their hardware but are scared to do so for this very reason -- they might have designed a patented feature into their hardware without realizing it. ron From ollie at lanl.gov Mon Feb 9 18:58:01 2004 From: ollie at lanl.gov (Li-Ta Lo) Date: Mon Feb 9 18:58:01 2004 Subject: ATI gets a clue. In-Reply-To: References: Message-ID: <1076371938.4047.20.camel@exponential.lanl.gov> On Mon, 2004-02-09 at 16:18, Terry Blunt wrote: > "Hendricks David W." wrote: > > > We don't need to with nVidia, we can run their VGA BIOS using testbios. > > > > Though in the perfect world, they'd be more forthcoming with specs so that > > someone can make an LB port for their nForce boards. > > > > On Mon, 9 Feb 2004, Carlos Silva wrote: > > > > > Really nice news... i'll keep dreaming that nvidia will do the same. > > Maybe I'm missing something, but I can never understand hardware > manufacturers being cagey about their specs. I would have thought it would > save them a lot of hassle if they *didn't* have to write drivers themselves. > If they made the information available with suggestions and worked examples, > the software industry would do it all for them. > >From my previous experience working for some chipset company, there are reasons not to release the spec. 1. For software guys, if the software can be written by outside parties, most of the people in the software dept. are going to be laid off. 2. For hardware guys, they made bugs too. They need software guys to save their ass. Of course they want as few people know they are stupid as possible. 3. For marketing guys, it is a rule in efficient market theory. The less information avaliable in the market the more profit an insider can make from the market. Why should the company release those inside information to hurt its own profit ? Ollie From ollie at lanl.gov Mon Feb 9 19:03:00 2004 From: ollie at lanl.gov (Li-Ta Lo) Date: Mon Feb 9 19:03:00 2004 Subject: ATI gets a clue. In-Reply-To: References: Message-ID: <1076372250.4047.24.camel@exponential.lanl.gov> On Mon, 2004-02-09 at 17:03, ron minnich wrote: > On Mon, 9 Feb 2004, Hendricks David W. wrote: > > > We don't need to with nVidia, we can run their VGA BIOS using testbios. > > > > Though in the perfect world, they'd be more forthcoming with specs so that > > someone can make an LB port for their nForce boards. > > We'll have to see how big this all gets. The one good thing about running > the BIOS on the board is that linuxbios doesn't get too big, i.e you don't > need code in linuxbios to initiate a particular board. The size is the > emulator code -- no more. If we put in code for every card, how big will > it get? How big is the ATI Radeon code? > > I still like this a lot, however. Certainly for boards with ATI glued on > this is a huge win. > I have no idea about ATI chips. But from what I have done on SiS chipset, if you do it correctly, that can be made quite small. It is possible smaller than the emulator+VGA BIOS (if you are working on embedded systems, the VGA BIOS takes the space too). Ollie From hansolofalcon at worldnet.att.net Mon Feb 9 20:20:01 2004 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Mon Feb 9 20:20:01 2004 Subject: ATI gets a clue. In-Reply-To: <402814CC.8000303@bitworks.com> Message-ID: <001001c3ef76$3de1e660$6401a8c0@who5> Hello (again) from Gregg C Levine Richard, I've got a Mach64 chip here, or at least one part of the set, here. Do you know where I can track down the literature for it? I've been resisting designing it into a design because of that problem. And yes, I've got a number of ATI based video cards here, probably both either PCI, or AGP based. And yes, this is indeed wonderful news. ------------------- Gregg C Levine hansolofalcon at worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke."? Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) > -----Original Message----- > From: linuxbios-admin at clustermatic.org [mailto:linuxbios- > admin at clustermatic.org] On Behalf Of Richard Smith > Sent: Monday, February 09, 2004 6:16 PM > To: dwh at lanl.gov > Cc: linuxbios at clustermatic.org > Subject: Re: ATI gets a clue. > > Hendricks David W. wrote: > > > Woohoo! Does this also apply to their latest R3xx core Radeons such as the > > 8500 and up? Or only their old crummy ones? > > > > Bitworks's agreement only covers the Rage Mobility M1 which is several > years old and Mach64 based. > > I don't know about the new cores. Probally not as they are not trying > to sell those into the embedded market. > > -- > Richard A. Smith > rsmith at bitworks.com > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From benwang at synrax.com Mon Feb 9 23:31:00 2004 From: benwang at synrax.com (Ben Wang) Date: Mon Feb 9 23:31:00 2004 Subject: LinuxBIOS Message-ID: <402862AD.8090802@synrax.com> Hi, I have been following the mailinglist for some time now (several months) I have noticed that there is alot of active development. I represent a System Integration company (Synrax) based in Australia however, I have also been in contact with my manufacturers and have managed to capture their interest regarding LinuxBIOS. These manufacturers include: Axiomtek (http://www.axiomtek.com.tw) Iwill (http://www.iwill.net) Evalue (http://www.evalue-tech.com) Axiomtek and Evalue produce embedded SBCs whilst Iwill products Server/Workstation mainboards. My question is, what type of support documentation and/or other information is required to take LinuxBIOS to an even greater level? I wish to try/port LinuxBIOS to as many different boards as I can (time/resources permitting). Unfortunately, BIOS level programming is a relatively new area for me so my contributions may be limited to testing and providing documentation (where possible) initially. Thank you for taking the time to read this. Regards, Ben Wang Senior Applications Engineer, Synrax Australia Pty. Ltd. From stepan at suse.de Tue Feb 10 06:18:01 2004 From: stepan at suse.de (Stefan Reinauer) Date: Tue Feb 10 06:18:01 2004 Subject: What is this good for? Message-ID: <20040210112552.GB6764@suse.de> Hi, I appreciate that we only have to do one reset when optimizing HT links: http://cvs.sourceforge.net/viewcvs.py/freebios/freebios2/src/northbridge/amd/amdk8/misc_control.c?r1=1.4&r2=1.5 What I don't like about the whole situation is the fact that this code does not honour the actually available links but does hardcodes. This will break Athlon64 systems _ONCE AGAIN_ Please, instead of removing my comments, do read them - They explain pretty well why certain code is only enabled for CONFIG_MAX_CPUS > 1 Best regards, Stefan Reinauer -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From spidermantm at freenet.de Tue Feb 10 09:55:01 2004 From: spidermantm at freenet.de (spidermantm at freenet.de) Date: Tue Feb 10 09:55:01 2004 Subject: where is a step-by-step tutorial ? Message-ID: An HTML attachment was scrubbed... URL: From ebiederman at lnxi.com Tue Feb 10 10:02:01 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Feb 10 10:02:01 2004 Subject: What is this good for? In-Reply-To: <20040210112552.GB6764@suse.de> References: <20040210112552.GB6764@suse.de> Message-ID: Stefan Reinauer writes: > Hi, > > I appreciate that we only have to do one reset when optimizing HT links: > > http://cvs.sourceforge.net/viewcvs.py/freebios/freebios2/src/northbridge/amd/amdk8/misc_control.c?r1=1.4&r2=1.5 > > > What I don't like about the whole situation is the fact that this code > does not honour the actually available links but does hardcodes. > This will break Athlon64 systems _ONCE AGAIN_ > > Please, instead of removing my comments, do read them - They explain > pretty well why certain code is only enabled for CONFIG_MAX_CPUS > 1 Ugh yes that change looks nasty. Here is the version I am running, and it does work on AMD64 systems. It relies on the fact that the unused HT links return 0, instead of doing the prettier thing of walking the capabilities, but it does work. I don't have time at the moment to get this merged, but at least this will give you something to work with. Eric /* Turn off machine check triggers when reading * pci space where there are no devices. * This is necessary when scaning the bus for * devices which is done by the kernel */ #include #include #include #include #include #include #include "./cpu_rev.c" #include "amdk8.h" #define IOMMU_APETURE_SIZE (64*1024*1024) /* 64M */ static void mcf3_read_resources(device_t dev) { struct resource *resource; /* Read the generic PCI resources */ pci_dev_read_resources(dev); /* If we are not the first processor don't allocate the gart apeture */ if (dev->path.u.pci.devfn != PCI_DEVFN(24, 3)) { return; } /* Add a 64M Gart apeture resource */ if (dev->resources < MAX_RESOURCES) { resource = &dev->resource[dev->resources]; dev->resources++; resource->base = 0; resource->size = IOMMU_APETURE_SIZE; resource->align = log2(resource->size); resource->gran = log2(resource->size); resource->limit = 0xffffffff; /* 4G */ resource->flags = IORESOURCE_MEM; resource->index = 0x94; } else { printk_err("%s Unexpeted resource shortage\n", dev_path(dev)); } } static void mcf3_set_resources(device_t dev) { struct resource *resource, *last; last = &dev->resource[dev->resources]; for(resource = &dev->resource[0]; resource < last; resource++) { if (resource->index == 0x94) { device_t pdev; uint32_t base; uint32_t size; size = (0<<6)|(0<<5)|(0<<4)|((log2(resource->size) - 25) << 1)|(0<<0); base = ((resource->base) >> 25) & 0x00007fff; pdev = 0; while(pdev = dev_find_device(PCI_VENDOR_ID_AMD, 0x1103, pdev)) { /* I want a 64M GART apeture */ pci_write_config32(pdev, 0x90, (0<<6)|(0<<5)|(0<<4)|(1<<1)|(0<<0)); /* Store the GART base address */ pci_write_config32(pdev, 0x94, base); /* Don't set the GART Table base address */ pci_write_config32(pdev, 0x98, 0); printk_debug( "%s %02x <- [0x%08lx - 0x%08lx] mem \n", dev_path(pdev), resource->index, resource->base, resource->base + resource->size - 1); } /* Remember this resource has been stored */ resource->flags |= IORESOURCE_STORED; } } /* Set the generic PCI resources */ pci_dev_set_resources(dev); } static void misc_control_init(struct device *dev) { uint32_t cmd, cmd_ref; int needs_reset; struct device *f0_dev, *f2_dev; printk_debug("NB: Function 3 Misc Control.. "); needs_reset = 0; /* Disable Machine checks from Invalid Locations. * This is needed for PC backwards compatibility. */ cmd = pci_read_config32(dev, 0x44); cmd |= (1<<6) | (1<<25); pci_write_config32(dev, 0x44, cmd ); if (is_cpu_pre_c0()) { /* Errata 58 * Disable CPU low power states C2, C1 and throttling */ cmd = pci_read_config32(dev, 0x80); cmd &= ~(1<<0); pci_write_config32(dev, 0x80, cmd ); cmd = pci_read_config32(dev, 0x84); cmd &= ~(1<<24); cmd &= ~(1<<8); pci_write_config32(dev, 0x84, cmd ); /* Errata 66 * Limit the number of downstream posted requests to 1 */ cmd = pci_read_config32(dev, 0x70); if ((cmd & (3 << 0)) != 2) { cmd &= ~(3<<0); cmd |= (2<<0); pci_write_config32(dev, 0x70, cmd ); needs_reset = 1; } cmd = pci_read_config32(dev, 0x7c); if ((cmd & (3 << 4)) != 0) { cmd &= ~(3<<4); cmd |= (0<<4); pci_write_config32(dev, 0x7c, cmd ); needs_reset = 1; } /* Clock Power/Timing Low */ cmd = pci_read_config32(dev, 0xd4); if (cmd != 0x000D0001) { cmd = 0x000D0001; pci_write_config32(dev, 0xd4, cmd); needs_reset = 1; /* Needed? */ } } else { uint32_t dcl; f2_dev = dev_find_slot(0, dev->path.u.pci.devfn - 3 + 2); /* Errata 98 * Set Clk Ramp Hystersis to 7 * Clock Power/Timing Low */ cmd_ref = 0x04e20707; /* Registered */ dcl = pci_read_config32(f2_dev, DRAM_CONFIG_LOW); if (dcl & DCL_UnBufDimm) { cmd_ref = 0x000D0701; /* Unbuffered */ } cmd = pci_read_config32(dev, 0xd4); if(cmd != cmd_ref) { pci_write_config32(dev, 0xd4, cmd_ref ); needs_reset = 1; /* Needed? */ } } /* Optimize the Link read pointers */ f0_dev = dev_find_slot(0, dev->path.u.pci.devfn - 3); if (f0_dev) { int link; cmd_ref = cmd = pci_read_config32(dev, 0xdc); for(link = 0; link < 3; link++) { uint32_t link_type; unsigned reg; reg = 0x98 + (link * 0x20); link_type = pci_read_config32(f0_dev, reg); if (link_type & LinkConnected) { cmd &= 0xff << (link *8); /* FIXME this assumes the device on the other side is an AMD device */ cmd |= 0x25 << (link *8); } } if (cmd != cmd_ref) { pci_write_config32(dev, 0xdc, cmd); needs_reset = 1; } } else { printk_err("Missing f0 device!\n"); } if (needs_reset) { printk_debug("resetting cpu\n"); hard_reset(); } printk_debug("done.\n"); } static struct device_operations mcf3_ops = { .read_resources = mcf3_read_resources, .set_resources = mcf3_set_resources, .enable_resources = pci_dev_enable_resources, .init = misc_control_init, .scan_bus = 0, }; static struct pci_driver mcf3_driver __pci_driver = { .ops = &mcf3_ops, .vendor = PCI_VENDOR_ID_AMD, .device = 0x1103, }; From ebiederman at lnxi.com Tue Feb 10 10:05:01 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Feb 10 10:05:01 2004 Subject: /dev/bios for 2.6 In-Reply-To: <4025C6DC.6060501@bitworks.com> References: <3174569B9743D511922F00A0C943142303990D22@TYANWEB> <20031210213555.GB9144@suse.de> <4025C6DC.6060501@bitworks.com> Message-ID: Richard Smith writes: > Any chance of getting devbios updated to 2.6? I get Invalid module format > trying to load. > > Or perhaps someone will tell me if the MTD drivers support a AMD29f040b. If you look in jedec_probe.c AM29F040, and AM29LV040B are supported so if it is not it should be just a tiny tweak to jedec probe to get the chip recognized. > The MTD > webpage dosen't have any info and I build and inserted lots of different mtd > modules but nothing indicated they did anything. Do you have a proper map driver? Eric From rminnich at lanl.gov Tue Feb 10 10:31:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Tue Feb 10 10:31:01 2004 Subject: What is this good for? In-Reply-To: Message-ID: I'll talk to the guys who merged that code in and we'll update to this newer stuff. ron From stepan at suse.de Tue Feb 10 10:38:00 2004 From: stepan at suse.de (Stefan Reinauer) Date: Tue Feb 10 10:38:00 2004 Subject: /dev/bios for 2.6 In-Reply-To: <4025C6DC.6060501@bitworks.com> References: <3174569B9743D511922F00A0C943142303990D22@TYANWEB> <20031210213555.GB9144@suse.de> <4025C6DC.6060501@bitworks.com> Message-ID: <20040210154950.GA4635@suse.de> * Richard Smith [040208 06:19]: > Any chance of getting devbios updated to 2.6? I get Invalid module > format trying to load. I don't think it should survive another decade.. there were some efforts to integrate devbios into mtd, which i am happy to support, but it dried out again.. mtd is definitely the way to go! Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From rminnich at lanl.gov Tue Feb 10 10:38:05 2004 From: rminnich at lanl.gov (ron minnich) Date: Tue Feb 10 10:38:05 2004 Subject: What is this good for? In-Reply-To: Message-ID: On Tue, 10 Feb 2004, ron minnich wrote: > I'll talk to the guys who merged that code in and we'll update to this > newer stuff. FYI the reason for this merge was: - CVS had stopped working on the 2885 - YH Lu had submitted these changes some time ago - nothing else was forthcoming from other developers It is very helpful if we can all do as much as possible to get incremental patches in. I know we're all busy, but delayed commits and "giant commits" have caused some real trouble for several platforms. Please keep this in mind as you work on your improvements to the code base. thanks ron From rminnich at lanl.gov Tue Feb 10 10:42:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Tue Feb 10 10:42:01 2004 Subject: latest commit of changes from here In-Reply-To: Message-ID: I note that there is a hack that was allowed to creep in related to VGA, and it will be removed shortly. However, those of you with AGP on HT link 0 will find it very useful. Also, note that there is now an amdk8_enable_resources, due to the need for special VGA init on the K8 northbridge (i.e. you don't just set PCI_BRIDGE_CONTROL and have it all work; you have to set some routing in an iopair and set up an mmiopair for VGA to work). These northbridge fixes are the first required step in getting VGA/AGP support done for LinuxBIOS. ron From rsmith at bitworks.com Tue Feb 10 10:50:00 2004 From: rsmith at bitworks.com (Richard Smith) Date: Tue Feb 10 10:50:00 2004 Subject: /dev/bios for 2.6 In-Reply-To: References: <3174569B9743D511922F00A0C943142303990D22@TYANWEB> <20031210213555.GB9144@suse.de> <4025C6DC.6060501@bitworks.com> Message-ID: <402900C4.4050609@bitworks.com> Eric W. Biederman wrote: > If you look in jedec_probe.c AM29F040, and AM29LV040B are supported so if > it is not it should be just a tiny tweak to jedec probe to get the chip > recognized. Ah.. jdec_probe ok well that gives me a place to start. I'll go see if I can tweak that to find a AM29F040B. I would have though that the AM29F040 id would have matched. > >>The MTD >>webpage dosen't have any info and I build and inserted lots of different mtd >>modules but nothing indicated they did anything. > > Do you have a proper map driver? Er... I don't know. How do I check? I've not found any documentation explaining anything about useing the MTD with BIOS type flash chips. Its all Msystems or CF stuff so I've just been guessing. My chip is hanging out just like a normal BIOS chip would at physical address 0xfff80000 - 0xffffffff. The 1Meg extended BIOS space area should be enabled in my chipset. So BIOS chipselects should be generated for 0xfff0ffff up. There was an option in the kernel building that asked for a start address and a size to which I entered 0xfff80000 and 0x80000. Hmmm... come to think about it now I may have entered 0x80000 rather than 0xfff80000 as the start address.. In any case.. given my setup what and where do I config this? -- Richard A. Smith rsmith at bitworks.com From rsmith at bitworks.com Tue Feb 10 11:17:01 2004 From: rsmith at bitworks.com (Richard Smith) Date: Tue Feb 10 11:17:01 2004 Subject: ATI gets a clue. In-Reply-To: <001001c3ef76$3de1e660$6401a8c0@who5> References: <001001c3ef76$3de1e660$6401a8c0@who5> Message-ID: <40290768.7030301@bitworks.com> Gregg C Levine wrote: > Hello (again) from Gregg C Levine > Richard, I've got a Mach64 chip here, or at least one part of the set, > here. Do you know where I can track down the literature for it? I've > been resisting designing it into a design because of that problem. And > yes, I've got a number of ATI based video cards here, probably both > either PCI, or AGP based. You have to set up an NDA with ATI to get the info. I'm allowed to release my _code_ but the docs describing all the registers are protected by the NDA and are not publicly available. -- Richard A. Smith rsmith at bitworks.com From ebiederman at lnxi.com Tue Feb 10 11:46:01 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Feb 10 11:46:01 2004 Subject: What is this good for? In-Reply-To: References: Message-ID: ron minnich writes: > On Tue, 10 Feb 2004, ron minnich wrote: > > > I'll talk to the guys who merged that code in and we'll update to this > > newer stuff. > > FYI the reason for this merge was: > - CVS had stopped working on the 2885 > - YH Lu had submitted these changes some time ago > - nothing else was forthcoming from other developers > > It is very helpful if we can all do as much as possible to get incremental > patches in. I know we're all busy, but delayed commits and "giant commits" > have caused some real trouble for several platforms. Please keep this in > mind as you work on your improvements to the code base. Right. This is why I would very much like to get us using a distributed version control system, to help ease the merges. For many of the people developing LinuxBIOS the primary responsibility is to our internal trees that we use internally or support our customers with. This allows a buffer so we are certain big changes don't break things until we are ready to retest things in our internal trees. And it allows hacks that only work for a few boards to be used before the code is generalized to work for everyone. Eric From ebiederman at lnxi.com Tue Feb 10 11:51:00 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Feb 10 11:51:00 2004 Subject: /dev/bios for 2.6 In-Reply-To: <402900C4.4050609@bitworks.com> References: <3174569B9743D511922F00A0C943142303990D22@TYANWEB> <20031210213555.GB9144@suse.de> <4025C6DC.6060501@bitworks.com> <402900C4.4050609@bitworks.com> Message-ID: Richard Smith writes: > Eric W. Biederman wrote: > > > If you look in jedec_probe.c AM29F040, and AM29LV040B are supported so if > > it is not it should be just a tiny tweak to jedec probe to get the chip > > recognized. > > Ah.. jdec_probe ok well that gives me a place to start. I'll go see if I can > tweak that to find a AM29F040B. I would have though that the AM29F040 id would > have matched. It might I don't know how you have things configured. > >> The MTD webpage dosen't have any info and I build and inserted lots of > >> different mtd > >>modules but nothing indicated they did anything. > > Do you have a proper map driver? > > Er... I don't know. How do I check? MTD has 3 levels of drivers. - The map driver (i.e. ich2rom and amd76xrom ) which knows how to find the ROM chip on a specific board, or chipset. - The probe driver (cfi_probe or jedec_probe) which knows how to detect which ROM chip you have. - The chip driver (cfi_cmdset_0001 cfi_cmdset_002..) which knows how to use a specific command set regardless of which device you have. > I've not found any documentation explaining anything about useing the MTD with > BIOS type flash chips. Its all Msystems or CF stuff so I've just been guessing. > > > My chip is hanging out just like a normal BIOS chip would at physical address > 0xfff80000 - 0xffffffff. The 1Meg extended BIOS space area should be enabled in > my chipset. So BIOS chipselects should be generated for 0xfff0ffff up. > There was an option in the kernel building that asked for a start address and a > size to which I entered 0xfff80000 and 0x80000. > > Hmmm... come to think about it now I may have entered 0x80000 rather than > 0xfff80000 as the start address.. > > In any case.. given my setup what and where do I config this? Basically it depends on the map driver you are using. Some of them can look at your chipset and figure these things out. Some are really generic and you have to hard code things. I don't know if those work at all. Eric From stepan at suse.de Tue Feb 10 12:04:01 2004 From: stepan at suse.de (Stefan Reinauer) Date: Tue Feb 10 12:04:01 2004 Subject: What is this good for? In-Reply-To: References: Message-ID: <20040210171734.GG4635@suse.de> * Eric W. Biederman [040210 18:05]: > For many of the people developing LinuxBIOS the primary responsibility > is to our internal trees that we use internally or support our > customers with. This allows a buffer so we are certain big changes > don't break things until we are ready to retest things in our internal > trees. And it allows hacks that only work for a few boards to be > used before the code is generalized to work for everyone. This is perfectly fine as long as the code is reviewed before it goes to the official public tree to not contain these hacks anymore. Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From rminnich at lanl.gov Tue Feb 10 12:27:00 2004 From: rminnich at lanl.gov (ron minnich) Date: Tue Feb 10 12:27:00 2004 Subject: What is this good for? In-Reply-To: <20040210171734.GG4635@suse.de> Message-ID: On Tue, 10 Feb 2004, Stefan Reinauer wrote: > * Eric W. Biederman [040210 18:05]: > > For many of the people developing LinuxBIOS the primary responsibility > > is to our internal trees that we use internally or support our > > customers with. This allows a buffer so we are certain big changes > > don't break things until we are ready to retest things in our internal > > trees. And it allows hacks that only work for a few boards to be > > used before the code is generalized to work for everyone. > > This is perfectly fine as long as the code is reviewed before it goes to > the official public tree to not contain these hacks anymore. Also, for now I want to maintain the sourceforge as the definitive code base. sourceforge has the wonderful property of being well known, reasonably reliable, understood by most people, and vendor neutral. A potential replacement for the "definitive code base" should support at least these properties. ron From YhLu at tyan.com Tue Feb 10 12:44:00 2004 From: YhLu at tyan.com (YhLu) Date: Tue Feb 10 12:44:00 2004 Subject: =?GB2312?B?tPC4tDogV2hhdCBpcyB0aGlzIGdvb2QgZm9yPw==?= Message-ID: <3174569B9743D511922F00A0C9431423041D1FCE@TYANWEB> Eric, Can you commit the patch that can reduce the time of memory clearing? If the MB is configured with 8G, it will take around 2 minutes to get it finished. Regards YH. -----????----- ???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] ????: 2004?2?10? 7:21 ???: Stefan Reinauer ??: linuxbios at clustermatic.org ??: Re: What is this good for? Stefan Reinauer writes: > Hi, > > I appreciate that we only have to do one reset when optimizing HT links: > > http://cvs.sourceforge.net/viewcvs.py/freebios/freebios2/src/northbridge/amd /amdk8/misc_control.c?r1=1.4&r2=1.5 > > > What I don't like about the whole situation is the fact that this code > does not honour the actually available links but does hardcodes. > This will break Athlon64 systems _ONCE AGAIN_ > > Please, instead of removing my comments, do read them - They explain > pretty well why certain code is only enabled for CONFIG_MAX_CPUS > 1 Ugh yes that change looks nasty. Here is the version I am running, and it does work on AMD64 systems. It relies on the fact that the unused HT links return 0, instead of doing the prettier thing of walking the capabilities, but it does work. I don't have time at the moment to get this merged, but at least this will give you something to work with. Eric /* Turn off machine check triggers when reading * pci space where there are no devices. * This is necessary when scaning the bus for * devices which is done by the kernel */ #include #include #include #include #include #include #include "./cpu_rev.c" #include "amdk8.h" #define IOMMU_APETURE_SIZE (64*1024*1024) /* 64M */ static void mcf3_read_resources(device_t dev) { struct resource *resource; /* Read the generic PCI resources */ pci_dev_read_resources(dev); /* If we are not the first processor don't allocate the gart apeture */ if (dev->path.u.pci.devfn != PCI_DEVFN(24, 3)) { return; } /* Add a 64M Gart apeture resource */ if (dev->resources < MAX_RESOURCES) { resource = &dev->resource[dev->resources]; dev->resources++; resource->base = 0; resource->size = IOMMU_APETURE_SIZE; resource->align = log2(resource->size); resource->gran = log2(resource->size); resource->limit = 0xffffffff; /* 4G */ resource->flags = IORESOURCE_MEM; resource->index = 0x94; } else { printk_err("%s Unexpeted resource shortage\n", dev_path(dev)); } } static void mcf3_set_resources(device_t dev) { struct resource *resource, *last; last = &dev->resource[dev->resources]; for(resource = &dev->resource[0]; resource < last; resource++) { if (resource->index == 0x94) { device_t pdev; uint32_t base; uint32_t size; size = (0<<6)|(0<<5)|(0<<4)|((log2(resource->size) - 25) << 1)|(0<<0); base = ((resource->base) >> 25) & 0x00007fff; pdev = 0; while(pdev = dev_find_device(PCI_VENDOR_ID_AMD, 0x1103, pdev)) { /* I want a 64M GART apeture */ pci_write_config32(pdev, 0x90, (0<<6)|(0<<5)|(0<<4)|(1<<1)|(0<<0)); /* Store the GART base address */ pci_write_config32(pdev, 0x94, base); /* Don't set the GART Table base address */ pci_write_config32(pdev, 0x98, 0); printk_debug( "%s %02x <- [0x%08lx - 0x%08lx] mem \n", dev_path(pdev), resource->index, resource->base, resource->base + resource->size - 1); } /* Remember this resource has been stored */ resource->flags |= IORESOURCE_STORED; } } /* Set the generic PCI resources */ pci_dev_set_resources(dev); } static void misc_control_init(struct device *dev) { uint32_t cmd, cmd_ref; int needs_reset; struct device *f0_dev, *f2_dev; printk_debug("NB: Function 3 Misc Control.. "); needs_reset = 0; /* Disable Machine checks from Invalid Locations. * This is needed for PC backwards compatibility. */ cmd = pci_read_config32(dev, 0x44); cmd |= (1<<6) | (1<<25); pci_write_config32(dev, 0x44, cmd ); if (is_cpu_pre_c0()) { /* Errata 58 * Disable CPU low power states C2, C1 and throttling */ cmd = pci_read_config32(dev, 0x80); cmd &= ~(1<<0); pci_write_config32(dev, 0x80, cmd ); cmd = pci_read_config32(dev, 0x84); cmd &= ~(1<<24); cmd &= ~(1<<8); pci_write_config32(dev, 0x84, cmd ); /* Errata 66 * Limit the number of downstream posted requests to 1 */ cmd = pci_read_config32(dev, 0x70); if ((cmd & (3 << 0)) != 2) { cmd &= ~(3<<0); cmd |= (2<<0); pci_write_config32(dev, 0x70, cmd ); needs_reset = 1; } cmd = pci_read_config32(dev, 0x7c); if ((cmd & (3 << 4)) != 0) { cmd &= ~(3<<4); cmd |= (0<<4); pci_write_config32(dev, 0x7c, cmd ); needs_reset = 1; } /* Clock Power/Timing Low */ cmd = pci_read_config32(dev, 0xd4); if (cmd != 0x000D0001) { cmd = 0x000D0001; pci_write_config32(dev, 0xd4, cmd); needs_reset = 1; /* Needed? */ } } else { uint32_t dcl; f2_dev = dev_find_slot(0, dev->path.u.pci.devfn - 3 + 2); /* Errata 98 * Set Clk Ramp Hystersis to 7 * Clock Power/Timing Low */ cmd_ref = 0x04e20707; /* Registered */ dcl = pci_read_config32(f2_dev, DRAM_CONFIG_LOW); if (dcl & DCL_UnBufDimm) { cmd_ref = 0x000D0701; /* Unbuffered */ } cmd = pci_read_config32(dev, 0xd4); if(cmd != cmd_ref) { pci_write_config32(dev, 0xd4, cmd_ref ); needs_reset = 1; /* Needed? */ } } /* Optimize the Link read pointers */ f0_dev = dev_find_slot(0, dev->path.u.pci.devfn - 3); if (f0_dev) { int link; cmd_ref = cmd = pci_read_config32(dev, 0xdc); for(link = 0; link < 3; link++) { uint32_t link_type; unsigned reg; reg = 0x98 + (link * 0x20); link_type = pci_read_config32(f0_dev, reg); if (link_type & LinkConnected) { cmd &= 0xff << (link *8); /* FIXME this assumes the device on the other side is an AMD device */ cmd |= 0x25 << (link *8); } } if (cmd != cmd_ref) { pci_write_config32(dev, 0xdc, cmd); needs_reset = 1; } } else { printk_err("Missing f0 device!\n"); } if (needs_reset) { printk_debug("resetting cpu\n"); hard_reset(); } printk_debug("done.\n"); } static struct device_operations mcf3_ops = { .read_resources = mcf3_read_resources, .set_resources = mcf3_set_resources, .enable_resources = pci_dev_enable_resources, .init = misc_control_init, .scan_bus = 0, }; static struct pci_driver mcf3_driver __pci_driver = { .ops = &mcf3_ops, .vendor = PCI_VENDOR_ID_AMD, .device = 0x1103, }; _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From YhLu at tyan.com Tue Feb 10 12:50:01 2004 From: YhLu at tyan.com (YhLu) Date: Tue Feb 10 12:50:01 2004 Subject: =?GB2312?B?tPC4tDogL2Rldi9iaW9zIGZvciAyLjY=?= Message-ID: <3174569B9743D511922F00A0C9431423041D1FCF@TYANWEB> Why not use flash_rom in freebios2/util? YH -----????----- ???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] ????: 2004?2?10? 9:10 ???: RSmith at bitworks.com ??: stepan at suse.de; linuxbios at clustermatic.org ??: Re: /dev/bios for 2.6 Richard Smith writes: > Eric W. Biederman wrote: > > > If you look in jedec_probe.c AM29F040, and AM29LV040B are supported so if > > it is not it should be just a tiny tweak to jedec probe to get the chip > > recognized. > > Ah.. jdec_probe ok well that gives me a place to start. I'll go see if I can > tweak that to find a AM29F040B. I would have though that the AM29F040 id would > have matched. It might I don't know how you have things configured. > >> The MTD webpage dosen't have any info and I build and inserted lots of > >> different mtd > >>modules but nothing indicated they did anything. > > Do you have a proper map driver? > > Er... I don't know. How do I check? MTD has 3 levels of drivers. - The map driver (i.e. ich2rom and amd76xrom ) which knows how to find the ROM chip on a specific board, or chipset. - The probe driver (cfi_probe or jedec_probe) which knows how to detect which ROM chip you have. - The chip driver (cfi_cmdset_0001 cfi_cmdset_002..) which knows how to use a specific command set regardless of which device you have. > I've not found any documentation explaining anything about useing the MTD with > BIOS type flash chips. Its all Msystems or CF stuff so I've just been guessing. > > > My chip is hanging out just like a normal BIOS chip would at physical address > 0xfff80000 - 0xffffffff. The 1Meg extended BIOS space area should be enabled in > my chipset. So BIOS chipselects should be generated for 0xfff0ffff up. > There was an option in the kernel building that asked for a start address and a > size to which I entered 0xfff80000 and 0x80000. > > Hmmm... come to think about it now I may have entered 0x80000 rather than > 0xfff80000 as the start address.. > > In any case.. given my setup what and where do I config this? Basically it depends on the map driver you are using. Some of them can look at your chipset and figure these things out. Some are really generic and you have to hard code things. I don't know if those work at all. Eric _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From rsmith at bitworks.com Tue Feb 10 13:41:00 2004 From: rsmith at bitworks.com (Richard Smith) Date: Tue Feb 10 13:41:00 2004 Subject: =?GB2312?B?tPC4tDogL2Rldi9iaW9zIGZvciAyLjY=?= In-Reply-To: <3174569B9743D511922F00A0C9431423041D1FCF@TYANWEB> References: <3174569B9743D511922F00A0C9431423041D1FCF@TYANWEB> Message-ID: <402928C8.6010308@bitworks.com> YhLu wrote: > Why not use flash_rom in freebios2/util? > No reason except ignorance. My board is still only under v1 and so I've never checked out a v2 tree. I'll give it go and see what happens. -- Richard A. Smith rsmith at bitworks.com From bari at onelabs.com Tue Feb 10 13:46:01 2004 From: bari at onelabs.com (Bari Ari) Date: Tue Feb 10 13:46:01 2004 Subject: ATI gets a clue. In-Reply-To: <40290768.7030301@bitworks.com> References: <001001c3ef76$3de1e660$6401a8c0@who5> <40290768.7030301@bitworks.com> Message-ID: <40292ADF.5090902@onelabs.com> Richard Smith wrote: > > You have to set up an NDA with ATI to get the info. I'm allowed to > release my _code_ but the docs describing all the registers are > protected by the NDA and are not publicly available. > Are they allowing you to release source or just a binary? If it's source then it gets tricky as to how you comment your code since you're under NDA. There have been several issues that have come up on this list and all I could do was offer a binary solution. -Bari From rsmith at bitworks.com Tue Feb 10 14:11:00 2004 From: rsmith at bitworks.com (Richard Smith) Date: Tue Feb 10 14:11:00 2004 Subject: ATI gets a clue. In-Reply-To: <40292ADF.5090902@onelabs.com> References: <001001c3ef76$3de1e660$6401a8c0@who5> <40290768.7030301@bitworks.com> <40292ADF.5090902@onelabs.com> Message-ID: <40292FE2.6030804@bitworks.com> Bari Ari wrote: >> You have to set up an NDA with ATI to get the info. I'm allowed to >> release my _code_ but the docs describing all the registers are >> protected by the NDA and are not publicly available. >> > Are they allowing you to release source or just a binary? > > If it's source then it gets tricky as to how you comment your code since > you're under NDA. There have been several issues that have come up on > this list and all I could do was offer a binary solution. I specifically asked about source and I was very detailed in my request so I am interpreting thier response to source really means source. I plan on integrating it into the LinuxBios code for our board so binary only is not an option. Yes commenting could be abused if I started listing all the registers, thier descriptions and meanings in my comments. I don't plan on commenting any different than I normally would though. Which pretty much only involves heavly commenting things that don't work like the docs say they should. Most of the info is already present in the atyfb kernel framebuffer driver anyway. I've requested an "offical" permission statement so I'll just have to wait and see what in that to really know. -- Richard A. Smith rsmith at bitworks.com From ebiederman at lnxi.com Tue Feb 10 16:09:01 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Feb 10 16:09:01 2004 Subject: =?gb2312?b?tPC4tA==?=: What is this good for? In-Reply-To: <3174569B9743D511922F00A0C9431423041D1FCE@TYANWEB> References: <3174569B9743D511922F00A0C9431423041D1FCE@TYANWEB> Message-ID: YhLu writes: > Eric, > > Can you commit the patch that can reduce the time of memory clearing? > > If the MB is configured with 8G, it will take around 2 minutes to get it > finished. Not at least until friday. I am quite heavily loaded at the moment. But thank you for bugging me. I need the reminders if I am going to get this done soon. I currently have this working in just a couple of seconds so it is definitely worthwhile. Eric From dwh at lanl.gov Tue Feb 10 16:15:01 2004 From: dwh at lanl.gov (Hendricks David W.) Date: Tue Feb 10 16:15:01 2004 Subject: LinuxBIOS....on desktop PCs? In-Reply-To: <20040210040416.HJTD15913.imf16aec.mail.bellsouth.net@mail.bellsouth.net> Message-ID: That's a KT266 mainboard, which might be familiar with the Chaintech mainboard recently added. You might want to check out the details and see how similar they are. On Mon, 9 Feb 2004 bjm_ at bellsouth.net wrote: > Well...I'm running on an Athlon, yes...2GHz infact. Mainboard is a Shuttle Ak32a, not sure how big the ROM is, how big does it have to be to have LinuxBIOS? > > Oh I just wanted to try out LinuxBIOS because I heard it has fast boot times...and it's linux so it has to work ;) > > -Brad > > > > > From: "Hendricks David W." > > Date: 2004/02/09 Mon PM 05:05:46 EST > > To: bjm_ at bellsouth.net > > CC: linuxbios at clustermatic.org > > Subject: Re: LinuxBIOS....on desktop PCs? > > > > Yes, depending on which mainboard you're running. And with the recent > > revelations in VGA support (It works :)), I think LinuxBIOS is well > > underway for use in the desktop market. > > > > Did you have anything specific in mind? If you're looking for a mainboard, > > check out the Epia or perhaps the Chaintech 7KJD if you're looking for an > > Athlon platform. > > > > On Sat, 7 Feb 2004 bjm_ at bellsouth.net wrote: > > > > > Is it possible to have LinuxBIOS on desktop PCs? Was wondering...if so, I'd like to use it :) > > > > > > _______________________________________________ > > > Linuxbios mailing list > > > Linuxbios at clustermatic.org > > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > > > > > > From rminnich at lanl.gov Tue Feb 10 16:17:00 2004 From: rminnich at lanl.gov (ron minnich) Date: Tue Feb 10 16:17:00 2004 Subject: LinuxBIOS....on desktop PCs? In-Reply-To: Message-ID: On Tue, 10 Feb 2004, Hendricks David W. wrote: > That's a KT266 mainboard, which might be familiar with the Chaintech > mainboard recently added. You might want to check out the details and see > how similar they are. turns out the chaintech just added doesn't build, which I forget. Anyone wants to take a look, please do. ron From rminnich at lanl.gov Tue Feb 10 16:24:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Tue Feb 10 16:24:01 2004 Subject: flash_rom support for amd 8111 and pm49fl004 Message-ID: I just committed YhLu's updates to flash_from for the amd 8111 and pm49fl004 parts. This is in freebios2 only for now, since freebios 1 does not support this chipset anyway. ron From dwh at lanl.gov Tue Feb 10 16:24:08 2004 From: dwh at lanl.gov (Hendricks David W.) Date: Tue Feb 10 16:24:08 2004 Subject: LinuxBIOS In-Reply-To: <402862AD.8090802@synrax.com> Message-ID: Add Tyan to that list. Support documentation--HOWTOs are always nice. There are so many possible combinations of mainboards and variatous revisions of different mainboards and flash parts that it's impossible for any single party to test them all. If you get around to building and installing LinuxBIOS for your machine, we'd like to hear about your experience and details about which parts work. And you should add Tyan (http://www.tyan.com) to your list. Dr. Lu has contributed a lot to the project and the S2885 has shown to be a very capable workstation and server mainboard. On Tue, 10 Feb 2004, Ben Wang wrote: > Hi, > > I have been following the mailinglist for some time now (several months) > I have noticed that there is alot of active development. > > I represent a System Integration company (Synrax) based in Australia > however, I have also been in contact with my manufacturers and have > managed to capture their interest regarding LinuxBIOS. These > manufacturers include: > > Axiomtek (http://www.axiomtek.com.tw) > Iwill (http://www.iwill.net) > Evalue (http://www.evalue-tech.com) > > Axiomtek and Evalue produce embedded SBCs whilst Iwill products > Server/Workstation mainboards. > > My question is, what type of support documentation and/or other > information is required to take LinuxBIOS to an even greater level? > > I wish to try/port LinuxBIOS to as many different boards as I can > (time/resources permitting). Unfortunately, BIOS level programming is a > relatively new area for me so my contributions may be limited to testing > and providing documentation (where possible) initially. > > Thank you for taking the time to read this. > > Regards, > Ben Wang > Senior Applications Engineer, > Synrax Australia Pty. Ltd. > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From dwh at lanl.gov Tue Feb 10 16:54:01 2004 From: dwh at lanl.gov (Hendricks David W.) Date: Tue Feb 10 16:54:01 2004 Subject: LinuxBIOS In-Reply-To: Message-ID: And yes, Tyan is so important that I mentioned them twice. On Tue, 10 Feb 2004, Hendricks David W. wrote: > Add Tyan to that list. > > Support documentation--HOWTOs are always nice. There are so many possible > combinations of mainboards and variatous revisions of different mainboards > and flash parts that it's impossible for any single party to test them > all. If you get around to building and installing LinuxBIOS for your > machine, we'd like to hear about your experience and details about which > parts work. > > And you should add Tyan (http://www.tyan.com) to your list. Dr. Lu has > contributed a lot to the project and the S2885 has shown to be a very > capable workstation and server mainboard. > > On Tue, 10 Feb 2004, Ben Wang wrote: > > > Hi, > > > > I have been following the mailinglist for some time now (several months) > > I have noticed that there is alot of active development. > > > > I represent a System Integration company (Synrax) based in Australia > > however, I have also been in contact with my manufacturers and have > > managed to capture their interest regarding LinuxBIOS. These > > manufacturers include: > > > > Axiomtek (http://www.axiomtek.com.tw) > > Iwill (http://www.iwill.net) > > Evalue (http://www.evalue-tech.com) > > > > Axiomtek and Evalue produce embedded SBCs whilst Iwill products > > Server/Workstation mainboards. > > > > My question is, what type of support documentation and/or other > > information is required to take LinuxBIOS to an even greater level? > > > > I wish to try/port LinuxBIOS to as many different boards as I can > > (time/resources permitting). Unfortunately, BIOS level programming is a > > relatively new area for me so my contributions may be limited to testing > > and providing documentation (where possible) initially. > > > > Thank you for taking the time to read this. > > > > Regards, > > Ben Wang > > Senior Applications Engineer, > > Synrax Australia Pty. Ltd. > > _______________________________________________ > > Linuxbios mailing list > > Linuxbios at clustermatic.org > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From ebiederman at lnxi.com Tue Feb 10 22:08:00 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Feb 10 22:08:00 2004 Subject: 64MB MMIO Hole ? In-Reply-To: References: <1076459153.4047.416.camel@exponential.lanl.gov> Message-ID: ebiederman at lnxi.com (Eric W. Biederman) writes: > Li-Ta Lo writes: > > > Eric, > > > > You put a preprocessor warnning for 64MB MMIO Hole in > > the amdk8/northbridge.c. > > > > #warning "FIXME improve mtrr.c so we don't use up all of the mtrrs with > > a 64M MMIO hole" > > > > What exactly is it ? Is that for the AGP aperture (you call it > > IOMMU_APERTURE) ? > > No, although the IOMMU_APERATURE plays a role there. But this > was implemented before I implemented the IOMMU_APERATURE code > in misc_control.c The IOMMU_APERATURE is just another large I/O region as far as that code is concerned. > Consider a machine with 4GB of RAM. Not all of the RAM can > be used as there are PCI I/O devices at the end of memory. > With just positive mtrrs you get: > > 2GB > 1GB > 512MB > 256MB > 128MB > 64MB > ------ This is where you exhaust all six BIOS mtrrs. > 32MB > 16MB > ------ All 8 mtrrs are exhausted. > > So we need to find a way to assign MTRRS. But still be able > to assign a write-combining area to the video frame buffer. > > The linux mtrr support does not know how to cope with overlapping > mtrrs. I forgot to mention the very elegant solution to this problem. At some simple power of 2 the Opteron memory is hoisted above 4G. The overlapping mtrrs do not need to be implemented. This is something I would like to play with but I have not yet had the chance. The meaning of that FIXME is that we are currently misplacing a noticeable chunk of memory on Opteron machines with 4GB of RAM. Eric From bjm_ at bellsouth.net Tue Feb 10 22:22:01 2004 From: bjm_ at bellsouth.net (bjm_ at bellsouth.net) Date: Tue Feb 10 22:22:01 2004 Subject: LinuxBIOS....on desktop PCs? Message-ID: <20040211033709.KYKJ7256.imf18aec.mail.bellsouth.net@mail.bellsouth.net> >turns out the chaintech just added doesn't build, which I forget. Anyone >wants to take a look, please do. Ah...well, maybe later then? Or maybe when I get a nice embedded linux rackmount server to replace my Linksys router, and act as a webserver I maybe could use LinuxBIOS then eh? -Brad From rminnich at lanl.gov Wed Feb 11 09:56:00 2004 From: rminnich at lanl.gov (ron minnich) Date: Wed Feb 11 09:56:00 2004 Subject: LinuxBIOS....on desktop PCs? In-Reply-To: <20040211033709.KYKJ7256.imf18aec.mail.bellsouth.net@mail.bellsouth.net> Message-ID: On Tue, 10 Feb 2004 bjm_ at bellsouth.net wrote: > >turns out the chaintech just added doesn't build, which I forget. Anyone > >wants to take a look, please do. > > Ah...well, maybe later then? Or maybe when I get a nice embedded linux > rackmount server to replace my Linksys router, and act as a webserver I > maybe could use LinuxBIOS then eh? sure. there is a variant epia mobo which would make an ideal router/filter/whatever, it has two enet ports. ron From stuge-linuxbios at cdy.org Wed Feb 11 10:19:00 2004 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Wed Feb 11 10:19:00 2004 Subject: LinuxBIOS....on desktop PCs? In-Reply-To: References: <20040211033709.KYKJ7256.imf18aec.mail.bellsouth.net@mail.bellsouth.net> Message-ID: <20040211153435.GB13364@foo.birdnet.se> On Wed, Feb 11, 2004 at 08:10:55AM -0700, ron minnich wrote: > there is a variant epia mobo which would make an ideal > router/filter/whatever, it has two enet ports. Do you know the LinuxBIOS status on it? Is it different from plain EPIA? I'm going to use it (it's the EPIA-CL) for a project in a few days, but I need to deliver ASAP so I wont have much time to tinker, although I could make a few tests, and it would be neat to ship it with LinuxBIOS! :) (It would of course be even neater if it shipped to me with LinuxBIOS, but that's the next step.) //Peter From ebiederman at lnxi.com Wed Feb 11 11:43:00 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 11 11:43:00 2004 Subject: 64MB MMIO Hole ? In-Reply-To: References: Message-ID: ron minnich writes: > On 10 Feb 2004, Eric W. Biederman wrote: > > > > > The linux mtrr support does not know how to cope with overlapping > > mtrrs. > > should we help them? Writing the patch and submitting it sounds like one good solution. There is also PAT which will let you set attributes per page and that is probably a cleaner solution when it is available. Right now I just have an understanding of the problem, but I am not working on it. So please feel free to find a solution that works. Eric From ebiederman at lnxi.com Wed Feb 11 11:58:01 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 11 11:58:01 2004 Subject: stdarg.h and -nostdinc In-Reply-To: <20040211153941.GA32041@suse.de> References: <20040211133815.GA2710@suse.de> <20040211153941.GA32041@suse.de> Message-ID: Stefan Reinauer writes: > * ron minnich [040211 16:22]: > > I can't think of anything better. My wish list is to try to remove > > GNU-isms so I can build this on Plan 9, but at the same time we keep > > hitting these issues. > > > > If we are determined to include things like stdarg.h, I would rather carry > > our own copy around than depend on the OS we're using. So for the moment I > > would say "there is nothing better". > > It seems the next thing bites me here is that the va_* macros get > resolved into gcc's builtin_va* stuff. Which, as you could guess, is > disabled with the -nobuiltins flag we pass to gcc. What I don't really > get yet is why I don't get unresolved symbols with this, but rather just > no output at all. Lets see... Just off the top of my head __builtin variants should continue to be recognized with -fnobuiltins. Guys do we need a developer list? I'm trying to figure out why more of the conversations I find myself involved in are not on the public list. Is it a signal to noise ratio problem? I'm just annoyed that the conversations that pass through my inbox not being on the public list seem to be more about linuxbios than the conversations on the LinuxBIOS list. Eric From stepan at suse.de Wed Feb 11 12:03:00 2004 From: stepan at suse.de (Stefan Reinauer) Date: Wed Feb 11 12:03:00 2004 Subject: device tree Message-ID: <20040211171529.GA25041@suse.de> Hi, what's the right way of getting the pci ids of a device when traversing the device tree? is seems that the "path" part can be used, but there's no reference to the real hardware. I need this only _after_ pci initialization. The config tool creates the following structure for an 8131 for example: struct chip amd8131 = { .link = 1, .path = { { .enable = 1, .path = {.type=DEVICE_PATH_PCI,.u={.pci={ .bus = 0x0, .devfn = PCI_DEVFN(0x0,0) }}}}, { .enable = 1, .path = {.type=DEVICE_PATH_PCI,.u={.pci={ .bus = 0x0, .devfn = PCI_DEVFN(0x0,1) }}}}, { .enable = 1, .path = {.type=DEVICE_PATH_PCI,.u={.pci={ .bus = 0x0, .devfn = PCI_DEVFN(0x1,0) }}}}, { .enable = 1, .path = {.type=DEVICE_PATH_PCI,.u={.pci={ .bus = 0x0, .devfn = PCI_DEVFN(0x1,1) }}}}, }, .next = &amd8111, .children = 0, .control= 0, .chip_info= 0, }; Best regards, Stefan Reinauer -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From rminnich at lanl.gov Wed Feb 11 12:14:00 2004 From: rminnich at lanl.gov (ron minnich) Date: Wed Feb 11 12:14:00 2004 Subject: LinuxBIOS....on desktop PCs? In-Reply-To: <20040211153435.GB13364@foo.birdnet.se> Message-ID: On Wed, 11 Feb 2004, Peter Stuge wrote: > Do you know the LinuxBIOS status on it? Is it different from plain EPIA? it's the 6000 I think, a variant of the -M ron From Tarl.Neustaedter at sun.com Wed Feb 11 12:30:01 2004 From: Tarl.Neustaedter at sun.com (Tarl Neustaedter) Date: Wed Feb 11 12:30:01 2004 Subject: stdarg.h and -nostdinc In-Reply-To: References: <20040211133815.GA2710@suse.de> <20040211153941.GA32041@suse.de> Message-ID: <402A6A3C.4000205@sun.com> > I'm trying to figure out why > more of the conversations I find myself involved in are not on > the public list. Is it a signal to noise ratio problem? More likely reflex; posting to the general list leaves your email address exposed on the web for spammers to find and add to their lists. The ~130 spams I receive every day have sharpened my reflexes into almost never sending emails to public aliases. If we change the publically-available discussion lists to not expose the email addresses of the senders, you'll have fewer people like myself sending to you before sending to the alias. tarl From rminnich at lanl.gov Wed Feb 11 12:37:00 2004 From: rminnich at lanl.gov (ron minnich) Date: Wed Feb 11 12:37:00 2004 Subject: 64MB MMIO Hole ? In-Reply-To: Message-ID: On 11 Feb 2004, Eric W. Biederman wrote: > There is also PAT which will let you set attributes per > page and that is probably a cleaner solution when it is > available. yes. I never quite figured out why MTRRs existed, given that every other machine I used did this kind of thing with attributes on pages. ah well. > Right now I just have an understanding of the problem, but > I am not working on it. So please feel free to find a solution > that works. we'll find somebody with the free time and ask them :-) ron From stuge-linuxbios at cdy.org Wed Feb 11 13:09:01 2004 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Wed Feb 11 13:09:01 2004 Subject: LinuxBIOS....on desktop PCs? In-Reply-To: References: <20040211153435.GB13364@foo.birdnet.se> Message-ID: <20040211182339.GD19730@foo.birdnet.se> On Wed, Feb 11, 2004 at 10:28:45AM -0700, ron minnich wrote: > On Wed, 11 Feb 2004, Peter Stuge wrote: > > > Do you know the LinuxBIOS status on it? Is it different from plain EPIA? > > it's the 6000 I think, a variant of the -M Yes, EPIA-CL6000E is what I'm looking at. (www.viavpsd.com -> Mainboards -> Mini ITX -> EPIA CL) There's also an EPIA-ME6000 but that doesn't seem to have dual NICs. I figure the numbers just describe the CPU, 5000=533MHz Eden, 6000=600MHz Eden, 800=800MHz C3 and 10000=1GHz C3 Nehemiah, where 533 and 600 are fanless. So I guess this means a new port.. -cl that is. Or maybe enough is similar between the three variants that -cl will actually work with one of the two existing ports? //Peter From stuge-linuxbios at cdy.org Wed Feb 11 13:14:01 2004 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Wed Feb 11 13:14:01 2004 Subject: stdarg.h and -nostdinc In-Reply-To: <402A6A3C.4000205@sun.com> References: <20040211133815.GA2710@suse.de> <20040211153941.GA32041@suse.de> <402A6A3C.4000205@sun.com> Message-ID: <20040211182939.GE19730@foo.birdnet.se> On Wed, Feb 11, 2004 at 12:45:32PM -0500, Tarl Neustaedter wrote: > More likely reflex; posting to the general list leaves your > email address exposed on the web for spammers to find and add > to their lists. The ~130 spams I receive every day have > sharpened my reflexes into almost never sending emails > to public aliases. Start using statistical spam filters. I use bogofilter and dropped the daily spam count from close to the hundreds to one or two! I trained it with 200+ MB of spam and ~2GB of ham when I started out though, so it may take a while for anyone starting out fresh to get those results, I like it a lot just the same! :) For Windows clients, there's K9 (keir.net/k9.html) which is a POP proxy implementing the same algoritm as bogofilter. //Peter From tyson at irobot.com Wed Feb 11 13:28:00 2004 From: tyson at irobot.com (tyson at irobot.com) Date: Wed Feb 11 13:28:00 2004 Subject: spam - was: stdarg.h and -nostdinc In-Reply-To: <20040211182939.GE19730@foo.birdnet.se> References: <20040211133815.GA2710@suse.de> <20040211153941.GA32041@suse.de> <402A6A3C.4000205@sun.com> <20040211182939.GE19730@foo.birdnet.se> Message-ID: <402A77AB.1010008@irobot.com> Peter Stuge wrote: > On Wed, Feb 11, 2004 at 12:45:32PM -0500, Tarl Neustaedter wrote: > >>More likely reflex; posting to the general list leaves your >>email address exposed on the web for spammers to find and add >>to their lists. The ~130 spams I receive every day have >>sharpened my reflexes into almost never sending emails >>to public aliases. > > > Start using statistical spam filters. I use bogofilter and dropped the > daily spam count from close to the hundreds to one or two! > > I trained it with 200+ MB of spam and ~2GB of ham when I started out > though, so it may take a while for anyone starting out fresh to get those > results, I like it a lot just the same! :) > > For Windows clients, there's K9 (keir.net/k9.html) which is a POP proxy > implementing the same algoritm as bogofilter. I probably shouldn't expand this off-topic thread, but oh well... Filters don't help those of us on dial-up connections. It can take a long time to download 100's of spams. Ty -- Tyson D Sawyer iRobot Corporation Senior Systems Engineer Government & Industrial Robotics tsawyer at irobot.com Robots for the Real World 781-345-0200 ext 3329 http://www.irobot.com From dwh at lanl.gov Wed Feb 11 15:38:01 2004 From: dwh at lanl.gov (Hendricks David W.) Date: Wed Feb 11 15:38:01 2004 Subject: LinuxBIOS....on desktop PCs? In-Reply-To: <20040211033709.KYKJ7256.imf18aec.mail.bellsouth.net@mail.bellsouth.net> Message-ID: I suggest the Linksys WRT54G :) On Tue, 10 Feb 2004 bjm_ at bellsouth.net wrote: > >turns out the chaintech just added doesn't build, which I forget. Anyone > >wants to take a look, please do. > > Ah...well, maybe later then? Or maybe when I get a nice embedded linux rackmount server to replace my Linksys router, and act as a webserver I maybe could use LinuxBIOS then eh? > > -Brad > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From ollie at lanl.gov Wed Feb 11 16:30:01 2004 From: ollie at lanl.gov (Li-Ta Lo) Date: Wed Feb 11 16:30:01 2004 Subject: 64MB MMIO Hole ? In-Reply-To: References: <1076459153.4047.416.camel@exponential.lanl.gov> Message-ID: <1076535892.4047.1701.camel@exponential.lanl.gov> On Tue, 2004-02-10 at 20:27, Eric W. Biederman wrote: > ebiederman at lnxi.com (Eric W. Biederman) writes: > > > Li-Ta Lo writes: > > > > > Eric, > > > > > > You put a preprocessor warnning for 64MB MMIO Hole in > > > the amdk8/northbridge.c. > > > > > > #warning "FIXME improve mtrr.c so we don't use up all of the mtrrs with > > > a 64M MMIO hole" > > > > > > What exactly is it ? Is that for the AGP aperture (you call it > > > IOMMU_APERTURE) ? > > > > No, although the IOMMU_APERATURE plays a role there. But this > > was implemented before I implemented the IOMMU_APERATURE code > > in misc_control.c > > The IOMMU_APERATURE is just another large I/O region as far > as that code is concerned. > But you also used it for AGP aperture in misc_control.c. Is there any reason to do this ? Or the AGP aperture can actually be anything else. Ollie From ebiederman at lnxi.com Wed Feb 11 20:05:01 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 11 20:05:01 2004 Subject: 64MB MMIO Hole ? In-Reply-To: <1076535892.4047.1701.camel@exponential.lanl.gov> References: <1076459153.4047.416.camel@exponential.lanl.gov> <1076535892.4047.1701.camel@exponential.lanl.gov> Message-ID: Li-Ta Lo writes: > But you also used it for AGP aperture in misc_control.c. Is there > any reason to do this ? Or the AGP aperture can actually be anything > else. As I recall the AGP aperature must be at least 64M if it exists. You can read the Opteron docs to confirm this. Eric From linuxbios at xdr.com Fri Feb 13 13:24:01 2004 From: linuxbios at xdr.com (Dave Ashley) Date: Fri Feb 13 13:24:01 2004 Subject: Etherboot 5.0.10 problems + patchfile Message-ID: <200402131839.i1DIdZ42011638@xdr.com> I'm going to post this patch to the etherboot mailing list but it is relevant here as well. This is our current patch against etherboot 5.0.10 to fix various problems: 1) RTL8139 interrupt handling was wrong 2) VIA-RHINE support needs workaround for the 3065 chip version. When resetting the chip, the act of shutting down the receive machinery can cause a problem, and when the chip is reset it never gets out of reset. So etherboot would hang when trying to send out a packet, such as a bootp request. This fix is from via's linuxfet driver. Google searches tracked down other people with the same problem and the eventual solution. 3) Some issue with initializing the timer, which without it was causing a divide by zero at some point. The #2 was an especially bad problem and affected our epia-m solution. The boxes would stop sending out BOOTP requests after a while. -Dave diff -Nur etherboot-5.0.10/src/misc.c etherboot-5.0.10-new/src/misc.c --- etherboot-5.0.10/src/misc.c Sun Mar 9 03:17:15 2003 +++ etherboot-5.0.10-new/src/misc.c Wed Jul 16 09:45:26 2003 @@ -282,7 +282,7 @@ enum { Disable_A20 = 0x2400, Enable_A20 = 0x2401, Query_A20_Status = 0x2402, Query_A20_Support = 0x2403 } Int0x15Arg; -#if defined(PCBIOS) && !defined(IBM_L40) +#if defined(TAGGED_IMAGE) || (defined(PCBIOS) && !defined(IBM_L40)) static void empty_8042(void) { unsigned long time; diff -Nur etherboot-5.0.10/src/rtl8139.c etherboot-5.0.10-new/src/rtl8139.c --- etherboot-5.0.10/src/rtl8139.c Tue Jul 23 17:50:53 2002 +++ etherboot-5.0.10-new/src/rtl8139.c Wed Jul 16 09:45:42 2003 @@ -183,7 +183,6 @@ static int rtl_poll(struct nic *nic); static void rtl_disable(struct nic*); - struct nic *rtl8139_probe(struct nic *nic, unsigned short *probeaddrs, struct pci_device *pci) { @@ -252,6 +251,16 @@ #define EE_READ_CMD (6) #define EE_ERASE_CMD (7) +static unsigned short cintr=0; +static unsigned short getstatus(void) +{ + return cintr|=inw(ioaddr + IntrStatus); +} +static void setstatus(unsigned short val) +{ + cintr&=~val; +} + static int read_eeprom(int location, int addr_len) { int i; @@ -340,7 +349,7 @@ static void rtl_transmit(struct nic *nic, const char *destaddr, unsigned int type, unsigned int len, const char *data) { - unsigned int status, to, nstype; + unsigned int status, to, nstype, st; unsigned long txstatus; /* nstype assignment moved up here to avoid gcc 3.0.3 compiler bug */ @@ -365,14 +374,15 @@ outl(((TX_FIFO_THRESH<<11) & 0x003f0000) | len, ioaddr + TxStatus0 + cur_tx*4); + st= currticks(); to = currticks() + RTL_TIMEOUT; do { - status = inw(ioaddr + IntrStatus); + status = getstatus(); /* Only acknlowledge interrupt sources we can properly handle * here - the RxOverflow/RxFIFOOver MUST be handled in the * rtl_poll() function. */ - outw(status & (TxOK | TxErr | PCIErr), ioaddr + IntrStatus); + setstatus(status & (TxOK | TxErr | PCIErr)); if ((status & (TxOK | TxErr | PCIErr)) != 0) break; } while (currticks() < to); @@ -382,12 +392,12 @@ cur_tx = (cur_tx + 1) % NUM_TX_DESC; #ifdef DEBUG_TX printf("tx done (%d ticks), status %hX txstatus %X\n", - to-currticks(), status, txstatus); + currticks()-st, status, txstatus); #endif } else { #ifdef DEBUG_TX printf("tx timeout/error (%d ticks), status %hX txstatus %X\n", - currticks()-to, status, txstatus); + currticks()-st, status, txstatus); #endif rtl_reset(nic); } @@ -403,9 +413,9 @@ return 0; } - status = inw(ioaddr + IntrStatus); + status = getstatus(); /* See below for the rest of the interrupt acknowledges. */ - outw(status & ~(RxFIFOOver | RxOverflow | RxOK), ioaddr + IntrStatus); + setstatus(status & ~(RxFIFOOver | RxOverflow | RxOK)); #ifdef DEBUG_RX printf("rtl_poll: int %hX ", status); @@ -449,7 +459,7 @@ /* See RTL8139 Programming Guide V0.1 for the official handling of * Rx overflow situations. The document itself contains basically no * usable information, except for a few exception handling rules. */ - outw(status & (RxFIFOOver | RxOverflow | RxOK), ioaddr + IntrStatus); + setstatus(status & (RxFIFOOver | RxOverflow | RxOK)); return 1; } diff -Nur etherboot-5.0.10/src/timer.c etherboot-5.0.10-new/src/timer.c --- etherboot-5.0.10/src/timer.c Sat Mar 22 11:52:25 2003 +++ etherboot-5.0.10-new/src/timer.c Wed Jul 16 09:45:46 2003 @@ -138,6 +138,8 @@ { unsigned long clocks_high, clocks_low; unsigned long currticks; + +setup_timers(); /* Read the Time Stamp Counter */ rdtsc(clocks_low, clocks_high); --- etherboot-5.0.10/src/Makefile 2003-03-09 17:39:21.000000000 -0800 +++ etherboot-5.0.10/src/Makefile.new 2003-11-06 06:22:26.000000000 -0800 @@ -98,8 +98,8 @@ include Config -GCC= gcc -CPP= gcc -E -Wp,-Wall +GCC= $(CC) +CPP= $(CC) -E -Wp,-Wall STRIP= strip OBJCOPY= objcopy # MAKEROM= bin/makerom diff -Nur etherboot-5.0.10/src/via-rhine.c etherboot-5.0.10-new/src/via-rhine.c --- etherboot-5.0.10/src/via-rhine.c 2003-02-07 15:07:56.000000000 -0800 +++ etherboot-5.0.10-new/src/via-rhine.c 2004-02-06 07:24:50.000000000 -0800 @@ -106,6 +106,10 @@ #define byCFGD ioaddr + 0x7b #define wTallyCntMPA ioaddr + 0x7c #define wTallyCntCRC ioaddr + 0x7d +#define bySTICKHW ioaddr + 0x83 +#define byWOLcrClr ioaddr + 0xA4 +#define byWOLcgClr ioaddr + 0xA7 +#define byPwrcsrClr ioaddr + 0xAC /*--------------------- Exioaddr Definitions -------------------------*/ /* @@ -873,6 +877,19 @@ return nic; } +static void set_rx_mode(struct nic *nic) { + struct rhine_private *tp = (struct rhine_private *) nic->priv_data; + unsigned char rx_mode; + int ioaddr = tp->ioaddr; + + /* ! IFF_PROMISC */ + outl(0xffffffff, byMAR0); + outl(0xffffffff, byMAR4); + rx_mode = 0x0C; + + outb(0x60 /* thresh */ | rx_mode, byRCR ); +} + static struct nic * rhine_probe1 (struct nic *nic, int ioaddr, int chip_id, int options) { @@ -885,6 +902,29 @@ if (rhine_debug > 0 && did_version++ == 0) printf (version); + + /* D-Link provided reset code (with comment additions) */ + if((chip_id != 0x3043) && (chip_id != 0x6100)) { + unsigned char byOrgValue; + + if(rhine_debug > 0) + printf("Enabling Sticky Bit Workaround for Chip_id: 0x%hX\n" + , chip_id); + /* clear sticky bit before reset & read ethernet address */ + byOrgValue = inb(bySTICKHW); + byOrgValue = byOrgValue & 0xFC; + outb(byOrgValue, bySTICKHW); + + /* (bits written are cleared?) */ + /* disable force PME-enable */ + outb(0x80, byWOLcgClr); + /* disable power-event config bit */ + outb(0xFF, byWOLcrClr); + /* clear power status (undocumented in vt6102 docs?) */ + outb(0xFF, byPwrcsrClr); + + } + /* Perhaps this should be read from the EEPROM? */ for (i = 0; i < ETH_ALEN; i++) nic->node_addr[i] = inb (byPAR0 + i); @@ -980,6 +1020,9 @@ struct rhine_private *tp = (struct rhine_private *) nic->priv_data; int ioaddr = tp->ioaddr; + /* merge reset and disable */ + rhine_reset(nic); + printf ("rhine disable\n"); /* Switch to loopback mode to avoid hardware races. */ writeb(0x60 | 0x01, byTCR); @@ -1018,6 +1061,45 @@ /* Soft reset the chip. */ /*outb(CmdReset, ioaddr + ChipCmd); */ + /* if the chip is 3065, we must patch shutdown bug*/ +// if ((np->revision >= 0x40) && (np->revision <= 0x80)) + { + int ww; + //Nic Loop Back On + + outb(inb(byTCR) | 0x01, byTCR); + + //Tx Off + outb(inb(byCR0) & 0xEF, byCR0); + +#define W_MAX_TIMEOUT 0x0FFF + // W_MAX_TIMEOUT is the timeout period + for (ww = 0; ww < W_MAX_TIMEOUT; ww++) { + if((inb(byCR0) & 0x10) == 0) + break; + } + + //Rx Off + outb(inb(byCR0) & 0xF7, byCR0); + + // W_MAX_TIMEOUT is the timeout period + for (ww = 0; ww < W_MAX_TIMEOUT; ww++) { + if((inb(byCR0) & 0x08) == 0) + break; + } + + if (ww == W_MAX_TIMEOUT) { + + // Turn on fifo test + outw(inw(dwNextTDSE1) | 0x0001, dwNextTDSE1); + // Turn on fifo reject + outw(inw(dwNextTDSE1) | 0x0800, dwNextTDSE1); + // Turn off fifo test + outw(inw(dwNextTDSE1) & 0xFFFE, dwNextTDSE1); + } + } + + tx_bufs_tmp = (int) buf1; tx_ring_tmp = (int) desc1; rx_bufs_tmp = (int) buf2; @@ -1069,6 +1151,9 @@ outl (virt_to_bus (tp->rx_ring), dwCurrentRxDescAddr); outl (virt_to_bus (tp->tx_ring), dwCurrentTxDescAddr); + /* Setup Multicast */ + set_rx_mode(nic); + /* close IMR */ outw (0x0000, byIMR0); From aod at ponto-i.net Fri Feb 13 13:57:00 2004 From: aod at ponto-i.net (Andre Dias) Date: Fri Feb 13 13:57:00 2004 Subject: linuxbios on cheaper motherboards Message-ID: <1076699511.3018.23.camel@laptop> Hello Fellows, I have been using linuxbios for a while on some products of my company, we make pc-based jukeboxes and arcade machines for pubs and public venues and I have been using linuxbios and DOC to make a fast boot and prevent the computer to hang at boot when CMOS clears, and to store some information on DOC and prevent hard disk corruption problems. We also have busybox on DOC, so we can verify problems and provide maintenance even when HD fails. We used pcchips M810 (red motherboard) and ECS K7SEM (purple). We used this board mainly because it was the cheapest and worked fine with linuxbios. Now this motherboards are impossible to find on retailers and SDRAM modules are becoming scarce. I have seen that EPIA is being actively developed but EPIA is not really easy to find and cheap (at least in south america), also its CPU is not the best performance. I was thinking of using PCCHIPS m810D (SIS 740, closer to SIS730) but its PLCC BIOS is soldered onboard! So I had to switch to ASROCK K7VM2 (via KM266), and we could afford donnate $400 and this motherboard plus cpu and memory, to a developer that could make linuxbios work on this board (with sound, eth0, framebuffer, IDE and serial port working). Its a very small reward, but maybe it will help any developer that is already working on it. thanks for the attention From linuxbios at smashed.demon.co.uk Fri Feb 13 15:37:00 2004 From: linuxbios at smashed.demon.co.uk (James Weir) Date: Fri Feb 13 15:37:00 2004 Subject: Advice on Board Selection Message-ID: Can anyone please recommend a board preferably small form factor ( itx? ) which the documentation is available for ( or a port of linux bios is available for ) which would be suitable for dvd playback? Thanks, James. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwh at lanl.gov Fri Feb 13 15:43:01 2004 From: dwh at lanl.gov (Hendricks David W.) Date: Fri Feb 13 15:43:01 2004 Subject: Advice on Board Selection In-Reply-To: Message-ID: EPIA It has a hardware DVD decoder, if I'm not mistaken. But more importantly, extensive work has been done on LinuxBIOS ports for various versions of this board. If you find one you like, get detailed specifications and check back here before ordering it so that someone can confirm if it works with LinuxBIOS. On Fri, 13 Feb 2004, James Weir wrote: > Can anyone please recommend a board preferably small form factor ( itx? ) > which the documentation is available for ( or a port of linux bios is > available for ) which would be suitable for dvd playback? > > > > Thanks, > > > > James. > > > > From dwh at lanl.gov Fri Feb 13 16:01:01 2004 From: dwh at lanl.gov (Hendricks David W.) Date: Fri Feb 13 16:01:01 2004 Subject: linuxbios on cheaper motherboards In-Reply-To: <1076699511.3018.23.camel@laptop> Message-ID: You might want to consider the ECS K7S5A--It uses a SiS735 chipset. It is also compatible with both DDR SDRAM and normal SDRAM, but I am not sure if anybody has tried this using DDR SDRAM on the SiS73x series boards with LinuxBIOS yet. On Fri, 13 Feb 2004, Andre Dias wrote: > Hello Fellows, > > I have been using linuxbios for a while on some products of my company, > we make pc-based jukeboxes and arcade machines for pubs and public > venues and I have been using linuxbios and DOC to make a fast boot and > prevent the computer to hang at boot when CMOS clears, and to store some > information on DOC and prevent hard disk corruption problems. We also > have busybox on DOC, so we can verify problems and provide maintenance > even when HD fails. > > We used pcchips M810 (red motherboard) and ECS K7SEM (purple). We used > this board mainly because it was the cheapest and worked fine with > linuxbios. Now this motherboards are impossible to find on retailers and > SDRAM modules are becoming scarce. I have seen that EPIA is being > actively developed but EPIA is not really easy to find and cheap (at > least in south america), also its CPU is not the best performance. > > I was thinking of using PCCHIPS m810D (SIS 740, closer to SIS730) but > its PLCC BIOS is soldered onboard! So I had to switch to ASROCK K7VM2 > (via KM266), and we could afford donnate $400 and this motherboard plus > cpu and memory, to a developer that could make linuxbios work on this > board (with sound, eth0, framebuffer, IDE and serial port working). Its > a very small reward, but maybe it will help any developer that is > already working on it. > > thanks for the attention > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From kok at surfbest.net Fri Feb 13 16:10:01 2004 From: kok at surfbest.net (Jan Kok) Date: Fri Feb 13 16:10:01 2004 Subject: linuxbios on cheaper motherboards In-Reply-To: <1076699511.3018.23.camel@laptop> Message-ID: <000001c3f277$f064e540$1601a8c0@Dell1> Andre, what is your schedule? How long can you wait for a solution? All, Some of the Disks On Chips are now available in a "FBGA 69-ball (9x12mm)". Would any of these work, electrically? If so, is there a FBGA to PLCC adapter available anywhere? If there is not an adapter available, someone on the Homebrew_PCBs Yahoo group might be able to come up with an adapter and produce them in a moderate quantity for use by people in this group. I know someone who can assemble BGAs onto boards. That approach would allow using DOC on a wider range of modern motherboards. Cheers, - Jan -----Original Message----- From: linuxbios-admin at clustermatic.org [mailto:linuxbios-admin at clustermatic.org] On Behalf Of Andre Dias Sent: Friday, February 13, 2004 12:12 PM To: Linux BIOS List Subject: linuxbios on cheaper motherboards Hello Fellows, I have been using linuxbios for a while on some products of my company, we make pc-based jukeboxes and arcade machines for pubs and public venues and I have been using linuxbios and DOC to make a fast boot and prevent the computer to hang at boot when CMOS clears, and to store some information on DOC and prevent hard disk corruption problems. We also have busybox on DOC, so we can verify problems and provide maintenance even when HD fails. We used pcchips M810 (red motherboard) and ECS K7SEM (purple). We used this board mainly because it was the cheapest and worked fine with linuxbios. Now this motherboards are impossible to find on retailers and SDRAM modules are becoming scarce. I have seen that EPIA is being actively developed but EPIA is not really easy to find and cheap (at least in south america), also its CPU is not the best performance. I was thinking of using PCCHIPS m810D (SIS 740, closer to SIS730) but its PLCC BIOS is soldered onboard! So I had to switch to ASROCK K7VM2 (via KM266), and we could afford donnate $400 and this motherboard plus cpu and memory, to a developer that could make linuxbios work on this board (with sound, eth0, framebuffer, IDE and serial port working). Its a very small reward, but maybe it will help any developer that is already working on it. thanks for the attention _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From rminnich at lanl.gov Fri Feb 13 16:13:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Fri Feb 13 16:13:01 2004 Subject: linuxbios on cheaper motherboards In-Reply-To: <000001c3f277$f064e540$1601a8c0@Dell1> Message-ID: On Fri, 13 Feb 2004, Jan Kok wrote: > That approach would allow using DOC on a wider range of modern > motherboards. A bigger limitation than packaging for DoC has been M-systems. They have an attitude about open source that is hard to fathom and seems to change weekly, which makes it difficult to commit to using their parts -- if you commit, you don't know if they will make the next part open or not. I think you're much better off with an adapter for compact flash. That's an open, widely used standard which has worked well for us. ron From linuxbios at smashed.demon.co.uk Fri Feb 13 16:15:01 2004 From: linuxbios at smashed.demon.co.uk (James Weir) Date: Fri Feb 13 16:15:01 2004 Subject: Advice on Board Selection In-Reply-To: Message-ID: EPIA ME6000 Is this board currently supported, and is there any hope of getting register descriptions for the north/south bridge and such. Many thanks, James -----Original Message----- From: linuxbios-admin at clustermatic.org [mailto:linuxbios-admin at clustermatic.org] On Behalf Of Hendricks David W. Sent: 13 February 2004 20:59 To: James Weir Cc: LinuxBIOS Subject: Re: Advice on Board Selection EPIA It has a hardware DVD decoder, if I'm not mistaken. But more importantly, extensive work has been done on LinuxBIOS ports for various versions of this board. If you find one you like, get detailed specifications and check back here before ordering it so that someone can confirm if it works with LinuxBIOS. On Fri, 13 Feb 2004, James Weir wrote: > Can anyone please recommend a board preferably small form factor ( itx? ) > which the documentation is available for ( or a port of linux bios is > available for ) which would be suitable for dvd playback? > > > > Thanks, > > > > James. > > > > _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From linuxbios at smashed.demon.co.uk Fri Feb 13 16:19:00 2004 From: linuxbios at smashed.demon.co.uk (James Weir) Date: Fri Feb 13 16:19:00 2004 Subject: Advice on Board Selection In-Reply-To: Message-ID: I should also have asked for the best location to purchase in UK. -----Original Message----- From: linuxbios-admin at clustermatic.org [mailto:linuxbios-admin at clustermatic.org] On Behalf Of James Weir Sent: 13 February 2004 21:31 To: 'Hendricks David W.' Cc: 'LinuxBIOS' Subject: RE: Advice on Board Selection EPIA ME6000 Is this board currently supported, and is there any hope of getting register descriptions for the north/south bridge and such. Many thanks, James -----Original Message----- From: linuxbios-admin at clustermatic.org [mailto:linuxbios-admin at clustermatic.org] On Behalf Of Hendricks David W. Sent: 13 February 2004 20:59 To: James Weir Cc: LinuxBIOS Subject: Re: Advice on Board Selection EPIA It has a hardware DVD decoder, if I'm not mistaken. But more importantly, extensive work has been done on LinuxBIOS ports for various versions of this board. If you find one you like, get detailed specifications and check back here before ordering it so that someone can confirm if it works with LinuxBIOS. On Fri, 13 Feb 2004, James Weir wrote: > Can anyone please recommend a board preferably small form factor ( itx? ) > which the documentation is available for ( or a port of linux bios is > available for ) which would be suitable for dvd playback? > > > > Thanks, > > > > James. > > > > _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From dwh at lanl.gov Fri Feb 13 16:40:01 2004 From: dwh at lanl.gov (Hendricks David W.) Date: Fri Feb 13 16:40:01 2004 Subject: Advice on Board Selection In-Reply-To: Message-ID: Dave Ashley sent us one of those exact mainboards, we'll test it here at LANL next week. If you're in a rush, however, you should get Dave's attention. As for vendors, I usually use www.pricewatch.com. I noticed there's a pricewatch.co.uk, but I'm not sure if it's run by the same people. Also, a lot of retailers are absolutely clueless about the hardware they're selling so you must be careful when trying to order a specific part. On Fri, 13 Feb 2004, James Weir wrote: > EPIA ME6000 > > Is this board currently supported, and is there any hope of getting register > descriptions for the north/south bridge and such. > > Many thanks, > > James > > -----Original Message----- > From: linuxbios-admin at clustermatic.org > [mailto:linuxbios-admin at clustermatic.org] On Behalf Of Hendricks David W. > Sent: 13 February 2004 20:59 > To: James Weir > Cc: LinuxBIOS > Subject: Re: Advice on Board Selection > > EPIA > > It has a hardware DVD decoder, if I'm not mistaken. But more importantly, > extensive work has been done on LinuxBIOS ports for various versions of > this board. If you find one you like, get detailed specifications and > check back here before ordering it so that someone can confirm if it works > with LinuxBIOS. > > On Fri, 13 Feb 2004, James Weir wrote: > > > Can anyone please recommend a board preferably small form factor ( itx? ) > > which the documentation is available for ( or a port of linux bios is > > available for ) which would be suitable for dvd playback? > > > > > > > > Thanks, > > > > > > > > James. > > > > > > > > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From YhLu at tyan.com Fri Feb 13 16:45:00 2004 From: YhLu at tyan.com (YhLu) Date: Fri Feb 13 16:45:00 2004 Subject: ATI XL Init in kernel 2.6.2 Message-ID: <3174569B9743D511922F00A0C9431423041D21C0@TYANWEB> Stefan, I have checked Kernel 2.6.2 for ATI XL No init in BIOS, the Makefile doesn't include the xlinit.c and it is not called. So patch is not properly merged with the kernel 2.6.2. Did you try that ever? Regards Yinghai Lu From rminnich at lanl.gov Fri Feb 13 18:01:00 2004 From: rminnich at lanl.gov (ron minnich) Date: Fri Feb 13 18:01:00 2004 Subject: freebios2/util/flash_and_burn Message-ID: I just fixed a makefile problem that was introduced with the AMD 8111 support, so if you had trouble making it, do a cvs update. ron From ian.castle at coldcomfortfarm.net Sat Feb 14 03:25:01 2004 From: ian.castle at coldcomfortfarm.net (Ian Castle) Date: Sat Feb 14 03:25:01 2004 Subject: Advice on Board Selection In-Reply-To: References: Message-ID: <1076748118.3373.3.camel@chromium.dark.lan> I've used both http://www.mini-itx.com/ http://www.linitx.com/ Linitx has tended to be a bit cheaper. mini-itx.com has a much more interesting site. I've had no problems with the service from either of them. They both also sell compact flash + low profile ram. The latter is tricky to get right when ordering from non-specialist suppliers. On Fri, 2004-02-13 at 21:34, James Weir wrote: > I should also have asked for the best location to purchase in UK. > > -----Original Message----- > From: linuxbios-admin at clustermatic.org > [mailto:linuxbios-admin at clustermatic.org] On Behalf Of James Weir > Sent: 13 February 2004 21:31 > To: 'Hendricks David W.' > Cc: 'LinuxBIOS' > Subject: RE: Advice on Board Selection > > EPIA ME6000 > > Is this board currently supported, and is there any hope of getting register > descriptions for the north/south bridge and such. > > Many thanks, > > James > > -----Original Message----- > From: linuxbios-admin at clustermatic.org > [mailto:linuxbios-admin at clustermatic.org] On Behalf Of Hendricks David W. > Sent: 13 February 2004 20:59 > To: James Weir > Cc: LinuxBIOS > Subject: Re: Advice on Board Selection > > EPIA > > It has a hardware DVD decoder, if I'm not mistaken. But more importantly, > extensive work has been done on LinuxBIOS ports for various versions of > this board. If you find one you like, get detailed specifications and > check back here before ordering it so that someone can confirm if it works > with LinuxBIOS. > > On Fri, 13 Feb 2004, James Weir wrote: > > > Can anyone please recommend a board preferably small form factor ( itx? ) > > which the documentation is available for ( or a port of linux bios is > > available for ) which would be suitable for dvd playback? > > > > > > > > Thanks, > > > > > > > > James. > > > > > > > > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From rminnich at lanl.gov Sat Feb 14 10:31:00 2004 From: rminnich at lanl.gov (ron minnich) Date: Sat Feb 14 10:31:00 2004 Subject: Advice on Board Selection In-Reply-To: <1076748118.3373.3.camel@chromium.dark.lan> Message-ID: I still like the ituner the best, due to the front-plug-in CF slot. ron From dlc4 at jhu.edu Sat Feb 14 19:20:00 2004 From: dlc4 at jhu.edu (DAVID CUMMINGS) Date: Sat Feb 14 19:20:00 2004 Subject: IBM T20 Message-ID: <1922f21919ee.1919ee1922f2@jhumail.jhu.edu> Alright, the status is IBM doesn't want it. I know this has probably been gone over hundreds of times before. What's the deal with the T20 and LinuxBIOS. Also, how would I go about searching the archives? I couldn't find a search form anywhere, and I'm on dialup so I can't d/l the entire archive and grep it or similar. Anyway, thanks -dave From stepan at suse.de Sat Feb 14 20:37:00 2004 From: stepan at suse.de (Stefan Reinauer) Date: Sat Feb 14 20:37:00 2004 Subject: ATI XL Init in kernel 2.6.2 In-Reply-To: <3174569B9743D511922F00A0C9431423041D21C0@TYANWEB> References: <3174569B9743D511922F00A0C9431423041D21C0@TYANWEB> Message-ID: <20040215014915.GA20101@suse.de> * YhLu [040213 23:04]: > I have checked Kernel 2.6.2 for ATI XL No init in BIOS, the Makefile doesn't > include the xlinit.c and it is not called. > > So patch is not properly merged with the kernel 2.6.2. > > Did you try that ever? It's not properly merged, not even in James Simmons' tree, as far as I can tell. I only had this working with 2.4, but it seems with a little work it can be merged.. Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From rminnich at lanl.gov Sat Feb 14 20:59:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Sat Feb 14 20:59:01 2004 Subject: IBM T20 In-Reply-To: <1922f21919ee.1919ee1922f2@jhumail.jhu.edu> Message-ID: All you have to do is figure out how to turn on SPD and the T20 should be easy. It's just a 440bx mobo, after all, and those are easy! ron From andy.pearce at austrocontrol.at Mon Feb 16 01:57:01 2004 From: andy.pearce at austrocontrol.at (Andy Pearce) Date: Mon Feb 16 01:57:01 2004 Subject: Use of compact flash In-Reply-To: Message-ID: Hi, I've been watching the list and saw the comment from Ron Date: Fri, 13 Feb 2004 14:28:43 -0700 (MST) From: Ron minnich rminnich at lanl.gov To: Jan Kok kok at surfbest.net "I think you're much better off with an adapter for compact flash. That's an open, widely used standard which has worked well for us." Can you explain this a bit, does it mean that its possible to some how redirect the rom from which the PC boots ? i.e. switch it to a CF adapter card ? Thanks Andy Pearce -------------- next part -------------- An HTML attachment was scrubbed... URL: From Antony at Soft-Solutions.co.uk Mon Feb 16 04:11:01 2004 From: Antony at Soft-Solutions.co.uk (Antony Stone) Date: Mon Feb 16 04:11:01 2004 Subject: Use of compact flash In-Reply-To: References: Message-ID: <200402160926.50201.Antony@Soft-Solutions.co.uk> On Monday 16 February 2004 7:12 am, Andy Pearce wrote: > Hi, > > I've been watching the list and saw the comment from Ron > > "I think you're much better off with an adapter for compact flash. That's > an open, widely used standard which has worked well for us." > > Can you explain this a bit, does it mean that its possible to > some how redirect the rom from which the PC boots ? i.e. switch > it to a CF adapter card ? A CF adapter simply make the CF card appear to be an IDE device as far as the machien is concerned, therefore you use the CF the same way you'd otherwise use an IDE hard drive. You can get single and dual CF adapters, they can be set to master or slave; they simply plug into the standard IDE cable, or sometimes into the motherbard IDE header. As far as your machine is concerned, you simply have a rather low capacity hard drive (by today's standards). Regards, Antony. -- RTFM may be the appropriate reply, but please specify exactly which FM to R. Please reply to the list; please don't CC me. From fboudra at uxp.fr Mon Feb 16 10:56:00 2004 From: fboudra at uxp.fr (Fathi BOUDRA) Date: Mon Feb 16 10:56:00 2004 Subject: compile error Message-ID: <200402161712.20763.fboudra@uxp.fr> Hi, I'm a newbie on linuxbios so i followed the howto. But when i arrived to run the make command : debfat:~/dev/freebios/util/config/winfast# make Makefile:517: attention : ?crasement des commandes pour la cible ? keyboard.o ? Makefile:421: attention : anciennes commandes ignor?es pour la cible ? keyboard.o ? cp /root/dev/freebios/src/arch/i386/config/crt0.base crt0.S gcc -x assembler-with-cpp -DASSEMBLY -E ... crt0.S > crt0.s /bin/sh: -c: line 1: syntax error near unexpected token `(' /bin/sh: -c: line 1: `gcc -x assembler-with-cpp -DASSEMBLY -E -I/root/dev/freebios/src/include -I/root/dev/freebios/src/arch/i386/include -I -DCC='gcc' -DCMD_LINE='"root=/dev/hda1 console=ttyS0,115200 console=tty0 video=sisfb:1024x768-32 at 85,font:VGA8x16"' -DCONFIGURE_L2_CACHE='1' -DCONFIG_ASSIGNIRQ='0' -DCONFIG_COMPRESS='1' -DCONFIG_LOGICAL_CPUS='1' -DCONFIG_MC146818RTC='1' -DCONFIG_PCIBIOS_IRQ='0' -DCONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2='0' -DCONFIG_UNCOMPRESSED='0' -DCRT0='/root/dev/freebios/src/arch/i386/config/crt0.base' -DENABLE_FIXED_AND_VARIABLE_MTRRS='1' -DENABLE_SIS630_CPU_PIPELINE='1' -DFINAL_MAINBOARD_FIXUP='1' -DHAVE_FRAMEBUFFER='1' -DHAVE_PIRQ_TABLE='1' -DHEAP_SIZE='0x40000' -DHOSTCC='gcc' -DINTEL_PPRO_MTRR='1' -DLINUXBIOS_ASSEMBLER='Version de l'assembleur GNU 2.14.90.0.7 (i386-linux) utilisant la version BFD 2.14.90.0.7 20031029 Debian GNU/Linux' -DLINUXBIOS_BUILD='lun f?v 16 16:58:23 CET 2004' -DLINUXBIOS_COMPILER='version gcc 3.3.3 20040214 (prerelease) (Debian)' -DLINUXBIOS_COMPILE_BY='root' -DLINUXBIOS_COMPILE_DOMAIN -DLINUXBIOS_COMPILE_HOST='debfat' -DLINUXBIOS_COMPILE_TIME='16:58:23' -DLINUXBIOS_LINKER='GNU ld version 2.14.90.0.7 20031029 Debian GNU/Linux' -DLINUXBIOS_VERSION='1.0.0' -DMAINBOARD_PART_NUMBER='winfast6300' -DMAINBOARD_VENDOR='leadtek' -DMAX_CPUS='1' -DMEMORY_HOLE='1' -DOBJCOPY='objcopy' -DPAYLOAD_SIZE='458752' -DROM_IMAGE_SIZE='65536' -DSERIAL_CONSOLE='1' -DSIS630='1' -DSMA_SIZE='0xA0' -DSTACK_SIZE='0x2000' -DUPDATE_MICROCODE='1' -DUSE_DOC='1' -DUSE_DOC_2000_TSOP='0' -DUSE_DOC_MIL='1' -DUSE_NEW_SUPERIO_INTERFACE='1' -D_RAMBASE='0x4000' -D_ROMBASE='0x80000' -Di586='1' -Di686='1' -I/root/dev/freebios/src crt0.S > crt0.s.new && mv crt0.s.new crt0.s' make: *** [crt0.s] Erreur 2 is there a problem with the version of software i use ? (gcc 3.3.3, python, perl, shell,...) Maybe i need to have a redhat 6.2 ? I think it's a common problem but don't find anything on the mailling list. when i change in the Makefile, the line : D_item = $(if $(subst undefined,,$(origin $1)),-D$1$(if $($1),='$($1)',),-U$1) by D_item = $(if $(subst undefined,,$(origin $1)),-D$1$(if $($1),="$($1)",),-U$1) i've got : debfat:~/dev/freebios/util/config/winfast# make Makefile:517: attention : ?crasement des commandes pour la cible ? keyboard.o ? Makefile:421: attention : anciennes commandes ignor?es pour la cible ? keyboard.o ? cp /root/dev/freebios/src/arch/i386/config/crt0.base crt0.S gcc -x assembler-with-cpp -DASSEMBLY -E ... crt0.S > crt0.s gcc: console=ttyS0,115200 : Aucun fichier ou r?pertoire de ce type gcc: console=tty0 : Aucun fichier ou r?pertoire de ce type gcc: video=sisfb:1024x768-32 at 85,font:VGA8x16 : Aucun fichier ou r?pertoire de ce type make: *** [crt0.s] Erreur 1 if someone have an idea ... best regards fathi From rminnich at lanl.gov Mon Feb 16 18:42:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Mon Feb 16 18:42:01 2004 Subject: Use of compact flash In-Reply-To: Message-ID: On Mon, 16 Feb 2004, Andy Pearce wrote: > "I think you're much better off with an adapter for compact flash. That's > an open, widely used standard which has worked well for us." > Can you explain this a bit, does it mean that its possible to > some how redirect the rom from which the PC boots ? i.e. switch > it to a CF adapter card ? you boot linuxbios from flash, but the linuxbios payload comes from CF. ron From YhLu at tyan.com Mon Feb 16 19:45:01 2004 From: YhLu at tyan.com (YhLu) Date: Mon Feb 16 19:45:01 2004 Subject: =?GB2312?B?tPC4tDogVXNlIG9mIGNvbXBhY3QgZmxhc2g=?= Message-ID: <3174569B9743D511922F00A0C9431423041D227C@TYANWEB> Ron, Do you mean put kernel and rootfs on the CF? Regards YH. -----????----- ???: ron minnich [mailto:rminnich at lanl.gov] ????: 2004?2?16? 15:58 ???: Andy Pearce ??: linuxbios at clustermatic.org ??: Re: Use of compact flash On Mon, 16 Feb 2004, Andy Pearce wrote: > "I think you're much better off with an adapter for compact flash. That's > an open, widely used standard which has worked well for us." > Can you explain this a bit, does it mean that its possible to > some how redirect the rom from which the PC boots ? i.e. switch > it to a CF adapter card ? you boot linuxbios from flash, but the linuxbios payload comes from CF. ron _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From rminnich at lanl.gov Mon Feb 16 22:22:00 2004 From: rminnich at lanl.gov (ron minnich) Date: Mon Feb 16 22:22:00 2004 Subject: =?GB2312?B?tPC4tDogVXNlIG9mIGNvbXBhY3QgZmxhc2g=?= In-Reply-To: <3174569B9743D511922F00A0C9431423041D227C@TYANWEB> Message-ID: On Mon, 16 Feb 2004, YhLu wrote: > Do you mean put kernel and rootfs on the CF? we put kernel and initrd on CF ron From andy.pearce at austrocontrol.at Tue Feb 17 01:57:01 2004 From: andy.pearce at austrocontrol.at (Andy Pearce) Date: Tue Feb 17 01:57:01 2004 Subject: Use of compact flash In-Reply-To: Message-ID: Hi, So if I get this correct the rom has been flashed but it effectively has no kernel in it, this resides on the CF card. I guess this means that this card can then be switched to another machine and easily changed with another kernel to test changes. Am I anywhere near on the right lines yet ? Andy > -----Original Message----- > From: ron minnich [mailto:rminnich at lanl.gov] > Sent: Tuesday, February 17, 2004 12:58 AM > To: Andy Pearce > Cc: linuxbios at clustermatic.org > Subject: Re: Use of compact flash > > > On Mon, 16 Feb 2004, Andy Pearce wrote: > > > "I think you're much better off with an adapter for compact > flash. That's > > an open, widely used standard which has worked well for us." > > Can you explain this a bit, does it mean that its possible to > > some how redirect the rom from which the PC boots ? i.e. switch > > it to a CF adapter card ? > > you boot linuxbios from flash, but the linuxbios payload comes from CF. > > ron > > From fboudra at uxp.fr Tue Feb 17 04:53:01 2004 From: fboudra at uxp.fr (Fathi BOUDRA) Date: Tue Feb 17 04:53:01 2004 Subject: compile error In-Reply-To: <200402161712.20763.fboudra@uxp.fr> References: <200402161712.20763.fboudra@uxp.fr> Message-ID: <200402171109.25096.fboudra@uxp.fr> hi, i installed a redhat 6.2 and have the toolchain needed by linuxbios : egcs-2.91.66, gas-2.95, ... i take linuxbios from the cvs, and as usual, followed the HOWTO. i tried the sis630 and stpc targets. and again, i can't do the compilation. for the stpc and the winfast same error : gcc -x assembler-with-cpp -DASSEMBLY -E ... crt0.S > crt0.s gcc ... -o crt0.o crt0.s crt0.s : Assembler messages: crt0.s:2303: Error: suffic or operands invalid for 'jmp' make: *** [crt0.o] Error 1 so how can you use linuxbios ? best regards fathi From stepan at suse.de Tue Feb 17 05:22:00 2004 From: stepan at suse.de (Stefan Reinauer) Date: Tue Feb 17 05:22:00 2004 Subject: src/northbridge/amdk8/coherent_ht.c Message-ID: <20040217103845.GA30082@suse.de> Hi, can't we drop optimize_connection() from coherent_ht.c? The link optimization is done later, too, during PCI initialization and currently it assumes a fixed link setup. (ACROSS links of node 0 and 1 used to connect CPUs) Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From pchez at mail.cyberneme.com Tue Feb 17 09:51:01 2004 From: pchez at mail.cyberneme.com (Poonchezhian P.) Date: Tue Feb 17 09:51:01 2004 Subject: Linux BIOS for Intel Pentium MotherBoards ... Message-ID: <200402172036.37812.pchez@mail.cyberneme.com> Can I use Linux BIOS on a Intel Pentium IV Motherboard??? Is that possible for me to compile one such, if it is not available at present ??? -- Poonchezhian P. Email : pchez at mail.cyberneme.com From ollie at lanl.gov Tue Feb 17 11:02:01 2004 From: ollie at lanl.gov (Li-Ta Lo) Date: Tue Feb 17 11:02:01 2004 Subject: 64MB MMIO Hole ? In-Reply-To: References: <1076459153.4047.416.camel@exponential.lanl.gov> <1076535892.4047.1701.camel@exponential.lanl.gov> Message-ID: <1077034682.4047.1717.camel@exponential.lanl.gov> On Wed, 2004-02-11 at 18:23, Eric W. Biederman wrote: > Li-Ta Lo writes: > > > But you also used it for AGP aperture in misc_control.c. Is there > > any reason to do this ? Or the AGP aperture can actually be anything > > else. > > As I recall the AGP aperature must be at least 64M if it exists. > You can read the Opteron docs to confirm this. > > Eric > No, it can be 32MBytes too. So I am confused, are you using the same #define for two different things ? Ollie From ollie at lanl.gov Tue Feb 17 15:45:00 2004 From: ollie at lanl.gov (Li-Ta Lo) Date: Tue Feb 17 15:45:00 2004 Subject: Use of compact flash In-Reply-To: References: Message-ID: <1077051655.3489.25.camel@exponential.lanl.gov> On Tue, 2004-02-17 at 00:13, Andy Pearce wrote: > Hi, > > So if I get this correct the rom has been flashed but it effectively > has no kernel in it, this resides on the CF card. I guess this means that > this card can then be switched to another machine and easily changed with > another kernel to test changes. Am I anywhere near on the right lines yet ? > Yes, in this configuration, the card is just like an HD. Actually, you don't have to change the CF to change the kernel. You just "reinstall" the kernel like what you do with LILO or GRUB. Ollie From david.n.lombard at intel.com Tue Feb 17 16:36:00 2004 From: david.n.lombard at intel.com (Lombard, David N) Date: Tue Feb 17 16:36:00 2004 Subject: Use of compact flash Message-ID: <187D3A7CAB42A54DB61F1D05F0125722025F556F@orsmsx402.jf.intel.com> Be aware, that there are some small "adapters" that allow you to plug your CF onto an IDE cable; PC-CARD-to-CF adapters; and USB (and some IDE) based devices that support CF and other memory devices. The latter two are hot-swap capable; AFAIK, the first type is not. I have both a PC-CARD-based unit (a SanDisk "CompactFlash(tm) PC Card Adapter") that I use in my laptop along with a USB-based built-in device (fits into a 3.5" drive slot of my desktop) that supports the gamut of memory devices. I've had the PC CARD unit much longer as it was supported in the 2.2 kernel. I've heard direct reports of people that have fried bits of their chipsets by just yanking a CF out of the IDE cable "adapter" type of connector while the system was powered. Bottom line, make sure you use know the operating characteristics of your CF connection technology. -- David N. Lombard My comments represent my opinions, not those of Intel Corporation. From ebiederman at lnxi.com Tue Feb 17 17:01:02 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Feb 17 17:01:02 2004 Subject: 64bit intel exentions to ia32 Message-ID: see: http://developer.intel.com/technology/64bitextensions/ Eric From ollie at lanl.gov Tue Feb 17 17:06:00 2004 From: ollie at lanl.gov (Li-Ta Lo) Date: Tue Feb 17 17:06:00 2004 Subject: 64bit intel exentions to ia32 In-Reply-To: References: Message-ID: <1077056564.3489.30.camel@exponential.lanl.gov> On Tue, 2004-02-17 at 15:22, Eric W. Biederman wrote: > see: > http://developer.intel.com/technology/64bitextensions/ > I don't want to read the book. Is it the same as AMD's ? Ollie From ebiederman at lnxi.com Tue Feb 17 17:29:01 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Feb 17 17:29:01 2004 Subject: 64bit intel exentions to ia32 In-Reply-To: <1077056564.3489.30.camel@exponential.lanl.gov> References: <1077056564.3489.30.camel@exponential.lanl.gov> Message-ID: Li-Ta Lo writes: > On Tue, 2004-02-17 at 15:22, Eric W. Biederman wrote: > > see: > > http://developer.intel.com/technology/64bitextensions/ > > > > I don't want to read the book. Is it the same as AMD's ? I haven't found any differences yet. It's still a Xeon and not an Opteron, but I don't see that the OS would really care. Eric From bari at onelabs.com Tue Feb 17 17:30:01 2004 From: bari at onelabs.com (Bari Ari) Date: Tue Feb 17 17:30:01 2004 Subject: 64bit intel exentions to ia32 In-Reply-To: <1077056564.3489.30.camel@exponential.lanl.gov> References: <1077056564.3489.30.camel@exponential.lanl.gov> Message-ID: <403299DD.7020508@onelabs.com> Li-Ta Lo wrote: > I don't want to read the book. Is it the same as AMD's ? From the Intel FAQ: Q9: Is it possible to write software that will run on Intel's processors with 64-bit extension technology, and AMD's 64-bit capable processors? A9: With both companies designing entirely different architectures, the question is whether the operating system and software ported to each processor will run on the other processor, and the answer is yes in most cases. However, Intel processors support additional features, like the SSE3 instructions and Hyper-Threading Technology, which are not supported on non-Intel platforms. As such, we believe developers will achieve maximum performance and stability by designing specifically for Intel architectures and by taking advantage of Intel's breadth of software tools and enabling services. -Bari From sxpert at esitcom.org Tue Feb 17 17:34:00 2004 From: sxpert at esitcom.org (Amaury Jacquot) Date: Tue Feb 17 17:34:00 2004 Subject: 64bit intel exentions to ia32 In-Reply-To: References: <1077056564.3489.30.camel@exponential.lanl.gov> Message-ID: <40329AD4.5060001@esitcom.org> Eric W. Biederman wrote: > Li-Ta Lo writes: > > >>On Tue, 2004-02-17 at 15:22, Eric W. Biederman wrote: >> >>>see: >>>http://developer.intel.com/technology/64bitextensions/ >>> >> >>I don't want to read the book. Is it the same as AMD's ? > > > I haven't found any differences yet. > > It's still a Xeon and not an Opteron, but I don't see that the OS > would really care. unless they somehow manage to install the memory controller inside the proco, there's no way this is gonna be as good as the opteron... > Eric > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From malas at pinetron.com Tue Feb 17 17:47:00 2004 From: malas at pinetron.com (malas at pinetron.com) Date: Tue Feb 17 17:47:00 2004 Subject: ID qghfnodftg... thanks Message-ID: Yours ID gsmpdyibpsh -- Thank -------------- next part -------------- A non-text attachment was scrubbed... Name: iphdsonuyjk.exe Type: application/x-msdownload Size: 11264 bytes Desc: not available URL: From rminnich at lanl.gov Tue Feb 17 23:17:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Tue Feb 17 23:17:01 2004 Subject: Use of compact flash In-Reply-To: <1077051655.3489.25.camel@exponential.lanl.gov> Message-ID: what's really nice on the iTuner is that the CF pops in the front. I can convert nodes from Plan 9 to Linux just by swapping CF cards. Really nice. ron From kevin at koconnor.net Wed Feb 18 20:39:00 2004 From: kevin at koconnor.net (Kevin O'Connor) Date: Wed Feb 18 20:39:00 2004 Subject: Use of compact flash In-Reply-To: References: <1077051655.3489.25.camel@exponential.lanl.gov> Message-ID: <20040219015558.GA21243@arizona.localdomain> On Tue, Feb 17, 2004 at 09:33:12PM -0700, ron minnich wrote: > what's really nice on the iTuner is that the CF pops in the front. I can > convert nodes from Plan 9 to Linux just by swapping CF cards. Really nice. Looking through my local paper's advertisements, I saw an interesting trend - the USB flash parts have become as cheap per MB as the Compact Flash parts. If this trend continues, replacing IDE with USB in the second stage could become a popular alternative. -Kevin -- --------------------------------------------------------------------- | Kevin O'Connor "BTW, IMHO we need a FAQ for | | kevin at koconnor.net 'IMHO', 'FAQ', 'BTW', etc. !" | --------------------------------------------------------------------- From rezso at rdsor.ro Mon Feb 23 04:03:01 2004 From: rezso at rdsor.ro (Balint Cristian) Date: Mon Feb 23 04:03:01 2004 Subject: Testing linuxbios Message-ID: <200402231122.10891.rezso@rdsor.ro> Hi ! I played a little building up few images of linuxbios but i need to know if there is a way of test these images via floppy boot to not need every time to flash ? Thanks, cristian From rezso at rdsor.ro Mon Feb 23 06:18:00 2004 From: rezso at rdsor.ro (Balint Cristian) Date: Mon Feb 23 06:18:00 2004 Subject: Puzzled. Help Please ! Message-ID: <200402231337.41698.rezso@rdsor.ro> I am a little puzzled in steps of making/flashing/testing, I dont understand something at few points: First Q: So my config file, (i atempt to boot on 440bx plus Stefan's latest bk OpenBIOS) so i put it as elf payload, Is it correct ? --------------------///////////////----------------------------------------------------------> target l440bx mainboard intel/l440bx # Enable Serial Console for debugging # It will come up at 115200,8n1 option SERIAL_CONSOLE=1 option VIDEO_CONSOLE=1 # Enable MicroCode update and L2 Cache init for PII and PIII option UPDATE_MICROCODE=1 option CONFIGURE_L2_CACHE=1 # Use the internal VGA frame buffer device #option HAVE_FRAMEBUFFER=0 option USE_CACHE_RAM=0 option USE_GENERIC_ROM=1 option USE_ELF_BOOT=1 makedefine PHLASH_BASE_NAME=laci option CONFIG_UDELAY_TSC=1 option CONFIG_COMPRESS=0 payload /home/rezso/freebios/builtin.image ----------------////////--------------------------------------------------------------------------> I used todays sourceforge CVS pool. Than I obtain the following stuff after typed "make": -rw-r--r-- 1 root root 3506 Feb 23 12:59 linuxbios.map -rwxr-xr-x 1 root root 35852 Feb 23 12:59 linuxbios_payload -rwxr-xr-x 1 root root 35852 Feb 23 12:59 linuxbios_payload.bin -rw-r--r-- 1 root root 65536 Feb 23 12:59 linuxbios.rom -rw-r--r-- 1 root root 524288 Feb 23 12:53 romimage I guess romimage is the one i need but the big dilema: [root at rezso l440bx]# file romimage romimage: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped It is ELF ...... will it boot from flash ? Do i need to do some special conversion over it ? It is flashable with any kind AWARD MS-DOS tool ? I readed that i need to run make phlash but always encouter errors: ----------------------------------------------------------------------------------------------////////////////////////-------------------------------------------------------> [root at rezso l440bx]# make phlash gcc -x assembler-with-cpp -DASSEMBLY -E ... crt0.S > crt0.s gcc ... -o crt0.o crt0.s /home/rezso/freebios/src/northbridge/intel/440bx/raminit.inc: Assembler messages: /home/rezso/freebios/src/northbridge/intel/440bx/raminit.inc:478: Warning: using `%al' instead of `%eax' due to `b' suffix crt0.S:156: Warning: indirect jmp without `*' gcc ... -o version.o /home/rezso/freebios/src/lib/version.c rm -f linuxbios.a ar cr linuxbios.a linuxbiosmain.o linuxpci.o newpci.o clog2.o printk.o serial_subr.o video_subr.o subr.o vsprintf.o memset.o memcpy.o memcmp.o malloc.o elfboot.o do_inflate.o delay.o compute_ip_checksum.o version.o keyboard.o mc146818rtc.o isa-dma.o beep.o vga_load_regs.o font_8x16.o vga_set_mode.o vga_load_pcx.o ide.o boot.o linuxbios_table.o i386_subr.o params.o hardwaremain.o c_start.o northbridge.o southbridge.o superio.o mainboard.o microcode.o mtrr.o l2_cache.o cpuid.o delay_tsc.o gcc -nostdlib -r -o linuxbios_c.o c_start.o rom_fill_inbuf.o linuxbios.a /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/libgcc.a gcc -nostdlib -nostartfiles -static -o linuxbios_c -T /home/rezso/freebios/src/config/linuxbios_c.ld linuxbios_c.o nm -n linuxbios_c | sort > linuxbios_c.map objcopy -O binary linuxbios_c linuxbios_payload.bin cp linuxbios_payload.bin linuxbios_payload gcc -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o nm -n linuxbios | sort > linuxbios.map objcopy -O binary linuxbios linuxbios.strip export size=`ls -l linuxbios.strip | (read p c u g size r ; echo $size)` ; \ echo $size ; \ dd if=linuxbios.strip of=linuxbios.rom bs=1 seek=`expr 65536 - $size` 65536 65536+0 records in 65536+0 records out make: *** No rule to make target `/home/rezso/freebios/../intel_flash_disk/laci.bi1', needed by `laci.bi1.header'. Stop. -----------------------------------------------------------------//////////////////////////////////--------------------------------------------------------> :( Thanks in advance, cristian From bari at onelabs.com Mon Feb 23 10:04:01 2004 From: bari at onelabs.com (Bari Ari) Date: Mon Feb 23 10:04:01 2004 Subject: Testing linuxbios In-Reply-To: <200402231122.10891.rezso@rdsor.ro> References: <200402231122.10891.rezso@rdsor.ro> Message-ID: <403A1AC5.709@onelabs.com> Balint Cristian wrote: > Hi ! > > I played a little building up few images of linuxbios > but i need to know if there is a way of test these images via > floppy boot to not need every time to flash ? BIOS is the first place x86 jumps to after reset (long before floppy access since BIOS sets up the hardware in able to make a floppy access). You can only test a BIOS by having it in Flash waiting to be accessed when the x86 starts or by emulation. Emulating your exact hardware in software like bochs is going to be more work than playing the shell game with BIOS images in Flash. -Bari From peter.fox at aeroflex.com Mon Feb 23 10:11:01 2004 From: peter.fox at aeroflex.com (Peter Fox) Date: Mon Feb 23 10:11:01 2004 Subject: Freebios1 STPC Elite development board changes attached Message-ID: Please find attached my changes to support the STPC Elite processor, and the mainboard/elite build configuration for the STPC Elite development board. These changes are for freebios1. They are mostly copies of the consumer-II stuff by Steve M. Gehlbach, but modified to remove all the graphics stuff, as the Elite has no graphics controller, and to add initialisation for the GP clock etc. I've also put in the bit-bashing SPD code for the Elite, though I don't use it on the development mainboard. I can run Redhat 7.1 fine (serial console only) using filo as the payload. This is using the 20/01/2004 snapshot for other files. -- Peter Fox Aeroflex Test Solutions Principal Design Engineer Stevenage Any opinions expressed above are http://www.aeroflex.com/ not necessarily those of Aeroflex. Tel: + 44 (0) 1438 742200 -------------- next part -------------- A non-text attachment was scrubbed... Name: linuxbios1-stpc-elite.tgz Type: application/x-compressed Size: 15289 bytes Desc: not available URL: From peter.fox at aeroflex.com Mon Feb 23 10:18:01 2004 From: peter.fox at aeroflex.com (Peter Fox) Date: Mon Feb 23 10:18:01 2004 Subject: Freebios1 STPC Elite development board changes attached In-Reply-To: Message-ID: Aagh ! Ignore the following files in the archive, as they are not required: src/include/cpu/stpc/elite/stpc_conf-notused.h src/cpu/stpc/elite/stpc_framebuffer.inc Ta. -- Peter Fox Aeroflex Test Solutions Principal Design Engineer Stevenage Any opinions expressed above are http://www.aeroflex.com/ not necessarily those of Aeroflex. Tel: + 44 (0) 1438 742200 -----Original Message----- From: Peter Fox [mailto:peter.fox at aeroflex.com] Sent: 23 February 2004 15:29 To: Linuxbios Subject: Freebios1 STPC Elite development board changes attached Please find attached my changes to support the STPC Elite processor, and the mainboard/elite build configuration for the STPC Elite development board. These changes are for freebios1. They are mostly copies of the consumer-II stuff by Steve M. Gehlbach, but modified to remove all the graphics stuff, as the Elite has no graphics controller, and to add initialisation for the GP clock etc. I've also put in the bit-bashing SPD code for the Elite, though I don't use it on the development mainboard. I can run Redhat 7.1 fine (serial console only) using filo as the payload. This is using the 20/01/2004 snapshot for other files. -- Peter Fox Aeroflex Test Solutions Principal Design Engineer Stevenage Any opinions expressed above are http://www.aeroflex.com/ not necessarily those of Aeroflex. Tel: + 44 (0) 1438 742200 From dwh at lanl.gov Mon Feb 23 18:47:00 2004 From: dwh at lanl.gov (Hendricks David W.) Date: Mon Feb 23 18:47:00 2004 Subject: Puzzled. Help Please ! Message-ID: (Hoping this goes into the correct thread) You are correct, romimage is what you need to burn. About the ELF image thing--The payload is indeed an ELF image, and LinuxBIOS uses "elfboot" to boot it. The payload can be a normal Linux kernel made bootable by the mkelfImage utility ( ftp://ftp.lnxi.com/pub/mkelfImage/ ), a FILO image ( http://te.to/~ts1/filo/ ), or an Etherboot image ( http://sourceforge.net/projects/etherboot/ ). Perhaps someone more experienced with this can explain in further detail. >>It is flashable with any kind AWARD MS-DOS tool ? You should probably try to use with Flash 'n Burn (Check the original freebios tree) or Linux memory technology devices (MTD -- http://www.linux-mtd.infradead.org/ ). Sure beats booting off a FreeDOS floppy! From rminnich at lanl.gov Mon Feb 23 18:55:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Mon Feb 23 18:55:01 2004 Subject: Puzzled. Help Please ! In-Reply-To: Message-ID: the payload is an elfimage. But 'romimage' should not be elf. It is just a raw romimage to be burned onto flash. I am not sure what happened. GX is pretty much unused nowadays, so that's part of it. ron From fboudra at uxp.fr Wed Feb 25 08:52:01 2004 From: fboudra at uxp.fr (Fathi BOUDRA) Date: Wed Feb 25 08:52:01 2004 Subject: Freebios1 STPC Elite development board changes attached In-Reply-To: References: Message-ID: <200402251510.06938.fboudra@uxp.fr> Hi, thanks for all, the compile works now. I used the redhat 7.1. with Debian stable (woody) it works also. Now i try to use the romimage with my stpc elite board but it hangs after: Call init Enabling com device: 04 iobase = 0x03f8 irq=4 after this some strange character ... On my stpc elite card, i have only 2 serial ports, no floppy, no parallel port. Maybe something goes wrong with this ... i try to use NO_KEYBOARD option set to 1 and MUST_ENABLE_FLOPPY option set to 0 but no change. if someone have an idea ..., now i'm looking into the sources. Best regards -- Fathi > These are the versions I used (from redhat 7.1): > > Program Version Used for > python 1.5.2 Configuring the BIOS. > perl 5.6.0 Used during building the image. > make 3.79.1 For orchestrating compilation etc > gcc 2.96 The C compiler. > binutils 2.10.91 Other program building tools, assembler, linker etc. > fileutils 4.0.36 dd, cp, ls, mkdir etc > textutils 2.0.11 cat etc > sed 3.02 scripts > bash 2.04.1 Command shell, shell scripts > cvs 1.11 Extracting/updating files from the external project archive > sh-utils 2.0 date etc, note some such as echo, test etc are bash built-ins > > -- > Peter Fox Aeroflex Test Solutions > Principal Design Engineer Stevenage > Any opinions expressed above are http://www.aeroflex.com/ > not necessarily those of Aeroflex. Tel: + 44 (0) 1438 742200 From fboudra at uxp.fr Wed Feb 25 09:31:01 2004 From: fboudra at uxp.fr (Fathi BOUDRA) Date: Wed Feb 25 09:31:01 2004 Subject: Freebios1 STPC Elite development board changes attached In-Reply-To: <200402251510.06938.fboudra@uxp.fr> References: <200402251510.06938.fboudra@uxp.fr> Message-ID: <200402251549.01622.fboudra@uxp.fr> my superio base adress is 0x370. the debug show : handle_superio: port 0x0, defaultport 0x3f0 handle_superio: using port 0x3f0 in the Makefile.settings, i have : export SMC_BASE:=0x370 what's wrong ? > Hi, > > thanks for all, the compile works now. I used the redhat 7.1. > with Debian stable (woody) it works also. > > Now i try to use the romimage with my stpc elite board but it hangs after: > Call init > Enabling com device: 04 > iobase = 0x03f8 irq=4 > > after this some strange character ... > On my stpc elite card, i have only 2 serial ports, no floppy, no parallel > port. Maybe something goes wrong with this ... > > i try to use NO_KEYBOARD option set to 1 and MUST_ENABLE_FLOPPY option set > to 0 but no change. > > if someone have an idea ..., now i'm looking into the sources. > > Best regards > > -- > Fathi From rminnich at lanl.gov Wed Feb 25 09:33:00 2004 From: rminnich at lanl.gov (ron minnich) Date: Wed Feb 25 09:33:00 2004 Subject: Freebios1 STPC Elite development board changes attached In-Reply-To: <200402251549.01622.fboudra@uxp.fr> Message-ID: On Wed, 25 Feb 2004, Fathi BOUDRA wrote: > my superio base adress is 0x370. > > the debug show : > handle_superio: port 0x0, defaultport 0x3f0 > handle_superio: using port 0x3f0 > > in the Makefile.settings, i have : > export SMC_BASE:=0x370 OK, you've found the problem. Send me your configure file again. ron From fboudra at uxp.fr Wed Feb 25 09:38:01 2004 From: fboudra at uxp.fr (Fathi BOUDRA) Date: Wed Feb 25 09:38:01 2004 Subject: Freebios1 STPC Elite development board changes attached In-Reply-To: References: Message-ID: <200402251556.33216.fboudra@uxp.fr> > On Wed, 25 Feb 2004, Fathi BOUDRA wrote: > > my superio base adress is 0x370. > > > > the debug show : > > handle_superio: port 0x0, defaultport 0x3f0 > > handle_superio: using port 0x3f0 > > > > in the Makefile.settings, i have : > > export SMC_BASE:=0x370 > > OK, you've found the problem. Send me your configure file again. > > ron -------------- next part -------------- target /root/build/freebios1/stpc mainboard stpc/elite biosbase 0xffff0000 option CONFIG_COMPRESS=0 option ELITE_GPCLOCK_INIT=1 option SERIAL_CONSOLE=1 option TTYS0_BAUD=9600 option DEFAULT_CONSOLE_LOGLEVEL=9 #option MAXIMUM_CONSOLE_LOGLEVEL=9 option DEBUG=1 # enable floppy support option MUST_ENABLE_FLOPPY=0 # enable keyboard support option NO_KEYBOARD=1 # option ROM_IMAGE_SIZE=131072 option ROM_SIZE=131072 option USE_GENERIC_ROM=1 option ZKERNEL_START=0xfffe0000 option USE_ELF_BOOT=1 option PAYLOAD_SIZE=65536 payload /root/build/filo-0.4/filo.elf From rminnich at lanl.gov Wed Feb 25 09:40:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Wed Feb 25 09:40:01 2004 Subject: Freebios1 STPC Elite development board changes attached In-Reply-To: <200402251556.33216.fboudra@uxp.fr> Message-ID: send the config file for the src/mainboard/elite ron From fboudra at uxp.fr Wed Feb 25 09:56:00 2004 From: fboudra at uxp.fr (Fathi BOUDRA) Date: Wed Feb 25 09:56:00 2004 Subject: Freebios1 STPC Elite development board changes attached In-Reply-To: References: Message-ID: <200402251614.04953.fboudra@uxp.fr> Le Mercredi 25 F?vrier 2004 15:57, ron minnich a ?crit : > send the config file for the src/mainboard/elite > > ron > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios -------------- next part -------------- arch i386 mainboardinit cpu/i386/entry16.inc mainboardinit cpu/i386/entry32.inc ldscript cpu/i386/entry16.lds ldscript cpu/i386/entry32.lds mainboardinit cpu/i386/reset16.inc ldscript cpu/i386/reset16.lds # if you prefer 38400 for the console option TTYS0_BAUD=9600 mainboardinit cpu/stpc/elite/stpc_chip.inc mainboardinit cpu/stpc/elite/stpc_ram_init.inc option SMC_BASE=0x370 option HAVE_PIRQ_TABLE=1 mainboardinit superio/SMC/fdc37b78x/setup_serial.inc mainboardinit pc80/serial.inc mainboardinit arch/i386/lib/console.inc mainboardinit cpu/stpc/elite/stpc_ioinit.inc mainboardinit cpu/stpc/elite/stpc_memsize.inc mainboardinit cpu/stpc/elite/stpc_shadow_ram.inc mainboardinit cpu/stpc/elite/stpc_cache.inc northsouthbridge stpc/elite nsuperio SMC/fdc37b78x com1={1,9600} floppy=0 lpt=0 keyboard=0 cpu stpc/elite object mainboard.o object irq_tables.o HAVE_PIRQ_TABLE From rminnich at lanl.gov Wed Feb 25 10:12:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Wed Feb 25 10:12:01 2004 Subject: Freebios1 STPC Elite development board changes attached In-Reply-To: <200402251614.04953.fboudra@uxp.fr> Message-ID: nsuperio SMC/fdc37b78x com1={1,9600} floppy=0 lpt=0 keyboard=0 This line is what is really going to set the SMC base unless the code is incorrectly written. So to change the port you can try this: nsuperio SMC/fdc37b78x port=0x3f0 com1={1,9600} floppy=0 lpt=0 keyboard=0 try that and let me know. ron From fboudra at uxp.fr Wed Feb 25 10:27:00 2004 From: fboudra at uxp.fr (Fathi BOUDRA) Date: Wed Feb 25 10:27:00 2004 Subject: Freebios1 STPC Elite development board changes attached In-Reply-To: References: Message-ID: <200402251645.00827.fboudra@uxp.fr> ok it works, the boot doesn't hang anymore, but now i have an infinite loop after the jump to the boot code : Jumping to boot code at 0x1048dc FILO version 0.4 ... i send a capture of what I have. Probably a problem with filo now. > nsuperio SMC/fdc37b78x com1={1,9600} floppy=0 lpt=0 keyboard=0 > > This line is what is really going to set the SMC base unless the code is > incorrectly written. > > So to change the port you can try this: > nsuperio SMC/fdc37b78x port=0x3f0 com1={1,9600} floppy=0 lpt=0 keyboard=0 > > try that and let me know. > > ron -------------- next part -------------- LinuxBIOS-1.0.0 Wed Feb 25 15:34:21 UTC 2004 starting... Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.0.0 Wed Feb 25 15:34:21 UTC 2004 booting... Finding PCI configuration type. PCI: Using configuration type 1 handle_superio start, nsuperio 1 handle_superio: Pass 0, check #0, s 0000a560 s->super 0000a704 handle_superio: Pass 0, Superio SMC fdc37b72x handle_superio: port 0x370, defaultport 0x3f0 handle_superio: Using port 0x370 handle_superio: Pass 0, done #0 handle_superio done Scanning PCI bus...PCI: pci_scan_bus for bus 0 PCI: 00:0b.0 [104a/020a] PCI: 00:0c.0 [104a/021a] PCI: 00:0c.1 [104a/021a] PCI: 00:1d.0 [8086/1209] PCI: 00:1e.0 [1131/1561] PCI: 00:1e.1 [1131/1561] PCI: 00:1e.2 [1131/1562] PCI: 00:1f.0 [8086/1209] PCI: pci_scan_bus returning with max=00 done Allocating PCI resources... ASSIGN RESOURCES, bus 0 PCI: 00:0c.1 10 <- [0x00001090 - 0x00001097] io PCI: 00:0c.1 14 <- [0x000010b0 - 0x000010b3] io PCI: 00:0c.1 18 <- [0x000010a0 - 0x000010a7] io PCI: 00:0c.1 1c <- [0x000010c0 - 0x000010c3] io PCI: 00:0c.1 20 <- [0x00001080 - 0x0000108f] io PCI: 00:1d.0 10 <- [0xfebe0000 - 0xfebe0fff] mem PCI: 00:1d.0 14 <- [0x00001000 - 0x0000103f] io PCI: 00:1d.0 18 <- [0xfeba0000 - 0xfebbffff] mem PCI: 00:1e.0 10 <- [0xfebe1000 - 0xfebe1fff] mem PCI: 00:1e.1 10 <- [0xfebe2000 - 0xfebe2fff] mem PCI: 00:1e.2 10 <- [0xfebe4000 - 0xfebe40ff] mem PCI: 00:1f.0 10 <- [0xfebe3000 - 0xfebe3fff] mem PCI: 00:1f.0 14 <- [0x00001040 - 0x0000107f] io PCI: 00:1f.0 18 <- [0xfebc0000 - 0xfebdffff] mem ASSIGNED RESOURCES, bus 0 done. Enabling PCI resourcess...PCI: 00:0b.0 cmd <- 07 PCI: 00:0c.0 cmd <- 0f PCI: 00:0c.1 cmd <- 01 PCI: 00:1d.0 cmd <- 03 PCI: 00:1e.0 cmd <- 02 PCI: 00:1e.1 cmd <- 02 PCI: 00:1e.2 cmd <- 02 PCI: 00:1f.0 cmd <- 03 done. Initializing PCI devices... PCI devices initialized stpc memory size= 32 MB totalram: 32M Initializing CPU #0 Enabling cache...done. done. CPU #0 Initialized stpc mainboard_fixup() stpc mainboard_fixup(): found INT pin for dev 0x1d -> pin 1 stpc mainboard_fixup(): wrote pci INTERRUPT_LINE for dev 0x1d -> irq 9 (9) stpc_mainboard_fixup(): wrote conf register 0x57= 0x3; conf register 0x54= 0x89 stpc_mainboard_fixup(): routing_table.slots[0].irq[0].link,mask = 0xf9,0xe00 stpc mainboard_fixup(): found INT pin for dev 0x1e -> pin 1 stpc mainboard_fixup(): wrote pci INTERRUPT_LINE for dev 0x1e -> irq 10 (10) stpc_mainboard_fixup(): wrote conf register 0x57= 0x7; conf register 0x53= 0x8a stpc_mainboard_fixup(): routing_table.slots[1].irq[0].link,mask = 0xfa,0xe00 stpc mainboard_fixup(): found INT pin for dev 0x1f -> pin 1 stpc mainboard_fixup(): wrote pci INTERRUPT_LINE for dev 0x1f -> irq 11 (11) stpc_mainboard_fixup(): wrote conf register 0x57= 0xf; conf register 0x52= 0x8b stpc_mainboard_fixup(): routing_table.slots[2].irq[0].link,mask = 0xfb,0xe00 stpc mainboard_fixup(): checksum calculated= 0x8 stpc mainboard_fixup complete. handle_superio start, nsuperio 1 handle_superio: Pass 1, check #0, s 0000a560 s->super 0000a704 handle_superio: Pass 1, Superio SMC fdc37b72x handle_superio: port 0x370, defaultport 0x3f0 handle_superio: Using port 0x370 Call init Enabling com device: 04 Disabling com device: 05 handle_superio: Pass 1, done #0 handle_superio done handle_superio start, nsuperio 1 handle_superio: Pass 2, check #0, s 0000a560 s->super 0000a704 handle_superio: Pass 2, Superio SMC fdc37b72x handle_superio: port 0x370, defaultport 0x3f0 handle_superio: Using port 0x370 handle_superio: Pass 2, done #0 handle_superio done Checking IRQ routing tables... /root/freebios/src/arch/i386/lib/pirq_routing.c: 30:check_pirq_routing_table() - irq_routing_table located at: 0x00009560 done. Copying IRQ routing tables to 0xf0000...done. Verifing priq routing tables copy at 0xf0000...succeed Wrote linuxbios table at: 00000500 - 00000670 checksum f4ae Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.2 37:init_bytes() - zkernel_start:0xfffe0000 zkernel_mask:0x0000ffff Found ELF candiate at offset 0 New segment addr 0x100000 size 0x20b90 offset 0xa0 filesize 0x6c00 (cleaned up) New segment addr 0x100000 size 0x20b90 offset 0xa0 filesize 0x6c00 New segment addr 0x120ba0 size 0x60 offset 0x6ca0 filesize 0x60 (cleaned up) New segment addr 0x120ba0 size 0x60 offset 0x6ca0 filesize 0x60 Dropping non PT_LOAD segment Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000020b90 filesz: 0x0000000000006c00 Clearing Segment: addr: 0x0000000000106c00 memsz: 0x0000000000019f90 Loading Segment: addr: 0x0000000000120ba0 memsz: 0x0000000000000060 filesz: 0x0000000000000060 Jumping to boot code at 0x1048dc FILO version 0.4 (root at debfat) Wed Feb 25 15:26:28 UTC 2004 From rminnich at lanl.gov Wed Feb 25 10:46:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Wed Feb 25 10:46:01 2004 Subject: Freebios1 STPC Elite development board changes attached In-Reply-To: <200402251645.00827.fboudra@uxp.fr> Message-ID: is your filo trying to use VGA? make sure that it is only trying to use the serial port. ron From fboudra at uxp.fr Wed Feb 25 11:01:01 2004 From: fboudra at uxp.fr (Fathi BOUDRA) Date: Wed Feb 25 11:01:01 2004 Subject: Freebios1 STPC Elite development board changes attached In-Reply-To: References: Message-ID: <200402251719.13266.fboudra@uxp.fr> no, i use set these options : VGA_CONSOLE = 0 PC_KEYBOARD = 0 this is ok, the same problem of peter fox. I used the modified timer.c for filo (don't use rdtsc in filo because it's a 486) and now it works. if someone need it, i join it. > is your filo trying to use VGA? make sure that it is only trying to use > the serial port. > > ron -------------- next part -------------- A non-text attachment was scrubbed... Name: timer.c Type: text/x-csrc Size: 1409 bytes Desc: not available URL: From jdarby at powercom.net Wed Feb 25 12:14:00 2004 From: jdarby at powercom.net (Justin C. Darby) Date: Wed Feb 25 12:14:00 2004 Subject: DFI AZ30-TL Message-ID: <1077730271.9721.22.camel@justin> I have a DFI AZ30-TL sitting in the corner, now collecting dust, that I built for a little duron box in the recent past. The boards, even new, are really cheap, and I was wondering if LinuxBIOS had enough support to get ide booting (via cf adapter) and video to work on them. I want to use this board for a car-based installation, so it (the board) being cheap and maybe unreliable is no problem. :) Here are the basics I beleive have been asked for in the past: VIA? chipsets: North bridge: VIA? KM266 South bridge: VIA? VT8235CD It has normal 184-pin DDR sockets, shared ProSavage8(TM) video (which I perceive to be a problem already..), generic PCI IDE, etc. I'd attach the output of scanpci, but only kernels on the box have grsecurity running on them and scanpci needs ioperm(). If it's needed, I can get it, I'll just need to build a new kernel for the box. DFI has its generic, non-detailed specs at http://www.dfi.com.tw/Product/xx_product_spec_details_r_us.jsp?PRODUCT_ID=1298&CATEGORY_TYPE=null I have some system hacking experience, but I'm mostly a generic application developer, low level code is not entirely my forte. Thanks, Justin From linuxbios at xdr.com Wed Feb 25 13:47:01 2004 From: linuxbios at xdr.com (Dave Ashley) Date: Wed Feb 25 13:47:01 2004 Subject: Quick linux question Message-ID: <200402251905.i1PJ5JqS023176@xdr.com> This is off-topic but I'm hoping someone here will know the answer. In the linux kernel I need to make a module that will map the BOOTROM of an RTL8139 based network card into PCI memory somewhere. I need to write the pci config longword at offset 0x30 with the bus address. I can arbitrarily pick one such as 0xd2000000 and the bootrom appears as expected, but I don't want to step on anything else that might be using that memory area. How can I allocate a block of memory in pci address space to know where to safely map in the bootrom? Also I'll want to free the allocation on module exit. Apologies/thanks as the case may be. -Dave From dwh at lanl.gov Wed Feb 25 16:15:01 2004 From: dwh at lanl.gov (Hendricks David W.) Date: Wed Feb 25 16:15:01 2004 Subject: Puzzled. Help Please ! In-Reply-To: Message-ID: Hmm, I used "file" on one of the rom images i built for the K8s and they also appear as ELFs. Wasn't there a problem with "file?" On Mon, 23 Feb 2004, ron minnich wrote: > the payload is an elfimage. But 'romimage' should not be elf. It is just a > raw romimage to be burned onto flash. > > I am not sure what happened. GX is pretty much unused nowadays, so that's > part of it. > > ron > From stepan at suse.de Wed Feb 25 16:46:00 2004 From: stepan at suse.de (Stefan Reinauer) Date: Wed Feb 25 16:46:00 2004 Subject: Puzzled. Help Please ! In-Reply-To: References: Message-ID: <20040225220401.GA7317@suse.de> * Hendricks David W. [040225 22:14]: > Hmm, I used "file" on one of the rom images i built for the K8s and > they also appear as ELFs. Wasn't there a problem with "file?" I'd guess, since LinuxBIOS is at the end of the image, file sees the payload of the image (which is normally at the beginning) and ignores the "trailing garbage". Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From rminnich at lanl.gov Wed Feb 25 17:18:00 2004 From: rminnich at lanl.gov (ron minnich) Date: Wed Feb 25 17:18:00 2004 Subject: Puzzled. Help Please ! In-Reply-To: Message-ID: On Wed, 25 Feb 2004, Hendricks David W. wrote: > Hmm, I used "file" on one of the rom images i built for the K8s and > they also appear as ELFs. Wasn't there a problem with "file?" yes there is sometimes a problem with file. The issue is that the payload in linuxbios rom is an elfimage, so that the first couple bytes of the romimage fool the file command. This is why the idea of a 'file' command is suspect. In some OSes the file type was a tag in the file metadata (inode to Unix types). ron From YhLu at tyan.com Wed Feb 25 19:48:01 2004 From: YhLu at tyan.com (YhLu) Date: Wed Feb 25 19:48:01 2004 Subject: IP get via Etherboot and IP get dhcpcd Message-ID: <3174569B9743D511922F00A0C9431423041D26DD@TYANWEB> Eric, I put the the dhcpcd in the initrd. After boot system with LinuxBIOS + Etherboot + elf ( with the initrd). I found the IP got by Etherboot and dhcpcd is different. I may only used fixed option in dhcpd.conf to make it get the same addr? Regards Yinghai Lu From stuge-linuxbios at cdy.org Wed Feb 25 20:03:01 2004 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Wed Feb 25 20:03:01 2004 Subject: IP get via Etherboot and IP get dhcpcd In-Reply-To: <3174569B9743D511922F00A0C9431423041D26DD@TYANWEB> References: <3174569B9743D511922F00A0C9431423041D26DD@TYANWEB> Message-ID: <20040226012043.GJ8547@foo.birdnet.se> On Wed, Feb 25, 2004 at 05:10:44PM -0800, YhLu wrote: > Eric, > > I put the the dhcpcd in the initrd. After boot system with LinuxBIOS + > Etherboot + elf ( with the initrd). I found the IP got by Etherboot and > dhcpcd is different. > > I may only used fixed option in dhcpd.conf to make it get the same addr? One explanation would be that Etherboot uses BOOTP while dhcpcd uses DHCP. Try making Etherboot speak DHCP as well. Otherwise maybe you can set up a fake dhcpcd-eth*.info file with the IP, but I doubt dhcpd will approve the request for that same address unless you use a really short lease time. //Peter From ebiederman at lnxi.com Wed Feb 25 21:25:00 2004 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 25 21:25:00 2004 Subject: IP get via Etherboot and IP get dhcpcd In-Reply-To: <20040226012043.GJ8547@foo.birdnet.se> References: <3174569B9743D511922F00A0C9431423041D26DD@TYANWEB> <20040226012043.GJ8547@foo.birdnet.se> Message-ID: Peter Stuge writes: > On Wed, Feb 25, 2004 at 05:10:44PM -0800, YhLu wrote: > > Eric, > > > > I put the the dhcpcd in the initrd. After boot system with LinuxBIOS + > > Etherboot + elf ( with the initrd). I found the IP got by Etherboot and > > dhcpcd is different. > > > > I may only used fixed option in dhcpd.conf to make it get the same addr? If you specify the mac address and a fixed ip address you should always get the same IP. > One explanation would be that Etherboot uses BOOTP while dhcpcd uses DHCP. > Try making Etherboot speak DHCP as well. > > Otherwise maybe you can set up a fake dhcpcd-eth*.info file with the IP, > but I doubt dhcpd will approve the request for that same address unless > you use a really short lease time. There are a couple of other possibilities. dhcpcd is a broken client and can be fooled into thinking a reply to another client is for itself as it does not verify the dhcp reply it uses has the mac address it is requesting an ip address for. dhclient works correctly and is strongly configurable. I think busybox also includes a working dhcp client. Etherboot filters dhcp replies looking for a filename so it will have something to boot from. If you have 2 dhcp servers answering you that could explain the difference. packet sniffers like tcpdump and ethreal are your friends, as well as log files in /var/log/ Eric From YhLu at tyan.com Wed Feb 25 21:34:00 2004 From: YhLu at tyan.com (YhLu) Date: Wed Feb 25 21:34:00 2004 Subject: =?gb2312?B?tPC4tDogSVAgZ2V0IHZpYSBFdGhlcmJvb3QgYW5kIElQIGdldCBk?= =?gb2312?B?aGNwY2Q=?= Message-ID: <3174569B9743D511922F00A0C9431423041D26F6@TYANWEB> Eric, When using nfsroot to put rootfs in NFS server, I need to set "root=/dev/nfs nfsroot=.... ip=bootp" to use mkelfImage to produce one. Elf for boot. Then If there is ip-mac pair in the dhcpd.conf. The kernel can not get the IP address from the DHCP server. The dhcp in busybox seems something simple dhcp.... I will try to use dhclient. Regards YH. -----????----- ???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] ????: 2004?2?25? 18:49 ???: LinuxBIOS ??: YhLu ??: Re: IP get via Etherboot and IP get dhcpcd Peter Stuge writes: > On Wed, Feb 25, 2004 at 05:10:44PM -0800, YhLu wrote: > > Eric, > > > > I put the the dhcpcd in the initrd. After boot system with LinuxBIOS + > > Etherboot + elf ( with the initrd). I found the IP got by Etherboot and > > dhcpcd is different. > > > > I may only used fixed option in dhcpd.conf to make it get the same addr? If you specify the mac address and a fixed ip address you should always get the same IP. > One explanation would be that Etherboot uses BOOTP while dhcpcd uses DHCP. > Try making Etherboot speak DHCP as well. > > Otherwise maybe you can set up a fake dhcpcd-eth*.info file with the IP, > but I doubt dhcpd will approve the request for that same address unless > you use a really short lease time. There are a couple of other possibilities. dhcpcd is a broken client and can be fooled into thinking a reply to another client is for itself as it does not verify the dhcp reply it uses has the mac address it is requesting an ip address for. dhclient works correctly and is strongly configurable. I think busybox also includes a working dhcp client. Etherboot filters dhcp replies looking for a filename so it will have something to boot from. If you have 2 dhcp servers answering you that could explain the difference. packet sniffers like tcpdump and ethreal are your friends, as well as log files in /var/log/ Eric From ollie at lanl.gov Thu Feb 26 12:32:01 2004 From: ollie at lanl.gov (Li-Ta Lo) Date: Thu Feb 26 12:32:01 2004 Subject: Quick linux question In-Reply-To: <200402251905.i1PJ5JqS023176@xdr.com> References: <200402251905.i1PJ5JqS023176@xdr.com> Message-ID: <1077817788.10012.64.camel@exponential.lanl.gov> On Wed, 2004-02-25 at 12:05, Dave Ashley wrote: > This is off-topic but I'm hoping someone here will know the answer. > In the linux kernel I need to make a module that will map the BOOTROM > of an RTL8139 based network card into PCI memory somewhere. I need to > write the pci config longword at offset 0x30 with the bus address. I can > arbitrarily pick one such as 0xd2000000 and the bootrom appears as expected, > but I don't want to step on anything else that might be using that memory > area. How can I allocate a block of memory in pci address space to know > where to safely map in the bootrom? Also I'll want to free the allocation > on module exit. > You probably need ioremap() and iounmap(). Ollie From linuxbios at smashed.demon.co.uk Thu Feb 26 13:05:01 2004 From: linuxbios at smashed.demon.co.uk (James Weir) Date: Thu Feb 26 13:05:01 2004 Subject: Canterwood/Springdale In-Reply-To: <1077817788.10012.64.camel@exponential.lanl.gov> Message-ID: Can anyone let me know if the documentation for the above chipsets is freely available/already ported to linuxbios and does the documentation require a NDA of any kind? Thanks, James From rminnich at lanl.gov Thu Feb 26 13:15:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Thu Feb 26 13:15:01 2004 Subject: Quick linux question In-Reply-To: <1077817788.10012.64.camel@exponential.lanl.gov> Message-ID: I think what dave is saying is 'how do I pick a physical address range on pci that won't conflict' there are calls to allocate address maps in the kernel .. what linux version again? ron From rminnich at lanl.gov Thu Feb 26 14:01:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Thu Feb 26 14:01:01 2004 Subject: Canterwood/Springdale In-Reply-To: Message-ID: On Thu, 26 Feb 2004, James Weir wrote: > Can anyone let me know if the documentation for the above chipsets is freely > available/already ported to linuxbios and does the documentation require a > NDA of any kind? Are these new intel chipsets? Intel has changed policy, it seems, and will no longer release chipset info. I'm not sure how this is going to play out. It seems the itanium secrecy policies are percolating down to the rest of intel's chipset groups. ron From linuxbios at smashed.demon.co.uk Thu Feb 26 14:19:00 2004 From: linuxbios at smashed.demon.co.uk (James Weir) Date: Thu Feb 26 14:19:00 2004 Subject: Canterwood/Springdale In-Reply-To: Message-ID: Ron, Yes these are reasonably new Intel Chips, do you know what is the latest intel chipset which was under the older policy? James. -----Original Message----- From: linuxbios-admin at clustermatic.org [mailto:linuxbios-admin at clustermatic.org] On Behalf Of ron minnich Sent: 26 February 2004 19:20 To: James Weir Cc: linuxbios at clustermatic.org Subject: Re: Canterwood/Springdale On Thu, 26 Feb 2004, James Weir wrote: > Can anyone let me know if the documentation for the above chipsets is freely > available/already ported to linuxbios and does the documentation require a > NDA of any kind? Are these new intel chipsets? Intel has changed policy, it seems, and will no longer release chipset info. I'm not sure how this is going to play out. It seems the itanium secrecy policies are percolating down to the rest of intel's chipset groups. ron _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From bari at onelabs.com Thu Feb 26 14:22:00 2004 From: bari at onelabs.com (Bari Ari) Date: Thu Feb 26 14:22:00 2004 Subject: Canterwood/Springdale In-Reply-To: References: Message-ID: <403E4BE9.2010007@onelabs.com> ron minnich wrote: > On Thu, 26 Feb 2004, James Weir wrote: > > >>Can anyone let me know if the documentation for the above chipsets is freely >>available/already ported to linuxbios and does the documentation require a >>NDA of any kind? > > > Are these new intel chipsets? Canterwood=i875 http://developer.intel.com/design/chipsets/875P/ Springdale=i865 and comes in four flavors http://developer.intel.com/design/chipsets/index.htm?iid=hdnav_dhtml+comp_chipsets& -Bari From rminnich at lanl.gov Thu Feb 26 14:59:01 2004 From: rminnich at lanl.gov (ron minnich) Date: Thu Feb 26 14:59:01 2004 Subject: Canterwood/Springdale In-Reply-To: Message-ID: On Thu, 26 Feb 2004, James Weir wrote: > Yes these are reasonably new Intel Chips, do you know what is the latest > intel chipset which was under the older policy? e7501 ron From YhLu at tyan.com Thu Feb 26 23:15:01 2004 From: YhLu at tyan.com (YhLu) Date: Thu Feb 26 23:15:01 2004 Subject: Prefmem of bus 3 Message-ID: <3174569B9743D511922F00A0C9431423041D27D4@TYANWEB> Eric, I'm trying Quadrics Card in S2882. When the card is plugged in, can not go through the Etherboot. Stuck there. I found the premem of bus calculating seems got some problem. PCI: 01:02.0 1c <- [0x00002000 - 0x00001fff] bus 3 io PCI: 01:02.0 24 <- [0xe0000000 - 0xffffffff] bus 3 prefmem PCI: 01:02.0 20 <- [0xf5200000 - 0xf51fffff] bus 3 mem ASSIGN RESOURCES, bus 3 PCI: 03:03.0 10 <- [0xe0000000 - 0xefffffff] prefmem PCI: 03:03.0 18 <- [0xf0000000 - 0xf3ffffff] prefmem ASSIGNED RESOURCES, bus 3 The bus 3 prefmem should be PCI: 01:02.0 24 <- [0xe0000000 - 0xf3ffffff] bus 3 prefmem Regards YH Allocating resources... PCI: 04:01.0 missing read_resources PCI: 04:01.0 missing read_resources PCI: 04:01.0 missing read_resources PCI: 01:04.5 missing read_resources PCI: 01:04.6 missing read_resources PCI: 01:04.5 missing read_resources PCI: 01:04.6 missing read_resources ASSIGN RESOURCES, bus 0 PCI: 01:04.5 missing read_resources PCI: 01:04.6 missing read_resources PCI: 00:18.0 c0 <- [0x00001000 - 0x00002fff] node 0 link 0 io PCI: 01:04.5 missing read_resources PCI: 01:04.6 missing read_resources PCI: 00:18.0 b8 <- [0xe0000000 - 0xf52fffff] node 0 link 0 mem ASSIGN RESOURCES, bus 1 PCI: 01:01.0 1c <- [0x00002000 - 0x00001fff] bus 2 io PCI: 01:01.0 24 <- [0xf5200000 - 0xf51fffff] bus 2 prefmem PCI: 01:01.0 20 <- [0xf5100000 - 0xf51fffff] bus 2 mem ASSIGN RESOURCES, bus 2 PCI: 02:09.0 10 <- [0xf5100000 - 0xf510ffff] mem PCI: 02:09.0 18 <- [0xf5110000 - 0xf511ffff] mem PCI: 02:09.1 10 <- [0xf5120000 - 0xf512ffff] mem PCI: 02:09.1 18 <- [0xf5130000 - 0xf513ffff] mem ASSIGNED RESOURCES, bus 2 PCI: 01:01.1 10 <- [0xf5200000 - 0xf5200fff] mem PCI: 01:02.0 1c <- [0x00002000 - 0x00001fff] bus 3 io PCI: 01:02.0 24 <- [0xe0000000 - 0xffffffff] bus 3 prefmem PCI: 01:02.0 20 <- [0xf5200000 - 0xf51fffff] bus 3 mem ASSIGN RESOURCES, bus 3 PCI: 03:03.0 10 <- [0xe0000000 - 0xefffffff] prefmem PCI: 03:03.0 18 <- [0xf0000000 - 0xf3ffffff] prefmem ASSIGNED RESOURCES, bus 3 PCI: 01:02.1 10 <- [0xf5201000 - 0xf5201fff] mem PCI: 04:01.0 missing read_resources PCI: 01:03.0 1c <- [0x00001000 - 0x00001fff] bus 4 io PCI: 04:01.0 missing read_resources PCI: 01:03.0 24 <- [0xf5200000 - 0xf51fffff] bus 4 prefmem PCI: 04:01.0 missing read_resources PCI: 01:03.0 20 <- [0xf4000000 - 0xf5ffffff] bus 4 mem ASSIGN RESOURCES, bus 4 PCI: 04:00.0 10 <- [0xf5020000 - 0xf5020fff] mem PCI: 04:00.1 10 <- [0xf5021000 - 0xf5021fff] mem PCI: 04:00.2 10 <- [0xf5025000 - 0xf50250ff] mem PCI: 04:00.2 14 <- [0xf5026000 - 0xf502601f] mem PCI: 04:01.0 missing set_resources PCI: 04:05.0 10 <- [0x00001450 - 0x00001457] io PCI: 04:05.0 14 <- [0x00001470 - 0x00001473] io PCI: 04:05.0 18 <- [0x00001460 - 0x00001467] io PCI: 04:05.0 1c <- [0x00001480 - 0x00001483] io PCI: 04:05.0 20 <- [0x00001440 - 0x0000144f] io PCI: 04:05.0 24 <- [0xf5024000 - 0xf50243ff] mem PCI: 04:06.0 10 <- [0xf4000000 - 0xf4ffffff] mem PCI: 04:06.0 14 <- [0x00001000 - 0x000010ff] io PCI: 04:06.0 18 <- [0xf5022000 - 0xf5022fff] mem PCI: 04:08.0 10 <- [0xf5023000 - 0xf5023fff] mem PCI: 04:08.0 14 <- [0x00001400 - 0x0000143f] io PCI: 04:08.0 18 <- [0xf5000000 - 0xf501ffff] mem ASSIGNED RESOURCES, bus 4 PCI: 01:04.0 00 <- [0x00000000 - 0xffffffff] io PCI: 01:04.0 00 <- [0x00000000 - 0xffffffff] mem ASSIGN RESOURCES, bus 0 PNP: 002e.0 60 <- [0x000003f0 - 0x000003f7 io] PNP: 002e.0 70 <- [0x00000006 - 0x00000006 irq] PNP: 002e.0 74 <- [0x00000002 - 0x00000002 drq] PNP: 002e.1 60 <- [0x00000378 - 0x0000037f io] PNP: 002e.1 70 <- [0x00000007 - 0x00000007 irq] PNP: 002e.1 74 <- [0x00000004 - 0x00000004 drq] PNP: 002e.2 60 <- [0x000003f8 - 0x000003ff io] PNP: 002e.2 70 <- [0x00000004 - 0x00000004 irq] PNP: 002e.3 60 <- [0x000002f8 - 0x000002ff io] PNP: 002e.3 70 <- [0x00000003 - 0x00000003 irq] PNP: 002e.5 60 <- [0x00000060 - 0x00000060 io] PNP: 002e.5 62 <- [0x00000064 - 0x00000064 io] PNP: 002e.5 70 <- [0x00000001 - 0x00000001 irq] PNP: 002e.5 72 <- [0x0000000c - 0x0000000c irq] PNP: 002e.6 60 <- [0x00002030 - 0x00002037 io] ERROR: PNP: 002e.6 70 not allocated PNP: 002e.7 60 <- [0x00000201 - 0x00000201 io] PNP: 002e.7 62 <- [0x00000330 - 0x00000330 io] PNP: 002e.7 70 <- [0x00000009 - 0x00000009 irq] ERROR: PNP: 002e.a 70 not allocated PNP: 002e.b 60 <- [0x00002040 - 0x00002047 io] ERROR: PNP: 002e.b 70 not allocated ASSIGNED RESOURCES, bus 0 PCI: 01:04.1 20 <- [0x00002020 - 0x0000202f] io PCI: 01:04.2 10 <- [0x00002000 - 0x0000201f] io PCI: 01:04.5 missing set_resources PCI: 01:04.6 missing set_resources ASSIGNED RESOURCES, bus 1 ASSIGNED RESOURCES, bus 0 Allocating VGA resource done. From YhLu at tyan.com Fri Feb 27 14:02:00 2004 From: YhLu at tyan.com (YhLu) Date: Fri Feb 27 14:02:00 2004 Subject: Prefmem of bus 3 Message-ID: <3174569B9743D511922F00A0C9431423041D280C@TYANWEB> Ron, Have you ever tested myrinet card on K8 MB under LinuxBIOS? I have tested the Mellanox IB card, and got problem too. And it also use prefmem. Regards YH -----????----- ???: YhLu ????: 2004?2?26? 20:38 ???: ebiederman at lnxi.com; LinuxBIOS ??: Prefmem of bus 3 Eric, I'm trying Quadrics Card in S2882. When the card is plugged in, can not go through the Etherboot. Stuck there. I found the premem of bus calculating seems got some problem. PCI: 01:02.0 1c <- [0x00002000 - 0x00001fff] bus 3 io PCI: 01:02.0 24 <- [0xe0000000 - 0xffffffff] bus 3 prefmem PCI: 01:02.0 20 <- [0xf5200000 - 0xf51fffff] bus 3 mem ASSIGN RESOURCES, bus 3 PCI: 03:03.0 10 <- [0xe0000000 - 0xefffffff] prefmem PCI: 03:03.0 18 <- [0xf0000000 - 0xf3ffffff] prefmem ASSIGNED RESOURCES, bus 3 The bus 3 prefmem should be PCI: 01:02.0 24 <- [0xe0000000 - 0xf3ffffff] bus 3 prefmem Regards YH Allocating resources... PCI: 04:01.0 missing read_resources PCI: 04:01.0 missing read_resources PCI: 04:01.0 missing read_resources PCI: 01:04.5 missing read_resources PCI: 01:04.6 missing read_resources PCI: 01:04.5 missing read_resources PCI: 01:04.6 missing read_resources ASSIGN RESOURCES, bus 0 PCI: 01:04.5 missing read_resources PCI: 01:04.6 missing read_resources PCI: 00:18.0 c0 <- [0x00001000 - 0x00002fff] node 0 link 0 io PCI: 01:04.5 missing read_resources PCI: 01:04.6 missing read_resources PCI: 00:18.0 b8 <- [0xe0000000 - 0xf52fffff] node 0 link 0 mem ASSIGN RESOURCES, bus 1 PCI: 01:01.0 1c <- [0x00002000 - 0x00001fff] bus 2 io PCI: 01:01.0 24 <- [0xf5200000 - 0xf51fffff] bus 2 prefmem PCI: 01:01.0 20 <- [0xf5100000 - 0xf51fffff] bus 2 mem ASSIGN RESOURCES, bus 2 PCI: 02:09.0 10 <- [0xf5100000 - 0xf510ffff] mem PCI: 02:09.0 18 <- [0xf5110000 - 0xf511ffff] mem PCI: 02:09.1 10 <- [0xf5120000 - 0xf512ffff] mem PCI: 02:09.1 18 <- [0xf5130000 - 0xf513ffff] mem ASSIGNED RESOURCES, bus 2 PCI: 01:01.1 10 <- [0xf5200000 - 0xf5200fff] mem PCI: 01:02.0 1c <- [0x00002000 - 0x00001fff] bus 3 io PCI: 01:02.0 24 <- [0xe0000000 - 0xffffffff] bus 3 prefmem PCI: 01:02.0 20 <- [0xf5200000 - 0xf51fffff] bus 3 mem ASSIGN RESOURCES, bus 3 PCI: 03:03.0 10 <- [0xe0000000 - 0xefffffff] prefmem PCI: 03:03.0 18 <- [0xf0000000 - 0xf3ffffff] prefmem ASSIGNED RESOURCES, bus 3 PCI: 01:02.1 10 <- [0xf5201000 - 0xf5201fff] mem PCI: 04:01.0 missing read_resources PCI: 01:03.0 1c <- [0x00001000 - 0x00001fff] bus 4 io PCI: 04:01.0 missing read_resources PCI: 01:03.0 24 <- [0xf5200000 - 0xf51fffff] bus 4 prefmem PCI: 04:01.0 missing read_resources PCI: 01:03.0 20 <- [0xf4000000 - 0xf5ffffff] bus 4 mem ASSIGN RESOURCES, bus 4 PCI: 04:00.0 10 <- [0xf5020000 - 0xf5020fff] mem PCI: 04:00.1 10 <- [0xf5021000 - 0xf5021fff] mem PCI: 04:00.2 10 <- [0xf5025000 - 0xf50250ff] mem PCI: 04:00.2 14 <- [0xf5026000 - 0xf502601f] mem PCI: 04:01.0 missing set_resources PCI: 04:05.0 10 <- [0x00001450 - 0x00001457] io PCI: 04:05.0 14 <- [0x00001470 - 0x00001473] io PCI: 04:05.0 18 <- [0x00001460 - 0x00001467] io PCI: 04:05.0 1c <- [0x00001480 - 0x00001483] io PCI: 04:05.0 20 <- [0x00001440 - 0x0000144f] io PCI: 04:05.0 24 <- [0xf5024000 - 0xf50243ff] mem PCI: 04:06.0 10 <- [0xf4000000 - 0xf4ffffff] mem PCI: 04:06.0 14 <- [0x00001000 - 0x000010ff] io PCI: 04:06.0 18 <- [0xf5022000 - 0xf5022fff] mem PCI: 04:08.0 10 <- [0xf5023000 - 0xf5023fff] mem PCI: 04:08.0 14 <- [0x00001400 - 0x0000143f] io PCI: 04:08.0 18 <- [0xf5000000 - 0xf501ffff] mem ASSIGNED RESOURCES, bus 4 PCI: 01:04.0 00 <- [0x00000000 - 0xffffffff] io PCI: 01:04.0 00 <- [0x00000000 - 0xffffffff] mem ASSIGN RESOURCES, bus 0 PNP: 002e.0 60 <- [0x000003f0 - 0x000003f7 io] PNP: 002e.0 70 <- [0x00000006 - 0x00000006 irq] PNP: 002e.0 74 <- [0x00000002 - 0x00000002 drq] PNP: 002e.1 60 <- [0x00000378 - 0x0000037f io] PNP: 002e.1 70 <- [0x00000007 - 0x00000007 irq] PNP: 002e.1 74 <- [0x00000004 - 0x00000004 drq] PNP: 002e.2 60 <- [0x000003f8 - 0x000003ff io] PNP: 002e.2 70 <- [0x00000004 - 0x00000004 irq] PNP: 002e.3 60 <- [0x000002f8 - 0x000002ff io] PNP: 002e.3 70 <- [0x00000003 - 0x00000003 irq] PNP: 002e.5 60 <- [0x00000060 - 0x00000060 io] PNP: 002e.5 62 <- [0x00000064 - 0x00000064 io] PNP: 002e.5 70 <- [0x00000001 - 0x00000001 irq] PNP: 002e.5 72 <- [0x0000000c - 0x0000000c irq] PNP: 002e.6 60 <- [0x00002030 - 0x00002037 io] ERROR: PNP: 002e.6 70 not allocated PNP: 002e.7 60 <- [0x00000201 - 0x00000201 io] PNP: 002e.7 62 <- [0x00000330 - 0x00000330 io] PNP: 002e.7 70 <- [0x00000009 - 0x00000009 irq] ERROR: PNP: 002e.a 70 not allocated PNP: 002e.b 60 <- [0x00002040 - 0x00002047 io] ERROR: PNP: 002e.b 70 not allocated ASSIGNED RESOURCES, bus 0 PCI: 01:04.1 20 <- [0x00002020 - 0x0000202f] io PCI: 01:04.2 10 <- [0x00002000 - 0x0000201f] io PCI: 01:04.5 missing set_resources PCI: 01:04.6 missing set_resources ASSIGNED RESOURCES, bus 1 ASSIGNED RESOURCES, bus 0 Allocating VGA resource done. _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From rminnich at lanl.gov Fri Feb 27 14:08:00 2004 From: rminnich at lanl.gov (ron minnich) Date: Fri Feb 27 14:08:00 2004 Subject: Prefmem of bus 3 In-Reply-To: <3174569B9743D511922F00A0C9431423041D280C@TYANWEB> Message-ID: On Fri, 27 Feb 2004, YhLu wrote: > Have you ever tested myrinet card on K8 MB under LinuxBIOS? we have a 1408-node K8 machine with myrinet working under linuxbios, and a 256-node K8 machine working with linuxbios. Arima HDAMA mainboards. I wonder what's going on here, I have not had time to look in detail. ron From ollie at lanl.gov Fri Feb 27 16:00:00 2004 From: ollie at lanl.gov (Li-Ta Lo) Date: Fri Feb 27 16:00:00 2004 Subject: Prefmem of bus 3 In-Reply-To: <3174569B9743D511922F00A0C9431423041D280C@TYANWEB> References: <3174569B9743D511922F00A0C9431423041D280C@TYANWEB> Message-ID: <1077916691.10012.81.camel@exponential.lanl.gov> On Fri, 2004-02-27 at 12:25, YhLu wrote: > Ron, > > Have you ever tested myrinet card on K8 MB under LinuxBIOS? > > I have tested the Mellanox IB card, and got problem too. And it also use > prefmem. > The device has two prefmem regions ? Ollie > Regards > > YH > > -----????----- > ???: YhLu > ????: 2004?2?26? 20:38 > ???: ebiederman at lnxi.com; LinuxBIOS > ??: Prefmem of bus 3 > > Eric, > > I'm trying Quadrics Card in S2882. When the card is plugged in, can not go > through the Etherboot. Stuck there. > > I found the premem of bus calculating seems got some problem. > > PCI: 01:02.0 1c <- [0x00002000 - 0x00001fff] bus 3 io > PCI: 01:02.0 24 <- [0xe0000000 - 0xffffffff] bus 3 prefmem > PCI: 01:02.0 20 <- [0xf5200000 - 0xf51fffff] bus 3 mem > ASSIGN RESOURCES, bus 3 > PCI: 03:03.0 10 <- [0xe0000000 - 0xefffffff] prefmem > PCI: 03:03.0 18 <- [0xf0000000 - 0xf3ffffff] prefmem > ASSIGNED RESOURCES, bus 3 > > The bus 3 prefmem should be > PCI: 01:02.0 24 <- [0xe0000000 - 0xf3ffffff] bus 3 prefmem > > > Regards > > YH > > > > > Allocating resources... > PCI: 04:01.0 missing read_resources > PCI: 04:01.0 missing read_resources > PCI: 04:01.0 missing read_resources > PCI: 01:04.5 missing read_resources > PCI: 01:04.6 missing read_resources > PCI: 01:04.5 missing read_resources > PCI: 01:04.6 missing read_resources > ASSIGN RESOURCES, bus 0 > PCI: 01:04.5 missing read_resources > PCI: 01:04.6 missing read_resources > PCI: 00:18.0 c0 <- [0x00001000 - 0x00002fff] node 0 link 0 io > PCI: 01:04.5 missing read_resources > PCI: 01:04.6 missing read_resources > PCI: 00:18.0 b8 <- [0xe0000000 - 0xf52fffff] node 0 link 0 mem > ASSIGN RESOURCES, bus 1 > PCI: 01:01.0 1c <- [0x00002000 - 0x00001fff] bus 2 io > PCI: 01:01.0 24 <- [0xf5200000 - 0xf51fffff] bus 2 prefmem > PCI: 01:01.0 20 <- [0xf5100000 - 0xf51fffff] bus 2 mem > ASSIGN RESOURCES, bus 2 > PCI: 02:09.0 10 <- [0xf5100000 - 0xf510ffff] mem > PCI: 02:09.0 18 <- [0xf5110000 - 0xf511ffff] mem > PCI: 02:09.1 10 <- [0xf5120000 - 0xf512ffff] mem > PCI: 02:09.1 18 <- [0xf5130000 - 0xf513ffff] mem > ASSIGNED RESOURCES, bus 2 > PCI: 01:01.1 10 <- [0xf5200000 - 0xf5200fff] mem > PCI: 01:02.0 1c <- [0x00002000 - 0x00001fff] bus 3 io > PCI: 01:02.0 24 <- [0xe0000000 - 0xffffffff] bus 3 prefmem > PCI: 01:02.0 20 <- [0xf5200000 - 0xf51fffff] bus 3 mem > ASSIGN RESOURCES, bus 3 > PCI: 03:03.0 10 <- [0xe0000000 - 0xefffffff] prefmem > PCI: 03:03.0 18 <- [0xf0000000 - 0xf3ffffff] prefmem > ASSIGNED RESOURCES, bus 3 > PCI: 01:02.1 10 <- [0xf5201000 - 0xf5201fff] mem > PCI: 04:01.0 missing read_resources > PCI: 01:03.0 1c <- [0x00001000 - 0x00001fff] bus 4 io > PCI: 04:01.0 missing read_resources > PCI: 01:03.0 24 <- [0xf5200000 - 0xf51fffff] bus 4 prefmem > PCI: 04:01.0 missing read_resources > PCI: 01:03.0 20 <- [0xf4000000 - 0xf5ffffff] bus 4 mem > ASSIGN RESOURCES, bus 4 > PCI: 04:00.0 10 <- [0xf5020000 - 0xf5020fff] mem > PCI: 04:00.1 10 <- [0xf5021000 - 0xf5021fff] mem > PCI: 04:00.2 10 <- [0xf5025000 - 0xf50250ff] mem > PCI: 04:00.2 14 <- [0xf5026000 - 0xf502601f] mem > PCI: 04:01.0 missing set_resources > PCI: 04:05.0 10 <- [0x00001450 - 0x00001457] io > PCI: 04:05.0 14 <- [0x00001470 - 0x00001473] io > PCI: 04:05.0 18 <- [0x00001460 - 0x00001467] io > PCI: 04:05.0 1c <- [0x00001480 - 0x00001483] io > PCI: 04:05.0 20 <- [0x00001440 - 0x0000144f] io > PCI: 04:05.0 24 <- [0xf5024000 - 0xf50243ff] mem > PCI: 04:06.0 10 <- [0xf4000000 - 0xf4ffffff] mem > PCI: 04:06.0 14 <- [0x00001000 - 0x000010ff] io > PCI: 04:06.0 18 <- [0xf5022000 - 0xf5022fff] mem > PCI: 04:08.0 10 <- [0xf5023000 - 0xf5023fff] mem > PCI: 04:08.0 14 <- [0x00001400 - 0x0000143f] io > PCI: 04:08.0 18 <- [0xf5000000 - 0xf501ffff] mem > ASSIGNED RESOURCES, bus 4 > PCI: 01:04.0 00 <- [0x00000000 - 0xffffffff] io > PCI: 01:04.0 00 <- [0x00000000 - 0xffffffff] mem > ASSIGN RESOURCES, bus 0 > PNP: 002e.0 60 <- [0x000003f0 - 0x000003f7 io] > PNP: 002e.0 70 <- [0x00000006 - 0x00000006 irq] > PNP: 002e.0 74 <- [0x00000002 - 0x00000002 drq] > PNP: 002e.1 60 <- [0x00000378 - 0x0000037f io] > PNP: 002e.1 70 <- [0x00000007 - 0x00000007 irq] > PNP: 002e.1 74 <- [0x00000004 - 0x00000004 drq] > PNP: 002e.2 60 <- [0x000003f8 - 0x000003ff io] > PNP: 002e.2 70 <- [0x00000004 - 0x00000004 irq] > PNP: 002e.3 60 <- [0x000002f8 - 0x000002ff io] > PNP: 002e.3 70 <- [0x00000003 - 0x00000003 irq] > PNP: 002e.5 60 <- [0x00000060 - 0x00000060 io] > PNP: 002e.5 62 <- [0x00000064 - 0x00000064 io] > PNP: 002e.5 70 <- [0x00000001 - 0x00000001 irq] > PNP: 002e.5 72 <- [0x0000000c - 0x0000000c irq] > PNP: 002e.6 60 <- [0x00002030 - 0x00002037 io] > ERROR: PNP: 002e.6 70 not allocated > PNP: 002e.7 60 <- [0x00000201 - 0x00000201 io] > PNP: 002e.7 62 <- [0x00000330 - 0x00000330 io] > PNP: 002e.7 70 <- [0x00000009 - 0x00000009 irq] > ERROR: PNP: 002e.a 70 not allocated > PNP: 002e.b 60 <- [0x00002040 - 0x00002047 io] > ERROR: PNP: 002e.b 70 not allocated > ASSIGNED RESOURCES, bus 0 > PCI: 01:04.1 20 <- [0x00002020 - 0x0000202f] io > PCI: 01:04.2 10 <- [0x00002000 - 0x0000201f] io > PCI: 01:04.5 missing set_resources > PCI: 01:04.6 missing set_resources > ASSIGNED RESOURCES, bus 1 > ASSIGNED RESOURCES, bus 0 > Allocating VGA resource > done. > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From YhLu at tyan.com Fri Feb 27 23:33:00 2004 From: YhLu at tyan.com (YhLu) Date: Fri Feb 27 23:33:00 2004 Subject: =?gb2312?B?tPC4tDogUHJlZm1lbSBvZiBidXMgMw==?= Message-ID: <3174569B9743D511922F00A0C9431423041D287D@TYANWEB> In Normal BIOS it is using Bus 1, device 3, function 0: Network controller: Quadrics Ltd QsNetII Cluster Interconnect (rev 1). IRQ 28. Master Capable. Latency=64. Min Gnt=255. Prefetchable 64 bit memory at 0xe0000000 [0xefffffff]. Prefetchable 64 bit memory at 0xf8000000 [0xfbffffff]. -----????----- ???: Li-Ta Lo [mailto:ollie at lanl.gov] ????: 2004?2?27? 13:18 ???: YhLu ??: ron minnich; ebiederman at lnxi.com; LinuxBIOS ??: Re: Prefmem of bus 3 On Fri, 2004-02-27 at 12:25, YhLu wrote: > Ron, > > Have you ever tested myrinet card on K8 MB under LinuxBIOS? > > I have tested the Mellanox IB card, and got problem too. And it also use > prefmem. > The device has two prefmem regions ? Ollie > Regards > > YH > > -----????----- > ???: YhLu > ????: 2004?2?26? 20:38 > ???: ebiederman at lnxi.com; LinuxBIOS > ??: Prefmem of bus 3 > > Eric, > > I'm trying Quadrics Card in S2882. When the card is plugged in, can not go > through the Etherboot. Stuck there. > > I found the premem of bus calculating seems got some problem. > > PCI: 01:02.0 1c <- [0x00002000 - 0x00001fff] bus 3 io > PCI: 01:02.0 24 <- [0xe0000000 - 0xffffffff] bus 3 prefmem > PCI: 01:02.0 20 <- [0xf5200000 - 0xf51fffff] bus 3 mem > ASSIGN RESOURCES, bus 3 > PCI: 03:03.0 10 <- [0xe0000000 - 0xefffffff] prefmem > PCI: 03:03.0 18 <- [0xf0000000 - 0xf3ffffff] prefmem > ASSIGNED RESOURCES, bus 3 > > The bus 3 prefmem should be > PCI: 01:02.0 24 <- [0xe0000000 - 0xf3ffffff] bus 3 prefmem > > > Regards > > YH > > > > > Allocating resources... > PCI: 04:01.0 missing read_resources > PCI: 04:01.0 missing read_resources > PCI: 04:01.0 missing read_resources > PCI: 01:04.5 missing read_resources > PCI: 01:04.6 missing read_resources > PCI: 01:04.5 missing read_resources > PCI: 01:04.6 missing read_resources > ASSIGN RESOURCES, bus 0 > PCI: 01:04.5 missing read_resources > PCI: 01:04.6 missing read_resources > PCI: 00:18.0 c0 <- [0x00001000 - 0x00002fff] node 0 link 0 io > PCI: 01:04.5 missing read_resources > PCI: 01:04.6 missing read_resources > PCI: 00:18.0 b8 <- [0xe0000000 - 0xf52fffff] node 0 link 0 mem > ASSIGN RESOURCES, bus 1 > PCI: 01:01.0 1c <- [0x00002000 - 0x00001fff] bus 2 io > PCI: 01:01.0 24 <- [0xf5200000 - 0xf51fffff] bus 2 prefmem > PCI: 01:01.0 20 <- [0xf5100000 - 0xf51fffff] bus 2 mem > ASSIGN RESOURCES, bus 2 > PCI: 02:09.0 10 <- [0xf5100000 - 0xf510ffff] mem > PCI: 02:09.0 18 <- [0xf5110000 - 0xf511ffff] mem > PCI: 02:09.1 10 <- [0xf5120000 - 0xf512ffff] mem > PCI: 02:09.1 18 <- [0xf5130000 - 0xf513ffff] mem > ASSIGNED RESOURCES, bus 2 > PCI: 01:01.1 10 <- [0xf5200000 - 0xf5200fff] mem > PCI: 01:02.0 1c <- [0x00002000 - 0x00001fff] bus 3 io > PCI: 01:02.0 24 <- [0xe0000000 - 0xffffffff] bus 3 prefmem > PCI: 01:02.0 20 <- [0xf5200000 - 0xf51fffff] bus 3 mem > ASSIGN RESOURCES, bus 3 > PCI: 03:03.0 10 <- [0xe0000000 - 0xefffffff] prefmem > PCI: 03:03.0 18 <- [0xf0000000 - 0xf3ffffff] prefmem > ASSIGNED RESOURCES, bus 3 > PCI: 01:02.1 10 <- [0xf5201000 - 0xf5201fff] mem > PCI: 04:01.0 missing read_resources > PCI: 01:03.0 1c <- [0x00001000 - 0x00001fff] bus 4 io > PCI: 04:01.0 missing read_resources > PCI: 01:03.0 24 <- [0xf5200000 - 0xf51fffff] bus 4 prefmem > PCI: 04:01.0 missing read_resources > PCI: 01:03.0 20 <- [0xf4000000 - 0xf5ffffff] bus 4 mem > ASSIGN RESOURCES, bus 4 > PCI: 04:00.0 10 <- [0xf5020000 - 0xf5020fff] mem > PCI: 04:00.1 10 <- [0xf5021000 - 0xf5021fff] mem > PCI: 04:00.2 10 <- [0xf5025000 - 0xf50250ff] mem > PCI: 04:00.2 14 <- [0xf5026000 - 0xf502601f] mem > PCI: 04:01.0 missing set_resources > PCI: 04:05.0 10 <- [0x00001450 - 0x00001457] io > PCI: 04:05.0 14 <- [0x00001470 - 0x00001473] io > PCI: 04:05.0 18 <- [0x00001460 - 0x00001467] io > PCI: 04:05.0 1c <- [0x00001480 - 0x00001483] io > PCI: 04:05.0 20 <- [0x00001440 - 0x0000144f] io > PCI: 04:05.0 24 <- [0xf5024000 - 0xf50243ff] mem > PCI: 04:06.0 10 <- [0xf4000000 - 0xf4ffffff] mem > PCI: 04:06.0 14 <- [0x00001000 - 0x000010ff] io > PCI: 04:06.0 18 <- [0xf5022000 - 0xf5022fff] mem > PCI: 04:08.0 10 <- [0xf5023000 - 0xf5023fff] mem > PCI: 04:08.0 14 <- [0x00001400 - 0x0000143f] io > PCI: 04:08.0 18 <- [0xf5000000 - 0xf501ffff] mem > ASSIGNED RESOURCES, bus 4 > PCI: 01:04.0 00 <- [0x00000000 - 0xffffffff] io > PCI: 01:04.0 00 <- [0x00000000 - 0xffffffff] mem > ASSIGN RESOURCES, bus 0 > PNP: 002e.0 60 <- [0x000003f0 - 0x000003f7 io] > PNP: 002e.0 70 <- [0x00000006 - 0x00000006 irq] > PNP: 002e.0 74 <- [0x00000002 - 0x00000002 drq] > PNP: 002e.1 60 <- [0x00000378 - 0x0000037f io] > PNP: 002e.1 70 <- [0x00000007 - 0x00000007 irq] > PNP: 002e.1 74 <- [0x00000004 - 0x00000004 drq] > PNP: 002e.2 60 <- [0x000003f8 - 0x000003ff io] > PNP: 002e.2 70 <- [0x00000004 - 0x00000004 irq] > PNP: 002e.3 60 <- [0x000002f8 - 0x000002ff io] > PNP: 002e.3 70 <- [0x00000003 - 0x00000003 irq] > PNP: 002e.5 60 <- [0x00000060 - 0x00000060 io] > PNP: 002e.5 62 <- [0x00000064 - 0x00000064 io] > PNP: 002e.5 70 <- [0x00000001 - 0x00000001 irq] > PNP: 002e.5 72 <- [0x0000000c - 0x0000000c irq] > PNP: 002e.6 60 <- [0x00002030 - 0x00002037 io] > ERROR: PNP: 002e.6 70 not allocated > PNP: 002e.7 60 <- [0x00000201 - 0x00000201 io] > PNP: 002e.7 62 <- [0x00000330 - 0x00000330 io] > PNP: 002e.7 70 <- [0x00000009 - 0x00000009 irq] > ERROR: PNP: 002e.a 70 not allocated > PNP: 002e.b 60 <- [0x00002040 - 0x00002047 io] > ERROR: PNP: 002e.b 70 not allocated > ASSIGNED RESOURCES, bus 0 > PCI: 01:04.1 20 <- [0x00002020 - 0x0000202f] io > PCI: 01:04.2 10 <- [0x00002000 - 0x0000201f] io > PCI: 01:04.5 missing set_resources > PCI: 01:04.6 missing set_resources > ASSIGNED RESOURCES, bus 1 > ASSIGNED RESOURCES, bus 0 > Allocating VGA resource > done. > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios >