From ollie at lanl.gov Fri Dec 1 00:05:53 2006 From: ollie at lanl.gov (Li-Ta Lo) Date: Thu, 30 Nov 2006 16:05:53 -0700 Subject: [LinuxBIOS] Disassembly? In-Reply-To: <561DC80D-CE7B-4B78-B34A-9ED4068FFE04@kernel.crashing.org> References: <561DC80D-CE7B-4B78-B34A-9ED4068FFE04@kernel.crashing.org> Message-ID: <1164927953.2407.104.camel@exponential.lanl.gov> On Thu, 2006-11-30 at 18:26 +0100, Segher Boessenkool wrote: > > Although I haven't seen discussion of disassembling factory BIOS, I > > would think this has been discussed; why is this not routine, or > > effective, for these unruly Intel chipsets which can't get DRAM happy? > > Of course it has been done. It won't tell you _why_ certain > things are done, or what they actually do -- disassembling > machine code doesn't give you source code. > Another factor you have think about is how do you even know the factory bios is doing it right? If you imitate what a buggy factory BIOS is doing, you are going to reproduce the exact same bug in LB. I guess this is not pretty in the court. Ollie From yinghai.lu at amd.com Fri Dec 1 00:55:31 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Thu, 30 Nov 2006 15:55:31 -0800 Subject: [LinuxBIOS] USB debug device Message-ID: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> Where to get USB-to-Serial or USB-to-USB device mentioned in the doc? http://www.usb.org/developers/presentations/pres0602/john_keys.pdf YH From segher at kernel.crashing.org Fri Dec 1 01:05:39 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Fri, 1 Dec 2006 01:05:39 +0100 Subject: [LinuxBIOS] 440BX progress. In-Reply-To: <20061130223748.GA25948@greenwood> References: <20061126165258.GA14839@greenwood> <6e22bb6c392468a0dd050b2f49ea98c8@kernel.crashing.org> <20061126210307.GA5102@greenwood> <20061130223748.GA25948@greenwood> Message-ID: <7BB313C6-6A90-41F1-9709-8F6B5B98911F@kernel.crashing.org> >> Be careful >> to set the enable bit (bit 7 in 0xe7) last. > > Yep. As the last step in sdram_set_registers() or as the last step > in RAM init in general? The last step of setting the registers e0..ef. >> Also, you probably didn't program the MRS on the memory. > > Yes, I'm quite sure I messed that up. Heh, nothing will work then ;-) > In general, in do_ram_command() I > have to set DRAMC bits 7-5 to the respective command and then read32 > () from > some memory location for the change to "take effect", right? Write to that location, instead. It's not that you make "a change take effect" -- it directly sends a command on the memory bus, instead. > If so, which memory location is that? Does it depend on some input > data? 0x1d0 in the rank, typically. There is some tiny documentation in the intel sheet; the idea is to send the correct pattern on the DRAM address pins (use the selected map to figure out what pattern that is). > I still don't really understand this part of the RAM init, so the code > might be very, very wrong... SDRAM requires an initialisation sequence to work properly. One of the steps of that init sequence is programming the MRS register, so the DRAM knows what CAS latency (CL) is in use, what burst length (BL), etc. >> You should do that with the register at 0x76. The correct >> sequence is: >> >> - precharge all banks, wait tRP >> - refresh, wait tRC (do this step 8 times) >> - write to MRS, wait 2 memory cycles > > I think I got this part right mostly. How about you show the code, much easier to diagnose that way :-) > Attached is my stripped-down raminit.c which does the bare minimum > hardcoding of the values and nothing more. :-) I'll have a look at it later. > It doesn't work, and > after quite a lot of testing I can't seem to find the problem(s). > > Shifting by 15 causes a hang in ram_check() so I tried 23 (looking at > the v1 code). Again, I don't know what I'm doing here ;-) I'm not too sure either, but I'll see what I can find. > Btw, I'm now running ram_check(0x1000, 0x4000000); which should check > all of the 64MB of RAM, right? Well except for the low 4kB, heh ;-) Segher From bari at onelabs.com Fri Dec 1 01:06:17 2006 From: bari at onelabs.com (Bari Ari) Date: Thu, 30 Nov 2006 18:06:17 -0600 Subject: [LinuxBIOS] [Fwd: USB Host to Host Debug Dongle/Cable] Message-ID: <456F71F9.70203@onelabs.com> -------------- next part -------------- An embedded message was scrubbed... From: Bari Ari Subject: [LinuxBIOS] USB Host to Host Debug Dongle/Cable Date: Fri, 21 Jul 2006 15:35:44 -0500 Size: 2933 URL: From c-d.hailfinger.devel.2006 at gmx.net Fri Dec 1 01:08:56 2006 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 01 Dec 2006 01:08:56 +0100 Subject: [LinuxBIOS] LPC SuperIO "add-in card" In-Reply-To: <456F59D8.8070600@gmx.net> References: <57947bf80611300927s31876f3ep79511fa85b0066cd@mail.gmail.com> <456F59D8.8070600@gmx.net> Message-ID: <456F7298.0@gmx.net> Carl-Daniel Hailfinger wrote: > Tom Sylla wrote: >> Another idea, there has been a lot of talk about homebrew LPC ROM >> emulators. It would not be much more work to make the emulator into a >> generic LPC analyzer. You could have it catch regular serial, or you >> could just have print_debug spew bytes to a specified I/O location. >> With careful design, high speed USB can keep up with the ~16MB/s you >> could spew to LPC. This would not end up costing much more than the >> SIO solution, the biggest cost is still the PCB/connectors (male >> PLCC). > > The male PLCC can be bought for ~12 Eur in single quantities. I > posted a link not so long ago, if you want I can dig it out. My mail from "2006-10-25 18:34" contained a link to the vendor, but not to the device. Go to http://www.segor.de/ and enter "PLCC32-Steck" (without the quotes) in the search box on the left. Direct link to the search result: http://cgi.segor.de/user-cgi-bin/sidestep2.pl?foto=1&Q=PLCC32-Steck&M=1 @Stefan: Could you maybe order some and ship them to Tom Sylla so he can start building such a LPC ROM emulator? Regards, Carl-Daniel -- http://www.hailfinger.org/ From bari at onelabs.com Fri Dec 1 01:30:52 2006 From: bari at onelabs.com (Bari Ari) Date: Thu, 30 Nov 2006 18:30:52 -0600 Subject: [LinuxBIOS] USB debug device In-Reply-To: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> Message-ID: <456F77BC.4080107@onelabs.com> Lu, Yinghai wrote: > Where to get USB-to-Serial or USB-to-USB device mentioned in the doc? > > http://www.usb.org/developers/presentations/pres0602/john_keys.pdf > Here's the info on the PLX Hi-Speed USB 2.0 Debug Cable: http://www.plxtech.com/products/NET2000/NET20DC/default.asp Here are some other adapters I've found to debug via I2C or SPI: I2C Bus to USB or serial adapters http://www.mcc-us.com/catalog.htm#I2C%20Bus%20Host%20Adapters I2C/SPI Host Adapter http://www.totalphase.com/products/aardvark/ I2C Bus to USB or serial adapters http://www.telos.info/products/ QBridge-I2C-USB http://www.qprotos.com/index.html This adapter even has Linux tools: USB-I2C/SPI/GPIO Interface Adapter http://www.diolan.com/i2c/u2c12.html with a probe like this that slides into the dimm socket: http://www.busboards.com/products/memory/ddrii/ddrii400dc/ddriidc.jpg http://www.busboards.com/products/memory/ddrii/ddrii400dc/index.html -Bari From ebiederman at lnxi.com Fri Dec 1 01:33:49 2006 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu, 30 Nov 2006 17:33:49 -0700 Subject: [LinuxBIOS] USB debug device In-Reply-To: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> (Yinghai Lu's message of "Thu, 30 Nov 2006 15:55:31 -0800") References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> Message-ID: "Lu, Yinghai" writes: > Where to get USB-to-Serial or USB-to-USB device mentioned in the doc? > > http://www.usb.org/developers/presentations/pres0602/john_keys.pdf It looks like Bari already answered this one but: http://tinyurl.com/nq6kc is the short version :) Eric From ebiederman at lnxi.com Fri Dec 1 01:39:27 2006 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu, 30 Nov 2006 17:39:27 -0700 Subject: [LinuxBIOS] Support for recent chipset and powerful desktop CPU In-Reply-To: <5986589C150B2F49A46483AC44C7BCA4907258@ssvlexmb2.amd.com> (Yinghai Lu's message of "Thu, 30 Nov 2006 10:44:05 -0800") References: <5986589C150B2F49A46483AC44C7BCA4907258@ssvlexmb2.amd.com> Message-ID: "Lu, Yinghai" writes: > -----Original Message----- > From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] > Sent: Thursday, November 30, 2006 12:00 AM > >>Has anyone made in progress sorting out the EHCI USB debug port yet. > I'm about >>1/4 of the way from implementing kernel support. Currently I have just > gotten >>as far as a user space client that can detect debug port support and > send characters >>across. A low level driver you can use early I have yet to implement, > possibly >>in the next couple of days. But if someone has done something I can > compare >>notes with that would be great. > > For Linux kernel earlyprintk or printk? I'm looking at earlyprintk. That looks like the most interesting case. But once something is bootstrapped it should be relatively straight forward to make the other cases work. Eric From yinghai.lu at amd.com Fri Dec 1 01:53:39 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Thu, 30 Nov 2006 16:53:39 -0800 Subject: [LinuxBIOS] Support for recent chipset and powerful desktop CPU Message-ID: <5986589C150B2F49A46483AC44C7BCA490726A@ssvlexmb2.amd.com> -----Original Message----- From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] >I'm looking at earlyprintk. That looks like the most interesting case. But >once something is bootstrapped it should be relatively straight forward >to make the other cases work. Me too. Simnow console is there! With USB serial console enabled in kernel and console=ttyUSB0, only can get boot message very late. From tsylla at gmail.com Fri Dec 1 02:05:31 2006 From: tsylla at gmail.com (Tom Sylla) Date: Thu, 30 Nov 2006 20:05:31 -0500 Subject: [LinuxBIOS] USB debug device In-Reply-To: <456F77BC.4080107@onelabs.com> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> Message-ID: <456F7FDB.5090802@gmail.com> Bari Ari wrote: > I2C Bus to USB or serial adapters > http://www.mcc-us.com/catalog.htm#I2C%20Bus%20Host%20Adapters > > I2C/SPI Host Adapter > http://www.totalphase.com/products/aardvark/ > > I2C Bus to USB or serial adapters > http://www.telos.info/products/ > > QBridge-I2C-USB > http://www.qprotos.com/index.html > > This adapter even has Linux tools: > USB-I2C/SPI/GPIO Interface Adapter > http://www.diolan.com/i2c/u2c12.html Those are a lot of interesting links. They are all pretty expensive, though. A bargain basement option would be an AVR butterfly. The Atmel micros have UART/SPI/I2C built in, and the butterfly is 20USD. You could even probably achieve USB with this, there is software bitbang (!) USB available for AVR. http://www.dwelch.com/avr/ http://www.obdev.at/products/avrusb/projects.html http://www.harbaum.org/till/i2c_tiny_usb/ > with a probe like this that slides into the dimm socket: > http://www.busboards.com/products/memory/ddrii/ddrii400dc/ddriidc.jpg > http://www.busboards.com/products/memory/ddrii/ddrii400dc/index.html That one is a little bit out there. That board is probably $10K, and you need a $100K Tek Logic Analyzer to use it. :) From bari at onelabs.com Fri Dec 1 02:18:56 2006 From: bari at onelabs.com (Bari Ari) Date: Thu, 30 Nov 2006 19:18:56 -0600 Subject: [LinuxBIOS] More USB Host to Host Adapters Message-ID: <456F8300.4050802@onelabs.com> USB 2.0 Host-to-Host Cable http://www.pccasegear.com/prod3972.htm The USB 2.0 LINK & NETWORK CABLE http://www.linkusb.com/ USB 2.0 Host-to-Host Cable http://www.datapro.net/products/UL2.html PCLinq2 (PL-2501) Hi-Speed USB Bridge Cable http://www.usbfiletransfer.com/ -Bari From yinghai.lu at amd.com Fri Dec 1 02:24:12 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Thu, 30 Nov 2006 17:24:12 -0800 Subject: [LinuxBIOS] More USB Host to Host Adapters Message-ID: <5986589C150B2F49A46483AC44C7BCA490726C@ssvlexmb2.amd.com> There should not work as USB debug device. I guess. YH -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Bari Ari Sent: Thursday, November 30, 2006 5:19 PM To: LinuxBIOS Subject: [LinuxBIOS] More USB Host to Host Adapters USB 2.0 Host-to-Host Cable http://www.pccasegear.com/prod3972.htm The USB 2.0 LINK & NETWORK CABLE http://www.linkusb.com/ USB 2.0 Host-to-Host Cable http://www.datapro.net/products/UL2.html PCLinq2 (PL-2501) Hi-Speed USB Bridge Cable http://www.usbfiletransfer.com/ -Bari -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios From bari at onelabs.com Fri Dec 1 02:44:47 2006 From: bari at onelabs.com (Bari Ari) Date: Thu, 30 Nov 2006 19:44:47 -0600 Subject: [LinuxBIOS] USB debug device In-Reply-To: <456F7FDB.5090802@gmail.com> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> Message-ID: <456F890F.9090503@onelabs.com> Tom Sylla wrote: > >> with a probe like this that slides into the dimm socket: >> http://www.busboards.com/products/memory/ddrii/ddrii400dc/ddriidc.jpg >> http://www.busboards.com/products/memory/ddrii/ddrii400dc/index.html > > That one is a little bit out there. That board is probably $10K, and > you need a $100K Tek Logic Analyzer to use it. :) > It's just a passive DIMM module with cables for each signal connection at the socket. I'm sure it's priced relatively high since it comes with coaxial cables for 8GHz timing analysis and was probably assembled by highly skilled elves. Someone could fab these however as a 2 sided pcb with only the SMBus signals for next to nothing in cost. -Bari From bari at onelabs.com Fri Dec 1 02:56:27 2006 From: bari at onelabs.com (Bari Ari) Date: Thu, 30 Nov 2006 19:56:27 -0600 Subject: [LinuxBIOS] More USB Host to Host Adapters In-Reply-To: <5986589C150B2F49A46483AC44C7BCA490726C@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA490726C@ssvlexmb2.amd.com> Message-ID: <456F8BCB.8020003@onelabs.com> Lu, Yinghai wrote: > There should not work as USB debug device. I guess. > > Lack of Linux support seems to be the problem. I've pulled a couple apart and they use the PLX or Maxim USB controllers with a small micro to pass the data back and forth. -Bari From drew.lundsten at ccpu.com Fri Dec 1 04:29:18 2006 From: drew.lundsten at ccpu.com (Drew Lundsten) Date: Thu, 30 Nov 2006 19:29:18 -0800 Subject: [LinuxBIOS] I2C/SPI UART Message-ID: http://www.nxp.com/pip/SC16IS752IBS.html should make various people happy. Now, if it just had the transceiver and crystal onboard... Drew From pdegler at rumms.uni-mannheim.de Fri Dec 1 09:24:11 2006 From: pdegler at rumms.uni-mannheim.de (Philipp Degler) Date: Fri, 1 Dec 2006 09:24:11 +0100 Subject: [LinuxBIOS] [PATCH] Add includes to it8712f/superio.c In-Reply-To: <20061129142219.GA6430@countzero.vandewege.net> References: <200611291351.27601.pdegler@rumms.uni-mannheim.de> <20061129142219.GA6430@countzero.vandewege.net> Message-ID: <200612010924.15958.pdegler@rumms.uni-mannheim.de> Hi sorry for confusion I've tested flashing again - this time with original BIOS chip (SST49LF004A/B) and I was able to write without problems. Phil >On Wednesday 29 November 2006 15:22, Ward Vandewege wrote: > Hi Philipp, > > Out of curiosity, have you managed in-board flashing with flashrom? > > We have a couple of A8N-VM CSM boards, and while reading data with flashrom > works, writing doesn't yet. > > Thanks, > Ward. > > On Wed, Nov 29, 2006 at 01:51:27PM +0100, Philipp Degler wrote: > > Hi, > > > > we've tested the it8712f code, too. We see serial output on our ASUS > > a8ne. It is equiped with a ck804 SB and 1GB of RAM and a Athlon64 CPU. From svn at openbios.org Fri Dec 1 10:41:12 2006 From: svn at openbios.org (svn at openbios.org) Date: Fri, 01 Dec 2006 09:41:12 -0000 Subject: [LinuxBIOS] r2512 - in trunk/LinuxBIOSv2/src/superio/ite: it8661f it8671f it8673f it8705f it8712f it8716f it8718f Message-ID: Author: uwe Date: 2006-12-01 10:41:11 +0100 (Fri, 01 Dec 2006) New Revision: 2512 Modified: trunk/LinuxBIOSv2/src/superio/ite/it8661f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8661f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8671f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8671f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8673f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8673f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8705f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8705f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8712f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8712f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8716f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8716f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8718f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8718f/superio.c Log: Add missing #includes to some ITE Super I/O files. Signed-off-by: Jon Dufresne Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Modified: trunk/LinuxBIOSv2/src/superio/ite/it8661f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8661f/chip.h 2006-11-30 21:26:45 UTC (rev 2511) +++ trunk/LinuxBIOSv2/src/superio/ite/it8661f/chip.h 2006-12-01 09:41:11 UTC (rev 2512) @@ -23,6 +23,7 @@ /* This chip doesn't seem to have keyboard and mouse support. */ +#include #include extern struct chip_operations superio_ite_it8661f_ops; Modified: trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f_early_serial.c 2006-11-30 21:26:45 UTC (rev 2511) +++ trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f_early_serial.c 2006-12-01 09:41:11 UTC (rev 2512) @@ -19,6 +19,7 @@ */ #include +#include #include "it8661f.h" /* The base address is 0x3f0, 0x3bd, or 0x370, depending on config bytes. */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8661f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8661f/superio.c 2006-11-30 21:26:45 UTC (rev 2511) +++ trunk/LinuxBIOSv2/src/superio/ite/it8661f/superio.c 2006-12-01 09:41:11 UTC (rev 2512) @@ -20,8 +20,9 @@ /* This chip doesn't seem to have keyboard and mouse support. */ +#include +#include #include -/* #include */ #include "chip.h" #include "it8661f.h" Modified: trunk/LinuxBIOSv2/src/superio/ite/it8671f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8671f/chip.h 2006-11-30 21:26:45 UTC (rev 2511) +++ trunk/LinuxBIOSv2/src/superio/ite/it8671f/chip.h 2006-12-01 09:41:11 UTC (rev 2512) @@ -21,6 +21,7 @@ #ifndef _SUPERIO_ITE_IT8671F #define _SUPERIO_ITE_IT8671F +#include #include #include Modified: trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f_early_serial.c 2006-11-30 21:26:45 UTC (rev 2511) +++ trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f_early_serial.c 2006-12-01 09:41:11 UTC (rev 2512) @@ -19,6 +19,7 @@ */ #include +#include #include "it8671f.h" /* The base address is 0x3f0, 0x3bd, or 0x370, depending on config bytes. */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8671f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8671f/superio.c 2006-11-30 21:26:45 UTC (rev 2511) +++ trunk/LinuxBIOSv2/src/superio/ite/it8671f/superio.c 2006-12-01 09:41:11 UTC (rev 2512) @@ -18,6 +18,8 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ +#include +#include #include #include #include "chip.h" Modified: trunk/LinuxBIOSv2/src/superio/ite/it8673f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8673f/chip.h 2006-11-30 21:26:45 UTC (rev 2511) +++ trunk/LinuxBIOSv2/src/superio/ite/it8673f/chip.h 2006-12-01 09:41:11 UTC (rev 2512) @@ -21,6 +21,7 @@ #ifndef _SUPERIO_ITE_IT8673F #define _SUPERIO_ITE_IT8673F +#include #include #include Modified: trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f_early_serial.c 2006-11-30 21:26:45 UTC (rev 2511) +++ trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f_early_serial.c 2006-12-01 09:41:11 UTC (rev 2512) @@ -19,6 +19,7 @@ */ #include +#include #include "it8673f.h" /* The base address is 0x3f0, 0x3bd, or 0x370, depending on config bytes. */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8673f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8673f/superio.c 2006-11-30 21:26:45 UTC (rev 2511) +++ trunk/LinuxBIOSv2/src/superio/ite/it8673f/superio.c 2006-12-01 09:41:11 UTC (rev 2512) @@ -18,6 +18,8 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ +#include +#include #include #include #include "chip.h" Modified: trunk/LinuxBIOSv2/src/superio/ite/it8705f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8705f/chip.h 2006-11-30 21:26:45 UTC (rev 2511) +++ trunk/LinuxBIOSv2/src/superio/ite/it8705f/chip.h 2006-12-01 09:41:11 UTC (rev 2512) @@ -23,6 +23,7 @@ /* This chip doesn't seem to have keyboard and mouse support. */ +#include #include extern struct chip_operations superio_ite_it8705f_ops; Modified: trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c 2006-11-30 21:26:45 UTC (rev 2511) +++ trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c 2006-12-01 09:41:11 UTC (rev 2512) @@ -19,6 +19,7 @@ */ #include +#include #include "it8705f.h" /* The base address is 0x2e or 0x4e, depending on config bytes. */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8705f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8705f/superio.c 2006-11-30 21:26:45 UTC (rev 2511) +++ trunk/LinuxBIOSv2/src/superio/ite/it8705f/superio.c 2006-12-01 09:41:11 UTC (rev 2512) @@ -20,6 +20,8 @@ /* This chip doesn't seem to have keyboard and mouse support. */ +#include +#include #include #include "chip.h" #include "it8705f.h" Modified: trunk/LinuxBIOSv2/src/superio/ite/it8712f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8712f/chip.h 2006-11-30 21:26:45 UTC (rev 2511) +++ trunk/LinuxBIOSv2/src/superio/ite/it8712f/chip.h 2006-12-01 09:41:11 UTC (rev 2512) @@ -21,6 +21,7 @@ #ifndef _SUPERIO_ITE_IT8712F #define _SUPERIO_ITE_IT8712F +#include #include #include Modified: trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c 2006-11-30 21:26:45 UTC (rev 2511) +++ trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c 2006-12-01 09:41:11 UTC (rev 2512) @@ -19,6 +19,7 @@ */ #include +#include #include "it8712f.h" /* The base address is 0x2e or 0x4e, depending on config bytes. */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8712f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8712f/superio.c 2006-11-30 21:26:45 UTC (rev 2511) +++ trunk/LinuxBIOSv2/src/superio/ite/it8712f/superio.c 2006-12-01 09:41:11 UTC (rev 2512) @@ -18,6 +18,8 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ +#include +#include #include #include #include "chip.h" Modified: trunk/LinuxBIOSv2/src/superio/ite/it8716f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8716f/chip.h 2006-11-30 21:26:45 UTC (rev 2511) +++ trunk/LinuxBIOSv2/src/superio/ite/it8716f/chip.h 2006-12-01 09:41:11 UTC (rev 2512) @@ -21,6 +21,7 @@ #ifndef _SUPERIO_ITE_IT8716F #define _SUPERIO_ITE_IT8716F +#include #include #include Modified: trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c 2006-11-30 21:26:45 UTC (rev 2511) +++ trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c 2006-12-01 09:41:11 UTC (rev 2512) @@ -19,6 +19,7 @@ */ #include +#include #include "it8716f.h" /* The base address is 0x2e or 0x4e, depending on config bytes. */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8716f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8716f/superio.c 2006-11-30 21:26:45 UTC (rev 2511) +++ trunk/LinuxBIOSv2/src/superio/ite/it8716f/superio.c 2006-12-01 09:41:11 UTC (rev 2512) @@ -18,6 +18,8 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ +#include +#include #include #include #include "chip.h" Modified: trunk/LinuxBIOSv2/src/superio/ite/it8718f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8718f/chip.h 2006-11-30 21:26:45 UTC (rev 2511) +++ trunk/LinuxBIOSv2/src/superio/ite/it8718f/chip.h 2006-12-01 09:41:11 UTC (rev 2512) @@ -21,6 +21,7 @@ #ifndef _SUPERIO_ITE_IT8718F #define _SUPERIO_ITE_IT8718F +#include #include #include Modified: trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f_early_serial.c 2006-11-30 21:26:45 UTC (rev 2511) +++ trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f_early_serial.c 2006-12-01 09:41:11 UTC (rev 2512) @@ -19,6 +19,7 @@ */ #include +#include #include "it8718f.h" /* The base address is 0x2e or 0x4e, depending on config bytes. */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8718f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8718f/superio.c 2006-11-30 21:26:45 UTC (rev 2511) +++ trunk/LinuxBIOSv2/src/superio/ite/it8718f/superio.c 2006-12-01 09:41:11 UTC (rev 2512) @@ -18,6 +18,8 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ +#include +#include #include #include #include "chip.h" From stepan at coresystems.de Fri Dec 1 11:14:44 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 1 Dec 2006 11:14:44 +0100 Subject: [LinuxBIOS] More USB Host to Host Adapters In-Reply-To: <456F8BCB.8020003@onelabs.com> References: <5986589C150B2F49A46483AC44C7BCA490726C@ssvlexmb2.amd.com> <456F8BCB.8020003@onelabs.com> Message-ID: <20061201101444.GB13380@coresystems.de> * Bari Ari [061201 02:56]: > Lu, Yinghai wrote: > > There should not work as USB debug device. I guess. > > > > > Lack of Linux support seems to be the problem. > > I've pulled a couple apart and they use the PLX or Maxim USB controllers > with a small micro to pass the data back and forth. the usb host to host adapter also needs to explixitly support the USB debug interface. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From stuge-linuxbios at cdy.org Fri Dec 1 11:36:14 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 1 Dec 2006 11:36:14 +0100 Subject: [LinuxBIOS] More USB Host to Host Adapters In-Reply-To: <20061201101444.GB13380@coresystems.de> References: <5986589C150B2F49A46483AC44C7BCA490726C@ssvlexmb2.amd.com> <456F8BCB.8020003@onelabs.com> <20061201101444.GB13380@coresystems.de> Message-ID: <20061201103614.6338.qmail@cdy.org> On Fri, Dec 01, 2006 at 11:14:44AM +0100, Stefan Reinauer wrote: > * Bari Ari [061201 02:56]: > > Lu, Yinghai wrote: > > > There should not work as USB debug device. I guess. > > > > Lack of Linux support seems to be the problem. > > > > I've pulled a couple apart and they use the PLX or Maxim USB > > controllers with a small micro to pass the data back and forth. True, but they also enumerate as completely different types of devices. > the usb host to host adapter also needs to explixitly support the > USB debug interface. Yes, specifically the device must comply to the Debug Class Device Specification. This is what I learned by taking apart the PLX debug device at the symposium: Two NET2270 chips, controlled by a UBICOM micro. I would assume the micro does only basic setup and then the 2270s just talk to each other. The device has two quite different USB interfaces. One is for the host system, the other is for the target (AKA remote in debug class terminology). The target interface does not work as a normal USB interface, it will not enumerate if plugged in to a USB controller in normal mode. The host interface works as a normal USB interface, with one IN and one OUT endpoint. (Bulk IIRC, but see debug device class spec.) The target end of the device will only work when connected to a USB controller that is in debug mode. No other devices than debug class devices work when the USB controller is in debug mode. I sent a probably-working program to the list a while back that uses libusb to access the host end of the device. It only handles reads from the target. I'll add it to trac. Stefan, you're in a unique position to test my code and Eric's code for driving the target end of the device, along with your device. :) Please report any progress. //Peter From stuge-linuxbios at cdy.org Fri Dec 1 11:41:07 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 1 Dec 2006 11:41:07 +0100 Subject: [LinuxBIOS] Support for recent chipset and powerful desktop CPU In-Reply-To: <5986589C150B2F49A46483AC44C7BCA4907263@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA4907263@ssvlexmb2.amd.com> Message-ID: <20061201104107.7031.qmail@cdy.org> On Thu, Nov 30, 2006 at 02:44:59PM -0800, Lu, Yinghai wrote: > I'm trying to get one. This is the one Stefan has, that I took apart in Hamburg: http://www.plxtech.com/products/NET2000/NET20DC/default.asp They call it a cable, which is silly, but it does the right thing. //Peter From stuge-linuxbios at cdy.org Fri Dec 1 11:43:11 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 1 Dec 2006 11:43:11 +0100 Subject: [LinuxBIOS] Support for recent chipset and powerful desktop CPU In-Reply-To: <5986589C150B2F49A46483AC44C7BCA490726A@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA490726A@ssvlexmb2.amd.com> Message-ID: <20061201104311.7337.qmail@cdy.org> On Thu, Nov 30, 2006 at 04:53:39PM -0800, Lu, Yinghai wrote: > With USB serial console enabled in kernel and console=ttyUSB0, only > can get boot message very late. > From usbcore: registered new interface driver ftdi_sio. Before that > only some lines in buffer. Yeah. The debug device is only useful when the full USB stack isn't up yet. It doesn't enumerate like other USB devices and can only handle small transfers, but the EHCI doesn't need RAM to drive it. I hope Stefan can do some tests with Eric's code. //Peter From indrek.kruusa at artecdesign.ee Fri Dec 1 12:26:31 2006 From: indrek.kruusa at artecdesign.ee (Indrek Kruusa) Date: Fri, 01 Dec 2006 13:26:31 +0200 Subject: [LinuxBIOS] LPC SuperIO "add-in card" In-Reply-To: <57947bf80611300927s31876f3ep79511fa85b0066cd@mail.gmail.com> References: <57947bf80611300927s31876f3ep79511fa85b0066cd@mail.gmail.com> Message-ID: <45701167.9@artecdesign.ee> Tom Sylla wrote: > Another idea, there has been a lot of talk about homebrew LPC ROM > emulators. It would not be much more work to make the emulator into a > generic LPC analyzer. You could have it catch regular serial, or you > could just have print_debug spew bytes to a specified I/O location. > With careful design, high speed USB can keep up with the ~16MB/s you > could spew to LPC. This would not end up costing much more than the > SIO solution, the biggest cost is still the PCB/connectors (male > PLCC). > > > For current Thincan (artecgroup/dbe61) development we are using our own designed dongles: - LPC connector (the cable shouldn't be longer than 5cm/2 inch) - Altera Cyclone FPGA as the control part - 16 MB flash: 4x separate 4MB banks; chosen by jumpers (I can have 4 separate booting configs( LB/kernel/initrd) in one dongle) - chosen flash bank is seen as 1MB at boot, switched to 4MB mode by LinuxBIOS. After that you can address that 4MB by FILO as mem at 0x.... - 4 digit LED display (POST code display + selftest) - miniUSB (by ftdi chip) for the programming flash banks - python script as programming tool PCB is 8cm x 6cm, i have seen the case for that unit too :) As much as I know this dongle were made available with initial price ca. ?90 (in small quantities). I'd expect that such a thing (with somewhat different design) can't be much cheaper. Indrek From stuge-linuxbios at cdy.org Fri Dec 1 12:30:25 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 1 Dec 2006 12:30:25 +0100 Subject: [LinuxBIOS] SPD as debug channel In-Reply-To: <456F890F.9090503@onelabs.com> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> Message-ID: <20061201113025.13793.qmail@cdy.org> On Thu, Nov 30, 2006 at 07:44:47PM -0600, Bari Ari wrote: > Someone could fab these however as a 2 sided pcb with only the > SMBus signals for next to nothing in cost. I looked into this yesterday. The place I normally order prototype boards from (Olimex) don't stock any 1.2mm laminate. The place I order production boards from (local fab) do have 1.2mm laminate but the minimum order they do is one full panel (about .5m2) - that means a big bag of boards. :) If there's interest I'll be happy to make a DDR2 board that does high speed SPD<->USB. I estimate they would go at $150 assembled or a bit cheaper as kits. (All SMD though.) I need about 20 orders before starting it up, then roughly two months until they're shipping. This is pretty special-purpose though. Perhaps time would be better spent on the LPC thingy, since they can be used for testing too. //Peter From stuge-linuxbios at cdy.org Fri Dec 1 12:47:08 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 1 Dec 2006 12:47:08 +0100 Subject: [LinuxBIOS] LPC SuperIO "add-in card" In-Reply-To: <45701167.9@artecdesign.ee> References: <57947bf80611300927s31876f3ep79511fa85b0066cd@mail.gmail.com> <45701167.9@artecdesign.ee> Message-ID: <20061201114708.16209.qmail@cdy.org> On Fri, Dec 01, 2006 at 01:26:31PM +0200, Indrek Kruusa wrote: > For current Thincan (artecgroup/dbe61) development we are using our > own designed dongles: http://208.109.65.208/products/hardware-products/programmable-lpc-dongle.html Very nice! > - LPC connector (the cable shouldn't be longer than 5cm/2 inch) > - Altera Cyclone FPGA as the control part > - 16 MB flash: 4x separate 4MB banks; chosen by jumpers (I can have 4 > separate booting configs( LB/kernel/initrd) in one dongle) > - chosen flash bank is seen as 1MB at boot, switched to 4MB mode by > LinuxBIOS. After that you can address that 4MB by FILO as mem at 0x.... > - 4 digit LED display (POST code display + selftest) > - miniUSB (by ftdi chip) for the programming flash banks > - python script as programming tool That's a serial emulation, right? How long does it take to program one bank? > PCB is 8cm x 6cm, i have seen the case for that unit too :) > > As much as I know this dongle were made available with initial price > ca. ?90 (in small quantities). I'd expect that such a thing (with > somewhat different design) can't be much cheaper. Is that EUR90 or USD90? Either way I agree - it's a good price! I want one. :) Do you also have a PLCC adapter? I looked into the product sold by Segor (that Carl-Daniel linked to) and found that it's made by cab GmbH: http://www.cabgmbh.com/englisch/index.cfm?fuseaction=elektronik&rubrik=Special%20sockets&produkte=159 //Peter From stepan at coresystems.de Fri Dec 1 12:48:24 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 1 Dec 2006 12:48:24 +0100 Subject: [LinuxBIOS] More USB Host to Host Adapters In-Reply-To: <20061201103614.6338.qmail@cdy.org> References: <5986589C150B2F49A46483AC44C7BCA490726C@ssvlexmb2.amd.com> <456F8BCB.8020003@onelabs.com> <20061201101444.GB13380@coresystems.de> <20061201103614.6338.qmail@cdy.org> Message-ID: <20061201114824.GA2583@coresystems.de> * Peter Stuge [061201 11:36]: > I sent a probably-working program to the list a while back that uses > libusb to access the host end of the device. It only handles reads > from the target. I'll add it to trac. > > Stefan, you're in a unique position to test my code and Eric's code > for driving the target end of the device, along with your device. :) > Please report any progress. Eric, where can I find your code? -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From stuge-linuxbios at cdy.org Fri Dec 1 12:50:27 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 1 Dec 2006 12:50:27 +0100 Subject: [LinuxBIOS] LPC SuperIO "add-in card" In-Reply-To: <45701167.9@artecdesign.ee> References: <57947bf80611300927s31876f3ep79511fa85b0066cd@mail.gmail.com> <45701167.9@artecdesign.ee> Message-ID: <20061201115027.16643.qmail@cdy.org> On Fri, Dec 01, 2006 at 01:26:31PM +0200, Indrek Kruusa wrote: > - chosen flash bank is seen as 1MB at boot, switched to 4MB mode by > LinuxBIOS. Can you explain how this works in more detail? Do you know if chipsets usually support >1MB? //Peter From svn at openbios.org Fri Dec 1 12:56:01 2006 From: svn at openbios.org (LinuxBIOS) Date: Fri, 01 Dec 2006 11:56:01 -0000 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device Message-ID: <060.73e8d45aad9d6cde977837a59b8449f5@openbios.org> #57: libusb host program for PLX NET20DC debug device ---------------------------------+------------------------------------------ Reporter: stuge | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: code | Version: Keywords: usb ehci debug | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ -- Ticket URL: LinuxBIOS From svn at openbios.org Fri Dec 1 12:59:00 2006 From: svn at openbios.org (LinuxBIOS) Date: Fri, 01 Dec 2006 11:59:00 -0000 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: <060.73e8d45aad9d6cde977837a59b8449f5@openbios.org> References: <060.73e8d45aad9d6cde977837a59b8449f5@openbios.org> Message-ID: <069.71f20a950966da8ae2f4c2363ead48a9@openbios.org> #57: libusb host program for PLX NET20DC debug device ----------------------------+----------------------------------------------- Reporter: stuge | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: code | Version: Resolution: | Keywords: usb ehci debug Dependencies: | Patchstatus: there is no patch ----------------------------+----------------------------------------------- Comment (by stuge): #can't attach the Makefile so here it is: LDFLAGS=-lusb TARGET=usb_debug_io SRC=$(TARGET).c $(TARGET): $(SRC) gcc -Wall -g -o $@ $(SRC) $(LDFLAGS) clean: rm -f $(TARGET) -- Ticket URL: LinuxBIOS From stuge-linuxbios at cdy.org Fri Dec 1 13:29:39 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 1 Dec 2006 13:29:39 +0100 Subject: [LinuxBIOS] LPC SuperIO "add-in card" In-Reply-To: <45701167.9@artecdesign.ee> References: <57947bf80611300927s31876f3ep79511fa85b0066cd@mail.gmail.com> <45701167.9@artecdesign.ee> Message-ID: <20061201122939.22128.qmail@cdy.org> On Fri, Dec 01, 2006 at 01:26:31PM +0200, Indrek Kruusa wrote: > - Altera Cyclone FPGA as the control part Do you think it would be possible to make a firmware for the FPGA that also does reads-make-a-write and can signal them back to the Linux host? The idea is similar to the JEDEC flash identifying method - a special sequence of reads at certain addresses are interpreted as a write and sent to the host. //Peter From ward at gnu.org Fri Dec 1 13:32:41 2006 From: ward at gnu.org (Ward Vandewege) Date: Fri, 1 Dec 2006 07:32:41 -0500 Subject: [LinuxBIOS] [PATCH] Add includes to it8712f/superio.c In-Reply-To: <200612010924.15958.pdegler@rumms.uni-mannheim.de> References: <200611291351.27601.pdegler@rumms.uni-mannheim.de> <20061129142219.GA6430@countzero.vandewege.net> <200612010924.15958.pdegler@rumms.uni-mannheim.de> Message-ID: <20061201123241.GA7185@countzero.vandewege.net> On Fri, Dec 01, 2006 at 09:24:11AM +0100, Philipp Degler wrote: > sorry for confusion I've tested flashing again - this time with original BIOS > chip (SST49LF004A/B) and I was able to write without problems. Great. Is your gpio-unlock code in the tree yet? Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From stuge-linuxbios at cdy.org Fri Dec 1 13:56:48 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 1 Dec 2006 13:56:48 +0100 Subject: [LinuxBIOS] [Fwd: USB Host to Host Debug Dongle/Cable] In-Reply-To: <456F71F9.70203@onelabs.com> References: <456F71F9.70203@onelabs.com> Message-ID: <20061201125648.25937.qmail@cdy.org> On Thu, Nov 30, 2006 at 06:06:17PM -0600, Bari Ari wrote: > SemiconductorStore.com has several of the the USB debug cables > currently in stock for $80: I just ordered one, but their terms say all international orders must be $250 or more. We'll see what happens. //Peter From indrek.kruusa at artecdesign.ee Fri Dec 1 14:02:26 2006 From: indrek.kruusa at artecdesign.ee (Indrek Kruusa) Date: Fri, 01 Dec 2006 15:02:26 +0200 Subject: [LinuxBIOS] LPC SuperIO "add-in card" In-Reply-To: <20061201114708.16209.qmail@cdy.org> References: <57947bf80611300927s31876f3ep79511fa85b0066cd@mail.gmail.com> <45701167.9@artecdesign.ee> <20061201114708.16209.qmail@cdy.org> Message-ID: <457027E2.9000405@artecdesign.ee> Peter Stuge wrote: > On Fri, Dec 01, 2006 at 01:26:31PM +0200, Indrek Kruusa wrote: > >> For current Thincan (artecgroup/dbe61) development we are using our >> own designed dongles: >> > > http://208.109.65.208/products/hardware-products/programmable-lpc-dongle.html > > Very nice! > Hm, there is even a web page. Nice to know :) > > >> - LPC connector (the cable shouldn't be longer than 5cm/2 inch) >> - Altera Cyclone FPGA as the control part >> - 16 MB flash: 4x separate 4MB banks; chosen by jumpers (I can have 4 >> separate booting configs( LB/kernel/initrd) in one dongle) >> - chosen flash bank is seen as 1MB at boot, switched to 4MB mode by >> LinuxBIOS. After that you can address that 4MB by FILO as mem at 0x.... >> - 4 digit LED display (POST code display + selftest) >> - miniUSB (by ftdi chip) for the programming flash banks >> - python script as programming tool >> > > That's a serial emulation, right? How long does it take to program > one bank? > > > Yes, it is emulation. It takes ca. 20 s to flash the 256K LinuxBIOS. Flashing a bigger binary takes proportionally more time. Usually I change one thing at a time (e.g. only kernel) so the need to flash the whole 4MB is quite rare. >> PCB is 8cm x 6cm, i have seen the case for that unit too :) >> >> As much as I know this dongle were made available with initial price >> ca. ?90 (in small quantities). I'd expect that such a thing (with >> somewhat different design) can't be much cheaper. >> > > Is that EUR90 or USD90? Either way I agree - it's a good price! > EUR90. > I want one. :) > You are welcome! :) Guys from info at artecgroup.com can give you more information about that. > Do you also have a PLCC adapter? Nope. thanks, Indrek > I looked into the product sold by > Segor (that Carl-Daniel linked to) and found that it's made by cab > GmbH: > > http://www.cabgmbh.com/englisch/index.cfm?fuseaction=elektronik&rubrik=Special%20sockets&produkte=159 > > > //Peter > > From indrek.kruusa at artecdesign.ee Fri Dec 1 14:13:02 2006 From: indrek.kruusa at artecdesign.ee (Indrek Kruusa) Date: Fri, 01 Dec 2006 15:13:02 +0200 Subject: [LinuxBIOS] LPC SuperIO "add-in card" In-Reply-To: <20061201115027.16643.qmail@cdy.org> References: <57947bf80611300927s31876f3ep79511fa85b0066cd@mail.gmail.com> <45701167.9@artecdesign.ee> <20061201115027.16643.qmail@cdy.org> Message-ID: <45702A5E.3080208@artecdesign.ee> Peter Stuge wrote: > On Fri, Dec 01, 2006 at 01:26:31PM +0200, Indrek Kruusa wrote: > >> - chosen flash bank is seen as 1MB at boot, switched to 4MB mode by >> LinuxBIOS. >> > > Can you explain how this works in more detail? Do you know if > chipsets usually support >1MB? > I can't help here, sorry. Indrek From svn at openbios.org Fri Dec 1 14:14:56 2006 From: svn at openbios.org (svn at openbios.org) Date: Fri, 01 Dec 2006 13:14:56 -0000 Subject: [LinuxBIOS] r2513 - in trunk/LinuxBIOSv2/src/superio/ite: it8673f it8705f it8712f it8716f it8718f Message-ID: Author: uwe Date: 2006-12-01 14:14:55 +0100 (Fri, 01 Dec 2006) New Revision: 2513 Modified: trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f_early_serial.c Log: Explicitly set the CLKIN to 24 MHz on all ITE Super I/Os, otherwise serial output might not always work correctly (trivial). Thanks Philipp Degler for testing and reporting this issue. Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Modified: trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f_early_serial.c 2006-12-01 09:41:11 UTC (rev 2512) +++ trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f_early_serial.c 2006-12-01 13:14:55 UTC (rev 2513) @@ -86,7 +86,7 @@ it8673f_sio_write(IT8673F_KBCK, 0x30, 0x1); /* Keyboard */ it8673f_sio_write(IT8673F_KBCM, 0x30, 0x1); /* Mouse */ - /* Select 24MHz CLKIN (clear bit 0). TODO: is this really needed? */ + /* Select 24MHz CLKIN (clear bit 0). */ it8673f_sio_write(0x00, IT8673F_CONFIG_REG_CLOCKSEL, 0x00); /* Clear software suspend mode (clear bit 0). */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c 2006-12-01 09:41:11 UTC (rev 2512) +++ trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c 2006-12-01 13:14:55 UTC (rev 2513) @@ -78,8 +78,8 @@ it8705f_sio_write(IT8705F_IR, 0x30, 0x1); /* Consumer IR */ it8705f_sio_write(IT8705F_MIDI, 0x30, 0x1); /* MIDI port */ - /* Select 24MHz/48MHz CLKIN (set/clear bit 0). TODO: Needed? */ - /* it8705f_sio_write(0x00, IT8705F_CONFIG_REG_CLOCKSEL, 0x01); */ + /* Select 24MHz CLKIN (set bit 0). */ + it8705f_sio_write(0x00, IT8705F_CONFIG_REG_CLOCKSEL, 0x01); /* Clear software suspend mode (clear bit 0). TODO: Needed? */ /* it8705f_sio_write(0x00, IT8705F_CONFIG_REG_SWSUSP, 0x00); */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c 2006-12-01 09:41:11 UTC (rev 2512) +++ trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c 2006-12-01 13:14:55 UTC (rev 2513) @@ -78,8 +78,8 @@ it8712f_sio_write(IT8712F_GAME, 0x30, 0x1); /* GAME port */ it8712f_sio_write(IT8712F_IR, 0x30, 0x1); /* Consumer IR */ - /* Select 24MHz/48MHz CLKIN (set/clear bit 0). TODO: Needed? */ - /* it8712f_sio_write(0x00, IT8712F_CONFIG_REG_CLOCKSEL, 0x01); */ + /* Select 24MHz CLKIN (set bit 0). */ + it8712f_sio_write(0x00, IT8712F_CONFIG_REG_CLOCKSEL, 0x01); /* Clear software suspend mode (clear bit 0). TODO: Needed? */ /* it8712f_sio_write(0x00, IT8712F_CONFIG_REG_SWSUSP, 0x00); */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c 2006-12-01 09:41:11 UTC (rev 2512) +++ trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c 2006-12-01 13:14:55 UTC (rev 2513) @@ -78,8 +78,8 @@ it8716f_sio_write(IT8716F_GAME, 0x30, 0x1); /* GAME port */ it8716f_sio_write(IT8716F_IR, 0x30, 0x1); /* Consumer IR */ - /* Select 24MHz/48MHz CLKIN (set/clear bit 0). TODO: Needed? */ - /* it8716f_sio_write(0x00, IT8716F_CONFIG_REG_CLOCKSEL, 0x01); */ + /* Select 24MHz CLKIN (set bit 0). */ + it8716f_sio_write(0x00, IT8716F_CONFIG_REG_CLOCKSEL, 0x01); /* Clear software suspend mode (clear bit 0). TODO: Needed? */ /* it8716f_sio_write(0x00, IT8716F_CONFIG_REG_SWSUSP, 0x00); */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f_early_serial.c 2006-12-01 09:41:11 UTC (rev 2512) +++ trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f_early_serial.c 2006-12-01 13:14:55 UTC (rev 2513) @@ -76,8 +76,8 @@ it8718f_sio_write(IT8718F_KBCM, 0x30, 0x1); /* Mouse */ it8718f_sio_write(IT8718F_IR, 0x30, 0x1); /* Consumer IR */ - /* Select 24MHz/48MHz CLKIN (set/clear bit 0). TODO: Needed? */ - /* it8718f_sio_write(0x00, IT8718F_CONFIG_REG_CLOCKSEL, 0x01); */ + /* Select 24MHz CLKIN (set bit 0). */ + it8718f_sio_write(0x00, IT8718F_CONFIG_REG_CLOCKSEL, 0x01); /* Clear software suspend mode (clear bit 0). TODO: Needed? */ /* it8718f_sio_write(0x00, IT8718F_CONFIG_REG_SWSUSP, 0x00); */ From indrek.kruusa at artecdesign.ee Fri Dec 1 14:29:40 2006 From: indrek.kruusa at artecdesign.ee (Indrek Kruusa) Date: Fri, 01 Dec 2006 15:29:40 +0200 Subject: [LinuxBIOS] LPC SuperIO "add-in card" In-Reply-To: <20061201122939.22128.qmail@cdy.org> References: <57947bf80611300927s31876f3ep79511fa85b0066cd@mail.gmail.com> <45701167.9@artecdesign.ee> <20061201122939.22128.qmail@cdy.org> Message-ID: <45702E44.4040708@artecdesign.ee> Peter Stuge wrote: > On Fri, Dec 01, 2006 at 01:26:31PM +0200, Indrek Kruusa wrote: > >> - Altera Cyclone FPGA as the control part >> > > Do you think it would be possible to make a firmware for the FPGA > that also does reads-make-a-write and can signal them back to the > Linux host? > > I'v heard several ideas about the usage and yes - this usb-serial emulated connection can be used for whatever communications between dongle and Linux host. Of course it depends on FPGA firmware. I am not aware about the possibilites to custom-program the FPGA (for one dongle). This sould be asked again from Artec Group guys. Indrek > The idea is similar to the JEDEC flash identifying method - a special > sequence of reads at certain addresses are interpreted as a write and > sent to the host. > > > //Peter > > From indrek.kruusa at artecdesign.ee Fri Dec 1 15:01:54 2006 From: indrek.kruusa at artecdesign.ee (Indrek Kruusa) Date: Fri, 01 Dec 2006 16:01:54 +0200 Subject: [LinuxBIOS] LPC SuperIO "add-in card" In-Reply-To: <20061201114708.16209.qmail@cdy.org> References: <57947bf80611300927s31876f3ep79511fa85b0066cd@mail.gmail.com> <45701167.9@artecdesign.ee> <20061201114708.16209.qmail@cdy.org> Message-ID: <457035D2.8000103@artecdesign.ee> Peter Stuge wrote: > On Fri, Dec 01, 2006 at 01:26:31PM +0200, Indrek Kruusa wrote: > >> For current Thincan (artecgroup/dbe61) development we are using our >> own designed dongles: >> > > http://208.109.65.208/products/hardware-products/programmable-lpc-dongle.html > > Very nice! > > > >> - LPC connector (the cable shouldn't be longer than 5cm/2 inch) >> - Altera Cyclone FPGA as the control part >> - 16 MB flash: 4x separate 4MB banks; chosen by jumpers (I can have 4 >> separate booting configs( LB/kernel/initrd) in one dongle) >> - chosen flash bank is seen as 1MB at boot, switched to 4MB mode by >> LinuxBIOS. After that you can address that 4MB by FILO as mem at 0x.... >> - 4 digit LED display (POST code display + selftest) >> - miniUSB (by ftdi chip) for the programming flash banks >> - python script as programming tool >> > > That's a serial emulation, right? How long does it take to program > one bank? > > > >> PCB is 8cm x 6cm, i have seen the case for that unit too :) >> >> As much as I know this dongle were made available with initial price >> ca. ?90 (in small quantities). I'd expect that such a thing (with >> somewhat different design) can't be much cheaper. >> > > Is that EUR90 or USD90? Either way I agree - it's a good price! > Hey, this is quite a wrong price (my information was outdated). The latest information from marketing department: - for current dongle and for current revision the price is EUR149 + VAT It includes also the FPGA firmware (for registered dongle owners). Schematic design is freely downloadable (as detailed layout information). Sorry for the mess with such a important thing as a price. thanks, Indrek > I want one. :) > > Do you also have a PLCC adapter? I looked into the product sold by > Segor (that Carl-Daniel linked to) and found that it's made by cab > GmbH: > > http://www.cabgmbh.com/englisch/index.cfm?fuseaction=elektronik&rubrik=Special%20sockets&produkte=159 > > > //Peter > > From stuge-linuxbios at cdy.org Fri Dec 1 15:21:07 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 1 Dec 2006 15:21:07 +0100 Subject: [LinuxBIOS] LPC SuperIO "add-in card" In-Reply-To: <457035D2.8000103@artecdesign.ee> References: <57947bf80611300927s31876f3ep79511fa85b0066cd@mail.gmail.com> <45701167.9@artecdesign.ee> <20061201114708.16209.qmail@cdy.org> <457035D2.8000103@artecdesign.ee> Message-ID: <20061201142107.5753.qmail@cdy.org> On Fri, Dec 01, 2006 at 04:01:54PM +0200, Indrek Kruusa wrote: > > Is that EUR90 or USD90? Either way I agree - it's a good price! > > Hey, this is quite a wrong price (my information was outdated). The > latest information from marketing department: > - for current dongle and for current revision the price is EUR149 + > VAT Aha! Well, that's still a pretty good price. > It includes also the FPGA firmware (for registered dongle owners). As in the firmware source? As in I can modify it myself and reprogram my FPGA to do new things? Could I also distribute a patch with my changes to other customers that want their FPGAs to do the same new things? Then it's a very good price! :) > Schematic design is freely downloadable (as detailed layout > information). Yeah, I found it on your web site. This is also very nice to have! > Sorry for the mess with such a important thing as a price. Don't worry, it wasn't a quote, only an indication. :) //Peter From svn at openbios.org Fri Dec 1 15:49:47 2006 From: svn at openbios.org (LinuxBIOS) Date: Fri, 01 Dec 2006 14:49:47 -0000 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: <060.73e8d45aad9d6cde977837a59b8449f5@openbios.org> References: <060.73e8d45aad9d6cde977837a59b8449f5@openbios.org> Message-ID: <069.7edf681bfe20224db6c3c7041c2d50f1@openbios.org> #57: libusb host program for PLX NET20DC debug device ----------------------------+----------------------------------------------- Reporter: stuge | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: code | Version: Resolution: | Keywords: usb ehci debug Dependencies: | Patchstatus: patch needs review ----------------------------+----------------------------------------------- Changes (by uwe): * patchstatus: there is no patch => patch needs review Comment: Please add a license header to the file(s). Thanks! -- Ticket URL: LinuxBIOS From stepan at coresystems.de Fri Dec 1 15:52:40 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 1 Dec 2006 15:52:40 +0100 Subject: [LinuxBIOS] romcc and preprocessor problems Message-ID: <20061201145240.GA3182@coresystems.de> Hi, since the romcc builtin preprocessor silently eats lines of code, can we just use the gcc preprocessor (cpp) before calling romcc as a workaround? Is there a reason romcc has its own preprocessor? Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From indrek.kruusa at artecdesign.ee Fri Dec 1 15:54:24 2006 From: indrek.kruusa at artecdesign.ee (Indrek Kruusa) Date: Fri, 01 Dec 2006 16:54:24 +0200 Subject: [LinuxBIOS] LPC SuperIO "add-in card" In-Reply-To: <20061201142107.5753.qmail@cdy.org> References: <57947bf80611300927s31876f3ep79511fa85b0066cd@mail.gmail.com> <45701167.9@artecdesign.ee> <20061201114708.16209.qmail@cdy.org> <457035D2.8000103@artecdesign.ee> <20061201142107.5753.qmail@cdy.org> Message-ID: <45704220.9040007@artecdesign.ee> Peter Stuge wrote: > On Fri, Dec 01, 2006 at 04:01:54PM +0200, Indrek Kruusa wrote: > >>> Is that EUR90 or USD90? Either way I agree - it's a good price! >>> >> Hey, this is quite a wrong price (my information was outdated). The >> latest information from marketing department: >> - for current dongle and for current revision the price is EUR149 + >> VAT >> > > Aha! Well, that's still a pretty good price. > > > >> It includes also the FPGA firmware (for registered dongle owners). >> > > As in the firmware source? As in I can modify it myself and reprogram > my FPGA to do new things? > Yes, you can get FPGA firmware VHDL source. > Could I also distribute a patch with my changes to other customers > that want their FPGAs to do the same new things? > About the license for the source code - I don't have the proper inofrmation at moment to tell you. Indrek > Then it's a very good price! :) > > > >> Schematic design is freely downloadable (as detailed layout >> information). >> > > Yeah, I found it on your web site. This is also very nice to have! > > > >> Sorry for the mess with such a important thing as a price. >> > > Don't worry, it wasn't a quote, only an indication. :) > > > //Peter > > From rminnich at gmail.com Fri Dec 1 17:10:08 2006 From: rminnich at gmail.com (ron minnich) Date: Fri, 1 Dec 2006 09:10:08 -0700 Subject: [LinuxBIOS] SPD as debug channel In-Reply-To: <20061201113025.13793.qmail@cdy.org> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> Message-ID: <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> On 12/1/06, Peter Stuge wrote: > On Thu, Nov 30, 2006 at 07:44:47PM -0600, Bari Ari wrote: > > Someone could fab these however as a 2 sided pcb with only the > > SMBus signals for next to nothing in cost. > > I looked into this yesterday. > > The place I normally order prototype boards from (Olimex) don't stock > any 1.2mm laminate. > > The place I order production boards from (local fab) do have 1.2mm > laminate but the minimum order they do is one full panel (about .5m2) > - that means a big bag of boards. :) > > If there's interest I'll be happy to make a DDR2 board that does high > speed SPD<->USB. > > I estimate they would go at $150 assembled or a bit cheaper as kits. > (All SMD though.) > > I need about 20 orders before starting it up, then roughly two months > until they're shipping. > > This is pretty special-purpose though. Perhaps time would be better > spent on the LPC thingy, since they can be used for testing too. I am missing something here. If we have enough of PCI up to do SPD->USB, I would bet that we have enough of it up to do USB debug? or not? LPC is going away on many boards, I understand. I think that we are going into a world where we have to figure out usb debug port. I don't think that the PCI initial setup for USB debug is going to be impossible -- the vendors have to debug these boards too. All the boards I have used lately have a very straightforward path to USB, that could be set up in the ROMCC or CAR code. ron From rminnich at gmail.com Fri Dec 1 17:14:39 2006 From: rminnich at gmail.com (ron minnich) Date: Fri, 1 Dec 2006 09:14:39 -0700 Subject: [LinuxBIOS] 440BX progress. In-Reply-To: <7BB313C6-6A90-41F1-9709-8F6B5B98911F@kernel.crashing.org> References: <20061126165258.GA14839@greenwood> <6e22bb6c392468a0dd050b2f49ea98c8@kernel.crashing.org> <20061126210307.GA5102@greenwood> <20061130223748.GA25948@greenwood> <7BB313C6-6A90-41F1-9709-8F6B5B98911F@kernel.crashing.org> Message-ID: <13426df10612010814r7aa1a550idc11ae8682377930@mail.gmail.com> Did you check the digitallogic board in V1 that uses 440bx? It used to work ... ron From yinghailu at gmail.com Fri Dec 1 18:00:29 2006 From: yinghailu at gmail.com (yhlu) Date: Fri, 1 Dec 2006 09:00:29 -0800 Subject: [LinuxBIOS] LPC SuperIO "add-in card" In-Reply-To: <45704220.9040007@artecdesign.ee> References: <57947bf80611300927s31876f3ep79511fa85b0066cd@mail.gmail.com> <45701167.9@artecdesign.ee> <20061201114708.16209.qmail@cdy.org> <457035D2.8000103@artecdesign.ee> <20061201142107.5753.qmail@cdy.org> <45704220.9040007@artecdesign.ee> Message-ID: <2ea3fae10612010900y66dbbb8aq2bb226310ad0506e@mail.gmail.com> if you can change flash to SRAM that would be great. YH From pdegler at rumms.uni-mannheim.de Fri Dec 1 18:44:33 2006 From: pdegler at rumms.uni-mannheim.de (Philipp Degler) Date: Fri, 1 Dec 2006 18:44:33 +0100 Subject: [LinuxBIOS] [PATCH] Add includes to it8712f/superio.c In-Reply-To: <20061201123241.GA7185@countzero.vandewege.net> References: <200611291351.27601.pdegler@rumms.uni-mannheim.de> <200612010924.15958.pdegler@rumms.uni-mannheim.de> <20061201123241.GA7185@countzero.vandewege.net> Message-ID: <200612011844.33373.pdegler@rumms.uni-mannheim.de> hi On Friday 01 December 2006 13:32, Ward Vandewege wrote: > On Fri, Dec 01, 2006 at 09:24:11AM +0100, Philipp Degler wrote: > > sorry for confusion I've tested flashing again - this time with original > > BIOS chip (SST49LF004A/B) and I was able to write without problems. > > Great. Is your gpio-unlock code in the tree yet? There is no generic gpio-unlock code that I could provide. Actually gpio-lock is only one possible reason. The Island:Aruma is an example for that. You can try to find out the right GPIO register. How to do that? Last time I tried to explain that it was a little bit missleading. So give me a second chance :) 1. Disable Flash write support in your factory BIOS (The exact name of this option may vary from BIOS to BIOS --> maybe look after virus protection, lock chip access ....) 2. Boot your OS and dump the GPIO register settings of your superio 3. Reboot your system with Flash writing enabled 4. Dump registers again. Now look after a register that has changed it's value. If you have a datasheet available you could verify the registers functionality. This should be the one we are searching for in case of aruma it was GPIO 24 If there is no such functionality you could try to measure pins... hm... phil From idwer_v at hotmail.com Fri Dec 1 18:48:47 2006 From: idwer_v at hotmail.com (Idwer Vollering) Date: Fri, 01 Dec 2006 17:48:47 +0000 Subject: [LinuxBIOS] 440BX progress. In-Reply-To: <13426df10612010814r7aa1a550idc11ae8682377930@mail.gmail.com> Message-ID: Is there a equivalent of a snapshot repository for v1 (like http://snapshots.linuxbios.org is for v2) ? _________________________________________________________________ Geef jouw Hotmail kleur met Windows Live Mail! Stap nu over! http://imagine-windowslive.com/mail/launch/default.aspx?Locale=nl-nl From stuge-linuxbios at cdy.org Fri Dec 1 19:16:01 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 1 Dec 2006 19:16:01 +0100 Subject: [LinuxBIOS] SPD as debug channel In-Reply-To: <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> Message-ID: <20061201181602.7815.qmail@cdy.org> On Fri, Dec 01, 2006 at 09:10:08AM -0700, ron minnich wrote: > > This is pretty special-purpose though. Perhaps time would be better > > spent on the LPC thingy, since they can be used for testing too. > > I am missing something here. If we have enough of PCI up to do > SPD->USB, I would bet that we have enough of it up to do USB debug? > or not? SPD as in instead of reading from an EEPROM on a DIMM you would be talking to a I2C slave on a special DIMM-like board that sends data to a host somehow. The assumption was that not much needs to happen before the SPD I2C bus is accessible by the CPU - is that valid? If not, what IS easily accessible besides the boot ROM? (Which we don't want to rely on since we don't know exactly what it will speak when in the future.) We just need one bit that can do kHz signalling. SMI#? > LPC is going away on many boards, I understand. But DDR(2) SDRAM will probably stay a while longer. Or not? > I think that we are going into a world where we have to figure out > usb debug port. It's certainly one good debugging option but maybe not the only good one. > I don't think that the PCI initial setup for USB debug is going to > be impossible -- the vendors have to debug these boards too. All > the boards I have used lately have a very straightforward path to > USB, that could be set up in the ROMCC or CAR code. I think it should be fairly simple on x86 too, but we would also like more exotic systems in v3 so exploring other options is good. (And fun!) //Peter From yinghai.lu at amd.com Fri Dec 1 19:14:46 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 1 Dec 2006 10:14:46 -0800 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device Message-ID: <5986589C150B2F49A46483AC44C7BCA4907272@ssvlexmb2.amd.com> To my understanding, You don't need to waiting for Eric's code. You can use the cable on two system without debug port support. So just extend the program to make it can write the data too. YH From stepan at coresystems.de Fri Dec 1 19:20:18 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 1 Dec 2006 19:20:18 +0100 Subject: [LinuxBIOS] 440BX progress. In-Reply-To: References: <13426df10612010814r7aa1a550idc11ae8682377930@mail.gmail.com> Message-ID: <20061201182018.GA6242@coresystems.de> * Idwer Vollering [061201 18:48]: > > Is there a equivalent of a snapshot repository for v1 (like > http://snapshots.linuxbios.org is for v2) ? Not really. Since v1 is not actively developed anymore, it is just sitting in the svn repository. You can download the latest snapshot via viewvc though: http://www.linuxbios.org/viewvc/trunk/LinuxBIOSv1.tar.gz?view=tar Regards, Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From stepan at coresystems.de Fri Dec 1 19:28:53 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 1 Dec 2006 19:28:53 +0100 Subject: [LinuxBIOS] SPD as debug channel In-Reply-To: <20061201181602.7815.qmail@cdy.org> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> <20061201181602.7815.qmail@cdy.org> Message-ID: <20061201182853.GB6242@coresystems.de> * Peter Stuge [061201 19:16]: > The assumption was that not much needs to happen before the SPD I2C > bus is accessible by the CPU - is that valid? Since you need I2C, you need to get parts of the south bridge working. So, its basically the same amount of work as with the USB debug port. Question is: Will we see systems without USB (debug port) but with DDR2 sockets? > If not, what IS easily accessible besides the boot ROM? (Which we > don't want to rely on since we don't know exactly what it will speak > when in the future.) We just need one bit that can do kHz signalling. > SMI#? Boot rom is a good start I bet. That will always be there (as long as we all do firmware development at least). It might be parallel yesterday, LPC today and SPI tomorrow, but that is only the interface it connects to. Different connector, different VHDL source and we should be fine, no? > > LPC is going away on many boards, I understand. > > But DDR(2) SDRAM will probably stay a while longer. Or not? If LPC goes away, we need to do SPI. Ok. If we get DDR3, we would have to do that. Technical standards come and go,.. I'd prefer a solution that is so cheap that I dont mind throwing the whole kit away after doing a port or two, rather than trying to create something that is good forever. > > I think that we are going into a world where we have to figure out > > usb debug port. > > It's certainly one good debugging option but maybe not the only good > one. Especially it does not help for reflashing. Finding something nifty here would be nice. Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From yinghai.lu at amd.com Fri Dec 1 19:26:19 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 1 Dec 2006 10:26:19 -0800 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device Message-ID: <5986589C150B2F49A46483AC44C7BCA4907273@ssvlexmb2.amd.com> -----Original Message----- From: Lu, Yinghai >To my understanding, you don't need to waiting for Eric's code. >You can use the cable on two systems without debug port support. >So just extend the program to make it can write the data too. Greg, Anyone is working on creating one usb_serial_driver for USB debug device without using host debug port? YH From stuge-linuxbios at cdy.org Fri Dec 1 19:31:53 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 1 Dec 2006 19:31:53 +0100 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: <5986589C150B2F49A46483AC44C7BCA4907272@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA4907272@ssvlexmb2.amd.com> Message-ID: <20061201183153.10148.qmail@cdy.org> On Fri, Dec 01, 2006 at 10:14:46AM -0800, Lu, Yinghai wrote: > To my understanding, You don't need to waiting for Eric's code. I can rewrite code to do the same, but if he has working proof-of-concept there's no point in duplicating work. > You can use the cable on two system without debug port support. Not true, unfortunately. The target end of the debug device is special, it only works when connected to a USB port that operates in debug mode. It doesn't even enumerate (not seen in lsusb) if connected to a port controlled by a full USB stack. > So just extend the program to make it can write the data too. I have ordered a debug device since I am expecting that my code will need, eh, testing. Code to drive the target end of the device would be nice to have in the program but since it requires direct PCI access I think it is best placed in a kernel module. It could provide a simple character device, nothing fancy needed, just echo or cat. //Peter From yinghai.lu at amd.com Fri Dec 1 19:36:46 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 1 Dec 2006 10:36:46 -0800 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device Message-ID: <5986589C150B2F49A46483AC44C7BCA4907274@ssvlexmb2.amd.com> The two debug devices in the cable are different? YH From stuge-linuxbios at cdy.org Fri Dec 1 19:46:22 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 1 Dec 2006 19:46:22 +0100 Subject: [LinuxBIOS] SPD as debug channel In-Reply-To: <20061201182853.GB6242@coresystems.de> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> <20061201181602.7815.qmail@cdy.org> <20061201182853.GB6242@coresystems.de> Message-ID: <20061201184622.12298.qmail@cdy.org> On Fri, Dec 01, 2006 at 07:28:53PM +0100, Stefan Reinauer wrote: > * Peter Stuge [061201 19:16]: > > > The assumption was that not much needs to happen before the SPD I2C > > bus is accessible by the CPU - is that valid? > > Since you need I2C, you need to get parts of the south bridge > working. Even though it's on the DIMM? Ugh. :( > So, its basically the same amount of work as with the USB debug > port. Yeah. Not much point to it then. > Question is: Will we see systems without USB (debug port) but with > DDR2 sockets? See wiki page with list of EHCI chips that lack the debug port. On the other hand maybe all boards using them will have a serial port? > > If not, what IS easily accessible besides the boot ROM? (Which we > > don't want to rely on since we don't know exactly what it will speak > > when in the future.) We just need one bit that can do kHz signalling. > > SMI#? > > Boot rom is a good start I bet. That will always be there (as long > as we all do firmware development at least). > > It might be parallel yesterday, LPC today and SPI tomorrow, but that > is only the interface it connects to. Different connector, different > VHDL source and we should be fine, no? True. TSOPs are a bit unfriendly but still doable with a steady hand. > > > LPC is going away on many boards, I understand. > > > > But DDR(2) SDRAM will probably stay a while longer. Or not? > > If LPC goes away, we need to do SPI. Ok. If we get DDR3, we would > have to do that. Technical standards come and go,.. I'd prefer a > solution that is so cheap that I dont mind throwing the whole kit > away after doing a port or two, rather than trying to create > something that is good forever. Me too. But the kit only gets that cheap if it can be produced in at least a run of 100. And while those are too small quantities for even receiving a quote from some suppliers it's already too big for us. :\ The testing infrastructure is the dealbreaker right now. > > > I think that we are going into a world where we have to figure > > > out usb debug port. > > > > It's certainly one good debugging option but maybe not the only > > good one. > > Especially it does not help for reflashing. Finding something nifty > here would be nice. I hear you. //Peter From stuge-linuxbios at cdy.org Fri Dec 1 19:55:57 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 1 Dec 2006 19:55:57 +0100 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: <5986589C150B2F49A46483AC44C7BCA4907274@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA4907274@ssvlexmb2.amd.com> Message-ID: <20061201185557.13625.qmail@cdy.org> On Fri, Dec 01, 2006 at 10:36:46AM -0800, Lu, Yinghai wrote: > The two debug devices in the cable are different? Yes. The PLX NET20DC device I looked at in Hamburg is asymmetric. This is also consistent with the Debug Device Functional Device Specification. If you are familiar with USB, please have a look at it: http://developer.intel.com/technology/usb/download/DebugDeviceSpec_R090.pdf Looking at this again I completely mixed up the terms. Remote is the debugging host, target is the host being debugged. Sorry! In Hamburg, I plugged a USB cable into one connector at a time and ran lsusb, among other things. The device enumerated with cable connected to one port, but not with the cable connected to the other port. //Peter From yinghai.lu at amd.com Fri Dec 1 19:55:48 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 1 Dec 2006 10:55:48 -0800 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device Message-ID: <5986589C150B2F49A46483AC44C7BCA4907276@ssvlexmb2.amd.com> -----Original Message----- From: Greg KH [mailto:gregkh at suse.de] >I can do that in about 15 minutes if you give me the device ids for the >usb debug device that you wish to have. >Or you can also use the generic usb-serial driver today just fine with >no modification. Have you had a problem with using that option? We are talking about using USB debug device/EHCI debug port in LinuxBIOS in legacy free PC. Because one AM2+MCP55 MB doesn't have serial port. I guess Eric is working on USB debug device/EHCI debug port for earlyprintk or printk. So we need one client program on host side. So it would great if we could use current USB stack for the clients on system even without debug port. I'm getting one USB debug device cable, and will test generic usb_serial driver. Thanks YH From stepan at coresystems.de Fri Dec 1 20:10:45 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 1 Dec 2006 20:10:45 +0100 Subject: [LinuxBIOS] SPD as debug channel In-Reply-To: <20061201184622.12298.qmail@cdy.org> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> <20061201181602.7815.qmail@cdy.org> <20061201182853.GB6242@coresystems.de> <20061201184622.12298.qmail@cdy.org> Message-ID: <20061201191045.GA31735@coresystems.de> * Peter Stuge [061201 19:46]: > > Since you need I2C, you need to get parts of the south bridge > > working. > > Even though it's on the DIMM? Ugh. :( It's the same as trying to see the SPD ROM, isnt it? That is connected to the south bridge smbus. Not too wild though,.. > Me too. But the kit only gets that cheap if it can be produced in at > least a run of 100. And while those are too small quantities for even > receiving a quote from some suppliers it's already too big for us. :\ > > The testing infrastructure is the dealbreaker right now. Ok, I am waiting for the final ok to announce it all. Lets hope people will join in. Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From stuge-linuxbios at cdy.org Fri Dec 1 20:24:11 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 1 Dec 2006 20:24:11 +0100 Subject: [LinuxBIOS] SPD as debug channel In-Reply-To: <20061201191045.GA31735@coresystems.de> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> <20061201181602.7815.qmail@cdy.org> <20061201182853.GB6242@coresystems.de> <20061201184622.12298.qmail@cdy.org> <20061201191045.GA31735@coresystems.de> Message-ID: <20061201192411.17795.qmail@cdy.org> On Fri, Dec 01, 2006 at 08:10:45PM +0100, Stefan Reinauer wrote: > * Peter Stuge [061201 19:46]: > > > Since you need I2C, you need to get parts of the south bridge > > > working. > > > > Even though it's on the DIMM? Ugh. :( > > It's the same as trying to see the SPD ROM, isnt it? Right. > That is connected to the south bridge smbus. Not too wild though,.. Ugh again. :( What a detour. The memory controller is in the CPU or the northbridge, right? //Peter From stepan at coresystems.de Fri Dec 1 20:42:42 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 1 Dec 2006 20:42:42 +0100 Subject: [LinuxBIOS] SPD as debug channel In-Reply-To: <20061201192411.17795.qmail@cdy.org> References: <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> <20061201181602.7815.qmail@cdy.org> <20061201182853.GB6242@coresystems.de> <20061201184622.12298.qmail@cdy.org> <20061201191045.GA31735@coresystems.de> <20061201192411.17795.qmail@cdy.org> Message-ID: <20061201194242.GA17451@coresystems.de> * Peter Stuge [061201 20:24]: > > That is connected to the south bridge smbus. Not too wild though,.. > > Ugh again. :( What a detour. The memory controller is in the CPU or > the northbridge, right? Yeah. You need a little bit of everything to make it lit up. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From svn at openbios.org Fri Dec 1 21:41:07 2006 From: svn at openbios.org (LinuxBIOS) Date: Fri, 01 Dec 2006 20:41:07 -0000 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: <060.73e8d45aad9d6cde977837a59b8449f5@openbios.org> References: <060.73e8d45aad9d6cde977837a59b8449f5@openbios.org> Message-ID: <069.91899918bdef648889bdc27c4721d3f5@openbios.org> #57: libusb host program for PLX NET20DC debug device ----------------------------+----------------------------------------------- Reporter: stuge | Owner: somebody Type: enhancement | Status: closed Priority: major | Milestone: Component: code | Version: Resolution: invalid | Keywords: usb ehci debug Dependencies: | Patchstatus: patch needs review ----------------------------+----------------------------------------------- Changes (by stuge): * status: new => closed * resolution: => invalid Comment: Not much point in having this code. The usb-serial generic module can do the job just as well, and provides a ttyUSBx interface for any existing serial port utilities. Run # modprobe usb-serial vendor=0x0525 product=0x127a to load the driver and associate it with the NET20DC, either before or after the device is connected to the host. Greg K-H is working on a specific driver for the device (class) as well. -- Ticket URL: LinuxBIOS From svn at openbios.org Fri Dec 1 21:42:18 2006 From: svn at openbios.org (LinuxBIOS) Date: Fri, 01 Dec 2006 20:42:18 -0000 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: <060.73e8d45aad9d6cde977837a59b8449f5@openbios.org> References: <060.73e8d45aad9d6cde977837a59b8449f5@openbios.org> Message-ID: <069.08f561f695b2a1843246b2e17783e7a3@openbios.org> #57: libusb host program for PLX NET20DC debug device ----------------------------+----------------------------------------------- Reporter: stuge | Owner: somebody Type: enhancement | Status: closed Priority: major | Milestone: Component: code | Version: Resolution: invalid | Keywords: usb ehci debug Dependencies: | Patchstatus: patch needs review ----------------------------+----------------------------------------------- Comment (by stuge): If someone wants to use it on anything but Linux just reopen the ticket. :) -- Ticket URL: LinuxBIOS From stuge-linuxbios at cdy.org Fri Dec 1 21:42:49 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 1 Dec 2006 21:42:49 +0100 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: <20061201191916.GB3539@suse.de> References: <5986589C150B2F49A46483AC44C7BCA4907276@ssvlexmb2.amd.com> <20061201191916.GB3539@suse.de> Message-ID: <20061201204249.28842.qmail@cdy.org> On Fri, Dec 01, 2006 at 11:19:16AM -0800, Greg KH wrote: > Well, earlyprintk will not work, as you need PCI up and running. Not all of it though. LinuxBIOS will probably do just enough PCI setup to talk to the EHCI controller and use the debug port _very_ soon after power on. > And I have some code that barely works for this already, perhaps > Eric and I should work together on this :) I would be interested in having a look at any code for it too. > Yes, that will work just fine today using the usb-serial generic > driver. Ugh. I did not know it was that generic. The irony is that I always ask other libusb users to check the kernel drivers to see if they really need to write a libusb app. > I'll knock up a "real" driver for the device later today and send > it to Linus, as it's trivial to do so, and will make it simpler > than using the module parameters. Awesome. Thanks! //Peter From ebiederm at xmission.com Fri Dec 1 22:15:24 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Fri, 01 Dec 2006 14:15:24 -0700 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: <20061201204249.28842.qmail@cdy.org> (Peter Stuge's message of "Fri, 1 Dec 2006 21:42:49 +0100") References: <5986589C150B2F49A46483AC44C7BCA4907276@ssvlexmb2.amd.com> <20061201191916.GB3539@suse.de> <20061201204249.28842.qmail@cdy.org> Message-ID: Peter Stuge writes: > On Fri, Dec 01, 2006 at 11:19:16AM -0800, Greg KH wrote: >> Well, earlyprintk will not work, as you need PCI up and running. > > Not all of it though. LinuxBIOS will probably do just enough PCI > setup to talk to the EHCI controller and use the debug port _very_ > soon after power on. Right. For LinuxBIOS not a problem for earlyprintk in the kernel somethings might need to be refactored. The challenge in the kernel is we don't know at build to how to do a pci_read_config... The other hard part early in the kernel is the fact that the bar is memory mapped I/O. Which means it will need to get mapped into the kernels page tables. >> And I have some code that barely works for this already, perhaps >> Eric and I should work together on this :) > > I would be interested in having a look at any code for it too. Sure, I will send it out shortly. I currently have a working user space libusb thing (easy, but useful for my debug) and a rude read/write to the bar from user space program that allowed me to debug the worst of the state machine from user space. I don't think I have the state setup logic correct yet but that is minor in comparison. I really wish the EHCI spec had made that stupid interface 16 bytes instead of 8 or had a way to chain multiple access together. The we could have used a normal usb cable. As it is most descriptors are 1 byte to big to read. >> Yes, that will work just fine today using the usb-serial generic >> driver. > > Ugh. I did not know it was that generic. The irony is that I always > ask other libusb users to check the kernel drivers to see if they > really need to write a libusb app. > > >> I'll knock up a "real" driver for the device later today and send >> it to Linus, as it's trivial to do so, and will make it simpler >> than using the module parameters. > > Awesome. Thanks! Yep. It looks like it sufficient generic. The Maximum packet size appears to be reported correctly for writes which is the tidbit I was worried about but otherwise it is just a pair of bulk transfer endpoints. Eric From stuge-linuxbios at cdy.org Fri Dec 1 22:46:31 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 1 Dec 2006 22:46:31 +0100 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA4907276@ssvlexmb2.amd.com> <20061201191916.GB3539@suse.de> <20061201204249.28842.qmail@cdy.org> Message-ID: <20061201214631.6991.qmail@cdy.org> On Fri, Dec 01, 2006 at 02:15:24PM -0700, Eric W. Biederman wrote: > Right. For LinuxBIOS not a problem for earlyprintk in the kernel > somethings might need to be refactored. The challenge in the > kernel is we don't know at build to how to do a pci_read_config... > > The other hard part early in the kernel is the fact that the > bar is memory mapped I/O. Which means it will need to get mapped > into the kernels page tables. I see. > >> And I have some code that barely works for this already, perhaps > >> Eric and I should work together on this :) > > > > I would be interested in having a look at any code for it too. > > Sure, I will send it out shortly. I currently have a working > user space libusb thing (easy, but useful for my debug) Hm - for driving which end? > and a rude read/write to the bar from user space program that How does that work? /dev/{port,mem}? > allowed me to debug the worst of the state machine from user > space. I don't think I have the state setup logic correct yet > but that is minor in comparison. > > I really wish the EHCI spec had made that stupid interface 16 bytes > instead of 8 or had a way to chain multiple access together. The > we could have used a normal usb cable. As it is most descriptors > are 1 byte to big to read. Which descriptors are you reading? The debug port isn't really supposed to be used with anything but a debug device - which can't be enumerated normally anyway. //Peter From segher at kernel.crashing.org Fri Dec 1 22:57:23 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Fri, 1 Dec 2006 22:57:23 +0100 Subject: [LinuxBIOS] romcc and preprocessor problems In-Reply-To: <20061201145240.GA3182@coresystems.de> References: <20061201145240.GA3182@coresystems.de> Message-ID: > since the romcc builtin preprocessor silently eats lines of code, > can we just use the gcc preprocessor (cpp) before calling romcc as > a workaround? That should work (if you get the -I directives, etc., right). But use gcc -E instead of cpp... > Is there a reason romcc has its own preprocessor? Probably not. Segher From yinghai.lu at amd.com Fri Dec 1 23:10:59 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 1 Dec 2006 14:10:59 -0800 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device Message-ID: <5986589C150B2F49A46483AC44C7BCA490727A@ssvlexmb2.amd.com> -----Original Message----- From: ebiederm at xmission.com [mailto:ebiederm at xmission.com] Sent: Friday, December 01, 2006 1:15 PM Peter Stuge writes: >> On Fri, Dec 01, 2006 at 11:19:16AM -0800, Greg KH wrote: >>> Well, earlyprintk will not work, as you need PCI up and running. >> >> Not all of it though. LinuxBIOS will probably do just enough PCI >> setup to talk to the EHCI controller and use the debug port _very_ >> soon after power on. >Right. For LinuxBIOS not a problem for earlyprintk in the kernel >somethings might need to be refactored. The challenge in the kernel >is we don't know at build to how to do a pci_read_config... early_pci_read_config? Otherwise printk will come too late, and will not get output before pci bus ops is set. >The other hard part early in the kernel is the fact that the >bar is memory mapped I/O. Which means it will need to get mapped >into the kernels page tables. several entries to map 0xfc000000 ( PCI IO mem range) in page table in head.S? YH From segher at kernel.crashing.org Fri Dec 1 23:11:40 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Fri, 1 Dec 2006 23:11:40 +0100 Subject: [LinuxBIOS] SPD as debug channel In-Reply-To: <20061201113025.13793.qmail@cdy.org> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> Message-ID: <03204455-E7E8-4E3D-9942-D35357637751@kernel.crashing.org> > The place I order production boards from (local fab) do have 1.2mm > laminate but the minimum order they do is one full panel (about .5m2) > - that means a big bag of boards. :) Real cheap-skates just demolish an existing (already broken) DIMM ;-) > If there's interest I'll be happy to make a DDR2 board that does high > speed SPD<->USB. Why USB? RS232 is soooo much simpler, can connect to anything without special software / drivers needed. > This is pretty special-purpose though. Perhaps time would be better > spent on the LPC thingy, since they can be used for testing too. Many systems don't have LPC and it's getting worse. An LPC thing would be useful, of course. Segher From segher at kernel.crashing.org Fri Dec 1 23:15:16 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Fri, 1 Dec 2006 23:15:16 +0100 Subject: [LinuxBIOS] SPD as debug channel In-Reply-To: <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> Message-ID: <32AA4BBA-BAAC-400C-B523-ADC6DF488DA5@kernel.crashing.org> > I am missing something here. If we have enough of PCI up to do > SPD->USB, I would bet that we have enough of it up to do USB debug? or > not? Many systems don't require any PCI to access their I2C controllers. > LPC is going away on many boards, I understand. I think that we are > going into a world where we have to figure out usb debug port. I don't > think that the PCI initial setup for USB debug is going to be > impossible It is possible, sure -- *per board*. Anything generic would require a huge amount of code (and data). Not suitable for early boot. > All the > boards I have used lately have a very straightforward path to USB, > that could be set up in the ROMCC or CAR code. Yeah. So someone do it please, let's get some hands-on experience with this stuff :-) Segher From rminnich at gmail.com Fri Dec 1 23:18:34 2006 From: rminnich at gmail.com (ron minnich) Date: Fri, 1 Dec 2006 15:18:34 -0700 Subject: [LinuxBIOS] SPD as debug channel In-Reply-To: <32AA4BBA-BAAC-400C-B523-ADC6DF488DA5@kernel.crashing.org> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> <32AA4BBA-BAAC-400C-B523-ADC6DF488DA5@kernel.crashing.org> Message-ID: <13426df10612011418y4b4216d5t5aac517be9f92fbb@mail.gmail.com> On 12/1/06, Segher Boessenkool wrote: > > I am missing something here. If we have enough of PCI up to do > > SPD->USB, I would bet that we have enough of it up to do USB debug? or > > not? > > Many systems don't require any PCI to access their I2C controllers. I have never used a PC that doesn't require it. We come from different worlds. ron From segher at kernel.crashing.org Fri Dec 1 23:21:15 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Fri, 1 Dec 2006 23:21:15 +0100 Subject: [LinuxBIOS] SPD as debug channel In-Reply-To: <20061201181602.7815.qmail@cdy.org> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> <20061201181602.7815.qmail@cdy.org> Message-ID: > The assumption was that not much needs to happen before the SPD I2C > bus is accessible by the CPU - is that valid? Depends on the system. Intel tends to put the I2C controllers on the south bridge, such a shame. > If not, what IS easily accessible besides the boot ROM? In general? Nothing, not necessarily the boot ROM even! >> LPC is going away on many boards, I understand. > > But DDR(2) SDRAM will probably stay a while longer. Or not? That is the nice thing about the DIMM serial: memory modules will keep using I2C SPD eeproms for the foreseeable future, and (almost) every board uses DIMMs. >> I think that we are going into a world where we have to figure out >> usb debug port. > > It's certainly one good debugging option but maybe not the only good > one. And *all* these options require special (extra) debug hardware, no good for the end user. >> I don't think that the PCI initial setup for USB debug is going to >> be impossible -- the vendors have to debug these boards too. All >> the boards I have used lately have a very straightforward path to >> USB, that could be set up in the ROMCC or CAR code. > > I think it should be fairly simple on x86 too, but we would also like > more exotic systems in v3 so exploring other options is good. > (And fun!) It can't be done in a generic way. That doesn't matter of course, the CAR code by very nature isn't generic. It might require our CAR code to be more board-specific than we want though (although perhaps (some of) it can be parametrised in the DT). Segher From segher at kernel.crashing.org Fri Dec 1 23:31:48 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Fri, 1 Dec 2006 23:31:48 +0100 Subject: [LinuxBIOS] SPD as debug channel In-Reply-To: <20061201182853.GB6242@coresystems.de> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> <20061201181602.7815.qmail@cdy.org> <20061201182853.GB6242@coresystems.de> Message-ID: <4BE6C6A6-B892-4848-9F5D-5B2A95B6F7CA@kernel.crashing.org> >> The assumption was that not much needs to happen before the SPD I2C >> bus is accessible by the CPU - is that valid? > > Since you need I2C, you need to get parts of the south bridge working. > So, its basically the same amount of work as with the USB debug port. Most systems I work with have I2C controllers (and typically more than one) in the north bridge, not somewhere south (which is an insane idea). > Question is: Will we see systems without USB (debug port) but with > DDR2 > sockets? Yes. They exist already (mostly in the embedded world, of course). >> If not, what IS easily accessible besides the boot ROM? (Which we >> don't want to rely on since we don't know exactly what it will speak >> when in the future.) We just need one bit that can do kHz signalling. >> SMI#? > > Boot rom is a good start I bet. That will always be there (as long > as we > all do firmware development at least). > > It might be parallel yesterday, LPC today and SPI tomorrow, but that > is only the interface it connects to. Different connector, different > VHDL source and we should be fine, no? SPI buses as implemented on most x86 systems for flash, do _not_ support attaching extra devices on the bus (you'd need a separate chip-select signal, and those either don't exist or aren't readily available on the board). > If LPC goes away, we need to do SPI. Ok. If we get DDR3, we would have > to do that. Technical standards come and go,.. I'd prefer a solution > that is so cheap that I dont mind throwing the whole kit away after > doing a port or two, rather than trying to create something that is > good > forever. The "SPD" solution works over all families of DIMMs. >>> I think that we are going into a world where we have to figure out >>> usb debug port. >> >> It's certainly one good debugging option but maybe not the only good >> one. > > Especially it does not help for reflashing. Finding something nifty > here > would be nice. JTAG into the north bridge, and you can init all system buses, done ;-) On some systems you don't even need such init, the PCI starts running -- so you can DMA from a plug-in card to the flash chip. Again though: none of this is suitable for an "end-user", someone not too hardware savvy to help getting LinuxBIOS going on his board (or to restore flash after an "accident", etc). Segher From segher at kernel.crashing.org Fri Dec 1 23:36:54 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Fri, 1 Dec 2006 23:36:54 +0100 Subject: [LinuxBIOS] SPD as debug channel In-Reply-To: <20061201184622.12298.qmail@cdy.org> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> <20061201181602.7815.qmail@cdy.org> <20061201182853.GB6242@coresystems.de> <20061201184622.12298.qmail@cdy.org> Message-ID: <63FD97CE-19A8-470E-96EB-D58182ACBB61@kernel.crashing.org> >> Since you need I2C, you need to get parts of the south bridge >> working. > > Even though it's on the DIMM? Ugh. :( > >> So, its basically the same amount of work as with the USB debug >> port. > > Yeah. Not much point to it then. Well at least it's an I/O BAR instead of a memory BAR, quite a bit easier to do portably. >> Question is: Will we see systems without USB (debug port) but with >> DDR2 sockets? > > See wiki page with list of EHCI chips that lack the debug port. On > the other hand maybe all boards using them will have a serial port? Lots of boards don't have USB... Remember, the desktop market is only a very small percentage of the total (Linux) market! Segher From segher at kernel.crashing.org Fri Dec 1 23:38:43 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Fri, 1 Dec 2006 23:38:43 +0100 Subject: [LinuxBIOS] SPD as debug channel In-Reply-To: <20061201191045.GA31735@coresystems.de> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> <20061201181602.7815.qmail@cdy.org> <20061201182853.GB6242@coresystems.de> <20061201184622.12298.qmail@cdy.org> <20061201191045.GA31735@coresystems.de> Message-ID: <603E1190-96DA-49C0-9014-EB8D29249F9A@kernel.crashing.org> >>> Since you need I2C, you need to get parts of the south bridge >>> working. >> >> Even though it's on the DIMM? Ugh. :( > > It's the same as trying to see the SPD ROM, isnt it? That is connected > to the south bridge smbus. Not too wild though,.. No, it's on whatever I2C people put it on. Yes it's true intel puts their I2C controllers on the south bridge, they like making life hard. Not every hardware manufacturer is that way :-) Segher From segher at kernel.crashing.org Fri Dec 1 23:47:39 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Fri, 1 Dec 2006 23:47:39 +0100 Subject: [LinuxBIOS] SPD as debug channel In-Reply-To: <13426df10612011418y4b4216d5t5aac517be9f92fbb@mail.gmail.com> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> <32AA4BBA-BAAC-400C-B523-ADC6DF488DA5@kernel.crashing.org> <13426df10612011418y4b4216d5t5aac517be9f92fbb@mail.gmail.com> Message-ID: <8E9922D9-7699-4595-B2DE-082917592360@kernel.crashing.org> >> Many systems don't require any PCI to access their I2C controllers. > > I have never used a PC that doesn't require it. 486-era PCs didn't, it has gone downhill since then... > We come from different worlds. Yeah :-) Segher From ebiederm at xmission.com Sat Dec 2 00:02:03 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Fri, 01 Dec 2006 16:02:03 -0700 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: <20061201214631.6991.qmail@cdy.org> (Peter Stuge's message of "Fri, 1 Dec 2006 22:46:31 +0100") References: <5986589C150B2F49A46483AC44C7BCA4907276@ssvlexmb2.amd.com> <20061201191916.GB3539@suse.de> <20061201204249.28842.qmail@cdy.org> <20061201214631.6991.qmail@cdy.org> Message-ID: Peter Stuge writes: > On Fri, Dec 01, 2006 at 02:15:24PM -0700, Eric W. Biederman wrote: >> Right. For LinuxBIOS not a problem for earlyprintk in the kernel >> somethings might need to be refactored. The challenge in the >> kernel is we don't know at build to how to do a pci_read_config... >> >> The other hard part early in the kernel is the fact that the >> bar is memory mapped I/O. Which means it will need to get mapped >> into the kernels page tables. > > I see. > > >> >> And I have some code that barely works for this already, perhaps >> >> Eric and I should work together on this :) >> > >> > I would be interested in having a look at any code for it too. >> >> Sure, I will send it out shortly. I currently have a working >> user space libusb thing (easy, but useful for my debug) > > Hm - for driving which end? Either. The specific device we are talking about doesn't care. >> and a rude read/write to the bar from user space program that > > How does that work? /dev/{port,mem}? mmap /dev/mem. >> allowed me to debug the worst of the state machine from user >> space. I don't think I have the state setup logic correct yet >> but that is minor in comparison. >> >> I really wish the EHCI spec had made that stupid interface 16 bytes >> instead of 8 or had a way to chain multiple access together. The >> we could have used a normal usb cable. As it is most descriptors >> are 1 byte too big to read. > > Which descriptors are you reading? Minor. I was just wishing for less magic in this process, which would make these kinds of devices much more available. > The debug port isn't really supposed to be used with anything but a > debug device - which can't be enumerated normally anyway. It depends. If you have a debug cable with magic ends and a hardcoded address of 127 the normal enumeration doesn't work. I don't think anyone actually makes one of those. Debug devices are also allowed to be normal devices that just support the debug descriptor. Which is what I'm working with. Eric From ebiederm at xmission.com Sat Dec 2 00:13:39 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Fri, 01 Dec 2006 16:13:39 -0700 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: <20061201191916.GB3539@suse.de> (Greg KH's message of "Fri, 1 Dec 2006 11:19:16 -0800") References: <5986589C150B2F49A46483AC44C7BCA4907276@ssvlexmb2.amd.com> <20061201191916.GB3539@suse.de> Message-ID: Greg KH writes: > On Fri, Dec 01, 2006 at 10:55:48AM -0800, Lu, Yinghai wrote: >> -----Original Message----- >> From: Greg KH [mailto:gregkh at suse.de] >> >> >I can do that in about 15 minutes if you give me the device ids for the >> >usb debug device that you wish to have. >> >> >Or you can also use the generic usb-serial driver today just fine with >> >no modification. Have you had a problem with using that option? >> >> We are talking about using USB debug device/EHCI debug port in LinuxBIOS >> in legacy free PC. >> Because one AM2+MCP55 MB doesn't have serial port. >> >> I guess Eric is working on USB debug device/EHCI debug port for >> earlyprintk or printk. > > Well, earlyprintk will not work, as you need PCI up and running. > > And I have some code that barely works for this already, perhaps Eric > and I should work together on this :) I'd love to work with someone on this. I'm cc'ing Andi Kleen because he asked me where we had gotten on this the other day. One big thing we need is a way to tell if you have the system booted if your device is plugged into the usb port that connects to the usb debug port. Figuring out which usb port you really have to plug into is still trying and error but at least being able to tell without having to try the code is good. So here is my mostly somewhat working code. I don't understand what you have todo if you want to reset the device and then find the device so this code currently only works if you have ehci_hcd already loaded. I am avoiding the pci bit simply by having someone pass me the hard coded numbers... I think I can get it down to a single base address if I don't print debugging of which port you are plugged into, or try and debug the state out of reset. usbtest.c is my little libusb client program. It's useful for exploring things. usbdebug_direct.c is roughly a driver living in user space so I can debug the hard bits of the logic. Not a good production technique but great for prototyping. It has all of the basic primitives needed to actually use the ehci debug port. The next big thing for me I guess is to modify a kernel and see what state the usb ports are in when I am booting and how much of the reset logic I need to understand to make this work. Greg I expect you understand that a little better than I do. Eric -------------- next part -------------- A non-text attachment was scrubbed... Name: usbtest.c Type: text/x-csrc Size: 7104 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: usbdebug_direct.c Type: text/x-csrc Size: 17393 bytes Desc: not available URL: From rminnich at gmail.com Sat Dec 2 00:40:43 2006 From: rminnich at gmail.com (ron minnich) Date: Fri, 1 Dec 2006 16:40:43 -0700 Subject: [LinuxBIOS] SPD as debug channel In-Reply-To: <8E9922D9-7699-4595-B2DE-082917592360@kernel.crashing.org> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> <32AA4BBA-BAAC-400C-B523-ADC6DF488DA5@kernel.crashing.org> <13426df10612011418y4b4216d5t5aac517be9f92fbb@mail.gmail.com> <8E9922D9-7699-4595-B2DE-082917592360@kernel.crashing.org> Message-ID: <13426df10612011540p45145e53ydc83184a4417c929@mail.gmail.com> It seems to me the order of choices is something like this: Best: 1. USB debug port. This is going to work well in the x86 world, as even the embeddec boards tend to have USB. USB is replacing rs232 in those worlds. Based on the boards we have used in last 7 years, on x86, setting up the PCI infrastructure at very early boot to use this should not be hard. USB is almost always on bus 0. PowerPC sounds a bit harder. 2. JTAG. This is very common on the PPC boards we have used. It is by far the best option, since reflash after a disaster is possible, debugging is easy, and so on. Rare on x86, common on PowerPC and ARM. The next in line are: 3. SPD. Just as hard to get working as USB debug port on x86, since SPD is on the south. Not useful on most x86 and PowerPC embedded boards I have used, as they have no DRAM sockets of any kind -- and, if you only have one, the usefulness is quite limited, since you have to take the DRAM out to put the debugging in. But, most of the time, you're debugging DRAM ...Requires that we design and build a card. I don't think this approach is that practical. 4. LPC debugger. This one is kind of interesting, requires that we build a card, but could have good use -- as long as LPC doesn't go away. 5. I2C snooper. Just solder onto I2C and use a card you build? I still see (1) and (2) as the most practical. ron From stepan at coresystems.de Sat Dec 2 01:20:37 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 2 Dec 2006 01:20:37 +0100 Subject: [LinuxBIOS] SPD as debug channel In-Reply-To: <603E1190-96DA-49C0-9014-EB8D29249F9A@kernel.crashing.org> References: <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> <20061201181602.7815.qmail@cdy.org> <20061201182853.GB6242@coresystems.de> <20061201184622.12298.qmail@cdy.org> <20061201191045.GA31735@coresystems.de> <603E1190-96DA-49C0-9014-EB8D29249F9A@kernel.crashing.org> Message-ID: <20061202002037.GA29611@coresystems.de> * Segher Boessenkool [061201 23:38]: > No, it's on whatever I2C people put it on. Yes it's true > intel puts their I2C controllers on the south bridge, they > like making life hard. Not every hardware manufacturer is > that way :-) all PC components manufacturers do. 99% of the non-embedded market. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From stepan at coresystems.de Sat Dec 2 01:21:51 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 2 Dec 2006 01:21:51 +0100 Subject: [LinuxBIOS] SPD as debug channel In-Reply-To: <63FD97CE-19A8-470E-96EB-D58182ACBB61@kernel.crashing.org> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> <20061201181602.7815.qmail@cdy.org> <20061201182853.GB6242@coresystems.de> <20061201184622.12298.qmail@cdy.org> <63FD97CE-19A8-470E-96EB-D58182ACBB61@kernel.crashing.org> Message-ID: <20061202002151.GB29611@coresystems.de> * Segher Boessenkool [061201 23:36]: > > See wiki page with list of EHCI chips that lack the debug port. On > > the other hand maybe all boards using them will have a serial port? > > Lots of boards don't have USB... Remember, the desktop market > is only a very small percentage of the total (Linux) market! Linux is only a very small market to begin with. ;-) -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From stepan at coresystems.de Sat Dec 2 01:27:16 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 2 Dec 2006 01:27:16 +0100 Subject: [LinuxBIOS] SPD as debug channel In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> <20061201181602.7815.qmail@cdy.org> Message-ID: <20061202002716.GC29611@coresystems.de> * Segher Boessenkool [061201 23:21]: > > If not, what IS easily accessible besides the boot ROM? > In general? Nothing, not necessarily the boot ROM even! Right. The machine might be booting out of the air. Or have some overlay in the southbridge (our s-word today), like the xbox does. Besides that we will never see a port to a machine where ROM is not accessible when the firmware starts. I bet. ;-) -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From segher at kernel.crashing.org Sat Dec 2 03:01:17 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sat, 2 Dec 2006 03:01:17 +0100 Subject: [LinuxBIOS] SPD as debug channel In-Reply-To: <13426df10612011540p45145e53ydc83184a4417c929@mail.gmail.com> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> <32AA4BBA-BAAC-400C-B523-ADC6DF488DA5@kernel.crashing.org> <13426df10612011418y4b4216d5t5aac517be9f92fbb@mail.gmail.com> <8E9922D9-7699-4595-B2DE-082917592360@kernel.crashing.org> <13426df10612011540p45145e53ydc83184a4417c929@mail.gmail.com> Message-ID: > It seems to me the order of choices is something like this: > > Best: > 1. USB debug port. This is going to work well in the x86 world, as > even the embeddec boards tend to have USB. USB is replacing rs232 in > those worlds. Based on the boards we have used in last 7 years, on > x86, setting up the PCI infrastructure at very early boot to use this > should not be hard. USB is almost always on bus 0. PowerPC sounds a > bit harder. Not (much) harder in most cases -- x86 has most of the same problems (memory windows (MTRR), HT init, PCI in a completely unknown state at boot time (warm boot), etc.) > 2. JTAG. This is very common on the PPC boards we have used. It is by > far the best option, since reflash after a disaster is possible, > debugging is easy, and so on. Rare on x86, common on PowerPC and ARM. Common on anything but x86, yes (although almost all x86 CPUs and chipsets have JTAG, it hardly ever is brought out on the board). This is the #1 choice as it gives you *much* more than just a console; in most cases, it even allows you to boot the whole system without a ROM at all. > The next in line are: > 3. SPD. Just as hard to get working as USB debug port on x86, since > SPD is on the south. Not useful on most x86 and PowerPC embedded > boards I have used, as they have no DRAM sockets of any kind -- and, > if you only have one, the usefulness is quite limited, since you have > to take the DRAM out to put the debugging in. But, most of the time, > you're debugging DRAM ...Requires that we design and build a card. I > don't think this approach is that practical. Seems it would not too useful on most x86, yeah. Most embedded boards have I2C headers (or easily accessible pins) all over the place though, the general idea still holds -- the nice thing about using a DIMM is that the same connector works on many boards. > 4. LPC debugger. This one is kind of interesting, requires that we > build a card, but could have good use -- as long as LPC doesn't go > away. Not just LPC -- you want a common socket to use too. > 5. I2C snooper. Just solder onto I2C and use a card you build? Same as #3 really. > I still see (1) and (2) as the most practical. JTAG is best, sure. The "get the LPC bus from the flash socket" thing would be very nice for many boards, too. The other solutions only give you a "UART", and require some work at boot time; EHCI debug works if your board supports it, a UART on an I2C bus (on a DIMM, perhaps) can be used otherwise. And let's not forget that most boards have 16550-style ports still ;-) Segher From yinghai.lu at amd.com Sat Dec 2 03:43:03 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 1 Dec 2006 18:43:03 -0800 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device Message-ID: <5986589C150B2F49A46483AC44C7BCA490727C@ssvlexmb2.amd.com> Thanks for the code. In LinuxBIOS, I put usbdevice_direct.c in lib/, and call it from usb2_init in mcp55_usb2.c Got "No device in debug port" Waiting for cable, hope to get that cable next Tuesday. Will create usbdebug_direct_console.c in console/ for linuxbios_ram code. also usbdebug_direct_serial.c in pc80/ for cache_as_ram.c YH From dhbarr at gozelle.com Sat Dec 2 05:19:50 2006 From: dhbarr at gozelle.com (David H. Barr) Date: Fri, 1 Dec 2006 22:19:50 -0600 Subject: [LinuxBIOS] Support for recent chipset and powerful desktop CPU In-Reply-To: <002c01c7149d$d8301800$88904800$@ca> References: <20061130162319.22284.qmail@web54406.mail.yahoo.com> <002c01c7149d$d8301800$88904800$@ca> Message-ID: On 11/30/06, Simon Labrecque wrote: > The problem with the MSI K9N is that the Northbridge's passive cooler is > said to get very, VERY hot, which might be problematic in our application as > noise (and therefore airflow) needs to be minimized. > > I haven't tested it personally though, but every review I read on the K9N > seems to mention the heat issue. That's why I liked the Abit board in the > first place; passively cooled, but with heat pipes and an easy way out for > the heat. I have my ms7260 v1.0 (AKA MSI K9N Neo-f) in-hand, and I can verify that the northbridge is literally painfully hot. The good news is the heatsink itself is quite large, and there's a 3-prong header marked "NBFAN" directly adjacent. Either a small fan attached to the stock heatsink or a large replacement passive heatsink ought to do the trick nicely. Close-up pictures are available upon request ?grin?. Regards, -dhbarr. From ebiederman at lnxi.com Sat Dec 2 08:54:11 2006 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Sat, 02 Dec 2006 00:54:11 -0700 Subject: [LinuxBIOS] romcc and preprocessor problems In-Reply-To: <20061201145240.GA3182@coresystems.de> (Stefan Reinauer's message of "Fri, 1 Dec 2006 15:52:40 +0100") References: <20061201145240.GA3182@coresystems.de> Message-ID: Stefan Reinauer writes: > Hi, > > since the romcc builtin preprocessor silently eats lines of code, > can we just use the gcc preprocessor (cpp) before calling romcc as > a workaround? I'd love to see a reproducer of that problem. I don't have a good feel that it has been root caused. The parser is fairly straight forward so if we can reproduce this problem it shouldn't be hard to fix. I'm not convinced the problem is actually isolated to just the c pre processor. > Is there a reason romcc has its own preprocessor? A couple of reasons. - It was comparatively easy. - It makes the dependencies much easier to get right. - We don't have to worry about gcc polluting the compile with #defines that are not correct for the romcc environment. - There are several C features that you cannot implement properly unless you implement some level of c preprocessor. All of that said you can look back into the history to when romcc did not have a preprocessor and can probably make that work. I'd much rather fix the stupid parsing bug. Eric From segher at kernel.crashing.org Sat Dec 2 09:30:58 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sat, 2 Dec 2006 09:30:58 +0100 Subject: [LinuxBIOS] 440BX progress. In-Reply-To: <20061130223748.GA25948@greenwood> References: <20061126165258.GA14839@greenwood> <6e22bb6c392468a0dd050b2f49ea98c8@kernel.crashing.org> <20061126210307.GA5102@greenwood> <20061130223748.GA25948@greenwood> Message-ID: >> Also, you probably didn't program the MRS on the memory. > > Yes, I'm quite sure I messed that up. In general, in do_ram_command > () I > have to set DRAMC bits 7-5 to the respective command and then read32 > () from > some memory location for the change to "take effect", right? > If so, which memory location is that? Does it depend on some input > data? > > I still don't really understand this part of the RAM init, so the code > might be very, very wrong... It looks reasonable. You want to shift by 3 though, not 23, not 15, so you read from 0x1d0 for writing to the MRS. It seems the i440 might want the address bits inverted on the high banks in some configurations, btw; so if it won't work, you can try 0x1d0 ^ 0xff8 or so. From the comments it seems you used the DDR-II spec, not the SDRAM spec; but the code looks okay. Segher From ben at hewson-venieri.com Sat Dec 2 10:37:48 2006 From: ben at hewson-venieri.com (Ben Hewson) Date: Sat, 02 Dec 2006 09:37:48 +0000 Subject: [LinuxBIOS] romcc and preprocessor problems In-Reply-To: References: <20061201145240.GA3182@coresystems.de> Message-ID: <4571496C.8040807@hewson-venieri.com> Hi Eric Please find attached some simple test cases. These were compiled using the following ./romcc -O -fno-eliminate-inefectual-code -I../../../../../src/arch/i386/include/ -o testdef3.inc testdef3.c if you look at testdef2.c, testdef2.inc you can see that a C++ comment has caused one line to be missed, no comment or a C comment are fine. I checked no comments, C comments and C++ comments on both the #if and #else lines. The one thing I did not check was a C++ comment on the #endif to see if the following line was missed. I may be missing needed options for romcc, but I have tried similar tests in a proper build, with the same results. regards Ben > Stefan Reinauer writes: > > >> Hi, >> >> since the romcc builtin preprocessor silently eats lines of code, >> can we just use the gcc preprocessor (cpp) before calling romcc as >> a workaround? >> > > I'd love to see a reproducer of that problem. I don't have a good feel > that it has been root caused. The parser is fairly straight forward > so if we can reproduce this problem it shouldn't be hard to fix. > > I'm not convinced the problem is actually isolated to just the c pre processor. > > >> Is there a reason romcc has its own preprocessor? >> > > A couple of reasons. > - It was comparatively easy. > - It makes the dependencies much easier to get right. > - We don't have to worry about gcc polluting the compile with #defines > that are not correct for the romcc environment. > - There are several C features that you cannot implement properly unless > you implement some level of c preprocessor. > > All of that said you can look back into the history to when romcc did not have > a preprocessor and can probably make that work. I'd much rather fix > the stupid parsing bug. > > Eric > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: testdef.c Type: text/x-csrc Size: 240 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: testdef.inc URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testdef2.c Type: text/x-csrc Size: 240 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: testdef2.inc URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testdef3.c Type: text/x-csrc Size: 239 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: testdef3.inc URL: From anton.borisov at gmail.com Sat Dec 2 12:09:33 2006 From: anton.borisov at gmail.com (Anton) Date: Sat, 2 Dec 2006 19:09:33 +0800 Subject: [LinuxBIOS] MIPS arch. Message-ID: <20061202190933.2e88aa0c.anton.borisov@gmail.com> Hi. IIRC, LinuxBIOS is available for Alpha, x86 and .. it's all? No MIPS? From anton.borisov at gmail.com Sat Dec 2 12:28:38 2006 From: anton.borisov at gmail.com (Anton) Date: Sat, 2 Dec 2006 19:28:38 +0800 Subject: [LinuxBIOS] Concepts for LX v3 Message-ID: <20061202192838.78a92d56.anton.borisov@gmail.com> It would be nice to have TMS (Test Monitor System) onboard. Some big vendors have it on their systems for ages. Pros: a) Test for DRAM b) Test for Media (HDD, CF, SD, ..) connected to the host c) Test for Peripherals Cons: a) size. may not fit into 1/2/4 Mbit. TMS is a regular payload, access is done via RS232 (or USB in future), the same way as we all see printk messages nowdays. However, it's not yet clear to me is it possible to have multiple payloads at once and how to choose between them. Where to store boot options (CMOS is a way too small for it). Another concept to store big payloads which can't be stored in flash (even 16 Mbit is not enough) is to have dedicated partition. On booting media. With FAT16 or use a very simple FS to avoid licensing problems (no journaling features required). Pros: a) bigger and more payload sources at once from one place b) possibility to have several linuxbios images to be flashed back in case of emergency Cons: a) need to prepare boot media, like SATA/IDE device, to have dedicated partition b) need to add support lines for FS on dedicated FS (however, I see FILO can boot ext2 partition, hope this one will be enough). Comments are welcome. From stepan at coresystems.de Sat Dec 2 12:47:14 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 2 Dec 2006 12:47:14 +0100 Subject: [LinuxBIOS] MIPS arch. In-Reply-To: <20061202190933.2e88aa0c.anton.borisov@gmail.com> References: <20061202190933.2e88aa0c.anton.borisov@gmail.com> Message-ID: <20061202114714.GA14509@coresystems.de> * Anton [061202 12:09]: > Hi. > IIRC, LinuxBIOS is available for Alpha, x86 and .. it's all? No MIPS? v1 was Alpha and x86, v2 is PPC and x86. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From uwe at hermann-uwe.de Sat Dec 2 14:50:29 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 2 Dec 2006 14:50:29 +0100 Subject: [LinuxBIOS] 440BX progress. In-Reply-To: References: <20061126165258.GA14839@greenwood> <6e22bb6c392468a0dd050b2f49ea98c8@kernel.crashing.org> <20061126210307.GA5102@greenwood> <20061130223748.GA25948@greenwood> Message-ID: <20061202135029.GA15152@greenwood> On Sat, Dec 02, 2006 at 09:30:58AM +0100, Segher Boessenkool wrote: > It looks reasonable. You want to shift by 3 though, not 23, > not 15, so you read from 0x1d0 for writing to the MRS. OK, a few questions: * Do I read32() from somewhere for _every_ RAM command or only for MRS? * The v1 code seems to read from the highest RAM address for each DRB register. In my case: Get contents of DRB6 (0x8), shift left by 23 as the DRB registers store multiples of 8 MB, so I get my 64 MB. Correct? Now; do I read32() from * (8 << 23) * (8 << 23) + 0x1d0 * 0x0 + 0x1d0 * 0x0 + 0x1d0 AND (8 << 23) + 0x1d0 * 0x0 * ??? Do I read from x for most commands but from (x + 0x1d0) for MRS? Or should I read from (x + 0x1d0) for all commands? I've tried a lot of variations here, but nothing worked. Maybe some other parts of the code are still broken? > It seems the i440 might want the address bits inverted on > the high banks in some configurations, btw; so if it won't > work, you can try 0x1d0 ^ 0xff8 or so. Doesn't seem to work either. Attached my latest code and a minicom log... Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: raminit.c Type: text/x-csrc Size: 8686 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: minicom.cap Type: application/cap Size: 23194 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From uwe at hermann-uwe.de Sat Dec 2 14:53:06 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 2 Dec 2006 14:53:06 +0100 Subject: [LinuxBIOS] 440BX progress. In-Reply-To: <13426df10612010814r7aa1a550idc11ae8682377930@mail.gmail.com> References: <20061126165258.GA14839@greenwood> <6e22bb6c392468a0dd050b2f49ea98c8@kernel.crashing.org> <20061126210307.GA5102@greenwood> <20061130223748.GA25948@greenwood> <7BB313C6-6A90-41F1-9709-8F6B5B98911F@kernel.crashing.org> <13426df10612010814r7aa1a550idc11ae8682377930@mail.gmail.com> Message-ID: <20061202135305.GB15152@greenwood> On Fri, Dec 01, 2006 at 09:14:39AM -0700, ron minnich wrote: > Did you check the digitallogic board in V1 that uses 440bx? It used to > work ... I looked at the v1 440bx raminit code, as well as a bunch of v2 chipsets for pointers, but I can't seem to find what exactly the problem is. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ebiederm at xmission.com Sat Dec 2 15:02:57 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Sat, 02 Dec 2006 07:02:57 -0700 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: <5986589C150B2F49A46483AC44C7BCA490727C@ssvlexmb2.amd.com> (Yinghai Lu's message of "Fri, 1 Dec 2006 18:43:03 -0800") References: <5986589C150B2F49A46483AC44C7BCA490727C@ssvlexmb2.amd.com> Message-ID: "Lu, Yinghai" writes: > Thanks for the code. > > In LinuxBIOS, > I put usbdevice_direct.c in lib/, and call it from usb2_init in > mcp55_usb2.c > > Got > "No device in debug port" > > Waiting for cable, hope to get that cable next Tuesday. > > Will create usbdebug_direct_console.c in console/ for linuxbios_ram > code. > also usbdebug_direct_serial.c in pc80/ for cache_as_ram.c Please yank the direct out of the filename if you are making something like this out of it. That was my note I was going direct to hardware which is pretty much assumed if you are in LinuxBIOS. Eric From ebiederman at lnxi.com Sat Dec 2 15:47:52 2006 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Sat, 02 Dec 2006 07:47:52 -0700 Subject: [LinuxBIOS] romcc and preprocessor problems In-Reply-To: <4571496C.8040807@hewson-venieri.com> (Ben Hewson's message of "Sat, 02 Dec 2006 09:37:48 +0000") References: <20061201145240.GA3182@coresystems.de> <4571496C.8040807@hewson-venieri.com> Message-ID: Ben Hewson writes: > Hi Eric > > Please find attached some simple test cases. > These were compiled using the following > > > > ./romcc -O -fno-eliminate-inefectual-code > -I../../../../../src/arch/i386/include/ -o testdef3.inc testdef3.c > > if you look at testdef2.c, testdef2.inc you can see that a C++ comment > has caused one line to be missed, no comment or a C comment are fine. I > checked no comments, C comments and C++ comments on both the #if and > #else lines. The one thing I did not check was a C++ comment on the > #endif to see if the following line was missed. > > I may be missing needed options for romcc, but I have tried similar > tests in a proper build, with the same results. I took a quick look and it turns out the problem was the tokenizer was treating the newline as part of the EOL comment. This only showed up in the preprocessor because that really the only place that cares about seeing the EOL token separately from a space. Please test the attached patch. Thanks. Eric --- ../romcc-0.64/romcc.c 2006-12-02 07:39:11.000000000 -0700 +++ romcc.c 2006-12-02 07:41:23.000000000 -0700 @@ -4027,10 +4027,15 @@ tok = TOK_SPACE; tokp = next_char(file, tokp, 1); while((c = get_char(file, tokp)) != -1) { - tokp = next_char(file, tokp, 1); + /* Advance to the next character only after we verify + * the current character is not a newline. + * EOL is special to the preprocessor so we don't + * want to loose any. + */ if (c == '\n') { break; } + tokp = next_char(file, tokp, 1); } } /* Comments */ From shaddamcorrinoiv at gmail.com Sat Dec 2 15:54:44 2006 From: shaddamcorrinoiv at gmail.com (Shaddam Corrino IV) Date: Sat, 2 Dec 2006 15:54:44 +0100 Subject: [LinuxBIOS] Intel 815 In-Reply-To: References: <45691A54.8000008@verizon.net> Message-ID: I had a closer look at this i815 platform it contains : FW82815 FW82801BA SST49LF004A, which seems to be 512KiB flash Unfortunatelly, it seems that the above flash is soldered to the MBO :-( Does it mean there's no way I can use the system for L/B or is there some inexpensive way to correct this deficiency? Not sure if that's a good price, but you can get complete 1 GHZ i815 systems (ie ready for use desktop) here for about $65. -- Thanks! Shaddam IV -------------- next part -------------- An HTML attachment was scrubbed... URL: From svn at openbios.org Sat Dec 2 17:48:49 2006 From: svn at openbios.org (svn at openbios.org) Date: Sat, 02 Dec 2006 16:48:49 -0000 Subject: [LinuxBIOS] r2515 - trunk/LinuxBIOSv2/util/romcc Message-ID: Author: stepan Date: 2006-12-02 17:48:48 +0100 (Sat, 02 Dec 2006) New Revision: 2515 Modified: trunk/LinuxBIOSv2/util/romcc/romcc.c Log: fix romcc preprocessor bug Signed-off-by: Eric Biederman Acked-by: Stefan Reinauer Modified: trunk/LinuxBIOSv2/util/romcc/romcc.c =================================================================== --- trunk/LinuxBIOSv2/util/romcc/romcc.c 2006-12-01 15:25:21 UTC (rev 2514) +++ trunk/LinuxBIOSv2/util/romcc/romcc.c 2006-12-02 16:48:48 UTC (rev 2515) @@ -3,8 +3,8 @@ #undef RELEASE_DATE #undef VERSION #define VERSION_MAJOR "0" -#define VERSION_MINOR "68" -#define RELEASE_DATE "15 November 2004" +#define VERSION_MINOR "69" +#define RELEASE_DATE "02 December 2006" #define VERSION VERSION_MAJOR "." VERSION_MINOR #include @@ -4028,10 +4028,15 @@ tok = TOK_SPACE; tokp = next_char(file, tokp, 1); while((c = get_char(file, tokp)) != -1) { - tokp = next_char(file, tokp, 1); + /* Advance to the next character only after we verify + * the current character is not a newline. + * EOL is special to the preprocessor so we don't + * want to loose any. + */ if (c == '\n') { break; } + tokp = next_char(file, tokp, 1); } } /* Comments */ From corey_osgood at verizon.net Sat Dec 2 21:04:17 2006 From: corey_osgood at verizon.net (Corey Osgood) Date: Sat, 02 Dec 2006 15:04:17 -0500 Subject: [LinuxBIOS] Intel 815 Message-ID: <4571DC41.8000202@verizon.net> Shaddam Corrino IV wrote: > > I had a closer look at this i815 platform > > it contains : > > FW82815 > FW82801BA > SST49LF004A, which seems to be 512KiB flash > > Unfortunatelly, it seems that the above flash is soldered to the MBO :-( This is the case with the D815EEA, but other motherboards (probably not from intel) may have removable flash. I'm not really concerned with this, I ordered an extra plcc socket and a couple flash chips for this board when I ordered the flash chips for the athlon, and I don't think I'll have any problem with the sodiering process. If you've never used a sodiering iron before though, you might want to see if you can find someone to do it for you. > > Does it mean there's no way I can use the system for L/B or is there > some inexpensive way to correct this deficiency? > > Not sure if that's a good price, but you can get complete 1 GHZ i815 > systems (ie ready for use desktop) here for about $65. That's about what I paid for mine, just for the 1ghz cpu and mobo, then another $40 for 512mb PC133 and an asus P2-99 (440zx), and case/power supply/hard drive/cdrom from my collection. I've been following the discussion about i855 support, and that honestly has me concerned. This, if i remember right, was the first (well, second, but afaik it's just i810+graphics) desktop chipset intel made after ending the 440 line, so I don't know how good the docs will be (ie did intel decide to go into lockdown yet or no?), and if they suck royally, I probably won't bother messing around with this. -Corey Oops, forgot to cc the mailing list! From corey_osgood at verizon.net Sat Dec 2 21:10:02 2006 From: corey_osgood at verizon.net (Corey Osgood) Date: Sat, 02 Dec 2006 15:10:02 -0500 Subject: [LinuxBIOS] Intel 815 In-Reply-To: References: <45691A54.8000008@verizon.net> Message-ID: <4571DD9A.7050508@verizon.net> Just a quick thought regarding this, does anyone know if it would be possible to (easily) build a bios-savior-like device for such a case as this? I'm thinking something like this: connect two plcc sockets together, back to back, sodiering together all the connectors except chip enable and/or power. then, de-sodier those connectors from the existing chip. run wires to the motherboard on those lines, and also to a switch, and then also to the pair of plcc sockets. Then, fit a new "savior" chip into one of the sockets, and put the other one on top of the existing chip. Anyone think this would work? would sure save a heck of a lot of hassle. I haven't looked to see how the actual ioss bios savior does this yet, but I imagine it's something similar. -Corey From yinghailu at gmail.com Sat Dec 2 21:47:18 2006 From: yinghailu at gmail.com (yhlu) Date: Sat, 2 Dec 2006 12:47:18 -0800 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA490727C@ssvlexmb2.amd.com> Message-ID: <2ea3fae10612021247v33cfaa4evbc8ad1d5eaf196ba@mail.gmail.com> On 12/2/06, Eric W. Biederman wrote: > Please yank the direct out of the filename if you are making something > like this out of it. That was my note I was going direct to hardware > which is pretty much assumed if you are in LinuxBIOS. Yes, I adapted the code to used in LinuxBIOS, including CAR stage code and RAM satge code. I didn't have debug cable plugged yet. BTW in kernel earlyprintk or prink, you could use read_pci_config/write_pci_config before PCI system is loaded. YH From stepan at coresystems.de Sat Dec 2 23:23:20 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 2 Dec 2006 23:23:20 +0100 Subject: [LinuxBIOS] epia In-Reply-To: <456C6F41.7050001@hewson-venieri.com> References: <503ab0210611271554p11714a1ar61fa86fc1f6c6998@mail.gmail.com> <456BADBF.90208@verizon.net> <456C6F41.7050001@hewson-venieri.com> Message-ID: <20061202222320.GA19007@coresystems.de> * Ben Hewson [061128 18:17]: > The main problem with the EPIA board is that ROMCC misses the next line after > any #if or #else directive with a C++ style comment when compiling. It may also > miss the line after a #endif as well, I didn't check that. There are quite a > few in raminit.c that set various registers. Needless to say missing lines of > code is not good. > > If you either take out the C++ comments or change them to standard C comments > the raminit does mostly work. > > There are some problems which I havent got to the bottom of yet. Can you verify how far you get with the latest version of romcc? -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From rminnich at gmail.com Sun Dec 3 00:27:48 2006 From: rminnich at gmail.com (ron minnich) Date: Sat, 2 Dec 2006 16:27:48 -0700 Subject: [LinuxBIOS] Concepts for LX v3 In-Reply-To: <20061202192838.78a92d56.anton.borisov@gmail.com> References: <20061202192838.78a92d56.anton.borisov@gmail.com> Message-ID: <13426df10612021527p4fbc7b84jc1149cc4f177e447@mail.gmail.com> On 12/2/06, Anton wrote: > It would be nice to have TMS (Test Monitor System) onboard. Some big vendors have it on their systems for ages. > Pros: > a) Test for DRAM > b) Test for Media (HDD, CF, SD, ..) connected to the host > c) Test for Peripherals > Cons: > a) size. may not fit into 1/2/4 Mbit. > > TMS is a regular payload, access is done via RS232 (or USB in future), the same way as we all see printk messages nowdays. > However, it's not yet clear to me is it possible to have multiple payloads at once and how to choose between them. > Where to store boot options (CMOS is a way too small for it). > > Another concept to store big payloads which can't be stored in flash (even 16 Mbit is not enough) is to have > dedicated partition. On booting media. With FAT16 or use a very simple FS to avoid licensing problems (no journaling > features required). > > Pros: > a) bigger and more payload sources at once from one place > b) possibility to have several linuxbios images to be flashed back in case of emergency > Cons: > a) need to prepare boot media, like SATA/IDE device, to have dedicated partition > b) need to add support lines for FS on dedicated FS (however, I see FILO can boot ext2 partition, > hope this one will be enough). We're trying to keep linuxbios simple. A TMS payload is fine. Linux is the desired payload, and linux can do a very good job of testing all this stuff, and experience shows it has the best bug-fixed drivers. open firmware could also play this game, and OFW has a lot of drivers too -- more every day, now that it is open source. ron From segher at kernel.crashing.org Sun Dec 3 00:38:37 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 3 Dec 2006 00:38:37 +0100 Subject: [LinuxBIOS] 440BX progress. In-Reply-To: <20061202135029.GA15152@greenwood> References: <20061126165258.GA14839@greenwood> <6e22bb6c392468a0dd050b2f49ea98c8@kernel.crashing.org> <20061126210307.GA5102@greenwood> <20061130223748.GA25948@greenwood> <20061202135029.GA15152@greenwood> Message-ID: >> It looks reasonable. You want to shift by 3 though, not 23, >> not 15, so you read from 0x1d0 for writing to the MRS. > > OK, a few questions: > > * Do I read32() from somewhere for _every_ RAM command or only for > MRS? For every command. For commands other than "load MRS", you use address 0. > * The v1 code seems to read from the highest RAM address for each DRB > register. You need to do this init sequence for every rank of memory. Using each DRB gives you a lot of duplicates, which can be harmless; it can also give you 0 as the top-of-rank address (if the first ranks are empty) which is bad. > In my case: > Get contents of DRB6 (0x8), shift left by 23 as the DRB registers > store multiples of 8 MB, so I get my 64 MB. Correct? Yes. So you need to address somewhere between the previous rank top, and this 64MB. Using the _previous_ rank top as-is might be best. Example: rank 0 empty DRB=0 don't init rank 1 0..64MB-1 DRB=8 init @ 0 (+0x1d0) rank 2 64MB..128MB-1 DRB=16 init @ 64MB (+0x1d0) rank 3 empty DRB=16 don't init > Now; do I read32() from > * (8 << 23) > * (8 << 23) + 0x1d0 > * 0x0 + 0x1d0 > * 0x0 + 0x1d0 AND (8 << 23) + 0x1d0 > * 0x0 > * ??? You init exactly the memory that's there; nothing more, nothing less. A useful trick is to temporarily set the DRB registers such that the one rank under consideration is mapped to address 0, all the rest disabled; only later set the full "real" DRB map. This might or might not make the code simpler, your choice. > Do I read from x for most commands but from (x + 0x1d0) for MRS? > Or should I read from (x + 0x1d0) for all commands? x for most commands. The 0x1d0 actually is the data sent to the MRS reg on the memory; it is sent over the address lines. > I've tried a lot of variations here, but nothing worked. Maybe some > other parts of the code are still broken? Could be, hard to tell. > Attached my latest code and a minicom log... I'll see if I see anything. Segher From stuge-linuxbios at cdy.org Sun Dec 3 04:01:15 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Sun, 3 Dec 2006 04:01:15 +0100 Subject: [LinuxBIOS] Intel 815 In-Reply-To: <4571DD9A.7050508@verizon.net> References: <45691A54.8000008@verizon.net> <4571DD9A.7050508@verizon.net> Message-ID: <20061203030116.24152.qmail@cdy.org> On Sat, Dec 02, 2006 at 03:10:02PM -0500, Corey Osgood wrote: > I'm thinking something like this: connect two plcc sockets > together, back to back, sodiering together all the connectors > except chip enable and/or power. Sure, it will work just fine. I would suggest wiring between the two PLCC sockets however, since they're keyed and don't handle mirroring without help. Or - make a board for two SMT PLCC sockets. > then, de-sodier those connectors from the existing chip. run wires > to the motherboard on those lines, and also to a switch, and then > also to the pair of plcc sockets. I would probably let the switch control one of two AND gates per switched signal, the other input being the signal from mobo and output going to one socket each. //Peter From rminnich at gmail.com Sun Dec 3 05:00:27 2006 From: rminnich at gmail.com (ron minnich) Date: Sat, 2 Dec 2006 21:00:27 -0700 Subject: [LinuxBIOS] 440BX progress. In-Reply-To: References: <20061126165258.GA14839@greenwood> <6e22bb6c392468a0dd050b2f49ea98c8@kernel.crashing.org> <20061126210307.GA5102@greenwood> <20061130223748.GA25948@greenwood> <20061202135029.GA15152@greenwood> Message-ID: <13426df10612022000v4b9525a5qa856156dd0e949b8@mail.gmail.com> On 12/2/06, Segher Boessenkool wrote: > > * The v1 code seems to read from the highest RAM address for each DRB > > register. > > You need to do this init sequence for every rank of > memory. Using each DRB gives you a lot of duplicates, > which can be harmless; it can also give you 0 as the > top-of-rank address (if the first ranks are empty) > which is bad. no, not really duplicates, I think. You set up the DRBs for max size, you do all the DRAM setup, you size the actual RAM and reprogram the DRBs. This will work even if there is air in the socket. It ensures that a single DRB does not hit the same DRAM bank. ron From segher at kernel.crashing.org Sun Dec 3 11:53:59 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 3 Dec 2006 11:53:59 +0100 Subject: [LinuxBIOS] 440BX progress. In-Reply-To: <13426df10612022000v4b9525a5qa856156dd0e949b8@mail.gmail.com> References: <20061126165258.GA14839@greenwood> <6e22bb6c392468a0dd050b2f49ea98c8@kernel.crashing.org> <20061126210307.GA5102@greenwood> <20061130223748.GA25948@greenwood> <20061202135029.GA15152@greenwood> <13426df10612022000v4b9525a5qa856156dd0e949b8@mail.gmail.com> Message-ID: <52C2C5FD-D665-4AA4-8D62-4C888618D2CF@kernel.crashing.org> >> You need to do this init sequence for every rank of >> memory. Using each DRB gives you a lot of duplicates, >> which can be harmless; it can also give you 0 as the >> top-of-rank address (if the first ranks are empty) >> which is bad. > > no, not really duplicates, I think. You set up the DRBs for max size, > you do all the DRAM setup, you size the actual RAM and reprogram the > DRBs. This will work even if there is air in the socket. It ensures > that a single DRB does not hit the same DRAM bank. Yes, if you set up the DRBs so that no DRAM ranks are overlapping, you can program them all separately. This is the kind of thing people do if they cannot read the SPDs or just don't want to for some reason (many fuctory BIOSes do). At some later stage you'll have to program the DRBs properly; and you cannot change the config while the DRAM controller is active (even the i440 "specification update" warns against this) -- the kind of CPUs attached to this chip won't do any prefetch or similar, so you actually *can* make this work, but in principle it's a bad idea to change settings on a running memory controller. If you use the SPDs properly (or at all!), you really don't have to fall back to tricks like this. Segher From ebiederm at xmission.com Sun Dec 3 12:51:15 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Sun, 03 Dec 2006 04:51:15 -0700 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: <2ea3fae10612021247v33cfaa4evbc8ad1d5eaf196ba@mail.gmail.com> (yinghailu@gmail.com's message of "Sat, 2 Dec 2006 12:47:18 -0800") References: <5986589C150B2F49A46483AC44C7BCA490727C@ssvlexmb2.amd.com> <2ea3fae10612021247v33cfaa4evbc8ad1d5eaf196ba@mail.gmail.com> Message-ID: yhlu writes: > On 12/2/06, Eric W. Biederman wrote: >> Please yank the direct out of the filename if you are making something >> like this out of it. That was my note I was going direct to hardware >> which is pretty much assumed if you are in LinuxBIOS. > > Yes, I adapted the code to used in LinuxBIOS, including CAR stage code > and RAM satge code. > > I didn't have debug cable plugged yet. Even if you did it wouldn't work right now. My initial version does initialize the ehci properly so it won't find any usb devices. I almost have that fixed, but it looks like for the usb device reset I need a usable delay function, so I can delay 50ms. Grr... > BTW in kernel earlyprintk or prink, you could use > read_pci_config/write_pci_config before PCI system is loaded. Yep thanks that seems to be working. Now I just need to find an early delay and I can try this mess out! Eric From stepan at coresystems.de Sun Dec 3 13:01:30 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 3 Dec 2006 13:01:30 +0100 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA490727C@ssvlexmb2.amd.com> <2ea3fae10612021247v33cfaa4evbc8ad1d5eaf196ba@mail.gmail.com> Message-ID: <20061203120130.GA32458@coresystems.de> * Eric W. Biederman [061203 12:51]: > > BTW in kernel earlyprintk or prink, you could use > > read_pci_config/write_pci_config before PCI system is loaded. > > Yep thanks that seems to be working. Now I just need > to find an early delay and I can try this mess out! you could use io delay, one outb uses roughly 1us iirc. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From segher at kernel.crashing.org Sun Dec 3 13:42:07 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 3 Dec 2006 13:42:07 +0100 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: <20061203120130.GA32458@coresystems.de> References: <5986589C150B2F49A46483AC44C7BCA490727C@ssvlexmb2.amd.com> <2ea3fae10612021247v33cfaa4evbc8ad1d5eaf196ba@mail.gmail.com> <20061203120130.GA32458@coresystems.de> Message-ID: <77E505A2-6E0B-422F-92AB-97395730A522@kernel.crashing.org> > you could use io delay, one outb uses roughly 1us iirc. On LPC, yes -- or 0.5us or something like that. On ISA it's a lot faster, on PCI too -- better do 20 or so outb's to be safe. Or use a *real* timer instead, you'll have to abstract this for portability anyway... Segher From stepan at coresystems.de Sun Dec 3 13:52:50 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 3 Dec 2006 13:52:50 +0100 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: <77E505A2-6E0B-422F-92AB-97395730A522@kernel.crashing.org> References: <5986589C150B2F49A46483AC44C7BCA490727C@ssvlexmb2.amd.com> <2ea3fae10612021247v33cfaa4evbc8ad1d5eaf196ba@mail.gmail.com> <20061203120130.GA32458@coresystems.de> <77E505A2-6E0B-422F-92AB-97395730A522@kernel.crashing.org> Message-ID: <20061203125250.GA17019@coresystems.de> * Segher Boessenkool [061203 13:42]: > On LPC, yes -- or 0.5us or something like that. On ISA it's > a lot faster, on PCI too -- better do 20 or so outb's to be > safe. The value's actually something we have been using as a rule of thumb while doing outb to port 80. Don't think these are routed to LPC, are they? -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From ebiederm at xmission.com Sun Dec 3 14:11:57 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Sun, 03 Dec 2006 06:11:57 -0700 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: <20061203125250.GA17019@coresystems.de> (Stefan Reinauer's message of "Sun, 3 Dec 2006 13:52:50 +0100") References: <5986589C150B2F49A46483AC44C7BCA490727C@ssvlexmb2.amd.com> <2ea3fae10612021247v33cfaa4evbc8ad1d5eaf196ba@mail.gmail.com> <20061203120130.GA32458@coresystems.de> <77E505A2-6E0B-422F-92AB-97395730A522@kernel.crashing.org> <20061203125250.GA17019@coresystems.de> Message-ID: Stefan Reinauer writes: > * Segher Boessenkool [061203 13:42]: >> On LPC, yes -- or 0.5us or something like that. On ISA it's >> a lot faster, on PCI too -- better do 20 or so outb's to be >> safe. > > The value's actually something we have been using as a rule of thumb > while doing outb to port 80. Don't think these are routed to LPC, are > they? Depends on the destination address. For 0x80 you can be fairly certain it will be an unacknowledged cycle subtractively decoded to the slowest bus on the system. Or routed to 32 PCI or the LPC bus if there is something to actually looking at the value so it is slow. Since all I need is something that delays for about 50ms 50,000 outb to port 0x80 looks like a good first approximation, and since it only happens once it is probably better to just bump that count up instead of trying to be precise about it and have an accurate timer. I'm not at all convinced a usb console can be made sufficiently solid to be useful. But it is at least worth trying so we can clearly say it doesn't work well. Eric From ebiederm at xmission.com Sun Dec 3 16:49:47 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Sun, 03 Dec 2006 08:49:47 -0700 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: <20061201191916.GB3539@suse.de> (Greg KH's message of "Fri, 1 Dec 2006 11:19:16 -0800") References: <5986589C150B2F49A46483AC44C7BCA4907276@ssvlexmb2.amd.com> <20061201191916.GB3539@suse.de> Message-ID: Greg KH writes: > On Fri, Dec 01, 2006 at 10:55:48AM -0800, Lu, Yinghai wrote: >> -----Original Message----- >> From: Greg KH [mailto:gregkh at suse.de] >> >> >I can do that in about 15 minutes if you give me the device ids for the >> >usb debug device that you wish to have. >> >> >Or you can also use the generic usb-serial driver today just fine with >> >no modification. Have you had a problem with using that option? >> >> We are talking about using USB debug device/EHCI debug port in LinuxBIOS >> in legacy free PC. >> Because one AM2+MCP55 MB doesn't have serial port. >> >> I guess Eric is working on USB debug device/EHCI debug port for >> earlyprintk or printk. > > Well, earlyprintk will not work, as you need PCI up and running. *grin* I just generated the bootlog below. So I think I have it working. There is a lot of cleanup left and I need some sleep but it works for me. I will generate a patch to start the conversation after I wake up. > And I have some code that barely works for this already, perhaps Eric > and I should work together on this :) Eric Linux version 2.6.19-rc6devel (eric at fess.biederman.org) (gcc version 4.1.1 2006 0525 (Red Hat 4.1.1-1)) #153 SMP Sun Dec 3 07:56:52 MST 2006 Command line: ro root=LABEL=/ rhgb earlyprintk=dbgp console=tty0 console=ttyS0,1 15200 panic=30 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e6000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000009ffd0000 (usable) BIOS-e820: 000000009ffd0000 - 000000009ffde000 (ACPI data) BIOS-e820: 000000009ffde000 - 00000000a0000000 (ACPI NVS) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000ff780000 - 0000000100000000 (reserved) BIOS-e820: 0000000100000000 - 000000024c000000 (usable) end_pfn_map = 2408448 kernel direct mapping tables up to 24c000000 @ 8000-13000 DMI 2.3 present. SRAT: PXM 0 -> APIC 0 -> Node 0 SRAT: PXM 0 -> APIC 1 -> Node 0 SRAT: PXM 1 -> APIC 2 -> Node 1 SRAT: PXM 1 -> APIC 3 -> Node 1 SRAT: Node 0 PXM 0 100000-a0000000 SRAT: Node 1 PXM 1 14c000000-24c000000 SRAT: Node 0 PXM 0 100000-14c000000 SRAT: Node 0 PXM 0 0-14c000000 Bootmem setup node 0 0000000000000000-000000014c000000 Bootmem setup node 1 000000014c000000-000000024c000000 Zone PFN ranges: DMA 0 -> 4096 DMA32 4096 -> 1048576 Normal 1048576 -> 2408448 early_node_map[4] active PFN ranges 0: 0 -> 159 0: 256 -> 655312 0: 1048576 -> 1359872 1: 1359872 -> 2408448 Nvidia board detected. Ignoring ACPI timer override. If you got timer trouble try acpi_use_timer_override ACPI: PM-Timer IO Port: 0x4008 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) Processor #2 ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) Processor #3 ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 4, address 0xfec00000, GSI 0-23 ACPI: IOAPIC (id[0x05] address[0xdfefc000] gsi_base[24]) IOAPIC[1]: apic_id 5, address 0xdfefc000, GSI 24-47 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: BIOS IRQ0 pin2 override ignored. ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information Nosave address range: 000000000009f000 - 00000000000a0000 Nosave address range: 00000000000a0000 - 00000000000e6000 Nosave address range: 00000000000e6000 - 0000000000100000 Nosave address range: 000000009ffd0000 - 000000009ffde000 Nosave address range: 000000009ffde000 - 00000000a0000000 Nosave address range: 00000000a0000000 - 00000000fec00000 Nosave address range: 00000000fec00000 - 00000000fec01000 Nosave address range: 00000000fec01000 - 00000000fee00000 Nosave address range: 00000000fee00000 - 00000000fee01000 Nosave address range: 00000000fee01000 - 00000000ff780000 Nosave address range: 00000000ff780000 - 0000000100000000 Allocating PCI resources starting at a8000000 (gap: a0000000:5ec00000) PERCPU: Allocating 66560 bytes of per cpu data Built 2 zonelists. Total pages: 1960348 Kernel command line: ro root=LABEL=/ rhgb earlyprintk=dbgp console=tty0 console= ttyS0,115200 panic=30 Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) disabling early console From stuge-linuxbios at cdy.org Sun Dec 3 18:00:46 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Sun, 3 Dec 2006 18:00:46 +0100 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA4907276@ssvlexmb2.amd.com> <20061201191916.GB3539@suse.de> <20061201204249.28842.qmail@cdy.org> <20061201214631.6991.qmail@cdy.org> Message-ID: <20061203170046.28314.qmail@cdy.org> On Fri, Dec 01, 2006 at 04:02:03PM -0700, Eric W. Biederman wrote: > >> Sure, I will send it out shortly. I currently have a working > >> user space libusb thing (easy, but useful for my debug) > > > > Hm - for driving which end? > > Either. The specific device we are talking about doesn't care. Which device do you have? > > The debug port isn't really supposed to be used with anything but > > a debug device - which can't be enumerated normally anyway. > > It depends. If you have a debug cable with magic ends and a > hardcoded address of 127 the normal enumeration doesn't work. I > don't think anyone actually makes one of those. Only one of the ports on Stefan's PLX NET20DC that I had a look at during the LinuxBIOS symposium enumerated for me. > Debug devices are also allowed to be normal devices that just > support the debug descriptor. Which is what I'm working with. Aye. I would be happy if we could get something out, as you have done! :) Looking forward to trying it, I hope I get my device soon. //Peter From stuge-linuxbios at cdy.org Sun Dec 3 19:08:33 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Sun, 3 Dec 2006 19:08:33 +0100 Subject: [LinuxBIOS] SPD as debug channel In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> <20061201181602.7815.qmail@cdy.org> Message-ID: <20061203180833.5412.qmail@cdy.org> On Fri, Dec 01, 2006 at 11:21:15PM +0100, Segher Boessenkool wrote: > > If not, what IS easily accessible besides the boot ROM? > > In general? Nothing, not necessarily the boot ROM even! I was trying to think outside the box. Is there any way to affect the system in a way that is easy to measure? Power? Voltage? Any bit that is easy to tap works. It must not be intended for communication, a side-effect is fine, as long as it is portable. (Ie. certain instructions executed in a certain order => CPU draws more power.) A bit wild, but simple to implement. > >> I think that we are going into a world where we have to figure > >> out usb debug port. > > > > It's certainly one good debugging option but maybe not the only > > good one. > > And *all* these options require special (extra) debug hardware, > no good for the end user. We have to make sure the code never fails that early then. He-he. > >> I don't think that the PCI initial setup for USB debug is going to > >> be impossible -- the vendors have to debug these boards too. All > >> the boards I have used lately have a very straightforward path to > >> USB, that could be set up in the ROMCC or CAR code. > > > > I think it should be fairly simple on x86 too, > > It can't be done in a generic way. This is an interesting topic. See other thread about RAM. //Peter From stuge-linuxbios at cdy.org Sun Dec 3 19:28:05 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Sun, 3 Dec 2006 19:28:05 +0100 Subject: [LinuxBIOS] Generic framework for early PCI and RAM init? In-Reply-To: <32AA4BBA-BAAC-400C-B523-ADC6DF488DA5@kernel.crashing.org> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> <32AA4BBA-BAAC-400C-B523-ADC6DF488DA5@kernel.crashing.org> Message-ID: <20061203182805.8186.qmail@cdy.org> Turns out it's the same thread. On Fri, Dec 01, 2006 at 11:15:16PM +0100, Segher Boessenkool wrote: > > I don't think that the PCI initial setup for USB debug is going > > to be impossible > > It is possible, sure -- *per board*. Anything generic would > require a huge amount of code (and data). The low-level specifics of "init enough PCI to reach EHCI" and "init the DRAM controller" obviously differ between boards. Both these tasks will however share at least some code between boards. It would be nice if we could re-use code instead of having duplicates. For the EHCI PCI init I guess we will have to wait for experience and improve when we see problems, all I can come up with is that the early EHCI finder could use common PCI functions, which it probably already does. Perhaps we could do better with RAM init though. Would a RAM init API make sense? How different is SDRAM, DDR and DDR2 init on one controller compared to another? Do the controllers usually work in similar ways so that the higher level sequence of things to do is the same on them all? If so, it would be nice to encode these init sequences into lib/{sdram,ddr,ddr2} and make an API that the northbridge code has to implement. This is especially nice if there are many high-level steps. It will also help new ports and new porters a great deal since it wont be neccessary to learn all about RAM init before a new port - only how to do a certain task (eg. set CAS latency) on the given chipset, which may be easier to find in the data sheet, or from vendor support. Such an (internal) interface might make it easier for chipset vendors to support LinuxBIOS too. //Peter From rminnich at gmail.com Sun Dec 3 19:33:40 2006 From: rminnich at gmail.com (ron minnich) Date: Sun, 3 Dec 2006 11:33:40 -0700 Subject: [LinuxBIOS] 440BX progress. In-Reply-To: <52C2C5FD-D665-4AA4-8D62-4C888618D2CF@kernel.crashing.org> References: <20061126165258.GA14839@greenwood> <20061126210307.GA5102@greenwood> <20061130223748.GA25948@greenwood> <20061202135029.GA15152@greenwood> <13426df10612022000v4b9525a5qa856156dd0e949b8@mail.gmail.com> <52C2C5FD-D665-4AA4-8D62-4C888618D2CF@kernel.crashing.org> Message-ID: <13426df10612031033t484f2615w7d01c72af57a3969@mail.gmail.com> On 12/3/06, Segher Boessenkool wrote: > Yes, if you set up the DRBs so that no DRAM ranks are overlapping, > you can program them all separately. This is the kind of thing > people do if they cannot read the SPDs or just don't want to for > some reason (many fuctory BIOSes do). yes, this was very common on lots of V1 boards, even in SPD cases. The reason was that some dram setup could be done in assembly, but doing DRB in C was simpler. > > At some later stage you'll have to program the DRBs properly; and ah well some things you can. DRB is one of them. Of course, given an OS that can handle non-contiguous ram, there would never be a need to anything BUT size the DRB to max size. But that was not the case in 1999. > If you use the SPDs properly (or at all!), you really don't have > to fall back to tricks like this. certain tricks are ok if they simplify assembly. This was one of them in some cases IIRC. ron From stepan at coresystems.de Sun Dec 3 19:48:02 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 3 Dec 2006 19:48:02 +0100 Subject: [LinuxBIOS] Generic framework for early PCI and RAM init? In-Reply-To: <20061203182805.8186.qmail@cdy.org> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> <32AA4BBA-BAAC-400C-B523-ADC6DF488DA5@kernel.crashing.org> <20061203182805.8186.qmail@cdy.org> Message-ID: <20061203184802.GA12502@coresystems.de> * Peter Stuge [061203 19:28]: > Perhaps we could do better with RAM init though. > > Would a RAM init API make sense? > > How different is SDRAM, DDR and DDR2 init on one controller compared > to another? Do the controllers usually work in similar ways so that > the higher level sequence of things to do is the same on them all? Many things are different, but I think we could seriously gain from anything we can APIfy. DRAM init is our biggest time waster nowadays. > If so, it would be nice to encode these init sequences into > lib/{sdram,ddr,ddr2} and make an API that the northbridge code has to > implement. Yes!! -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From ebiederm at xmission.com Mon Dec 4 00:03:55 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Sun, 03 Dec 2006 16:03:55 -0700 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: <20061203170046.28314.qmail@cdy.org> (Peter Stuge's message of "Sun, 3 Dec 2006 18:00:46 +0100") References: <5986589C150B2F49A46483AC44C7BCA4907276@ssvlexmb2.amd.com> <20061201191916.GB3539@suse.de> <20061201204249.28842.qmail@cdy.org> <20061201214631.6991.qmail@cdy.org> <20061203170046.28314.qmail@cdy.org> Message-ID: Peter Stuge writes: > On Fri, Dec 01, 2006 at 04:02:03PM -0700, Eric W. Biederman wrote: >> >> Sure, I will send it out shortly. I currently have a working >> >> user space libusb thing (easy, but useful for my debug) >> > >> > Hm - for driving which end? >> >> Either. The specific device we are talking about doesn't care. > > Which device do you have? Well it is built by PLX, and from lsusb I see are: 0525:127a Netchip Technology, Inc. The hardware is a little rectangular pcb board a little smaller then a business card. Wrapped in a blue case, with vertical vents on both of the long sides, and gets a little warm when you have been running it for a while. The device has what appears to be 2 normal host to slave cables running into it. The picture at the bottom of: http://advdbg.org/blogs/advdbg_system/articles/64.aspx Looks like what I have. I'm curious about the whole plug both ends into the host before plugging it into the client, and about the strange target system BIOS requirements. I think I succeeded in making it work without out that by just putting in a reset. It does make the whole setup of the device a pain though. >> > The debug port isn't really supposed to be used with anything but >> > a debug device - which can't be enumerated normally anyway. >> >> It depends. If you have a debug cable with magic ends and a >> hardcoded address of 127 the normal enumeration doesn't work. I >> don't think anyone actually makes one of those. > > Only one of the ports on Stefan's PLX NET20DC that I had a look at > during the LinuxBIOS symposium enumerated for me. Very odd. I'm pretty certain we are talking same thing. But I do know it has a couple of weird quirks, so maybe you just ran up against that. >> Debug devices are also allowed to be normal devices that just >> support the debug descriptor. Which is what I'm working with. > > Aye. I would be happy if we could get something out, as you have > done! :) Looking forward to trying it, I hope I get my device soon. Well at least this means after it works I can probably forget about it and let someone else maintain the code ;) Eric From svn at openbios.org Mon Dec 4 00:46:37 2006 From: svn at openbios.org (svn at openbios.org) Date: Sun, 03 Dec 2006 23:46:37 -0000 Subject: [LinuxBIOS] r2516 - in trunk/LinuxBIOSv2/src/superio/ite: it8661f it8671f it8673f it8705f it8712f it8716f it8718f Message-ID: Author: uwe Date: 2006-12-04 00:46:36 +0100 (Mon, 04 Dec 2006) New Revision: 2516 Modified: trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f_early_serial.c Log: Remove #include from all *_early_serial.c ITE Super I/O files, as arch/romcc_io.h already #defines device_t, thus adding device/device.h breaks the build (trivial). Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Modified: trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f_early_serial.c 2006-12-02 16:48:48 UTC (rev 2515) +++ trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f_early_serial.c 2006-12-03 23:46:36 UTC (rev 2516) @@ -19,7 +19,6 @@ */ #include -#include #include "it8661f.h" /* The base address is 0x3f0, 0x3bd, or 0x370, depending on config bytes. */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f_early_serial.c 2006-12-02 16:48:48 UTC (rev 2515) +++ trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f_early_serial.c 2006-12-03 23:46:36 UTC (rev 2516) @@ -19,7 +19,6 @@ */ #include -#include #include "it8671f.h" /* The base address is 0x3f0, 0x3bd, or 0x370, depending on config bytes. */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f_early_serial.c 2006-12-02 16:48:48 UTC (rev 2515) +++ trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f_early_serial.c 2006-12-03 23:46:36 UTC (rev 2516) @@ -19,7 +19,6 @@ */ #include -#include #include "it8673f.h" /* The base address is 0x3f0, 0x3bd, or 0x370, depending on config bytes. */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c 2006-12-02 16:48:48 UTC (rev 2515) +++ trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c 2006-12-03 23:46:36 UTC (rev 2516) @@ -19,7 +19,6 @@ */ #include -#include #include "it8705f.h" /* The base address is 0x2e or 0x4e, depending on config bytes. */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c 2006-12-02 16:48:48 UTC (rev 2515) +++ trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c 2006-12-03 23:46:36 UTC (rev 2516) @@ -19,7 +19,6 @@ */ #include -#include #include "it8712f.h" /* The base address is 0x2e or 0x4e, depending on config bytes. */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c 2006-12-02 16:48:48 UTC (rev 2515) +++ trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c 2006-12-03 23:46:36 UTC (rev 2516) @@ -19,7 +19,6 @@ */ #include -#include #include "it8716f.h" /* The base address is 0x2e or 0x4e, depending on config bytes. */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f_early_serial.c 2006-12-02 16:48:48 UTC (rev 2515) +++ trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f_early_serial.c 2006-12-03 23:46:36 UTC (rev 2516) @@ -19,7 +19,6 @@ */ #include -#include #include "it8718f.h" /* The base address is 0x2e or 0x4e, depending on config bytes. */ From svn at openbios.org Mon Dec 4 00:50:12 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 03 Dec 2006 23:50:12 -0000 Subject: [LinuxBIOS] #58: abuild: Fails for iwill/dk8_htx due to hardcoded paths Message-ID: <060.9b7546c925ea48fe642b823478637e26@openbios.org> #58: abuild: Fails for iwill/dk8_htx due to hardcoded paths ---------------------------------+------------------------------------------ Reporter: uwe | Owner: stepan Type: defect | Status: new Priority: major | Milestone: Component: testsystem | Version: v2 Keywords: abuild | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ When invoking 'abuild' manually it fails due to some hardcoded paths. {{{ Processing mainboard/iwill/dk8_htx (i386: ok) Using existing test target /home/uwe/code/linuxbios/repos/trunk/LinuxBIOSv2/targets/iwill/dk8_htx /Config-abuild.lb ok Creating builddir...ok Compiling image ..FAILED after 3s! Log excerpt: nm -n linuxbios | sort > linuxbios.map objcopy --gap-fill 0xff -O binary linuxbios linuxbios.strip make[1]: *** No rule to make target `/home/stepan/svn/LinuxBIOSv2/util/abuild/LinuxBIOS- payloads/payloads/default/filo-0.5.0.elf', needed by `payload.lzma'. Stop. make[1]: Leaving directory `/home/uwe/code/linuxbios/repos/trunk/LinuxBIOSv2/util/abuild/linuxbios- builds/iwill_dk8_htx/normal' make: *** [normal/linuxbios.rom] Error 1 }}} -- Ticket URL: LinuxBIOS From segher at kernel.crashing.org Mon Dec 4 01:40:47 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Mon, 4 Dec 2006 01:40:47 +0100 Subject: [LinuxBIOS] 440BX progress. In-Reply-To: <13426df10612031033t484f2615w7d01c72af57a3969@mail.gmail.com> References: <20061126165258.GA14839@greenwood> <20061126210307.GA5102@greenwood> <20061130223748.GA25948@greenwood> <20061202135029.GA15152@greenwood> <13426df10612022000v4b9525a5qa856156dd0e949b8@mail.gmail.com> <52C2C5FD-D665-4AA4-8D62-4C888618D2CF@kernel.crashing.org> <13426df10612031033t484f2615w7d01c72af57a3969@mail.gmail.com> Message-ID: <115DADD4-13DA-438F-92C0-D9CB19B55B87@kernel.crashing.org> > Of course, given an OS that can handle non-contiguous ram, there would > never be a need to anything BUT size the DRB to max size. But that was > not the case in 1999. There's no _need_ sure, but the result is pretty nasty: say, a DRB is set up for 128MB, but the DIMM it covers is only 64MB; then any access to the "high half" of the DRB aliases to the lower addresses. Not a problem /an sich/, but it makes certain problems hard to debug. >> If you use the SPDs properly (or at all!), you really don't have >> to fall back to tricks like this. > > certain tricks are ok if they simplify assembly. This was one of them > in some cases IIRC. Yeah, I know what you're saying. But if you don't use assembler code, please let's not do too many tricks (you can take this argument and apply it to my code too, promise :-) ) Segher From segher at kernel.crashing.org Mon Dec 4 01:47:09 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Mon, 4 Dec 2006 01:47:09 +0100 Subject: [LinuxBIOS] SPD as debug channel In-Reply-To: <20061203180833.5412.qmail@cdy.org> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> <20061201181602.7815.qmail@cdy.org> <20061203180833.5412.qmail@cdy.org> Message-ID: <4302B116-9CF4-4A81-B38C-F6B118CA58BA@kernel.crashing.org> >> And *all* these options require special (extra) debug hardware, >> no good for the end user. > > We have to make sure the code never fails that early then. He-he. That is of course the plan, but we all know that problems _will_ show up (not often hopefully), for example, a user has a hardware configuration that we never thought of (or didn't test on, at least); it would be quite helpful to get some debug data out in such a case. That being so hard, I guess we have to focus on making our code as bullet-proof as possible; i.e., even if half the hardware setup fails, make sure the rest works irrespectively, so we get the debug text out. Segher From segher at kernel.crashing.org Mon Dec 4 02:01:21 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Mon, 4 Dec 2006 02:01:21 +0100 Subject: [LinuxBIOS] Generic framework for early PCI and RAM init? In-Reply-To: <20061203182805.8186.qmail@cdy.org> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> <32AA4BBA-BAAC-400C-B523-ADC6DF488DA5@kernel.crashing.org> <20061203182805.8186.qmail@cdy.org> Message-ID: <8334A12A-947E-4973-B080-FE43816048C0@kernel.crashing.org> > The low-level specifics of "init enough PCI to reach EHCI" and "init > the DRAM controller" obviously differ between boards. > > Both these tasks will however share at least some code between > boards. It would be nice if we could re-use code instead of having > duplicates. Yes. > For the EHCI PCI init I guess we will have to wait for experience and > improve when we see problems, Yes -- it helps to think about the problem before coding it, and to discuss the problems, though. Which we did. Let's move on now :-) > Perhaps we could do better with RAM init though. > > Would a RAM init API make sense? > > How different is SDRAM, DDR and DDR2 init on one controller compared > to another? Very different. > Do the controllers usually work in similar ways so that > the higher level sequence of things to do is the same on them all? Well the signals on the actual DIMM bus end up being very similar; the registers to set, and what they do, vary wildly. > If so, it would be nice to encode these init sequences into > lib/{sdram,ddr,ddr2} and make an API that the northbridge code has to > implement. An API that the memory controller code has to implement isn't going to work. Having a bunch of helper functions that the memory controller code can call as it wishes, is a good plan though. > This is especially nice if there are many high-level steps. It will > also help new ports and new porters a great deal since it wont be > neccessary to learn all about RAM init before a new port - To successfully (and correctly!) program any memory controller, you really have to know both how the supported memory types work, and how the specific memory controller works. In detail. > only how > to do a certain task (eg. set CAS latency) on the given chipset, > which may be easier to find in the data sheet, or from vendor > support. Such an (internal) interface might make it easier for > chipset vendors to support LinuxBIOS too. It sure would help porting to have many nice helper hooks, and to have a clear overview what a new port should look like (a flowchart, or some pseudo code; or we can just point to some port and say "this one is really good"). We shouldn't make the framework too stringent as boards/systems really do vary *wildly*. Segher From rminnich at gmail.com Mon Dec 4 03:09:13 2006 From: rminnich at gmail.com (ron minnich) Date: Sun, 3 Dec 2006 19:09:13 -0700 Subject: [LinuxBIOS] 440BX progress. In-Reply-To: <115DADD4-13DA-438F-92C0-D9CB19B55B87@kernel.crashing.org> References: <20061126165258.GA14839@greenwood> <20061130223748.GA25948@greenwood> <20061202135029.GA15152@greenwood> <13426df10612022000v4b9525a5qa856156dd0e949b8@mail.gmail.com> <52C2C5FD-D665-4AA4-8D62-4C888618D2CF@kernel.crashing.org> <13426df10612031033t484f2615w7d01c72af57a3969@mail.gmail.com> <115DADD4-13DA-438F-92C0-D9CB19B55B87@kernel.crashing.org> Message-ID: <13426df10612031809u68819f3aj6cc01a1ac1728f74@mail.gmail.com> On 12/3/06, Segher Boessenkool wrote: > > Of course, given an OS that can handle non-contiguous ram, there would > > never be a need to anything BUT size the DRB to max size. But that was > > not the case in 1999. > > There's no _need_ sure, but the result is pretty nasty: say, a DRB > is set up for 128MB, but the DIMM it covers is only 64MB; then any > access to the "high half" of the DRB aliases to the lower addresses. > Not a problem /an sich/, but it makes certain problems hard to debug. no, because the e820 tables or whatever would set up a set of regions of memory. OS would never access the memory that does not exist. ron From uwe at hermann-uwe.de Mon Dec 4 03:39:59 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Mon, 4 Dec 2006 03:39:59 +0100 Subject: [LinuxBIOS] Generic framework for early PCI and RAM init? In-Reply-To: <8334A12A-947E-4973-B080-FE43816048C0@kernel.crashing.org> References: <5986589C150B2F49A46483AC44C7BCA4907266@ssvlexmb2.amd.com> <456F77BC.4080107@onelabs.com> <456F7FDB.5090802@gmail.com> <456F890F.9090503@onelabs.com> <20061201113025.13793.qmail@cdy.org> <13426df10612010810u104a6604n361036b0e1d9e210@mail.gmail.com> <32AA4BBA-BAAC-400C-B523-ADC6DF488DA5@kernel.crashing.org> <20061203182805.8186.qmail@cdy.org> <8334A12A-947E-4973-B080-FE43816048C0@kernel.crashing.org> Message-ID: <20061204023959.GB27917@greenwood> On Mon, Dec 04, 2006 at 02:01:21AM +0100, Segher Boessenkool wrote: > > Both these tasks will however share at least some code between > > boards. It would be nice if we could re-use code instead of having > > duplicates. > > Yes. Yes. > An API that the memory controller code has to implement isn't > going to work. Having a bunch of helper functions that the > memory controller code can call as it wishes, is a good plan > though. Yes, I agree. For example there are lots of very similar functions in current raminit.c implementations which deal mostly only with SPD registers and don't even access any controller registers. Those are perfect candidates to go into lib/spd or something. But yes, we must make sure that we do not hard-code anything which might work differently on more exotic systems... > > only how > > to do a certain task (eg. set CAS latency) on the given chipset, > > which may be easier to find in the data sheet, or from vendor > > support. Such an (internal) interface might make it easier for > > chipset vendors to support LinuxBIOS too. > > It sure would help porting to have many nice helper hooks, and > to have a clear overview what a new port should look like (a > flowchart Yeah, that would be a nice addition for the wiki. As for an API/flowchart, I currently only know of this very tiny "API" from src/sdram/generic_sdram.c: In auto.c (per-mainboard) you call * sdram_initialize(sizeof(cpu)/sizeof(cpu[0]), cpu); This, in turn, calls three functions which must be implemented by any raminit.c AFAIK: * sdram_set_registers() * sdram_set_spd_registers() * sdram_enable() Something similar, and more elaborate, for other types of RAM would be nice. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ebiederm at xmission.com Mon Dec 4 06:09:08 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Sun, 03 Dec 2006 22:09:08 -0700 Subject: [LinuxBIOS] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: (Eric W. Biederman's message of "Sun, 03 Dec 2006 08:49:47 -0700") References: <5986589C150B2F49A46483AC44C7BCA4907276@ssvlexmb2.amd.com> <20061201191916.GB3539@suse.de> Message-ID: With legacy free systems serial ports have stopped being an option to get early boot traces and other debug information out of a machine. EHCI USB controllers provide a relatively simple debug interface that can control port 1 of the root hub. This interface is limited to 8 byte packets so it can be used with most USB devices. But with a USB debug device this is sufficient to talk to another machine. When the special feature of the EHCI is not enabled the port 1 of the root hub acts just like any other USB port so machines with the necessary support are widely available. This debug device can be used to replace serial ports for kgdb, kdb, and console support. And gregkh has a simple usb serial driver for it so user space applications that control serial ports should work unmodified. Currently there only appears to be one manufacturer of debug devices see: http://www.plxtech.com/products/NET2000/NET20DC/default.asp I think simple RS232 serial ports provide a nicer and simpler interface but the usb debug port looks like a functional alternative when you don't have that. My code likely doesn't handle all of the corner cases yet, and needs a little more work to integrate cleanly into the build. But this is getting it out there so other people can look and help make clean drivers. When writing a polling driver you do have to be careful with your logic, because if you do things like reset a usb device at the wrong time you can completely confuse various EHCI controllers. My driver should be sufficient to work with any EHCI in a realatively clean state, and needs no special BIOS support just the hardware. This appears to be different than the way the windows drivers are using these debug devices. Eric From ebiederm at xmission.com Mon Dec 4 06:13:57 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Sun, 03 Dec 2006 22:13:57 -0700 Subject: [LinuxBIOS] [RFC][PATCH 1/2] x86_64: Preallocate the fixmap pud and pmd entries. In-Reply-To: (Eric W. Biederman's message of "Sun, 03 Dec 2006 22:09:08 -0700") References: <5986589C150B2F49A46483AC44C7BCA4907276@ssvlexmb2.amd.com> <20061201191916.GB3539@suse.de> Message-ID: To use the debug device I need to work through a port so I need to call ioreamp or similar. Since we are doing this very early I chose to use a fixmap (because we are unlikely to free the mapping) and because it is simple. If we preallocate the fixmap pud and pmd entries the existing fixmap codes works anytime from power up without modifications or memory allocations. So we don't need a special case. --- arch/x86_64/kernel/head.S | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/arch/x86_64/kernel/head.S b/arch/x86_64/kernel/head.S index 2f65469..4004965 100644 --- a/arch/x86_64/kernel/head.S +++ b/arch/x86_64/kernel/head.S @@ -271,7 +271,16 @@ NEXT_PAGE(level3_kernel_pgt) .fill 510,8,0 /* (2^48-(2*1024*1024*1024)-((2^39)*511))/(2^30) = 510 */ .quad phys_level2_kernel_pgt | 0x007 - .fill 1,8,0 + .quad phys_level2_fixmap_pgt | 0x007 + +NEXT_PAGE(level2_fixmap_pgt) + .fill 506,8,0 + .quad phys_level1_fixmap_pgt | 0x007 + /* 8MB reserved for vsyscalls + a 2MB hole = 4 + 1 entries */ + .fill 5,8,0 + +NEXT_PAGE(level1_fixmap_pgt) + .fill 512,8,0 NEXT_PAGE(level2_ident_pgt) /* 40MB for bootup. */ -- 1.4.2.rc3.g7e18e-dirty From ebiederm at xmission.com Mon Dec 4 06:18:01 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Sun, 03 Dec 2006 22:18:01 -0700 Subject: [LinuxBIOS] [RFC][PATCH 2/2] x86_64: earlyprintk usb debug device support. In-Reply-To: (Eric W. Biederman's message of "Sun, 03 Dec 2006 22:13:57 -0700") References: <5986589C150B2F49A46483AC44C7BCA4907276@ssvlexmb2.amd.com> <20061201191916.GB3539@suse.de> Message-ID: This patch is still a little rough but it gets all of the major pieces correct. With a little more work this should become a maintainable driver. In particular I believe the ehci debug port code is fairly solid (with rough edges). However there are several nasty bits that need to be resolved before we can push this upstream. Like my include of ehci.h And general early kernel space dependency problems. But the code works for me so it should at least be a reasonable starting point for others looking to make the debug port work in a reasonable fashion. Signed-off-by: Eric W. Biederman --- arch/x86_64/kernel/early_printk.c | 574 +++++++++++++++++++++++++++++++++++++ drivers/usb/host/ehci.h | 8 + include/asm-x86_64/fixmap.h | 1 3 files changed, 583 insertions(+), 0 deletions(-) diff --git a/arch/x86_64/kernel/early_printk.c b/arch/x86_64/kernel/early_printk.c index d4050a5..cb5182d 100644 --- a/arch/x86_64/kernel/early_printk.c +++ b/arch/x86_64/kernel/early_printk.c @@ -3,9 +3,19 @@ #include #include #include #include +#include +#include +#include +#include #include #include #include +#include +#include +#include +#define EARLY_PRINTK +#include "../../../drivers/usb/host/ehci.h" + /* Simple VGA output */ @@ -155,6 +165,558 @@ static struct console early_serial_conso .index = -1, }; + +static struct ehci_caps __iomem *ehci_caps; +static struct ehci_regs __iomem *ehci_regs; +static struct ehci_dbg_port __iomem *ehci_debug; +static unsigned dbgp_endpoint_out; + +#define USB_DEBUG_DEVNUM 127 + +#define DBGP_DATA_TOGGLE 0x8800 +#define DBGP_PID_UPDATE(x, tok) \ + ((((x) ^ DBGP_DATA_TOGGLE) & 0xffff00) | ((tok) & 0xff)) + +#define DBGP_LEN_UPDATE(x, len) (((x) & ~0x0f) | ((len) & 0x0f)) +/* + * USB Packet IDs (PIDs) + */ + +/* token */ +#define USB_PID_OUT 0xe1 +#define USB_PID_IN 0x69 +#define USB_PID_SOF 0xa5 +#define USB_PID_SETUP 0x2d +/* handshake */ +#define USB_PID_ACK 0xd2 +#define USB_PID_NAK 0x5a +#define USB_PID_STALL 0x1e +#define USB_PID_NYET 0x96 +/* data */ +#define USB_PID_DATA0 0xc3 +#define USB_PID_DATA1 0x4b +#define USB_PID_DATA2 0x87 +#define USB_PID_MDATA 0x0f +/* Special */ +#define USB_PID_PREAMBLE 0x3c +#define USB_PID_ERR 0x3c +#define USB_PID_SPLIT 0x78 +#define USB_PID_PING 0xb4 +#define USB_PID_UNDEF_0 0xf0 + +#define USB_PID_DATA_TOGGLE 0x88 +#define DBGP_CLAIM (DBGP_OWNER | DBGP_ENABLED | DBGP_INUSE) + +#define PCI_CAP_ID_EHCI_DEBUG 0xa + +#define HUB_ROOT_RESET_TIME 50 /* times are in msec */ +#define HUB_SHORT_RESET_TIME 10 +#define HUB_LONG_RESET_TIME 200 +#define HUB_RESET_TIMEOUT 500 + +#define DBGP_MAX_PACKET 8 + +static int dbgp_wait_until_complete(void) +{ + unsigned ctrl; + for (;;) { + ctrl = readl(&ehci_debug->control); + /* Stop when the transaction is finished */ + if (ctrl & DBGP_DONE) + break; + } + /* Now that we have observed the completed transaction, + * clear the done bit. + */ + writel(ctrl | DBGP_DONE, &ehci_debug->control); + return (ctrl & DBGP_ERROR) ? -DBGP_ERRCODE(ctrl) : DBGP_LEN(ctrl); +} + +static void dbgp_mdelay(int ms) +{ + int i; + while (ms--) { + for (i = 0; i < 1000; i++) + outb(0x1, 0x80); + } +} + +static void dbgp_breath(void) +{ + /* Sleep to give the debug port a chance to breathe */ +} + +static int dbgp_wait_until_done(unsigned ctrl) +{ + unsigned pids, lpid; + int ret; + +retry: + writel(ctrl | DBGP_GO, &ehci_debug->control); + ret = dbgp_wait_until_complete(); + pids = readl(&ehci_debug->pids); + lpid = DBGP_PID_GET(pids); + + if (ret < 0) + return ret; + + /* If the port is getting full or it has dropped data + * start pacing ourselves, not necessary but it's friendly. + */ + if ((lpid == USB_PID_NAK) || (lpid == USB_PID_NYET)) + dbgp_breath(); + + /* If I get a NACK reissue the transmission */ + if (lpid == USB_PID_NAK) + goto retry; + + return ret; +} + +static void dbgp_set_data(const void *buf, int size) +{ + const unsigned char *bytes = buf; + unsigned lo, hi; + int i; + lo = hi = 0; + for (i = 0; i < 4 && i < size; i++) + lo |= bytes[i] << (8*i); + for (; i < 8 && i < size; i++) + hi |= bytes[i] << (8*(i - 4)); + writel(lo, &ehci_debug->data03); + writel(hi, &ehci_debug->data47); +} + +static void dbgp_get_data(void *buf, int size) +{ + unsigned char *bytes = buf; + unsigned lo, hi; + int i; + lo = readl(&ehci_debug->data03); + hi = readl(&ehci_debug->data47); + for (i = 0; i < 4 && i < size; i++) + bytes[i] = (lo >> (8*i)) & 0xff; + for (; i < 8 && i < size; i++) + bytes[i] = (hi >> (8*(i - 4))) & 0xff; +} + +static int dbgp_bulk_write(unsigned devnum, unsigned endpoint, const char *bytes, int size) +{ + unsigned pids, addr, ctrl; + int ret; + if (size > DBGP_MAX_PACKET) + return -1; + + addr = DBGP_EPADDR(devnum, endpoint); + + pids = readl(&ehci_debug->pids); + pids = DBGP_PID_UPDATE(pids, USB_PID_OUT); + + ctrl = readl(&ehci_debug->control); + ctrl = DBGP_LEN_UPDATE(ctrl, size); + ctrl |= DBGP_OUT; + ctrl |= DBGP_GO; + + dbgp_set_data(bytes, size); + writel(addr, &ehci_debug->address); + writel(pids, &ehci_debug->pids); + + ret = dbgp_wait_until_done(ctrl); + if (ret < 0) { + return ret; + } + return ret; +} + +static int dbgp_bulk_read(unsigned devnum, unsigned endpoint, void *data, int size) +{ + unsigned pids, addr, ctrl; + int ret; + + if (size > DBGP_MAX_PACKET) + return -1; + + addr = DBGP_EPADDR(devnum, endpoint); + + pids = readl(&ehci_debug->pids); + pids = DBGP_PID_UPDATE(pids, USB_PID_IN); + + ctrl = readl(&ehci_debug->control); + ctrl = DBGP_LEN_UPDATE(ctrl, size); + ctrl &= ~DBGP_OUT; + ctrl |= DBGP_GO; + + writel(addr, &ehci_debug->address); + writel(pids, &ehci_debug->pids); + ret = dbgp_wait_until_done(ctrl); + if (ret < 0) + return ret; + if (size > ret) + size = ret; + dbgp_get_data(data, size); + return ret; +} + +static int dbgp_control_msg(unsigned devnum, int requesttype, int request, + int value, int index, void *data, int size) +{ + unsigned pids, addr, ctrl; + struct usb_ctrlrequest req; + int read; + int ret; + + read = (requesttype & USB_DIR_IN) != 0; + if (size > (read?DBGP_MAX_PACKET:0)) + return -1; + + /* Compute the control message */ + req.bRequestType = requesttype; + req.bRequest = request; + req.wValue = value; + req.wIndex = index; + req.wLength = size; + + pids = DBGP_PID_SET(USB_PID_DATA0, USB_PID_SETUP); + addr = DBGP_EPADDR(devnum, 0); + + ctrl = readl(&ehci_debug->control); + ctrl = DBGP_LEN_UPDATE(ctrl, sizeof(req)); + ctrl |= DBGP_OUT; + ctrl |= DBGP_GO; + + /* Send the setup message */ + dbgp_set_data(&req, sizeof(req)); + writel(addr, &ehci_debug->address); + writel(pids, &ehci_debug->pids); + ret = dbgp_wait_until_done(ctrl); + if (ret < 0) + return ret; + + + /* Read the result */ + ret = dbgp_bulk_read(devnum, 0, data, size); + return ret; +} + + +/* Find a PCI capability */ +static __u32 __init find_cap(int num, int slot, int func, int cap) +{ + u8 pos; + int bytes; + if (!(read_pci_config_16(num,slot,func,PCI_STATUS) & PCI_STATUS_CAP_LIST)) + return 0; + pos = read_pci_config_byte(num,slot,func,PCI_CAPABILITY_LIST); + for (bytes = 0; bytes < 48 && pos >= 0x40; bytes++) { + u8 id; + pos &= ~3; + id = read_pci_config_byte(num,slot,func,pos+PCI_CAP_LIST_ID); + if (id == 0xff) + break; + if (id == cap) + return pos; + pos = read_pci_config_byte(num,slot,func,pos+PCI_CAP_LIST_NEXT); + } + return 0; +} + +static __u32 __init find_dbgp(int ehci_num, unsigned *rbus, unsigned *rslot, unsigned *rfunc) +{ + unsigned bus, slot, func; + + for (bus = 0; bus < 256; bus++) { + for (slot = 0; slot < 32; slot++) { + for (func = 0; func < 8; func++) { + u32 class; + unsigned cap; + class = read_pci_config(bus, slot, func, PCI_CLASS_REVISION); + if ((class >> 8) != PCI_CLASS_SERIAL_USB_EHCI) + continue; + cap = find_cap(bus, slot, func, PCI_CAP_ID_EHCI_DEBUG); + if (!cap) + continue; + if (ehci_num-- != 0) + continue; + *rbus = bus; + *rslot = slot; + *rfunc = func; + return cap; + } + } + } + return 0; +} + +static int ehci_reset_port(int port) +{ + unsigned portsc; + unsigned delay_time, delay; + + /* Reset the usb debug port */ + portsc = readl(&ehci_regs->port_status[port - 1]); + portsc &= ~PORT_PE; + portsc |= PORT_RESET; + writel(portsc, &ehci_regs->port_status[port - 1]); + + delay = HUB_ROOT_RESET_TIME; + for (delay_time = 0; delay_time < HUB_RESET_TIMEOUT; + delay_time += delay) { + dbgp_mdelay(delay); + + portsc = readl(&ehci_regs->port_status[port - 1]); + if (portsc & PORT_RESET) { + /* force reset to complete */ + writel(portsc & ~(PORT_RWC_BITS | PORT_RESET), + &ehci_regs->port_status[port - 1]); + while (portsc & PORT_RESET) + portsc = readl(&ehci_regs->port_status[port - 1]); + } + + /* Device went away? */ + if (!(portsc & PORT_CONNECT)) + return -ENOTCONN; + + /* bomb out completely if something weird happend */ + if ((portsc & PORT_CSC)) + return -EINVAL; + + /* If we've finished resetting, then break out of the loop */ + if (!(portsc & PORT_RESET) && (portsc & PORT_PE)) + return 0; + } + return -EBUSY; +} + +static int ehci_wait_for_port(int port) +{ + unsigned status; + int ret, reps; + for (reps = 0; reps >= 0; reps++) { + status = readl(&ehci_regs->status); + if (status & STS_PCD) { + ret = ehci_reset_port(port); + if (ret == 0) + return 0; + } + } + return -ENOTCONN; +} + + +#define DBGP_DEBUG 0 +#if DBGP_DEBUG +void early_printk(const char *fmt, ...); +# define dbgp_printk early_printk +#else +static inline void dbgp_printk(const char *fmt, ...) { } +#endif + +static int ehci_setup(void) +{ + unsigned cmd, ctrl, status, portsc, hcs_params, debug_port, n_ports; + int ret; + int i; + + hcs_params = readl(&ehci_caps->hcs_params); + debug_port = HCS_DEBUG_PORT(hcs_params); + n_ports = HCS_N_PORTS(hcs_params); + + dbgp_printk("debug_port: %d\n", debug_port); + dbgp_printk("n_ports: %d\n", n_ports); + + /* Reset the EHCI controller */ + cmd = readl(&ehci_regs->command); + cmd |=CMD_RESET; + writel(cmd, &ehci_regs->command); + while (cmd & CMD_RESET) + cmd = readl(&ehci_regs->command); + + /* Claim ownership, but do not enable yet */ + ctrl = readl(&ehci_debug->control); + ctrl |= DBGP_OWNER; + ctrl &= ~(DBGP_ENABLED | DBGP_INUSE); + writel(ctrl, &ehci_debug->control); + + /* Start the ehci running */ + cmd = readl(&ehci_regs->command); + cmd &= ~(CMD_LRESET | CMD_IAAD | CMD_PSE | CMD_ASE | CMD_RESET); + cmd |= CMD_RUN; + writel(cmd, &ehci_regs->command); + + /* Ensure everything is routed to the EHCI */ + writel(FLAG_CF, &ehci_regs->configured_flag); + + /* Wait until the controller is no longer halted */ + do { + status = readl(&ehci_regs->status); + } while (status & STS_HALT); + + /* Wait for a device to show up in the debug port */ + ret = ehci_wait_for_port(debug_port); + if (ret < 0) { + dbgp_printk("No device found in debug port\n"); + return -1; + } + + /* Enable the debug port */ + ctrl = readl(&ehci_debug->control); + ctrl |= DBGP_CLAIM; + writel(ctrl, &ehci_debug->control); + ctrl = readl(&ehci_debug->control); + if ((ctrl & DBGP_CLAIM) != DBGP_CLAIM) { + dbgp_printk("No device in debug port\n"); + writel(ctrl & ~DBGP_CLAIM, &ehci_debug->control); + return -1; + + } + + /* Completely transfer the debug device to the debug controller */ + portsc = readl(&ehci_regs->port_status[debug_port - 1]); + portsc &= ~PORT_PE; + writel(portsc, &ehci_regs->port_status[debug_port - 1]); + + return 0; +} + +static __init void early_dbgp_init(char *s) +{ + struct usb_debug_descriptor dbgp_desc; + void __iomem *ehci_bar; + unsigned ctrl, devnum; + unsigned bus, slot, func, cap; + unsigned debug_port, bar, offset; + unsigned bar_val; + unsigned dbgp_num; + char *e; + int ret; + + if (!early_pci_allowed()) + return; + + dbgp_num = 0; + if (*s) { + dbgp_num = simple_strtoul(s, &e, 10); + } + dbgp_printk("dbgp_num: %d\n", dbgp_num); + cap = find_dbgp(dbgp_num, &bus, &slot, &func); + if (!cap) + return; + + dbgp_printk("Found EHCI debug port\n"); + + debug_port = read_pci_config(bus, slot, func, cap); + bar = (debug_port >> 29) & 0x7; + bar = (bar * 4) + 0xc; + offset = (debug_port >> 16) & 0xfff; + if (bar != PCI_BASE_ADDRESS_0) { + dbgp_printk("only debug ports on bar 1 handled.\n"); + return; + } + + /* FIXME this assumes the bar is a 32bit mmio bar */ + bar_val = read_pci_config(bus, slot, func, PCI_BASE_ADDRESS_0); + + /* FIXME I don't have the bar size so just guess PAGE_SIZE is more + * than enough. 1K is the biggest I have seen. + */ + set_fixmap_nocache(FIX_DBGP_BASE, bar_val & PAGE_MASK); + ehci_bar = (void __iomem *)__fix_to_virt(FIX_DBGP_BASE); + ehci_bar += bar_val & ~PAGE_MASK; + + ehci_caps = ehci_bar; + ehci_regs = ehci_bar + HC_LENGTH(readl(&ehci_caps->hc_capbase)); + ehci_debug = ehci_bar + offset; + + ret = ehci_setup(); + if (ret < 0) { + dbgp_printk("ehci_setup failed\n"); + return; + } + + /* Find the debug device and make it device number 127 */ + for (devnum = 0; devnum <= 127; devnum++) { + ret = dbgp_control_msg(devnum, + USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_DEVICE, + USB_REQ_GET_DESCRIPTOR, (USB_DT_DEBUG << 8), 0, + &dbgp_desc, sizeof(dbgp_desc)); + if (ret > 0) + break; + } + if (devnum > 127) { + dbgp_printk("Could not find attached debug device\n"); + goto err; + } + if (ret < 0) { + dbgp_printk("Attached device is not a debug device\n"); + goto err; + } + dbgp_endpoint_out = dbgp_desc.bDebugOutEndpoint; + + /* Move the device to 127 if it isn't already there */ + if (devnum != USB_DEBUG_DEVNUM) { + ret = dbgp_control_msg(devnum, + USB_DIR_OUT | USB_TYPE_STANDARD | USB_RECIP_DEVICE, + USB_REQ_SET_ADDRESS, USB_DEBUG_DEVNUM, 0, NULL, 0); + if (ret < 0) { + dbgp_printk("Could not move attached device to %d\n", + USB_DEBUG_DEVNUM); + goto err; + } + devnum = USB_DEBUG_DEVNUM; + } + + /* Enable the debug interface */ + ret = dbgp_control_msg(USB_DEBUG_DEVNUM, + USB_DIR_OUT | USB_TYPE_STANDARD | USB_RECIP_DEVICE, + USB_REQ_SET_FEATURE, USB_DEVICE_DEBUG_MODE, 0, NULL, 0); + if (ret < 0) { + dbgp_printk(" Could not enable the debug device\n"); + goto err; + } + + /* Perform a small write to get the even/odd data state in sync + */ + ret = dbgp_bulk_write(USB_DEBUG_DEVNUM, dbgp_endpoint_out, " ",1); + if (ret < 0) { + dbgp_printk("dbgp_bulk_write failed: %d\n", ret); + goto err; + } + + + return; +err: + /* Things didn't work so remove my claim */ + ctrl = readl(&ehci_debug->control); + ctrl &= ~(DBGP_CLAIM | DBGP_OUT); + writel(ctrl, &ehci_debug->control); + return; +} + +static void early_dbgp_write(struct console *con, const char *str, unsigned n) +{ + int chunk, ret; + if (!ehci_debug) + return; + while (n > 0) { + chunk = n; + if (chunk > DBGP_MAX_PACKET) + chunk = DBGP_MAX_PACKET; + ret = dbgp_bulk_write(USB_DEBUG_DEVNUM, + dbgp_endpoint_out, str, chunk); + str += chunk; + n -= chunk; + } +} + +static struct console early_dbgp_console = { + .name = "earlydbg", + .write = early_dbgp_write, + .flags = CON_PRINTBUFFER, + .index = -1, +}; + +#endif + /* Console interface to a host file on AMD's SimNow! */ static int simnow_fd; @@ -242,8 +804,20 @@ static int __init setup_early_printk(cha simnow_init(buf + 6); early_console = &simnow_console; keep_early = 1; + } else if (!strncmp(buf, "dbgp", 4)) { + early_dbgp_init(buf + 4); + early_console = &early_dbgp_console; } register_console(early_console); +#if DBGP_DEBUG + { + static const char dbgp_test_str[] = + "The quick brown fox jumped over the lazy dog!\n"; + early_dbgp_init(""); + early_dbgp_write(&early_dbgp_console, + dbgp_test_str, sizeof(dbgp_test_str) - 1); + } +#endif return 0; } diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h index bbc3082..0a67192 100644 --- a/drivers/usb/host/ehci.h +++ b/drivers/usb/host/ehci.h @@ -46,6 +46,7 @@ struct ehci_stats { #define EHCI_MAX_ROOT_PORTS 15 /* see HCS_N_PORTS */ +#ifndef EARLY_PRINTK struct ehci_hcd { /* one per controller */ /* glue to PCI and HCD framework */ struct ehci_caps __iomem *caps; @@ -160,6 +161,7 @@ timer_action (struct ehci_hcd *ehci, enu mod_timer (&ehci->watchdog, t); } } +#endif /* EARLY_PRINTK */ /*-------------------------------------------------------------------------*/ @@ -384,6 +386,7 @@ union ehci_shadow { * These appear in both the async and (for interrupt) periodic schedules. */ +#ifndef EARLY_PRINTK struct ehci_qh { /* first part defined by EHCI spec */ __le32 hw_next; /* see EHCI 3.6.1 */ @@ -432,6 +435,7 @@ #define QH_STATE_COMPLETING 5 /* don't #define NO_FRAME ((unsigned short)~0) /* pick new start */ struct usb_device *dev; /* access to TT */ } __attribute__ ((aligned (32))); +#endif /* EARLY_PRITNK */ /*-------------------------------------------------------------------------*/ @@ -601,6 +605,8 @@ struct ehci_fstn { union ehci_shadow fstn_next; /* ptr to periodic q entry */ } __attribute__ ((aligned (32))); +#ifndef EARLY_PRINTK + /*-------------------------------------------------------------------------*/ #ifdef CONFIG_USB_EHCI_ROOT_HUB_TT @@ -659,4 +665,6 @@ #endif /* DEBUG */ /*-------------------------------------------------------------------------*/ +#endif /* EARLY_PRINTK */ + #endif /* __LINUX_EHCI_HCD_H */ diff --git a/include/asm-x86_64/fixmap.h b/include/asm-x86_64/fixmap.h index 1b620db..1f2978a 100644 --- a/include/asm-x86_64/fixmap.h +++ b/include/asm-x86_64/fixmap.h @@ -36,6 +36,7 @@ enum fixed_addresses { VSYSCALL_LAST_PAGE, VSYSCALL_FIRST_PAGE = VSYSCALL_LAST_PAGE + ((VSYSCALL_END-VSYSCALL_START) >> PAGE_SHIFT) - 1, VSYSCALL_HPET, + FIX_DBGP_BASE, FIX_HPET_BASE, FIX_APIC_BASE, /* local (CPU) APIC) -- required for SMP or not */ FIX_IO_APIC_BASE_0, -- 1.4.2.rc3.g7e18e-dirty From svn at openbios.org Mon Dec 4 09:15:47 2006 From: svn at openbios.org (svn at openbios.org) Date: Mon, 04 Dec 2006 08:15:47 -0000 Subject: [LinuxBIOS] r2517 - trunk/LinuxBIOSv2/util/flashrom Message-ID: Author: uwe Date: 2006-12-04 09:15:47 +0100 (Mon, 04 Dec 2006) New Revision: 2517 Modified: trunk/LinuxBIOSv2/util/flashrom/README Log: List the supported flash chips and southbridges in the flashrom README file (trivial). Closes #52. Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Modified: trunk/LinuxBIOSv2/util/flashrom/README =================================================================== --- trunk/LinuxBIOSv2/util/flashrom/README 2006-12-03 23:46:36 UTC (rev 2516) +++ trunk/LinuxBIOSv2/util/flashrom/README 2006-12-04 08:15:47 UTC (rev 2517) @@ -84,3 +84,61 @@ Change CFLAGS in the Makefile to enable it: Remove -DDISABLE_DOC from CFLAGS. +Supported Flash Chips +--------------------- + +AMD AM-29F040B +AMD AM-29F016D +Atmel AT-29C040A +EMST F49B002UA +Intel 82802AB (Firmware Hub) +Intel 82802AC (Firmware Hub) +M-Systems MD-2802 (unsupported, disabled by default) +MX MX-29F002 +PMC PMC-49FL002 +PMC PMC-49FL004 +Sharp LHF-00L04 +SST SST-29EE020A +SST SST-28SF040A +SST SST-39SF010A +SST SST-39SF020A +SST SST-39SF040 +SST SST-39VF020 +SST SST-49LF040B +SST SST-49LF040 +SST SST-49LF020A +SST SST-49LF080A +SST SST-49LF002A/B +SST SST-49LF003A/B +SST SST-49LF004A/B +SST SST-49LF008A +ST ST-M29F400BT +ST ST-M29F040B +SyncMOS S29C51002T +Winbond W29C011 +Winbond W29C020C +Winbond W49F002U +Winbond W49V002A +Winbond W49V002FA +Winbond W39V040A +Winbond W39V040B + + +Supported Southbridges +---------------------- + +AMD CS5530 +AMD Geode SC1100 +AMD AMD-8111 +ATI SB400 +Intel ICH0-ICH8 (all variations) +Intel PIIX4/PIIX4E/PIIX4M +NVIDIA CK804 +NVIDIA MCP51 +SiS 630 +SiS 5595 +VIA VT8231 +VIA VT8235 +VIA VT8237 +VIA VT82C686 + From svn at openbios.org Mon Dec 4 09:18:22 2006 From: svn at openbios.org (LinuxBIOS) Date: Mon, 04 Dec 2006 08:18:22 -0000 Subject: [LinuxBIOS] #52: flashrom: List the supported flash chips and southbridges in the README In-Reply-To: <060.b27bff6a62fa60f88cc85ef1cb0866d2@openbios.org> References: <060.b27bff6a62fa60f88cc85ef1cb0866d2@openbios.org> Message-ID: <069.0338a10198ad360e6b1d72f20fb43d43@openbios.org> #52: flashrom: List the supported flash chips and southbridges in the README -------------------------+-------------------------------------------------- Reporter: uwe | Owner: somebody Type: defect | Status: closed Priority: major | Milestone: Enhance the flashrom utility Component: flashrom | Version: Resolution: fixed | Keywords: Dependencies: | Patchstatus: patch has been committed -------------------------+-------------------------------------------------- Changes (by uwe): * patchstatus: patch needs review => patch has been committed -- Ticket URL: LinuxBIOS From svn at openbios.org Mon Dec 4 09:20:40 2006 From: svn at openbios.org (svn at openbios.org) Date: Mon, 04 Dec 2006 08:20:40 -0000 Subject: [LinuxBIOS] r2518 - trunk/LinuxBIOSv2/util/flashrom Message-ID: Author: uwe Date: 2006-12-04 09:20:40 +0100 (Mon, 04 Dec 2006) New Revision: 2518 Modified: trunk/LinuxBIOSv2/util/flashrom/README Log: Update list of supported flash chips in the flashrom README (trivial). Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Modified: trunk/LinuxBIOSv2/util/flashrom/README =================================================================== --- trunk/LinuxBIOSv2/util/flashrom/README 2006-12-04 08:15:47 UTC (rev 2517) +++ trunk/LinuxBIOSv2/util/flashrom/README 2006-12-04 08:20:40 UTC (rev 2518) @@ -89,6 +89,7 @@ AMD AM-29F040B AMD AM-29F016D +ASD AE49F2008 Atmel AT-29C040A EMST F49B002UA Intel 82802AB (Firmware Hub) @@ -114,7 +115,10 @@ SST SST-49LF008A ST ST-M29F400BT ST ST-M29F040B -SyncMOS S29C51002T +SyncMOS S29C51001T/B +SyncMOS S29C51002T/B +SyncMOS S29C51004T/B +SyncMOS S29C31004T Winbond W29C011 Winbond W29C020C Winbond W49F002U From indrek.kruusa at artecdesign.ee Mon Dec 4 12:02:57 2006 From: indrek.kruusa at artecdesign.ee (Indrek Kruusa) Date: Mon, 04 Dec 2006 13:02:57 +0200 Subject: [LinuxBIOS] LPC SuperIO "add-in card" In-Reply-To: <2ea3fae10612010900y66dbbb8aq2bb226310ad0506e@mail.gmail.com> References: <57947bf80611300927s31876f3ep79511fa85b0066cd@mail.gmail.com> <45701167.9@artecdesign.ee> <20061201114708.16209.qmail@cdy.org> <457035D2.8000103@artecdesign.ee> <20061201142107.5753.qmail@cdy.org> <45704220.9040007@artecdesign.ee> <2ea3fae10612010900y66dbbb8aq2bb226310ad0506e@mail.gmail.com> Message-ID: <45740061.2060705@artecdesign.ee> yhlu wrote: > if you can change flash to SRAM that would be great. This could be possible I think.16Mbyte SRAM is a bit tough thing at first sight... but I am not the hardware parts specialist :) If your dongle is permanently connected to USB and the power is derived from there then you can hold your stuff in SRAM forever :) This is not bad idea at all. Indrek From stepan at coresystems.de Mon Dec 4 19:20:10 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 4 Dec 2006 19:20:10 +0100 Subject: [LinuxBIOS] Concepts for LX v3 In-Reply-To: <20061202192838.78a92d56.anton.borisov@gmail.com> References: <20061202192838.78a92d56.anton.borisov@gmail.com> Message-ID: <20061204182010.GA15492@coresystems.de> * Anton [061202 12:28]: > It would be nice to have TMS (Test Monitor System) onboard. Some big vendors have it on their systems for ages. > Pros: > a) Test for DRAM > b) Test for Media (HDD, CF, SD, ..) connected to the host > c) Test for Peripherals > Cons: > a) size. may not fit into 1/2/4 Mbit. > > TMS is a regular payload, access is done via RS232 (or USB in future), the same way as we all see printk messages nowdays. > However, it's not yet clear to me is it possible to have multiple payloads at once and how to choose between them. > Where to store boot options (CMOS is a way too small for it). It might also be interesting to put this together with another couple of tests from : http://www.linuxfirmwarekit.org/ > a) need to prepare boot media, like SATA/IDE device, to have dedicated partition CDROM or IDECF makes this kind of easy. You need modifications to the machine most likely, if you want to put parts of this in flash. Netbooting would be another alternative... Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From yinghai.lu at amd.com Mon Dec 4 21:18:30 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Mon, 4 Dec 2006 12:18:30 -0800 Subject: [LinuxBIOS] [RFC][PATCH 2/2] x86_64: earlyprintk usb debug device support. Message-ID: <5986589C150B2F49A46483AC44C7BCA4907280@ssvlexmb2.amd.com> -----Original Message----- From: ebiederm at xmission.com [mailto:ebiederm at xmission.com] >arch/x86_64/kernel/early_printk.c | 574 +++++++++++++++++++++++++++++++++++++ > drivers/usb/host/ehci.h | 8 + > include/asm-x86_64/fixmap.h | 1 Can you separate usbdebug handle out from early_printk? So We can share the code in LinuxBIOS easier. I like the version like usbdebug_direct.c. Also separate related USB debug port defines in one separate header file too. YH From yinghai.lu at amd.com Mon Dec 4 21:52:30 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Mon, 4 Dec 2006 12:52:30 -0800 Subject: [LinuxBIOS] [RFC][PATCH 2/2] x86_64: earlyprintk usb debug device support. Message-ID: <5986589C150B2F49A46483AC44C7BCA4907281@ssvlexmb2.amd.com> Eric, Please check the version I modified for LinuxBIOS from your usbdebug_direct. Put the related info in struct ehci_debug_info { void *ehci_base; void *ehci_op_base; void *ehci_debug_base; unsigned devnum; unsigned endpoint_out; unsigned endpoint_in; int inited; }; So for CAR stage code, I could put it the range after stack and easy to retrieve. YH -------------- next part -------------- A non-text attachment was scrubbed... Name: usbdebug_direct.h Type: application/octet-stream Size: 608 bytes Desc: usbdebug_direct.h URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: usbdebug_direct.c Type: application/octet-stream Size: 14476 bytes Desc: usbdebug_direct.c URL: From ebiederm at xmission.com Mon Dec 4 22:26:52 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Mon, 04 Dec 2006 14:26:52 -0700 Subject: [LinuxBIOS] [RFC][PATCH 2/2] x86_64: earlyprintk usb debug device support. In-Reply-To: <20061204203308.GA30307@suse.de> (Greg KH's message of "Mon, 4 Dec 2006 12:33:08 -0800") References: <5986589C150B2F49A46483AC44C7BCA4907280@ssvlexmb2.amd.com> <20061204203308.GA30307@suse.de> Message-ID: Greg KH writes: > On Mon, Dec 04, 2006 at 12:18:30PM -0800, Lu, Yinghai wrote: >> -----Original Message----- >> From: ebiederm at xmission.com [mailto:ebiederm at xmission.com] >> >> >arch/x86_64/kernel/early_printk.c | 574 >> +++++++++++++++++++++++++++++++++++++ >> > drivers/usb/host/ehci.h | 8 + >> > include/asm-x86_64/fixmap.h | 1 >> >> Can you separate usbdebug handle out from early_printk? > > Yeah, at least tear it out of x86-64, so those of us stuck on different > platforms can use this :) > > Other than that minor issue, this looks great. I don't have a x86-64 > box set up here at the moment, so I can't test it, but it looks > acceptable at first glance. Makes sense. I'm curious now what architecture do you have? Anyway next time I touch this the project will be how to integrate this into the kernel cleanly. This round was to figure out how to get some working code. If someone beats me to the punch on generalizing this code I won't mind. The first pass was a success. And the performance is reasonable assuming you don't plug the end you are watching into a usb1 only port. Given that I didn't really know anything about usb a week ago I think I did pretty well :) Eric From ben at hewson-venieri.com Mon Dec 4 22:46:13 2006 From: ben at hewson-venieri.com (Ben Hewson) Date: Mon, 04 Dec 2006 21:46:13 +0000 Subject: [LinuxBIOS] PCI bus expert needed. Message-ID: <45749725.1040707@hewson-venieri.com> Ok I have some problems and I hope someone here can shed some light on them. I have just downloaded the latest version from the repository to try out the ROMCC fix on the original EPIA code. I am using the same options and the same filo payload. When filo runs I get the following error FILO version 0.5 (root at localhost) Sun Nov 12 17:35:53 GMT 2006 boot: hda1:/kern root=/dev/hda3 console=ttyS0,115200 Detected floating bus No drive detected on IDE channel 0 Now this used to work and I said it is the same build of filo so I think it reasonable to assume the problem lies with linuxbios. Logging the boot messages I can see a few differences when it comes to enumerating the PCI bus. I am assuming this is where things go wrong. this is from the working boot PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done Root Device read_resources bus 0 link: 0 done PCI: 00:11.6 10 * [0x00000400 - 0x000004ff] io PCI: 00:12.0 10 * [0x00000800 - 0x000008ff] io PCI: 00:11.1 20 * [0x00000c00 - 0x00000c0f] io Root Device compute_allocate_io: base: 00000c10 size: 00000810 align: 8 gran: 0 done and this from the non-working boot PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done Root Device read_resources bus 0 link: 0 done PCI: 00:11.6 10 * [0x00000400 - 0x000004ff] io PCI: 00:12.0 10 * [0x00000800 - 0x000008ff] io PCI: 00:11.1 20 * [0x00000c00 - 0x00000c0f] io PCI: 00:11.1 10 * [0x00000c10 - 0x00000c17] io PCI: 00:11.1 18 * [0x00000c20 - 0x00000c27] io PCI: 00:11.1 14 * [0x00000c30 - 0x00000c33] io PCI: 00:11.1 1c * [0x00000c40 - 0x00000c43] io Root Device compute_allocate_io: base: 00000c44 size: 00000844 align: 8 gran: 0 done The non working version seems to see some different stuff and set the base to a different value. I get a similar situation again working Root Device read_resources bus 0 link: 0 done PCI: 00:11.6 10 * [0x00001000 - 0x000010ff] io PCI: 00:12.0 10 * [0x00001400 - 0x000014ff] io PCI: 00:11.1 20 * [0x00001800 - 0x0000180f] io Root Device compute_allocate_io: base: 00001810 size: 00000810 align: 8 gran: 0 done non working Root Device read_resources bus 0 link: 0 done PCI: 00:11.6 10 * [0x00001000 - 0x000010ff] io PCI: 00:12.0 10 * [0x00001400 - 0x000014ff] io PCI: 00:11.1 20 * [0x00001800 - 0x0000180f] io PCI: 00:11.1 10 * [0x00001810 - 0x00001817] io PCI: 00:11.1 18 * [0x00001820 - 0x00001827] io PCI: 00:11.1 14 * [0x00001830 - 0x00001833] io PCI: 00:11.1 1c * [0x00001840 - 0x00001843] io Root Device compute_allocate_io: base: 00001844 size: 00000844 align: 8 gran: 0 done I am right in thinking this is setting base offsets for various function ? Further down when initialising hte IDE I get this working ide_init: enabling compatibility IDE addresses enables in reg 0x42 0x0 enables in reg 0x42 read back as 0x0 non working ide_init: enabling compatibility IDE addresses enables in reg 0x42 0xc9 enables in reg 0x42 read back as 0x9 From jon.dufresne at gmail.com Mon Dec 4 22:50:38 2006 From: jon.dufresne at gmail.com (Jon Dufresne) Date: Mon, 4 Dec 2006 16:50:38 -0500 Subject: [LinuxBIOS] confusion about enabling resources Message-ID: <376ea3380612041350x771d8539he7c3b3154fb38658@mail.gmail.com> My ram initialization appears to work, at least enough to get me out of the romcc section. I am having quite a bit of difficulty getting the bios to run smoothly though. I am currently stuck somewhere either in filo or somewhere in elfboot. I think (once again) this has to do with the way LinuxBIOS understands the ram, and me not properly giving it the information it needs. As of right now if I put in code that looks more correct to me, the BIOS dies earlier than if I put in code that looks less correct. I'm guess that it is a lucky coincidence the less correct code works better, but it could be that I don't understand what is happening. In src/northbridge/intel/i855gm/northbridge.c (This northbridge isn't in the main tree but is based off of i855pm) I have see the following, mc_dev = dev->link[0].children; Which I've deduced will give me the PCI device 0:0.0, which is NOT the MCH for my northbridge. This is used by the line that says tomk = ((unsigned long)pci_read_config8(mc_dev, 0x63)) << 15; this will give tomk a value of 0, since that happens to always be in that register. Obviously I have more than 0 KiB of ram. To give what I think is the more correct value I modify it to say mc_dev = dev->link[0].children->sibling; This will give it the PCI device 0:0.1, which is the MCH. I then modify the read so it says tomk = ((unsigned long)pci_read_config8(mc_dev, 0x43)) << 15; which is the correct register holding the top of the memory (the shift just puts it into KiB). Now without my modifications the BIOS makes it into filo and can do some stuff before dying. With my modifications it dies within elfboot. With these statements at the end of the log: Jumping to boot code at 0x10af40 entry = 0x0010af40 lb_start = 0x00004000 lb_size = 0x00014000 adjust = 0x3ffe8000 buffer = 0x3ffd8000 elf_boot_notes = 0x0000eb80 adjusted_boot_notes = 0x3fff6b80 In the unmodified form these log statements look like Jumping to boot code at 0x10af40 entry = 0x0010af40 lb_start = 0x00004000 lb_size = 0x00014000 adjust = 0xfffe8000 buffer = 0xfffd8000 elf_boot_notes = 0x0000ec00 adjusted_boot_notes = 0xffff6c00 I am at a loss for what is going wrong here and would appreciate any insight that anyone has. Below is the unmodified form of the function. I commented out the pci_write's because those registers are not documented in my datasheet, nor is there any mention of low memory. Thanks for any help! static void pci_domain_set_resources(device_t dev) { device_t mc_dev; uint32_t pci_tolm; pci_tolm = find_pci_tolm(&dev->link[0]); mc_dev = dev->link[0].children; printk_debug("MC dev vid = %x\n", mc_dev->vendor); printk_debug("MC dev did = %x\n", mc_dev->device); if (mc_dev) { /* Figure out which areas are/should be occupied by RAM. * This is all computed in kilobytes and converted to/from * the memory controller right at the edges. * Having different variables in different units is * too confusing to get right. Kilobytes are good up to * 4 Terabytes of RAM... */ uint16_t tolm_r, remapbase_r, remaplimit_r; unsigned long tomk, tolmk; unsigned long remapbasek, remaplimitk; int idx; /* Get the value of the highest DRB. This tells the end of * the physical memory. The units are ticks of 64MB * i.e. 1 means 64MB. */ tomk = ((unsigned long)pci_read_config8(mc_dev, 0x63)) << 15; /* Compute the top of Low memory */ tolmk = pci_tolm >> 10; if (tolmk >= tomk) { /* The PCI hole does not overlap memory * we won't use the remap window. */ tolmk = tomk; remapbasek = 0x3ff << 15; remaplimitk = 0 << 15; } else { /* The PCI memory hole overlaps memory * setup the remap window. */ /* Find the bottom of the remap window * is it above 4G? */ remapbasek = 4*1024*1024; if (tomk > remapbasek) { remapbasek = tomk; } /* Find the limit of the remap window */ remaplimitk = (remapbasek + (4*1024*1024 - tolmk) - (1 << 15)); } /* Write the ram configuration registers, * preserving the reserved bits. */ /* tolm_r = pci_read_config16(mc_dev, 0xc4); tolm_r = ((tolmk >> 17) << 11) | (tolm_r & 0x7ff); pci_write_config16(mc_dev, 0xc4, tolm_r); remapbase_r = pci_read_config16(mc_dev, 0xc6); remapbase_r = (remapbasek >> 16) | (remapbase_r & 0xfc00); pci_write_config16(mc_dev, 0xc6, remapbase_r); remaplimit_r = pci_read_config16(mc_dev, 0xc8); remaplimit_r = (remaplimitk >> 16) | (remaplimit_r & 0xfc00); pci_write_config16(mc_dev, 0xc8, remaplimit_r); */ /* Report the memory regions */ printk_debug("tomk = %d\n", tomk); printk_debug("tolmk = %d\n", tolmk); printk_debug("remaplimitk = %d\n", remaplimitk); printk_debug("remapbasek = %d\n", remapbasek); idx = 10; ram_resource(dev, idx++, 0, 640); ram_resource(dev, idx++, 768, tolmk - 768); if (tomk > 4*1024*1024) { ram_resource(dev, idx++, 4096*1024, tomk - 4*1024*1024); } if (remaplimitk >= remapbasek) { ram_resource(dev, idx++, remapbasek, (remaplimitk + 64*1024) - remapbasek); } } assign_resources(&dev->link[0]); } From talbotx at comcast.net Tue Dec 5 02:05:23 2006 From: talbotx at comcast.net (Adam Talbot) Date: Mon, 04 Dec 2006 17:05:23 -0800 Subject: [LinuxBIOS] GX2 status In-Reply-To: <45749725.1040707@hewson-venieri.com> References: <45749725.1040707@hewson-venieri.com> Message-ID: <4574C5D3.7090600@comcast.net> Looks like the Geode LX line is well supported. How much work am I looking at in order to load LinuxBIOS on an iBase mb500? http://www.ibase.com.tw/mb500.htm -Adam Talbot From uwe at hermann-uwe.de Tue Dec 5 02:46:33 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Tue, 5 Dec 2006 02:46:33 +0100 Subject: [LinuxBIOS] [PATCH] Add support for SMSC FDC37M60X Super I/O Message-ID: <20061205014633.GA14588@greenwood> Add support for the SMSC FDC37M60X Super I/O (tested on FDC37M602). Serial output on serial port 1 is tested and works, the rest probably not yet. Signed-off-by: Uwe Hermann --- Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- Index: src/superio/smsc/fdc37m60x/Config.lb =================================================================== --- src/superio/smsc/fdc37m60x/Config.lb (Revision 0) +++ src/superio/smsc/fdc37m60x/Config.lb (Revision 0) @@ -0,0 +1,23 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2006 Uwe Hermann +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; either version 2 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## + +config chip.h +object superio.o + Index: src/superio/smsc/fdc37m60x/fdc37m60x.h =================================================================== --- src/superio/smsc/fdc37m60x/fdc37m60x.h (Revision 0) +++ src/superio/smsc/fdc37m60x/fdc37m60x.h (Revision 0) @@ -0,0 +1,39 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/* + * Datasheet: + * - Name: FDC37M60x Enhanced Super I/O Controller with Infrared Support. + * - URL: http://www.smsc.com/main/discfdc.html + * - PDF: http://www.smsc.com/main/tools/discontinued/37m602.pdf + * - Revision: 6/6/97 + */ + +/* Status: Serial port 1 is tested and works (tested on FDC37M602). */ + +/* Note: Logical devices 1, 2, 6, and 9 are reserved. */ + +#define FDC37M60X_FDC 0x00 /* Floppy */ +#define FDC37M60X_PP 0x03 /* Parallel port */ +#define FDC37M60X_SP1 0x04 /* Com1 */ +#define FDC37M60X_SP2 0x05 /* Com2 */ +#define FDC37M60X_KBCK 0x07 /* Keyboard */ +#define FDC37M60X_AUX 0x08 /* Auxiliary I/O */ + Index: src/superio/smsc/fdc37m60x/superio.c =================================================================== --- src/superio/smsc/fdc37m60x/superio.c (Revision 0) +++ src/superio/smsc/fdc37m60x/superio.c (Revision 0) @@ -0,0 +1,87 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +#include "chip.h" +#include "fdc37m60x.h" + +static void init(device_t dev) +{ + struct superio_smsc_fdc37m60x_config *conf; + struct resource *res0, *res1; + + if (!dev->enabled) { + return; + } + + conf = dev->chip_info; + + switch (dev->path.u.pnp.device) { + case FDC37M60X_FDC: /* TODO. */ + break; + case FDC37M60X_PP: /* TODO. */ + break; + case FDC37M60X_SP1: + res0 = find_resource(dev, PNP_IDX_IO0); + init_uart8250(res0->base, &conf->com1); + break; + case FDC37M60X_SP2: + res0 = find_resource(dev, PNP_IDX_IO0); + init_uart8250(res0->base, &conf->com2); + break; + case FDC37M60X_KBCK: + res0 = find_resource(dev, PNP_IDX_IO0); + res1 = find_resource(dev, PNP_IDX_IO1); + init_pc_keyboard(res0->base, res1->base, &conf->keyboard); + break; + case FDC37M60X_AUX: /* TODO. */ + break; + } +} + +static struct device_operations ops = { + .read_resources = pnp_read_resources, + .set_resources = pnp_set_resources, + .enable_resources = pnp_enable_resources, + .enable = pnp_enable, + .init = init, +}; + +/* TODO: FDC, PP, AUX. */ +static struct pnp_info pnp_dev_info[] = { + { &ops, FDC37M60X_SP1, PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, }, + { &ops, FDC37M60X_SP2, PNP_IO0 | PNP_IRQ0 | PNP_DRQ0 | PNP_DRQ1, { 0x7f8, 0 }, }, + { &ops, FDC37M60X_KBCK, PNP_IO0 | PNP_IO1 | PNP_IRQ0, { 0x7f8, 0 }, { 0x7f8, 0x4}, }, +}; + +static void enable_dev(struct device *dev) +{ + pnp_enable_devices(dev, &pnp_ops, + sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]), pnp_dev_info); +} + +struct chip_operations superio_smsc_fdc37m60x_ops = { + CHIP_NAME("SMSC FDC37M60X Super I/O") + .enable_dev = enable_dev, +}; + Index: src/superio/smsc/fdc37m60x/chip.h =================================================================== --- src/superio/smsc/fdc37m60x/chip.h (Revision 0) +++ src/superio/smsc/fdc37m60x/chip.h (Revision 0) @@ -0,0 +1,36 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#ifndef _SUPERIO_SMSC_FDC37M60X +#define _SUPERIO_SMSC_FDC37M60X + +#include +#include +#include + +extern struct chip_operations superio_smsc_fdc37m60x_ops; + +struct superio_smsc_fdc37m60x_config { + struct uart8250 com1, com2; + struct pc_keyboard keyboard; +}; + +#endif /* _SUPERIO_SMSC_FDC37M60X */ + Index: src/superio/smsc/fdc37m60x/fdc37m60x_early_serial.c =================================================================== --- src/superio/smsc/fdc37m60x/fdc37m60x_early_serial.c (Revision 0) +++ src/superio/smsc/fdc37m60x/fdc37m60x_early_serial.c (Revision 0) @@ -0,0 +1,78 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include "fdc37m60x.h" + +/* The base address is 0x3f0 or 0x370, depending on the SYSOPT pin. */ +#define SIO_BASE 0x3f0 +#define SIO_INDEX SIO_BASE +#define SIO_DATA SIO_BASE+1 + +/* Global configuration registers. */ +#define FDC37M60X_CONFIG_REG_CC 0x02 /* Configure Control. */ +#define FDC37M60X_CONFIG_REG_LDN 0x07 /* Logical Device Number. */ +#define FDC37M60X_CONFIG_POWER_CONTROL 0x22 /* Power Control. */ +#define FDC37M60X_CONFIG_POWER_MGMT 0x23 /* Intelligent Power Mgmt. */ +#define FDC37M60X_CONFIG_OSC 0x24 /* OSC. */ + +#define FDC37M60X_CONFIGURATION_PORT 0x3f0 /* Write-only. */ + +/* The content of FDC37M60X_CONFIG_REG_LDN (index 0x07) must be set to the + LDN the register belongs to, before you can access the register. */ +static void fdc37m60x_sio_write(uint8_t ldn, uint8_t index, uint8_t value) +{ + outb(FDC37M60X_CONFIG_REG_LDN, SIO_BASE); + outb(ldn, SIO_DATA); + outb(index, SIO_BASE); + outb(value, SIO_DATA); +} + +/* Enable the peripheral devices on the FDC37M60X Super I/O chip. */ +static void fdc37m60x_enable_serial(device_t dev, unsigned iobase) +{ + /* (1) Enter the configuration state. */ + outb(0x55, FDC37M60X_CONFIGURATION_PORT); + + /* (2) Modify the data of configuration registers. */ + + /* Power on all devices by setting the respective bit. + Bits: 0 (FDC), 3 (PP), 4 (Com1), 5 (Com2). The rest is reserved. */ + fdc37m60x_sio_write(0x00, FDC37M60X_CONFIG_POWER_CONTROL, 0x39); + + /* Disable intelligent power management. */ + fdc37m60x_sio_write(0x00, FDC37M60X_CONFIG_POWER_MGMT, 0x00); + + /* Turn on OSC, turn on BRG clock. */ + fdc37m60x_sio_write(0x00, FDC37M60X_CONFIG_OSC, 0x04); + + /* Configure serial port 1. */ + fdc37m60x_sio_write(FDC37M60X_SP1, 0x60, 0x03); + fdc37m60x_sio_write(FDC37M60X_SP1, 0x61, 0xf8); /* I/O 0x3f8 */ + fdc37m60x_sio_write(FDC37M60X_SP1, 0x70, 0x04); /* IRQ 4 */ + fdc37m60x_sio_write(FDC37M60X_SP1, 0xf0, 0x00); /* Normal */ + + /* Enable serial port 1. */ + fdc37m60x_sio_write(FDC37M60X_SP1, 0x30, 0x01); + + /* (3) Exit the configuration state. */ + outb(0xaa, FDC37M60X_CONFIGURATION_PORT); +} + -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From yinghai.lu at amd.com Tue Dec 5 04:18:01 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Mon, 4 Dec 2006 19:18:01 -0800 Subject: [LinuxBIOS] [RFC][PATCH 2/2] x86_64: earlyprintk usb debug device support. Message-ID: <5986589C150B2F49A46483AC44C7BCA4907285@ssvlexmb2.amd.com> -----Original Message----- From: Greg KH [mailto:gregkh at suse.de] Sent: Monday, December 04, 2006 4:45 PM To: Eric W. Biederman Cc: Lu, Yinghai; USB development list; Stefan Reinauer; Peter Stuge; linuxbios at linuxbios.org; linux-kernel at vger.kernel.org; Andi Kleen Subject: Re: [RFC][PATCH 2/2] x86_64: earlyprintk usb debug device support. On Mon, Dec 04, 2006 at 02:26:52PM -0700, Eric W. Biederman wrote: > Greg KH writes: > > Anyway next time I touch this the project will be how to integrate > this into the kernel cleanly. This round was to figure out how > to get some working code. Please check the adapted version for LinuxBIOS with your kernel patch. Hope your next version could have more good shape ... YH -------------- next part -------------- A non-text attachment was scrubbed... Name: usbdebug_direct.h Type: application/octet-stream Size: 590 bytes Desc: usbdebug_direct.h URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: usbdebug_direct.c Type: application/octet-stream Size: 12250 bytes Desc: usbdebug_direct.c URL: From svn at openbios.org Tue Dec 5 15:13:10 2006 From: svn at openbios.org (svn at openbios.org) Date: Tue, 05 Dec 2006 14:13:10 -0000 Subject: [LinuxBIOS] r2519 - in trunk/LinuxBIOSv2/src/superio/smsc: lpc47b272 lpc47n217 Message-ID: Author: uwe Date: 2006-12-05 15:13:10 +0100 (Tue, 05 Dec 2006) New Revision: 2519 Modified: trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/Config.lb trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/chip.h trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/lpc47b272.h trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/lpc47b272_early_serial.c trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/superio.c trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/Config.lb trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/chip.h trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/lpc47n217.h trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/lpc47n217_early_serial.c trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/superio.c Log: Add missing license headers to some files (info based on svn history). Adapt some existing license headers to use the common LinuxBIOS format. Please note that this does not make any qualitative license changes, merely cosmetic syntax changes (trivial). Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Modified: trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/Config.lb 2006-12-04 08:20:40 UTC (rev 2518) +++ trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/Config.lb 2006-12-05 14:13:10 UTC (rev 2519) @@ -1,2 +1,23 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2005 Digital Design Corporation +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; either version 2 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## + config chip.h object superio.o + Modified: trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/chip.h 2006-12-04 08:20:40 UTC (rev 2518) +++ trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/chip.h 2006-12-05 14:13:10 UTC (rev 2519) @@ -1,3 +1,23 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2005 Digital Design Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + struct chip_operations; extern struct chip_operations superio_smsc_lpc47b272_ops; Modified: trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/lpc47b272.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/lpc47b272.h 2006-12-04 08:20:40 UTC (rev 2518) +++ trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/lpc47b272.h 2006-12-05 14:13:10 UTC (rev 2519) @@ -1,3 +1,23 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2005 Digital Design Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + #define LPC47B272_FDC 0 /* Floppy */ #define LPC47B272_PP 3 /* Parallel Port */ #define LPC47B272_SP1 4 /* Com1 */ @@ -6,3 +26,4 @@ #define LPC47B272_RT 10 /* Runtime reg*/ #define LPC47B272_MAX_CONFIG_REGISTER 0x5F + Modified: trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/lpc47b272_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/lpc47b272_early_serial.c 2006-12-04 08:20:40 UTC (rev 2518) +++ trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/lpc47b272_early_serial.c 2006-12-05 14:13:10 UTC (rev 2519) @@ -1,5 +1,5 @@ /* - * lpc47b272_early_serial.c: Pre-RAM driver for SMSC LPC47B272 Super I/O chip + * This file is part of the LinuxBIOS project. * * Copyright (C) 2005 Digital Design Corporation * @@ -15,9 +15,11 @@ * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ +/* Pre-RAM driver for SMSC LPC47B272 Super I/O chip. */ + #include #include "lpc47b272.h" Modified: trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/superio.c 2006-12-04 08:20:40 UTC (rev 2518) +++ trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/superio.c 2006-12-05 14:13:10 UTC (rev 2519) @@ -1,9 +1,9 @@ /* - * superio.c: RAM driver for SMSC LPC47B272 Super I/O chip + * This file is part of the LinuxBIOS project. * - * Copyright 2000 AG Electronics Ltd. - * Copyright 2003-2004 Linux Networx - * Copyright 2004 Tyan + * Copyright (C) 2000 AG Electronics Ltd. + * Copyright (C) 2003-2004 Linux Networx + * Copyright (C) 2004 Tyan * Copyright (C) 2005 Digital Design Corporation * * This program is free software; you can redistribute it and/or modify @@ -18,9 +18,11 @@ * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ +/* RAM driver for SMSC LPC47B272 Super I/O chip. */ + #include #include #include Modified: trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/Config.lb 2006-12-04 08:20:40 UTC (rev 2518) +++ trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/Config.lb 2006-12-05 14:13:10 UTC (rev 2519) @@ -1,2 +1,22 @@ -config chip.h -object superio.o +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2005 Digital Design Corporation +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; either version 2 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## + +config chip.h +object superio.o Modified: trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/chip.h 2006-12-04 08:20:40 UTC (rev 2518) +++ trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/chip.h 2006-12-05 14:13:10 UTC (rev 2519) @@ -1,8 +1,28 @@ -struct chip_operations; -extern struct chip_operations superio_smsc_lpc47n217_ops; - -#include - -struct superio_smsc_lpc47n217_config { - struct uart8250 com1, com2; -}; +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2005 Digital Design Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +struct chip_operations; +extern struct chip_operations superio_smsc_lpc47n217_ops; + +#include + +struct superio_smsc_lpc47n217_config { + struct uart8250 com1, com2; +}; Modified: trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/lpc47n217.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/lpc47n217.h 2006-12-04 08:20:40 UTC (rev 2518) +++ trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/lpc47n217.h 2006-12-05 14:13:10 UTC (rev 2519) @@ -1,8 +1,28 @@ -// These are arbitrary, but must match declarations in the mainboard config file. -// Values chosen to match SMSC 47B37x. - -#define LPC47N217_PP 3 /* Parallel Port */ -#define LPC47N217_SP1 4 /* Com1 */ -#define LPC47N217_SP2 5 /* Com2 */ - -#define LPC47N217_MAX_CONFIG_REGISTER 0x39 +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2005 Digital Design Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +// These are arbitrary, but must match declarations in the mainboard config file. +// Values chosen to match SMSC 47B37x. + +#define LPC47N217_PP 3 /* Parallel Port */ +#define LPC47N217_SP1 4 /* Com1 */ +#define LPC47N217_SP2 5 /* Com2 */ + +#define LPC47N217_MAX_CONFIG_REGISTER 0x39 Modified: trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/lpc47n217_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/lpc47n217_early_serial.c 2006-12-04 08:20:40 UTC (rev 2518) +++ trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/lpc47n217_early_serial.c 2006-12-05 14:13:10 UTC (rev 2519) @@ -1,5 +1,5 @@ /* - * lpc47n217_early_serial.c: Pre-RAM driver for SMSC LPC47N217 Super I/O chip + * This file is part of the LinuxBIOS project. * * Copyright (C) 2005 Digital Design Corporation * @@ -15,9 +15,11 @@ * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ +/* Pre-RAM driver for SMSC LPC47N217 Super I/O chip. */ + #include #include #include "lpc47n217.h" Modified: trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/superio.c 2006-12-04 08:20:40 UTC (rev 2518) +++ trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/superio.c 2006-12-05 14:13:10 UTC (rev 2519) @@ -1,11 +1,9 @@ /* - * superio.c: RAM-based driver for SMSC LPC47N217 Super I/O chip + * This file is part of the LinuxBIOS project. * - * Based on LinuxBIOS code for SMSC 47B397: - * Copyright 2000 AG Electronics Ltd. - * Copyright 2003-2004 Linux Networx - * Copyright 2004 Tyan - * + * Copyright (C) 2000 AG Electronics Ltd. + * Copyright (C) 2003-2004 Linux Networx + * Copyright (C) 2004 Tyan * Copyright (C) 2005 Digital Design Corporation * * This program is free software; you can redistribute it and/or modify @@ -20,9 +18,12 @@ * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ +/* RAM-based driver for SMSC LPC47N217 Super I/O chip. */ +/* Based on LinuxBIOS code for SMSC 47B397. */ + #include #include #include From svn at openbios.org Tue Dec 5 16:27:47 2006 From: svn at openbios.org (svn at openbios.org) Date: Tue, 05 Dec 2006 15:27:47 -0000 Subject: [LinuxBIOS] r2520 - in trunk/LinuxBIOSv2/src: arch/ppc/include arch/ppc/lib cpu/ppc/mpc74xx cpu/ppc/ppc7xx mainboard/motorola/sandpoint mainboard/motorola/sandpoint/flash mainboard/motorola/sandpoint/nvram pmc/altimus/mpc7410 Message-ID: Author: uwe Date: 2006-12-05 16:27:46 +0100 (Tue, 05 Dec 2006) New Revision: 2520 Modified: trunk/LinuxBIOSv2/src/arch/ppc/include/ppc.h trunk/LinuxBIOSv2/src/arch/ppc/include/ppcreg.h trunk/LinuxBIOSv2/src/arch/ppc/include/timer.h trunk/LinuxBIOSv2/src/arch/ppc/lib/c_start.S trunk/LinuxBIOSv2/src/arch/ppc/lib/cpuid.c trunk/LinuxBIOSv2/src/arch/ppc/lib/floats.S trunk/LinuxBIOSv2/src/arch/ppc/lib/floats.inc trunk/LinuxBIOSv2/src/arch/ppc/lib/ppc.c trunk/LinuxBIOSv2/src/arch/ppc/lib/timer.c trunk/LinuxBIOSv2/src/cpu/ppc/mpc74xx/mpc74xx.inc trunk/LinuxBIOSv2/src/cpu/ppc/ppc7xx/ppc7xx.inc trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/clock.c trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/flash.h trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/flash/amd800.c trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/flash/flash.c trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/nvram.h trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/nvram/nvram.c trunk/LinuxBIOSv2/src/pmc/altimus/mpc7410/mpc7410.c trunk/LinuxBIOSv2/src/pmc/altimus/mpc7410/setup.c Log: Use the common LinuxBIOS license header (trivial). Refs #5. Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Modified: trunk/LinuxBIOSv2/src/arch/ppc/include/ppc.h =================================================================== --- trunk/LinuxBIOSv2/src/arch/ppc/include/ppc.h 2006-12-05 14:13:10 UTC (rev 2519) +++ trunk/LinuxBIOSv2/src/arch/ppc/include/ppc.h 2006-12-05 15:27:46 UTC (rev 2520) @@ -1,5 +1,21 @@ -/* Copyright 2000 AG Electronics Ltd. */ -/* This code is distributed without warranty under the GPL v2 (see COPYING) */ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2000 AG Electronics Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ #ifndef _PPC_H #define _PPC_H Modified: trunk/LinuxBIOSv2/src/arch/ppc/include/ppcreg.h =================================================================== --- trunk/LinuxBIOSv2/src/arch/ppc/include/ppcreg.h 2006-12-05 14:13:10 UTC (rev 2519) +++ trunk/LinuxBIOSv2/src/arch/ppc/include/ppcreg.h 2006-12-05 15:27:46 UTC (rev 2520) @@ -1,5 +1,21 @@ -/* Copyright 2000 AG Electronics Ltd. */ -/* This code is distributed without warranty under the GPL v2 (see COPYING) */ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2000 AG Electronics Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ /* In the MSR, not all bits are interesting to us 16 - EE - External interrupts Modified: trunk/LinuxBIOSv2/src/arch/ppc/include/timer.h =================================================================== --- trunk/LinuxBIOSv2/src/arch/ppc/include/timer.h 2006-12-05 14:13:10 UTC (rev 2519) +++ trunk/LinuxBIOSv2/src/arch/ppc/include/timer.h 2006-12-05 15:27:46 UTC (rev 2520) @@ -1,5 +1,21 @@ -/* Copyright 2000 AG Electronics Ltd. */ -/* This code is distributed without warranty under the GPL v2 (see COPYING) */ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2000 AG Electronics Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ #ifndef _TIMER_H #define __TIMER_H Modified: trunk/LinuxBIOSv2/src/arch/ppc/lib/c_start.S =================================================================== --- trunk/LinuxBIOSv2/src/arch/ppc/lib/c_start.S 2006-12-05 14:13:10 UTC (rev 2519) +++ trunk/LinuxBIOSv2/src/arch/ppc/lib/c_start.S 2006-12-05 15:27:46 UTC (rev 2520) @@ -1,5 +1,21 @@ -/* Copyright 2000 AG Electronics Ltd. */ -/* This code is distributed without warranty under the GPL v2 (see COPYING) */ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2000 AG Electronics Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ /* * The assumption is that we're located in ROM and we have a fake stack Modified: trunk/LinuxBIOSv2/src/arch/ppc/lib/cpuid.c =================================================================== --- trunk/LinuxBIOSv2/src/arch/ppc/lib/cpuid.c 2006-12-05 14:13:10 UTC (rev 2519) +++ trunk/LinuxBIOSv2/src/arch/ppc/lib/cpuid.c 2006-12-05 15:27:46 UTC (rev 2520) @@ -1,5 +1,21 @@ -/* Copyright 2000 AG Electronics Ltd. */ -/* This code is distributed without warranty under the GPL v2 (see COPYING) */ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2000 AG Electronics Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ #include "ppc.h" #include "ppcreg.h" Modified: trunk/LinuxBIOSv2/src/arch/ppc/lib/floats.S =================================================================== --- trunk/LinuxBIOSv2/src/arch/ppc/lib/floats.S 2006-12-05 14:13:10 UTC (rev 2519) +++ trunk/LinuxBIOSv2/src/arch/ppc/lib/floats.S 2006-12-05 15:27:46 UTC (rev 2520) @@ -1,5 +1,21 @@ -/* Copyright 1999-2000 AG Electronics Ltd. */ -/* This code is distributed without warranty under the GPL v2 (see COPYING) */ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 1999-2000 AG Electronics Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ #include Modified: trunk/LinuxBIOSv2/src/arch/ppc/lib/floats.inc =================================================================== --- trunk/LinuxBIOSv2/src/arch/ppc/lib/floats.inc 2006-12-05 14:13:10 UTC (rev 2519) +++ trunk/LinuxBIOSv2/src/arch/ppc/lib/floats.inc 2006-12-05 15:27:46 UTC (rev 2520) @@ -1,5 +1,21 @@ -/* Copyright 1999-2000 AG Electronics Ltd. */ -/* This code is distributed without warranty under the GPL v2 (see COPYING) */ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 1999-2000 AG Electronics Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ /* .text*/ .globl _init_float_registers Modified: trunk/LinuxBIOSv2/src/arch/ppc/lib/ppc.c =================================================================== --- trunk/LinuxBIOSv2/src/arch/ppc/lib/ppc.c 2006-12-05 14:13:10 UTC (rev 2519) +++ trunk/LinuxBIOSv2/src/arch/ppc/lib/ppc.c 2006-12-05 15:27:46 UTC (rev 2520) @@ -1,5 +1,21 @@ -/* Copyright 2000 AG Electronics Ltd. */ -/* This code is distributed without warranty under the GPL v2 (see COPYING) */ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2000 AG Electronics Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ #include "ppc.h" #include "ppcreg.h" Modified: trunk/LinuxBIOSv2/src/arch/ppc/lib/timer.c =================================================================== --- trunk/LinuxBIOSv2/src/arch/ppc/lib/timer.c 2006-12-05 14:13:10 UTC (rev 2519) +++ trunk/LinuxBIOSv2/src/arch/ppc/lib/timer.c 2006-12-05 15:27:46 UTC (rev 2520) @@ -1,5 +1,21 @@ -/* Copyright 2000 AG Electronics Ltd. */ -/* This code is distributed without warranty under the GPL v2 (see COPYING) */ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2000 AG Electronics Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ #include #include Modified: trunk/LinuxBIOSv2/src/cpu/ppc/mpc74xx/mpc74xx.inc =================================================================== --- trunk/LinuxBIOSv2/src/cpu/ppc/mpc74xx/mpc74xx.inc 2006-12-05 14:13:10 UTC (rev 2519) +++ trunk/LinuxBIOSv2/src/cpu/ppc/mpc74xx/mpc74xx.inc 2006-12-05 15:27:46 UTC (rev 2520) @@ -1,5 +1,21 @@ -/* Copyright 2000 AG Electronics Ltd. */ -/* This code is distributed without warranty under the GPL v2 (see COPYING) */ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2000 AG Electronics Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ /* * The aim of this code is to bring the machine from power-on to the point Modified: trunk/LinuxBIOSv2/src/cpu/ppc/ppc7xx/ppc7xx.inc =================================================================== --- trunk/LinuxBIOSv2/src/cpu/ppc/ppc7xx/ppc7xx.inc 2006-12-05 14:13:10 UTC (rev 2519) +++ trunk/LinuxBIOSv2/src/cpu/ppc/ppc7xx/ppc7xx.inc 2006-12-05 15:27:46 UTC (rev 2520) @@ -1,5 +1,21 @@ -/* Copyright 2000 AG Electronics Ltd. */ -/* This code is distributed without warranty under the GPL v2 (see COPYING) */ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2000 AG Electronics Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ /* * The aim of this code is to bring the machine from power-on to the point Modified: trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/clock.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/clock.c 2006-12-05 14:13:10 UTC (rev 2519) +++ trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/clock.c 2006-12-05 15:27:46 UTC (rev 2520) @@ -1,5 +1,21 @@ -/* Copyright 2000 AG Electronics Ltd. */ -/* This code is distributed without warranty under the GPL v2 (see COPYING) */ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2000 AG Electronics Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ #include Modified: trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/flash/amd800.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/flash/amd800.c 2006-12-05 14:13:10 UTC (rev 2519) +++ trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/flash/amd800.c 2006-12-05 15:27:46 UTC (rev 2520) @@ -1,5 +1,21 @@ -/* Copyright 2000 AG Electronics Ltd. */ -/* This code is distributed without warranty under the GPL v2 (see COPYING) */ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2000 AG Electronics Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ #include #include Modified: trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/flash/flash.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/flash/flash.c 2006-12-05 14:13:10 UTC (rev 2519) +++ trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/flash/flash.c 2006-12-05 15:27:46 UTC (rev 2520) @@ -1,5 +1,21 @@ -/* Copyright 2000 AG Electronics Ltd. */ -/* This code is distributed without warranty under the GPL v2 (see COPYING) */ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2000 AG Electronics Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ #include #include Modified: trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/flash.h =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/flash.h 2006-12-05 14:13:10 UTC (rev 2519) +++ trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/flash.h 2006-12-05 15:27:46 UTC (rev 2520) @@ -1,5 +1,21 @@ -/* Copyright 2000 AG Electronics Ltd. */ -/* This code is distributed without warranty under the GPL v2 (see COPYING) */ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2000 AG Electronics Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ #ifndef _FLASH_H #define _FLASH_H Modified: trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/nvram/nvram.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/nvram/nvram.c 2006-12-05 14:13:10 UTC (rev 2519) +++ trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/nvram/nvram.c 2006-12-05 15:27:46 UTC (rev 2520) @@ -1,5 +1,21 @@ -/* Copyright 2000 AG Electronics Ltd. */ -/* This code is distributed without warranty under the GPL v2 (see COPYING) */ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2000 AG Electronics Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ #include #include Modified: trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/nvram.h =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/nvram.h 2006-12-05 14:13:10 UTC (rev 2519) +++ trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/nvram.h 2006-12-05 15:27:46 UTC (rev 2520) @@ -1,5 +1,22 @@ -/* Copyright 2000 AG Electronics Ltd. */ -/* This code is distributed without warranty under the GPL v2 (see COPYING) */ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2000 AG Electronics Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + /* Definitions for nvram devices - these are flash or eeprom devices used to store information across power cycles and resets. Though they are byte addressable, writes must be committed to allow flash devices to write Modified: trunk/LinuxBIOSv2/src/pmc/altimus/mpc7410/mpc7410.c =================================================================== --- trunk/LinuxBIOSv2/src/pmc/altimus/mpc7410/mpc7410.c 2006-12-05 14:13:10 UTC (rev 2519) +++ trunk/LinuxBIOSv2/src/pmc/altimus/mpc7410/mpc7410.c 2006-12-05 15:27:46 UTC (rev 2520) @@ -1,5 +1,21 @@ -/* Copyright 2000 AG Electronics Ltd. */ -/* This code is distributed without warranty under the GPL v2 (see COPYING) */ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2000 AG Electronics Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ #include #include Modified: trunk/LinuxBIOSv2/src/pmc/altimus/mpc7410/setup.c =================================================================== --- trunk/LinuxBIOSv2/src/pmc/altimus/mpc7410/setup.c 2006-12-05 14:13:10 UTC (rev 2519) +++ trunk/LinuxBIOSv2/src/pmc/altimus/mpc7410/setup.c 2006-12-05 15:27:46 UTC (rev 2520) @@ -1,5 +1,21 @@ -/* Copyright 2000 AG Electronics Ltd. */ -/* This code is distributed without warranty under the GPL v2 (see COPYING) */ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2000 AG Electronics Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ #include "ppc.h" #include "ppcreg.h" From ebiederm at xmission.com Tue Dec 5 12:18:30 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Tue, 05 Dec 2006 04:18:30 -0700 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: <200612042001.09808.david-b@pacbell.net> (David Brownell's message of "Mon, 4 Dec 2006 20:01:08 -0800") References: <5986589C150B2F49A46483AC44C7BCA4907276@ssvlexmb2.amd.com> <200612042001.09808.david-b@pacbell.net> Message-ID: David Brownell writes: > On Sunday 03 December 2006 9:09 pm, Eric W. Biederman wrote: >> >> My driver should be sufficient to work with any EHCI in a realatively >> clean state, and needs no special BIOS support just the hardware. >> This appears to be different than the way the windows drivers are >> using these debug devices. > > I'm glad to see someone finally got progress on this ... :) > > Separately, I forwarded some stuff I did last year ... maybe it'll help. > You seem to have gotten further. Have you also observed that the > NetChip device seems to have polarity issues, such that only one > end behaves properly? I haven't yet. But I don't think I have actually tried turning the cable around in a very meaningful way yet either. Possibly this is something that has been fixed. I know there are some odd issues that I have encountered. Like occasionally I would need to stop the software on one side, or I would need to unplug it when things got sufficiently confused. > Note that this should **NOT** be specific to x86_64, since pretty > much any PCI based EHCI can do this. I wouldn't be able to use > this on my NForce2 box, for example ... So I took a quick look what it would take to do this truly generically and even initializing this generally when console code typically is registered looks like a problem. Although only because we don't get around to setting up pci_config space access helpers in a timely manner. To some extent that still sucks because you are still being initialized before the general ehci-hcd code. Regardless an arch specific i386 variant was easy to throw together. It still needs a bit of work but it basically worked. > As for EHCI registers, if this really _needs_ to live outside > of drivers/usb/host, then I'd suggest for > the relevant declarations ... the headers are > provided exactly for sharing such declaration between otherwise > unrelated parts of the tree. Yep that sounds like the right thing to do. I think I at least need to be called from something outside of drivers/usb and may need the code there. Doing this in a truly generic fashion looks like a major pain. Because all of the infrastructure needs to be fixed. Eric From ebiederm at xmission.com Tue Dec 5 12:01:07 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Tue, 05 Dec 2006 04:01:07 -0700 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: <200612042001.09808.david-b@pacbell.net> (David Brownell's message of "Mon, 4 Dec 2006 20:01:08 -0800") References: <5986589C150B2F49A46483AC44C7BCA4907276@ssvlexmb2.amd.com> <200612042001.09808.david-b@pacbell.net> Message-ID: Ok due to popular demands here is the slightly fixed patch that works on both i386 and x86_64. For the i386 version you must not have HIGHMEM64G enabled. I just rolled it all into one patch as I'm to lazy to transmit all 3 of them. Eric arch/i386/kernel/head.S | 8 + arch/x86_64/kernel/early_printk.c | 580 +++++++++++++++++++++++++++++++++++++ arch/x86_64/kernel/head.S | 11 +- drivers/usb/host/ehci.h | 8 + include/asm-i386/fixmap.h | 1 + include/asm-x86_64/fixmap.h | 1 + 6 files changed, 608 insertions(+), 1 deletions(-) diff --git a/arch/i386/kernel/head.S b/arch/i386/kernel/head.S index ca31f18..f683565 100644 --- a/arch/i386/kernel/head.S +++ b/arch/i386/kernel/head.S @@ -135,6 +135,12 @@ page_pde_offset = (__PAGE_OFFSET >> 20); jb 10b movl %edi,(init_pg_tables_end - __PAGE_OFFSET) + /* Do an early initialization of the fixmap area */ + movl $(swapper_pg_dir - __PAGE_OFFSET), %edx + movl $(swapper_pg_pmd - __PAGE_OFFSET), %eax + addl $0x007, %eax /* 0x007 = PRESENT+RW+USER */ + movl %eax, 4092(%edx) + #ifdef CONFIG_SMP xorl %ebx,%ebx /* This is the boot CPU (BSP) */ jmp 3f @@ -477,6 +483,8 @@ ENTRY(_stext) .section ".bss.page_aligned","w" ENTRY(swapper_pg_dir) .fill 1024,4,0 +ENTRY(swapper_pg_pmd) + .fill 1024,4,0 ENTRY(empty_zero_page) .fill 4096,1,0 diff --git a/arch/x86_64/kernel/early_printk.c b/arch/x86_64/kernel/early_printk.c index d4050a5..71f2f88 100644 --- a/arch/x86_64/kernel/early_printk.c +++ b/arch/x86_64/kernel/early_printk.c @@ -3,9 +3,19 @@ #include #include #include +#include +#include +#include +#include #include #include #include +#include +#include +#include +#define EARLY_PRINTK +#include "../../../drivers/usb/host/ehci.h" + /* Simple VGA output */ @@ -155,6 +165,564 @@ static struct console early_serial_console = { .index = -1, }; + +static struct ehci_caps __iomem *ehci_caps; +static struct ehci_regs __iomem *ehci_regs; +static struct ehci_dbg_port __iomem *ehci_debug; +static unsigned dbgp_endpoint_out; + +#define USB_DEBUG_DEVNUM 127 + +#define DBGP_DATA_TOGGLE 0x8800 +#define DBGP_PID_UPDATE(x, tok) \ + ((((x) ^ DBGP_DATA_TOGGLE) & 0xffff00) | ((tok) & 0xff)) + +#define DBGP_LEN_UPDATE(x, len) (((x) & ~0x0f) | ((len) & 0x0f)) +/* + * USB Packet IDs (PIDs) + */ + +/* token */ +#define USB_PID_OUT 0xe1 +#define USB_PID_IN 0x69 +#define USB_PID_SOF 0xa5 +#define USB_PID_SETUP 0x2d +/* handshake */ +#define USB_PID_ACK 0xd2 +#define USB_PID_NAK 0x5a +#define USB_PID_STALL 0x1e +#define USB_PID_NYET 0x96 +/* data */ +#define USB_PID_DATA0 0xc3 +#define USB_PID_DATA1 0x4b +#define USB_PID_DATA2 0x87 +#define USB_PID_MDATA 0x0f +/* Special */ +#define USB_PID_PREAMBLE 0x3c +#define USB_PID_ERR 0x3c +#define USB_PID_SPLIT 0x78 +#define USB_PID_PING 0xb4 +#define USB_PID_UNDEF_0 0xf0 + +#define USB_PID_DATA_TOGGLE 0x88 +#define DBGP_CLAIM (DBGP_OWNER | DBGP_ENABLED | DBGP_INUSE) + +#define PCI_CAP_ID_EHCI_DEBUG 0xa + +#define HUB_ROOT_RESET_TIME 50 /* times are in msec */ +#define HUB_SHORT_RESET_TIME 10 +#define HUB_LONG_RESET_TIME 200 +#define HUB_RESET_TIMEOUT 500 + +#define DBGP_MAX_PACKET 8 + +static int dbgp_wait_until_complete(void) +{ + unsigned ctrl; + for (;;) { + ctrl = readl(&ehci_debug->control); + /* Stop when the transaction is finished */ + if (ctrl & DBGP_DONE) + break; + } + /* Now that we have observed the completed transaction, + * clear the done bit. + */ + writel(ctrl | DBGP_DONE, &ehci_debug->control); + return (ctrl & DBGP_ERROR) ? -DBGP_ERRCODE(ctrl) : DBGP_LEN(ctrl); +} + +static void dbgp_mdelay(int ms) +{ + int i; + while (ms--) { + for (i = 0; i < 1000; i++) + outb(0x1, 0x80); + } +} + +static void dbgp_breath(void) +{ + /* Sleep to give the debug port a chance to breathe */ +} + +static int dbgp_wait_until_done(unsigned ctrl) +{ + unsigned pids, lpid; + int ret; + +retry: + writel(ctrl | DBGP_GO, &ehci_debug->control); + ret = dbgp_wait_until_complete(); + pids = readl(&ehci_debug->pids); + lpid = DBGP_PID_GET(pids); + + if (ret < 0) + return ret; + + /* If the port is getting full or it has dropped data + * start pacing ourselves, not necessary but it's friendly. + */ + if ((lpid == USB_PID_NAK) || (lpid == USB_PID_NYET)) + dbgp_breath(); + + /* If I get a NACK reissue the transmission */ + if (lpid == USB_PID_NAK) + goto retry; + + return ret; +} + +static void dbgp_set_data(const void *buf, int size) +{ + const unsigned char *bytes = buf; + unsigned lo, hi; + int i; + lo = hi = 0; + for (i = 0; i < 4 && i < size; i++) + lo |= bytes[i] << (8*i); + for (; i < 8 && i < size; i++) + hi |= bytes[i] << (8*(i - 4)); + writel(lo, &ehci_debug->data03); + writel(hi, &ehci_debug->data47); +} + +static void dbgp_get_data(void *buf, int size) +{ + unsigned char *bytes = buf; + unsigned lo, hi; + int i; + lo = readl(&ehci_debug->data03); + hi = readl(&ehci_debug->data47); + for (i = 0; i < 4 && i < size; i++) + bytes[i] = (lo >> (8*i)) & 0xff; + for (; i < 8 && i < size; i++) + bytes[i] = (hi >> (8*(i - 4))) & 0xff; +} + +static int dbgp_bulk_write(unsigned devnum, unsigned endpoint, const char *bytes, int size) +{ + unsigned pids, addr, ctrl; + int ret; + if (size > DBGP_MAX_PACKET) + return -1; + + addr = DBGP_EPADDR(devnum, endpoint); + + pids = readl(&ehci_debug->pids); + pids = DBGP_PID_UPDATE(pids, USB_PID_OUT); + + ctrl = readl(&ehci_debug->control); + ctrl = DBGP_LEN_UPDATE(ctrl, size); + ctrl |= DBGP_OUT; + ctrl |= DBGP_GO; + + dbgp_set_data(bytes, size); + writel(addr, &ehci_debug->address); + writel(pids, &ehci_debug->pids); + + ret = dbgp_wait_until_done(ctrl); + if (ret < 0) { + return ret; + } + return ret; +} + +static int dbgp_bulk_read(unsigned devnum, unsigned endpoint, void *data, int size) +{ + unsigned pids, addr, ctrl; + int ret; + + if (size > DBGP_MAX_PACKET) + return -1; + + addr = DBGP_EPADDR(devnum, endpoint); + + pids = readl(&ehci_debug->pids); + pids = DBGP_PID_UPDATE(pids, USB_PID_IN); + + ctrl = readl(&ehci_debug->control); + ctrl = DBGP_LEN_UPDATE(ctrl, size); + ctrl &= ~DBGP_OUT; + ctrl |= DBGP_GO; + + writel(addr, &ehci_debug->address); + writel(pids, &ehci_debug->pids); + ret = dbgp_wait_until_done(ctrl); + if (ret < 0) + return ret; + if (size > ret) + size = ret; + dbgp_get_data(data, size); + return ret; +} + +static int dbgp_control_msg(unsigned devnum, int requesttype, int request, + int value, int index, void *data, int size) +{ + unsigned pids, addr, ctrl; + struct usb_ctrlrequest req; + int read; + int ret; + + read = (requesttype & USB_DIR_IN) != 0; + if (size > (read?DBGP_MAX_PACKET:0)) + return -1; + + /* Compute the control message */ + req.bRequestType = requesttype; + req.bRequest = request; + req.wValue = value; + req.wIndex = index; + req.wLength = size; + + pids = DBGP_PID_SET(USB_PID_DATA0, USB_PID_SETUP); + addr = DBGP_EPADDR(devnum, 0); + + ctrl = readl(&ehci_debug->control); + ctrl = DBGP_LEN_UPDATE(ctrl, sizeof(req)); + ctrl |= DBGP_OUT; + ctrl |= DBGP_GO; + + /* Send the setup message */ + dbgp_set_data(&req, sizeof(req)); + writel(addr, &ehci_debug->address); + writel(pids, &ehci_debug->pids); + ret = dbgp_wait_until_done(ctrl); + if (ret < 0) + return ret; + + + /* Read the result */ + ret = dbgp_bulk_read(devnum, 0, data, size); + return ret; +} + + +/* Find a PCI capability */ +static __u32 __init find_cap(int num, int slot, int func, int cap) +{ + u8 pos; + int bytes; + if (!(read_pci_config_16(num,slot,func,PCI_STATUS) & PCI_STATUS_CAP_LIST)) + return 0; + pos = read_pci_config_byte(num,slot,func,PCI_CAPABILITY_LIST); + for (bytes = 0; bytes < 48 && pos >= 0x40; bytes++) { + u8 id; + pos &= ~3; + id = read_pci_config_byte(num,slot,func,pos+PCI_CAP_LIST_ID); + if (id == 0xff) + break; + if (id == cap) + return pos; + pos = read_pci_config_byte(num,slot,func,pos+PCI_CAP_LIST_NEXT); + } + return 0; +} + +static __u32 __init find_dbgp(int ehci_num, unsigned *rbus, unsigned *rslot, unsigned *rfunc) +{ + unsigned bus, slot, func; + + for (bus = 0; bus < 256; bus++) { + for (slot = 0; slot < 32; slot++) { + for (func = 0; func < 8; func++) { + u32 class; + unsigned cap; + class = read_pci_config(bus, slot, func, PCI_CLASS_REVISION); + if ((class >> 8) != PCI_CLASS_SERIAL_USB_EHCI) + continue; + cap = find_cap(bus, slot, func, PCI_CAP_ID_EHCI_DEBUG); + if (!cap) + continue; + if (ehci_num-- != 0) + continue; + *rbus = bus; + *rslot = slot; + *rfunc = func; + return cap; + } + } + } + return 0; +} + +static int ehci_reset_port(int port) +{ + unsigned portsc; + unsigned delay_time, delay; + + /* Reset the usb debug port */ + portsc = readl(&ehci_regs->port_status[port - 1]); + portsc &= ~PORT_PE; + portsc |= PORT_RESET; + writel(portsc, &ehci_regs->port_status[port - 1]); + + delay = HUB_ROOT_RESET_TIME; + for (delay_time = 0; delay_time < HUB_RESET_TIMEOUT; + delay_time += delay) { + dbgp_mdelay(delay); + + portsc = readl(&ehci_regs->port_status[port - 1]); + if (portsc & PORT_RESET) { + /* force reset to complete */ + writel(portsc & ~(PORT_RWC_BITS | PORT_RESET), + &ehci_regs->port_status[port - 1]); + while (portsc & PORT_RESET) + portsc = readl(&ehci_regs->port_status[port - 1]); + } + + /* Device went away? */ + if (!(portsc & PORT_CONNECT)) + return -ENOTCONN; + + /* bomb out completely if something weird happend */ + if ((portsc & PORT_CSC)) + return -EINVAL; + + /* If we've finished resetting, then break out of the loop */ + if (!(portsc & PORT_RESET) && (portsc & PORT_PE)) + return 0; + } + return -EBUSY; +} + +static int ehci_wait_for_port(int port) +{ + unsigned status; + int ret, reps; + for (reps = 0; reps >= 0; reps++) { + status = readl(&ehci_regs->status); + if (status & STS_PCD) { + ret = ehci_reset_port(port); + if (ret == 0) + return 0; + } + } + return -ENOTCONN; +} + + +#define DBGP_DEBUG 0 +#if DBGP_DEBUG +void early_printk(const char *fmt, ...); +# define dbgp_printk early_printk +#else +static inline void dbgp_printk(const char *fmt, ...) { } +#endif + +static int ehci_setup(void) +{ + unsigned cmd, ctrl, status, portsc, hcs_params, debug_port, n_ports; + int ret; + + hcs_params = readl(&ehci_caps->hcs_params); + debug_port = HCS_DEBUG_PORT(hcs_params); + n_ports = HCS_N_PORTS(hcs_params); + + dbgp_printk("debug_port: %d\n", debug_port); + dbgp_printk("n_ports: %d\n", n_ports); + + /* Reset the EHCI controller */ + cmd = readl(&ehci_regs->command); + cmd |=CMD_RESET; + writel(cmd, &ehci_regs->command); + while (cmd & CMD_RESET) + cmd = readl(&ehci_regs->command); + + /* Claim ownership, but do not enable yet */ + ctrl = readl(&ehci_debug->control); + ctrl |= DBGP_OWNER; + ctrl &= ~(DBGP_ENABLED | DBGP_INUSE); + writel(ctrl, &ehci_debug->control); + + /* Start the ehci running */ + cmd = readl(&ehci_regs->command); + cmd &= ~(CMD_LRESET | CMD_IAAD | CMD_PSE | CMD_ASE | CMD_RESET); + cmd |= CMD_RUN; + writel(cmd, &ehci_regs->command); + + /* Ensure everything is routed to the EHCI */ + writel(FLAG_CF, &ehci_regs->configured_flag); + + /* Wait until the controller is no longer halted */ + do { + status = readl(&ehci_regs->status); + } while (status & STS_HALT); + + /* Wait for a device to show up in the debug port */ + ret = ehci_wait_for_port(debug_port); + if (ret < 0) { + dbgp_printk("No device found in debug port\n"); + return -1; + } + + /* Enable the debug port */ + ctrl = readl(&ehci_debug->control); + ctrl |= DBGP_CLAIM; + writel(ctrl, &ehci_debug->control); + ctrl = readl(&ehci_debug->control); + if ((ctrl & DBGP_CLAIM) != DBGP_CLAIM) { + dbgp_printk("No device in debug port\n"); + writel(ctrl & ~DBGP_CLAIM, &ehci_debug->control); + return -1; + + } + + /* Completely transfer the debug device to the debug controller */ + portsc = readl(&ehci_regs->port_status[debug_port - 1]); + portsc &= ~PORT_PE; + writel(portsc, &ehci_regs->port_status[debug_port - 1]); + + return 0; +} + +static __init void early_dbgp_init(char *s) +{ + struct usb_debug_descriptor dbgp_desc; + void __iomem *ehci_bar; + unsigned ctrl, devnum; + unsigned bus, slot, func, cap; + unsigned debug_port, bar, offset; + unsigned bar_val; + unsigned dbgp_num; + char *e; + int ret; + + if (!early_pci_allowed()) + return; + + dbgp_num = 0; + if (*s) { + dbgp_num = simple_strtoul(s, &e, 10); + } + dbgp_printk("dbgp_num: %d\n", dbgp_num); + cap = find_dbgp(dbgp_num, &bus, &slot, &func); + if (!cap) + return; + + dbgp_printk("Found EHCI debug port\n"); + + debug_port = read_pci_config(bus, slot, func, cap); + bar = (debug_port >> 29) & 0x7; + bar = (bar * 4) + 0xc; + offset = (debug_port >> 16) & 0xfff; + dbgp_printk("bar: %02x offset: %03x\n", bar, offset); + if (bar != PCI_BASE_ADDRESS_0) { + dbgp_printk("only debug ports on bar 1 handled.\n"); + return; + } + + bar_val = read_pci_config(bus, slot, func, PCI_BASE_ADDRESS_0); + dbgp_printk("bar: %02x offset: %03x\n", bar, offset); + if (bar_val & ~PCI_BASE_ADDRESS_MEM_MASK) { + dbgp_printk("only simple 32bit mmio bars supported\n"); + return; + } + + + /* FIXME I don't have the bar size so just guess PAGE_SIZE is more + * than enough. 1K is the biggest I have seen. + */ + dbgp_printk("dbgp pre-set_fixmap_nocache\n"); + set_fixmap_nocache(FIX_DBGP_BASE, bar_val & PAGE_MASK); + dbgp_printk("dbgp post-set_fixmap_nocache\n"); + ehci_bar = (void __iomem *)__fix_to_virt(FIX_DBGP_BASE); + ehci_bar += bar_val & ~PAGE_MASK; + dbgp_printk("ehci_bar: %p\n", ehci_bar); + + ehci_caps = ehci_bar; + ehci_regs = ehci_bar + HC_LENGTH(readl(&ehci_caps->hc_capbase)); + ehci_debug = ehci_bar + offset; + + ret = ehci_setup(); + if (ret < 0) { + dbgp_printk("ehci_setup failed\n"); + return; + } + + /* Find the debug device and make it device number 127 */ + for (devnum = 0; devnum <= 127; devnum++) { + ret = dbgp_control_msg(devnum, + USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_DEVICE, + USB_REQ_GET_DESCRIPTOR, (USB_DT_DEBUG << 8), 0, + &dbgp_desc, sizeof(dbgp_desc)); + if (ret > 0) + break; + } + if (devnum > 127) { + dbgp_printk("Could not find attached debug device\n"); + goto err; + } + if (ret < 0) { + dbgp_printk("Attached device is not a debug device\n"); + goto err; + } + dbgp_endpoint_out = dbgp_desc.bDebugOutEndpoint; + + /* Move the device to 127 if it isn't already there */ + if (devnum != USB_DEBUG_DEVNUM) { + ret = dbgp_control_msg(devnum, + USB_DIR_OUT | USB_TYPE_STANDARD | USB_RECIP_DEVICE, + USB_REQ_SET_ADDRESS, USB_DEBUG_DEVNUM, 0, NULL, 0); + if (ret < 0) { + dbgp_printk("Could not move attached device to %d\n", + USB_DEBUG_DEVNUM); + goto err; + } + devnum = USB_DEBUG_DEVNUM; + } + + /* Enable the debug interface */ + ret = dbgp_control_msg(USB_DEBUG_DEVNUM, + USB_DIR_OUT | USB_TYPE_STANDARD | USB_RECIP_DEVICE, + USB_REQ_SET_FEATURE, USB_DEVICE_DEBUG_MODE, 0, NULL, 0); + if (ret < 0) { + dbgp_printk(" Could not enable the debug device\n"); + goto err; + } + + /* Perform a small write to get the even/odd data state in sync + */ + ret = dbgp_bulk_write(USB_DEBUG_DEVNUM, dbgp_endpoint_out, " ",1); + if (ret < 0) { + dbgp_printk("dbgp_bulk_write failed: %d\n", ret); + goto err; + } + + + return; +err: + /* Things didn't work so remove my claim */ + ctrl = readl(&ehci_debug->control); + ctrl &= ~(DBGP_CLAIM | DBGP_OUT); + writel(ctrl, &ehci_debug->control); + return; +} + +static void early_dbgp_write(struct console *con, const char *str, unsigned n) +{ + int chunk, ret; + if (!ehci_debug) + return; + while (n > 0) { + chunk = n; + if (chunk > DBGP_MAX_PACKET) + chunk = DBGP_MAX_PACKET; + ret = dbgp_bulk_write(USB_DEBUG_DEVNUM, + dbgp_endpoint_out, str, chunk); + str += chunk; + n -= chunk; + } +} + +static struct console early_dbgp_console = { + .name = "earlydbg", + .write = early_dbgp_write, + .flags = CON_PRINTBUFFER, + .index = -1, +}; + /* Console interface to a host file on AMD's SimNow! */ static int simnow_fd; @@ -242,8 +810,20 @@ static int __init setup_early_printk(char *buf) simnow_init(buf + 6); early_console = &simnow_console; keep_early = 1; + } else if (!strncmp(buf, "dbgp", 4)) { + early_dbgp_init(buf + 4); + early_console = &early_dbgp_console; } register_console(early_console); +#if DBGP_DEBUG + { + static const char dbgp_test_str[] = + "The quick brown fox jumped over the lazy dog!\n"; + early_dbgp_init(""); + early_dbgp_write(&early_dbgp_console, + dbgp_test_str, sizeof(dbgp_test_str) - 1); + } +#endif return 0; } diff --git a/arch/x86_64/kernel/head.S b/arch/x86_64/kernel/head.S index 2f65469..4004965 100644 --- a/arch/x86_64/kernel/head.S +++ b/arch/x86_64/kernel/head.S @@ -271,7 +271,16 @@ NEXT_PAGE(level3_kernel_pgt) .fill 510,8,0 /* (2^48-(2*1024*1024*1024)-((2^39)*511))/(2^30) = 510 */ .quad phys_level2_kernel_pgt | 0x007 - .fill 1,8,0 + .quad phys_level2_fixmap_pgt | 0x007 + +NEXT_PAGE(level2_fixmap_pgt) + .fill 506,8,0 + .quad phys_level1_fixmap_pgt | 0x007 + /* 8MB reserved for vsyscalls + a 2MB hole = 4 + 1 entries */ + .fill 5,8,0 + +NEXT_PAGE(level1_fixmap_pgt) + .fill 512,8,0 NEXT_PAGE(level2_ident_pgt) /* 40MB for bootup. */ diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h index bbc3082..0a67192 100644 --- a/drivers/usb/host/ehci.h +++ b/drivers/usb/host/ehci.h @@ -46,6 +46,7 @@ struct ehci_stats { #define EHCI_MAX_ROOT_PORTS 15 /* see HCS_N_PORTS */ +#ifndef EARLY_PRINTK struct ehci_hcd { /* one per controller */ /* glue to PCI and HCD framework */ struct ehci_caps __iomem *caps; @@ -160,6 +161,7 @@ timer_action (struct ehci_hcd *ehci, enum ehci_timer_action action) mod_timer (&ehci->watchdog, t); } } +#endif /* EARLY_PRINTK */ /*-------------------------------------------------------------------------*/ @@ -384,6 +386,7 @@ union ehci_shadow { * These appear in both the async and (for interrupt) periodic schedules. */ +#ifndef EARLY_PRINTK struct ehci_qh { /* first part defined by EHCI spec */ __le32 hw_next; /* see EHCI 3.6.1 */ @@ -432,6 +435,7 @@ struct ehci_qh { #define NO_FRAME ((unsigned short)~0) /* pick new start */ struct usb_device *dev; /* access to TT */ } __attribute__ ((aligned (32))); +#endif /* EARLY_PRITNK */ /*-------------------------------------------------------------------------*/ @@ -601,6 +605,8 @@ struct ehci_fstn { union ehci_shadow fstn_next; /* ptr to periodic q entry */ } __attribute__ ((aligned (32))); +#ifndef EARLY_PRINTK + /*-------------------------------------------------------------------------*/ #ifdef CONFIG_USB_EHCI_ROOT_HUB_TT @@ -659,4 +665,6 @@ ehci_port_speed(struct ehci_hcd *ehci, unsigned int portsc) /*-------------------------------------------------------------------------*/ +#endif /* EARLY_PRINTK */ + #endif /* __LINUX_EHCI_HCD_H */ diff --git a/include/asm-i386/fixmap.h b/include/asm-i386/fixmap.h index 02428cb..ea08885 100644 --- a/include/asm-i386/fixmap.h +++ b/include/asm-i386/fixmap.h @@ -56,6 +56,7 @@ extern unsigned long __FIXADDR_TOP; enum fixed_addresses { FIX_HOLE, FIX_VDSO, + FIX_DBGP_BASE, #ifdef CONFIG_X86_LOCAL_APIC FIX_APIC_BASE, /* local (CPU) APIC) -- required for SMP or not */ #endif diff --git a/include/asm-x86_64/fixmap.h b/include/asm-x86_64/fixmap.h index 1b620db..1f2978a 100644 --- a/include/asm-x86_64/fixmap.h +++ b/include/asm-x86_64/fixmap.h @@ -36,6 +36,7 @@ enum fixed_addresses { VSYSCALL_LAST_PAGE, VSYSCALL_FIRST_PAGE = VSYSCALL_LAST_PAGE + ((VSYSCALL_END-VSYSCALL_START) >> PAGE_SHIFT) - 1, VSYSCALL_HPET, + FIX_DBGP_BASE, FIX_HPET_BASE, FIX_APIC_BASE, /* local (CPU) APIC) -- required for SMP or not */ FIX_IO_APIC_BASE_0, From yinghai.lu at amd.com Wed Dec 6 00:29:32 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 5 Dec 2006 15:29:32 -0800 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. Message-ID: <5986589C150B2F49A46483AC44C7BCA490728A@ssvlexmb2.amd.com> -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of ebiederm at xmission.com Sent: Tuesday, December 05, 2006 3:01 AM >+static int ehci_wait_for_port(int port) >+{ >+ unsigned status; >+ int ret, reps; >+ for (reps = 0; reps >= 0; reps++) { >+ status = readl(&ehci_regs->status); >+ if (status & STS_PCD) { >+ ret = ehci_reset_port(port); >+ if (ret == 0) >+ return 0; >+ } >+ } >+ return -ENOTCONN; >+} >+ What do you mean by + for (reps = 0; reps >= 0; reps++) { ? YH From ebiederm at xmission.com Wed Dec 6 00:50:05 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Tue, 05 Dec 2006 16:50:05 -0700 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: <5986589C150B2F49A46483AC44C7BCA490728A@ssvlexmb2.amd.com> (Yinghai Lu's message of "Tue, 5 Dec 2006 15:29:32 -0800") References: <5986589C150B2F49A46483AC44C7BCA490728A@ssvlexmb2.amd.com> Message-ID: "Lu, Yinghai" writes: > -----Original Message----- > From: linuxbios-bounces at linuxbios.org > [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of > ebiederm at xmission.com > Sent: Tuesday, December 05, 2006 3:01 AM > >>+static int ehci_wait_for_port(int port) >>+{ >>+ unsigned status; >>+ int ret, reps; >>+ for (reps = 0; reps >= 0; reps++) { >>+ status = readl(&ehci_regs->status); >>+ if (status & STS_PCD) { >>+ ret = ehci_reset_port(port); >>+ if (ret == 0) >>+ return 0; >>+ } >>+ } >>+ return -ENOTCONN; >>+} >>+ > > What do you mean by > + for (reps = 0; reps >= 0; reps++) { > ? If you will not reps is negative. Roughly it is a loop that will timeout eventually if a usb debug cable is not present. Putting some deliberate delays in there so I could be certain of timing out after a second or two would probably be better, but I don't have anything that resembles a good timer at that point. The problem is you have to wait until the ehci notices your usb debug cable before you reset it and get it going and that can be a non-trivial amount of time. So the loop is 100% necessary. So since I didn't know how many loop iterations made sense I allowed it to loop for 2^31 times or until reps goes negative. Eric From yinghai.lu at amd.com Wed Dec 6 01:00:22 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 5 Dec 2006 16:00:22 -0800 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. Message-ID: <5986589C150B2F49A46483AC44C7BCA490728B@ssvlexmb2.amd.com> -----Original Message----- From: ebiederm at xmission.com [mailto:ebiederm at xmission.com] Sent: Tuesday, December 05, 2006 3:50 PM >If you will not reps is negative. Roughly it is a loop >that will timeout eventually if a usb debug cable is not present. >Putting some deliberate delays in there so I could be certain >of timing out after a second or two would probably be better, but >I don't have anything that resembles a good timer at that point. You have dbgp_mdelay in your code. YH From stuge-linuxbios at cdy.org Wed Dec 6 17:39:44 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Wed, 6 Dec 2006 17:39:44 +0100 Subject: [LinuxBIOS] C3 Lightning Talk abstract Message-ID: <20061206163944.10830.qmail@cdy.org> I'm going to C3 and would like to hold a LinuxBIOS Lightning Talk. See http://events.ccc.de/congress/2006/Lightning_Talks and http://www.guckes.net/cccc2006/lightning_talks.html We get five minutes. What do we want to say? I was thinking: (Please revise this list. :) * Describe what LinuxBIOS is and does, benefits and use cases off the excellent wiki welcome page. * Talk about payloads. * Mention OLPC. (But what are the important points?) * Show a demo. //Peter From ak at suse.de Wed Dec 6 18:31:14 2006 From: ak at suse.de (Andi Kleen) Date: Wed, 6 Dec 2006 18:31:14 +0100 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA4907276@ssvlexmb2.amd.com> <200612042001.09808.david-b@pacbell.net> Message-ID: <200612061831.14268.ak@suse.de> On Tuesday 05 December 2006 12:01, Eric W. Biederman wrote: > > Ok due to popular demands here is the slightly fixed patch that works > on both i386 and x86_64. For the i386 version you must not have > HIGHMEM64G enabled. > > I just rolled it all into one patch as I'm to lazy to transmit all > 3 of them. You should definitely move the usb code to a separate file Documentation/* needs to document the new option Also for usb console keep should be made default because the output won't be duplicated. -Andi From a1426z at gawab.com Wed Dec 6 19:17:24 2006 From: a1426z at gawab.com (Al Boldi) Date: Wed, 6 Dec 2006 21:17:24 +0300 Subject: [LinuxBIOS] C3 Lightning Talk abstract In-Reply-To: <20061206163944.10830.qmail@cdy.org> References: <20061206163944.10830.qmail@cdy.org> Message-ID: <200612062117.24179.a1426z@gawab.com> Peter Stuge wrote: > I'm going to C3 and would like to hold a LinuxBIOS Lightning Talk. > See http://events.ccc.de/congress/2006/Lightning_Talks and > http://www.guckes.net/cccc2006/lightning_talks.html > > We get five minutes. What do we want to say? > > I was thinking: (Please revise this list. :) > > * Describe what LinuxBIOS is and does, and does not (i.e: not backward-compatible with 16bit bios calls) > benefits and use cases off the > excellent wiki welcome page. > > * Talk about payloads. > > * Mention OLPC. (But what are the important points?) > > * Show a demo. Thanks! -- Al From yinghai.lu at amd.com Wed Dec 6 21:43:08 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Wed, 6 Dec 2006 12:43:08 -0800 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. Message-ID: <5986589C150B2F49A46483AC44C7BCA4907290@ssvlexmb2.amd.com> -----Original Message----- From: Andi Kleen [mailto:ak at suse.de] Sent: Wednesday, December 06, 2006 9:31 AM >Also for usb console keep should be made default because the output won't >be duplicated. Still need to tx_read to make console can take command? Or transfer to generic usb_serial or usb_debug that Greg just added with console=ttyUSB0 to get tty? Then you still need to disable that early_console sometime later. YH From stuge-linuxbios at cdy.org Wed Dec 6 21:58:44 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Wed, 6 Dec 2006 21:58:44 +0100 Subject: [LinuxBIOS] C3 Lightning Talk abstract In-Reply-To: <200612062117.24179.a1426z@gawab.com> References: <20061206163944.10830.qmail@cdy.org> <200612062117.24179.a1426z@gawab.com> Message-ID: <20061206205844.15218.qmail@cdy.org> On Wed, Dec 06, 2006 at 09:17:24PM +0300, Al Boldi wrote: > > * Describe what LinuxBIOS is and does, > > and does not (i.e: not backward-compatible with 16bit bios calls) Good point, thanks! Also: * Talk about all the improvements in v3. //Peter From ak at suse.de Wed Dec 6 21:58:39 2006 From: ak at suse.de (Andi Kleen) Date: Wed, 6 Dec 2006 21:58:39 +0100 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: <5986589C150B2F49A46483AC44C7BCA4907290@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA4907290@ssvlexmb2.amd.com> Message-ID: <200612062158.39250.ak@suse.de> On Wednesday 06 December 2006 21:43, Lu, Yinghai wrote: > -----Original Message----- > From: Andi Kleen [mailto:ak at suse.de] > Sent: Wednesday, December 06, 2006 9:31 AM > > >Also for usb console keep should be made default because the output > won't > >be duplicated. > > Still need to tx_read to make console can take command? > > Or transfer to generic usb_serial I think the protocols are incompatible? > or usb_debug that Greg just added Ah I didn't notice that. If there is a usb_debug that works later then yes it would need to be disabled. However I see a certain advantage to keep using the early usb console because it doesn't need any interrupts. So when the kernel is very confused after an oops it might have a higher chance to still get the oops out. I haven't looked how the other usb_debug works -- if it's polled too then it wouldn't have much advantage. Ok one advantage of a non early usb_debug is that it will properly use pci config space locking. The early implementation just ignores the port cf8 lock which might lead to corruption later. That's ok after an oops, but during normal output it can actually lead to data corruption if it interferes with somebody else's config write. Also on some systems cf8 is broken and doesn't work. Disadvantage of using the locks of course is that it can deadlock if an oops happen inside the critical region. So they might need to be added to bust_spinlocks() And it would be good if the late usb_debug still wouldn't rely on interrupts. But I agree it's probably better to transition to another usb_debug console and not do keep by default. -Andi From yinghai.lu at amd.com Wed Dec 6 22:08:14 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Wed, 6 Dec 2006 13:08:14 -0800 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. Message-ID: <5986589C150B2F49A46483AC44C7BCA4907291@ssvlexmb2.amd.com> -----Original Message----- From: Andi Kleen [mailto:ak at suse.de] Sent: Wednesday, December 06, 2006 12:59 PM >I haven't looked how the other usb_debug works -- if it's polled >too then it wouldn't have much advantage. Need to verify if the two sides of debug cable are identical. >And it would be good if the late usb_debug still wouldn't rely >on interrupts. Yes, esp. when usb can not get irq assigned correctly. YH From ebiederm at xmission.com Wed Dec 6 22:12:44 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Wed, 06 Dec 2006 14:12:44 -0700 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: <200612062158.39250.ak@suse.de> (Andi Kleen's message of "Wed, 6 Dec 2006 21:58:39 +0100") References: <5986589C150B2F49A46483AC44C7BCA4907290@ssvlexmb2.amd.com> <200612062158.39250.ak@suse.de> Message-ID: Andi Kleen writes: > On Wednesday 06 December 2006 21:43, Lu, Yinghai wrote: >> -----Original Message----- >> From: Andi Kleen [mailto:ak at suse.de] >> Sent: Wednesday, December 06, 2006 9:31 AM >> >> >Also for usb console keep should be made default because the output >> won't >> >be duplicated. >> >> Still need to tx_read to make console can take command? >> >> Or transfer to generic usb_serial > > I think the protocols are incompatible? > >> or usb_debug that Greg just added > > Ah I didn't notice that. If there is a usb_debug that works later > then yes it would need to be disabled. > > However I see a certain advantage to keep using the early > usb console because it doesn't need any interrupts. So when the > kernel is very confused after an oops it might have a higher > chance to still get the oops out. > > I haven't looked how the other usb_debug works -- if it's polled > too then it wouldn't have much advantage. > > Ok one advantage of a non early usb_debug is that it will properly use pci > config space locking. The early implementation just ignores the port cf8 > lock which might lead to corruption later. That's ok after > an oops, but during normal output it can actually lead to > data corruption if it interferes with somebody else's config write. > Also on some systems cf8 is broken and doesn't work. > > Disadvantage of using the locks of course is that it can deadlock > if an oops happen inside the critical region. So they might need > to be added to bust_spinlocks() > > And it would be good if the late usb_debug still wouldn't rely > on interrupts. > > But I agree it's probably better to transition to another usb_debug > console and not do keep by default. The only use of the early pci code is for finding the hardware. Everything else is through mmio. The practical issue is that during the normal initialization of the ehci the reset of the hardware state is going to remove the delegation to the ehci debug registers. Greg's current thing uses the hardware but through the normal interrupt driven usb methods. I think it is worth using the ehci debug registers if possible as that (except for reset) gives us independent control of what is going on. For understanding what needs to happen except for the initialization just look at my dbgp_bulk_write routine. That and the functions it call is the only code in there that is executed. It is just a hair more complicated than other early debug port code because it has to deal with retransmits. But I think it is still under 100 lines of code. Eric From ak at suse.de Wed Dec 6 22:24:33 2006 From: ak at suse.de (Andi Kleen) Date: Wed, 6 Dec 2006 22:24:33 +0100 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: <20061206211734.78DCB1E75FF@adsl-69-226-248-13.dsl.pltn13.pacbell.net> References: <5986589C150B2F49A46483AC44C7BCA4907290@ssvlexmb2.amd.com> <200612062158.39250.ak@suse.de> <20061206211734.78DCB1E75FF@adsl-69-226-248-13.dsl.pltn13.pacbell.net> Message-ID: <200612062224.33482.ak@suse.de> \ > - Host, to which that console connects (through the debug device); > runs usb_debug, much like any other usb-serial device My understanding was that the client could run in user space only on top of libusb. > > It's analagous to debugging an embedded box using a serial console > with a Linux host ... except the target here is a PC, not an ARM > (or PPC, MIPS, etc) custom board. > > > Once the coexistence issues between the debug port and normal EHCI > driver get worked, there's no reason not to keep using that debug > port as a system console. One reason is the one I covered in my last mail -- locking of the PCI type 1 ports. However I suppose it would be ok to switch Eric's code between early pci access and locked one once the PCI subsystem is up and running. Just don't forget bust_spinlocks() -Andi From ebiederm at xmission.com Wed Dec 6 22:37:29 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Wed, 06 Dec 2006 14:37:29 -0700 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: <200612062224.33482.ak@suse.de> (Andi Kleen's message of "Wed, 6 Dec 2006 22:24:33 +0100") References: <5986589C150B2F49A46483AC44C7BCA4907290@ssvlexmb2.amd.com> <200612062158.39250.ak@suse.de> <20061206211734.78DCB1E75FF@adsl-69-226-248-13.dsl.pltn13.pacbell.net> <200612062224.33482.ak@suse.de> Message-ID: Andi Kleen writes: > \ >> - Host, to which that console connects (through the debug device); >> runs usb_debug, much like any other usb-serial device > > My understanding was that the client could run in user > space only on top of libusb. Looks like a normal serial port with greg's patch. I still need to try it though. > One reason is the one I covered in my last mail -- locking of the PCI > type 1 ports. > > However I suppose it would be ok to switch Eric's code between early > pci access and locked one once the PCI subsystem is up and running. > Just don't forget bust_spinlocks() No pci access on that path. Eric From ak at suse.de Wed Dec 6 22:59:45 2006 From: ak at suse.de (Andi Kleen) Date: Wed, 6 Dec 2006 22:59:45 +0100 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA4907290@ssvlexmb2.amd.com> <200612062224.33482.ak@suse.de> Message-ID: <200612062259.46140.ak@suse.de> > > However I suppose it would be ok to switch Eric's code between early > > pci access and locked one once the PCI subsystem is up and running. > > Just don't forget bust_spinlocks() > > No pci access on that path. Hmm good point. Ok ignore that then. keep should be default then. -Andi From c-d.hailfinger.devel.2006 at gmx.net Thu Dec 7 02:16:47 2006 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 07 Dec 2006 02:16:47 +0100 Subject: [LinuxBIOS] C3 Lightning Talk abstract In-Reply-To: <20061206163944.10830.qmail@cdy.org> References: <20061206163944.10830.qmail@cdy.org> Message-ID: <45776B7F.2050608@gmx.net> Peter Stuge wrote: > * Describe what LinuxBIOS is and does, benefits and use cases off the > excellent wiki welcome page. Since C3 is going to be frequented by security-conscious people and general interest in tampering with hardware will be high, try this: * SSH into BIOS for the paranoid * Authenticated booting * Using any TPM against the intention of the vendor Other points: * Very fast boot process -> for routers it means availability one second after switchon > * Mention OLPC. (But what are the important points?) * BIOS can already use wireless * Automatic authenticated BIOS updates * BIOS can be tailored to individual needs (wireless/wired network card support, ipv4/ipv6, flat panel/vga...) * BIOS bugs can be fixed even if upstream is not ready/cooperating (not that I would want to suggest that upstream was uncooperative) Regards, Carl-Daniel -- http://www.hailfinger.org/ From cm7900 at hotmail.com Sat Dec 2 04:00:53 2006 From: cm7900 at hotmail.com (Max Power) Date: Sat, 02 Dec 2006 03:00:53 +0000 Subject: [LinuxBIOS] Overclocking Message-ID: Hello I whant to know, what are the plans for including overclocking (cpu, ram, etc.) features in the linuxBIOS? _________________________________________________________________ Charla con tus amigos en l?nea mediante MSN Messenger: http://messenger.latam.msn.com/ From david-b at pacbell.net Tue Dec 5 05:01:08 2006 From: david-b at pacbell.net (David Brownell) Date: Mon, 4 Dec 2006 20:01:08 -0800 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA4907276@ssvlexmb2.amd.com> Message-ID: <200612042001.09808.david-b@pacbell.net> On Sunday 03 December 2006 9:09 pm, Eric W. Biederman wrote: > > My driver should be sufficient to work with any EHCI in a realatively > clean state, and needs no special BIOS support just the hardware. > This appears to be different than the way the windows drivers are > using these debug devices. I'm glad to see someone finally got progress on this ... :) Separately, I forwarded some stuff I did last year ... maybe it'll help. You seem to have gotten further. Have you also observed that the NetChip device seems to have polarity issues, such that only one end behaves properly? Note that this should **NOT** be specific to x86_64, since pretty much any PCI based EHCI can do this. I wouldn't be able to use this on my NForce2 box, for example ... As for EHCI registers, if this really _needs_ to live outside of drivers/usb/host, then I'd suggest for the relevant declarations ... the headers are provided exactly for sharing such declaration between otherwise unrelated parts of the tree. - Dave From david-b at pacbell.net Wed Dec 6 22:17:34 2006 From: david-b at pacbell.net (David Brownell) Date: Wed, 06 Dec 2006 13:17:34 -0800 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: <200612062158.39250.ak@suse.de> References: <5986589C150B2F49A46483AC44C7BCA4907290@ssvlexmb2.amd.com> <200612062158.39250.ak@suse.de> Message-ID: <20061206211734.78DCB1E75FF@adsl-69-226-248-13.dsl.pltn13.pacbell.net> > > or usb_debug that Greg just added > > Ah I didn't notice that. If there is a usb_debug that works later > then yes it would need to be disabled. I detect confusion here ... remember that there are potentially two distinct Linux systems involved here: - Target, with some kind of console hooked up to the debug device; runs this _new_ "early debug port" code. - Host, to which that console connects (through the debug device); runs usb_debug, much like any other usb-serial device It's analagous to debugging an embedded box using a serial console with a Linux host ... except the target here is a PC, not an ARM (or PPC, MIPS, etc) custom board. Once the coexistence issues between the debug port and normal EHCI driver get worked, there's no reason not to keep using that debug port as a system console. Heck, being able to do that might be a huge win with some of the nasty suspend/resume problems we've got. - Dave From david-b at pacbell.net Thu Dec 7 00:47:49 2006 From: david-b at pacbell.net (David Brownell) Date: Wed, 6 Dec 2006 15:47:49 -0800 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: <200612062224.33482.ak@suse.de> References: <5986589C150B2F49A46483AC44C7BCA4907290@ssvlexmb2.amd.com> <20061206211734.78DCB1E75FF@adsl-69-226-248-13.dsl.pltn13.pacbell.net> <200612062224.33482.ak@suse.de> Message-ID: <200612061547.51524.david-b@pacbell.net> On Wednesday 06 December 2006 1:24 pm, Andi Kleen wrote: > > - Host, to which that console connects (through the debug device); > > runs usb_debug, much like any other usb-serial device > > My understanding was that the client could run in user > space only on top of libusb. I suppose it could, if you didn't want to use it like a normal serial consoe. > > It's analagous to debugging an embedded box using a serial console > > with a Linux host ... except the target here is a PC, not an ARM > > (or PPC, MIPS, etc) custom board. > > > > > > Once the coexistence issues between the debug port and normal EHCI > > driver get worked, there's no reason not to keep using that debug > > port as a system console. > > One reason is the one I covered in my last mail -- locking of the PCI > type 1 ports. That'd be part of coexistence. The debug port is _designed_ to share two different drivers like that ... EHCI can see, as it comes up, whether the debug port is in use, and could then ignore it. (At least, unless/until the debug device gets removed.) - Dave From gregkh at suse.de Fri Dec 1 19:41:23 2006 From: gregkh at suse.de (Greg KH) Date: Fri, 1 Dec 2006 10:41:23 -0800 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: <5986589C150B2F49A46483AC44C7BCA4907273@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA4907273@ssvlexmb2.amd.com> Message-ID: <20061201184123.GA2996@suse.de> On Fri, Dec 01, 2006 at 10:26:19AM -0800, Lu, Yinghai wrote: > -----Original Message----- > From: Lu, Yinghai > > >To my understanding, you don't need to waiting for Eric's code. > >You can use the cable on two systems without debug port support. > >So just extend the program to make it can write the data too. > > Greg, > > Anyone is working on creating one usb_serial_driver for USB debug device > without using host debug port? I can do that in about 15 minutes if you give me the device ids for the usb debug device that you wish to have. Or you can also use the generic usb-serial driver today just fine with no modification. Have you had a problem with using that option? thanks, greg k-h From gregkh at suse.de Fri Dec 1 20:17:30 2006 From: gregkh at suse.de (Greg KH) Date: Fri, 1 Dec 2006 11:17:30 -0800 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: <20061201190426.14911.qmail@stuge.se> References: <5986589C150B2F49A46483AC44C7BCA4907273@ssvlexmb2.amd.com> <20061201184123.GA2996@suse.de> <20061201190426.14911.qmail@stuge.se> Message-ID: <20061201191730.GA3539@suse.de> On Fri, Dec 01, 2006 at 08:04:26PM +0100, Peter Stuge wrote: > On Fri, Dec 01, 2006 at 10:41:23AM -0800, Greg KH wrote: > > On Fri, Dec 01, 2006 at 10:26:19AM -0800, Lu, Yinghai wrote: > > > Anyone is working on creating one usb_serial_driver for USB debug > > > device without using host debug port? > > > > I can do that in about 15 minutes if you give me the device ids for > > the usb debug device that you wish to have. > > The host (aka remote) end of the NET20DC debug device has vid 0x0525 > and pid 0x127a. You can use the usb-serial generic driver with those ids (as module parameters) today, with no kernel changes needed. > > Or you can also use the generic usb-serial driver today just fine > > with no modification. Have you had a problem with using that > > option? > > Does it check for a debug descriptor and attach to the device if one > is found? Neat! No, sorry, you need to use the device ids. thanks, greg k-h From gregkh at suse.de Fri Dec 1 20:19:16 2006 From: gregkh at suse.de (Greg KH) Date: Fri, 1 Dec 2006 11:19:16 -0800 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: <5986589C150B2F49A46483AC44C7BCA4907276@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA4907276@ssvlexmb2.amd.com> Message-ID: <20061201191916.GB3539@suse.de> On Fri, Dec 01, 2006 at 10:55:48AM -0800, Lu, Yinghai wrote: > -----Original Message----- > From: Greg KH [mailto:gregkh at suse.de] > > >I can do that in about 15 minutes if you give me the device ids for the > >usb debug device that you wish to have. > > >Or you can also use the generic usb-serial driver today just fine with > >no modification. Have you had a problem with using that option? > > We are talking about using USB debug device/EHCI debug port in LinuxBIOS > in legacy free PC. > Because one AM2+MCP55 MB doesn't have serial port. > > I guess Eric is working on USB debug device/EHCI debug port for > earlyprintk or printk. Well, earlyprintk will not work, as you need PCI up and running. And I have some code that barely works for this already, perhaps Eric and I should work together on this :) > So we need one client program on host side. So it would great if we > could use current USB stack for > the clients on system even without debug port. Yes, that will work just fine today using the usb-serial generic driver. I'll knock up a "real" driver for the device later today and send it to Linus, as it's trivial to do so, and will make it simpler than using the module parameters. thanks, greg k-h From gregkh at suse.de Mon Dec 4 21:33:08 2006 From: gregkh at suse.de (Greg KH) Date: Mon, 4 Dec 2006 12:33:08 -0800 Subject: [LinuxBIOS] [RFC][PATCH 2/2] x86_64: earlyprintk usb debug device support. In-Reply-To: <5986589C150B2F49A46483AC44C7BCA4907280@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA4907280@ssvlexmb2.amd.com> Message-ID: <20061204203308.GA30307@suse.de> On Mon, Dec 04, 2006 at 12:18:30PM -0800, Lu, Yinghai wrote: > -----Original Message----- > From: ebiederm at xmission.com [mailto:ebiederm at xmission.com] > > >arch/x86_64/kernel/early_printk.c | 574 > +++++++++++++++++++++++++++++++++++++ > > drivers/usb/host/ehci.h | 8 + > > include/asm-x86_64/fixmap.h | 1 > > Can you separate usbdebug handle out from early_printk? Yeah, at least tear it out of x86-64, so those of us stuck on different platforms can use this :) Other than that minor issue, this looks great. I don't have a x86-64 box set up here at the moment, so I can't test it, but it looks acceptable at first glance. thanks, greg k-h From gregkh at suse.de Tue Dec 5 01:45:21 2006 From: gregkh at suse.de (Greg KH) Date: Mon, 4 Dec 2006 16:45:21 -0800 Subject: [LinuxBIOS] [RFC][PATCH 2/2] x86_64: earlyprintk usb debug device support. In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA4907280@ssvlexmb2.amd.com> <20061204203308.GA30307@suse.de> Message-ID: <20061205004521.GA26035@suse.de> On Mon, Dec 04, 2006 at 02:26:52PM -0700, Eric W. Biederman wrote: > Greg KH writes: > > > On Mon, Dec 04, 2006 at 12:18:30PM -0800, Lu, Yinghai wrote: > >> -----Original Message----- > >> From: ebiederm at xmission.com [mailto:ebiederm at xmission.com] > >> > >> >arch/x86_64/kernel/early_printk.c | 574 > >> +++++++++++++++++++++++++++++++++++++ > >> > drivers/usb/host/ehci.h | 8 + > >> > include/asm-x86_64/fixmap.h | 1 > >> > >> Can you separate usbdebug handle out from early_printk? > > > > Yeah, at least tear it out of x86-64, so those of us stuck on different > > platforms can use this :) > > > > Other than that minor issue, this looks great. I don't have a x86-64 > > box set up here at the moment, so I can't test it, but it looks > > acceptable at first glance. > > Makes sense. I'm curious now what architecture do you have? i386 My main development box these days is a mac mini due to it's great form factor and ability to suspend to ram easily. Unfortunately they don't come with a working 64bit processor just yet. > Anyway next time I touch this the project will be how to integrate > this into the kernel cleanly. This round was to figure out how > to get some working code. > > If someone beats me to the punch on generalizing this code I won't > mind. > > The first pass was a success. And the performance is reasonable > assuming you don't plug the end you are watching into a usb1 only > port. > > Given that I didn't really know anything about usb a week ago I think > I did pretty well :) Yes, you certainly did, no complaint from me at all about that :) thanks, greg k-h From peter at stuge.se Fri Dec 1 20:04:26 2006 From: peter at stuge.se (Peter Stuge) Date: Fri, 1 Dec 2006 20:04:26 +0100 Subject: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device In-Reply-To: <20061201184123.GA2996@suse.de> References: <5986589C150B2F49A46483AC44C7BCA4907273@ssvlexmb2.amd.com> <20061201184123.GA2996@suse.de> Message-ID: <20061201190426.14911.qmail@stuge.se> On Fri, Dec 01, 2006 at 10:41:23AM -0800, Greg KH wrote: > On Fri, Dec 01, 2006 at 10:26:19AM -0800, Lu, Yinghai wrote: > > Anyone is working on creating one usb_serial_driver for USB debug > > device without using host debug port? > > I can do that in about 15 minutes if you give me the device ids for > the usb debug device that you wish to have. The host (aka remote) end of the NET20DC debug device has vid 0x0525 and pid 0x127a. > Or you can also use the generic usb-serial driver today just fine > with no modification. Have you had a problem with using that > option? Does it check for a debug descriptor and attach to the device if one is found? Neat! //Peter From segher at kernel.crashing.org Wed Dec 6 16:31:36 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Wed, 6 Dec 2006 16:31:36 +0100 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA490728A@ssvlexmb2.amd.com> Message-ID: <124CB3B2-C140-4B0A-96D0-21457B3DC086@kernel.crashing.org> >> What do you mean by >> + for (reps = 0; reps >= 0; reps++) { >> ? > > If you will not reps is negative. Roughly it is a loop > that will timeout eventually if a usb debug cable is not present. > So since I didn't know how many loop iterations made sense I allowed > it to loop for 2^31 times or until reps goes negative. This doesn't work however. Signed overflow in C is undefined, and GCC actually optimises accordingly (unless -fwrapv is used). Segher From rminnich at gmail.com Thu Dec 7 04:42:59 2006 From: rminnich at gmail.com (ron minnich) Date: Wed, 6 Dec 2006 20:42:59 -0700 Subject: [LinuxBIOS] Overclocking In-Reply-To: References: Message-ID: <13426df10612061942x55cdf2b9va852608caef90b90@mail.gmail.com> On 12/1/06, Max Power wrote: > Hello > > I whant to know, what are the plans for including overclocking (cpu, ram, > etc.) features in the linuxBIOS? we did this years ago, from linux, it worked fine. It's best to do overclocking AFTER bios startup when you can, so that if you mess things up you can get back via reset. But this makes dram overclocking kinda hard. ron From stuge-linuxbios at cdy.org Thu Dec 7 10:51:16 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Thu, 7 Dec 2006 10:51:16 +0100 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: <5986589C150B2F49A46483AC44C7BCA4907291@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA4907291@ssvlexmb2.amd.com> Message-ID: <20061207095116.27665.qmail@cdy.org> On Wed, Dec 06, 2006 at 01:08:14PM -0800, Lu, Yinghai wrote: > -----Original Message----- > From: Andi Kleen [mailto:ak at suse.de] > Sent: Wednesday, December 06, 2006 12:59 PM > > >I haven't looked how the other usb_debug works -- if it's polled > >too then it wouldn't have much advantage. > > Need to verify if the two sides of debug cable are identical. I got my device yesterday and after a small plugfest I can confirm that only one end of the device enumerates when connected to an ICH7 EHCI driven by 2.6.19. --8<-- Bus 001 Device 027: ID 0525:127a Netchip Technology, Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0525 Netchip Technology, Inc. idProduct 0x127a bcdDevice 1.01 iManufacturer 1 NetChip iProduct 2 NetChip TurboCONNECT 2.0 iSerial 3 1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Debug descriptor: bLength 4 bDescriptorType 10 bDebugInEndpoint 0x82 bDebugOutEndpoint 0x01 -->8-- The device is in fact not self-powered. My theory is that the same set of descriptors are used for both ends, but one end has been locked to address 127 in order to work with simpler debug port drivers that assume it will be there. I guess that the self-powered error is also to simplify life for debug port drivers. IIRC most if not all USB power management concerns are noops for debug ports. //Peter From stuge-linuxbios at cdy.org Thu Dec 7 11:18:24 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Thu, 7 Dec 2006 11:18:24 +0100 Subject: [LinuxBIOS] C3 Lightning Talk abstract In-Reply-To: <45776B7F.2050608@gmx.net> References: <20061206163944.10830.qmail@cdy.org> <45776B7F.2050608@gmx.net> Message-ID: <20061207101824.31786.qmail@cdy.org> Great stuff! Thanks for the input! On Thu, Dec 07, 2006 at 02:16:47AM +0100, Carl-Daniel Hailfinger wrote: > * Authenticated booting Have BIOS check payload you mean? Or have payload check rootfs? I guess they blend into one. > * Using any TPM against the intention of the vendor By using a payload that does tricks before the TPM starts up? > > * Mention OLPC. (But what are the important points?) > > * BIOS can already use wireless What's it used for? > * Automatic authenticated BIOS updates Are the details ironed out yet? Is userspace still involved? > * BIOS can be tailored to individual needs (wireless/wired network > card support, ipv4/ipv6, flat panel/vga...) Oh yes. //Peter From c-d.hailfinger.devel.2006 at gmx.net Thu Dec 7 13:19:17 2006 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 07 Dec 2006 13:19:17 +0100 Subject: [LinuxBIOS] C3 Lightning Talk abstract In-Reply-To: <20061207101824.31786.qmail@cdy.org> References: <20061206163944.10830.qmail@cdy.org> <45776B7F.2050608@gmx.net> <20061207101824.31786.qmail@cdy.org> Message-ID: <457806C5.8020705@gmx.net> Peter Stuge wrote: > Great stuff! Thanks for the input! > > On Thu, Dec 07, 2006 at 02:16:47AM +0100, Carl-Daniel Hailfinger wrote: >> * Authenticated booting > > Have BIOS check payload you mean? Or have payload check rootfs? I > guess they blend into one. Both. But the BIOS checking the payload is IMO key to a secure boot (if you don't trust the payload, you can't trust any assessment of rootfs security by the payload). >> * Using any TPM against the intention of the vendor > > By using a payload that does tricks before the TPM starts up? Yes. Some factory BIOSes seem to lock the TPM and/or do other (for that startup) irrevokable stuff. Using LinuxBIOS gives you full freedom in messing with the TPM (and you could use Vanderpool/ Pacifica to virtualize access to the TPM). >>> * Mention OLPC. (But what are the important points?) >> * BIOS can already use wireless > > What's it used for? Booting over wireless if the local flash "hard drive" has been corrupted. Sort of a recovery mode when no wired network connection is available. >> * Automatic authenticated BIOS updates > > Are the details ironed out yet? Is userspace still involved? A paper was due a few weeks ago, but nothing has surfaced yet. Regards, Carl-Daniel -- http://www.hailfinger.org/ From hawke at hawkesnest.net Thu Dec 7 13:42:54 2006 From: hawke at hawkesnest.net (Alex L. Mauer) Date: Thu, 07 Dec 2006 06:42:54 -0600 Subject: [LinuxBIOS] Overclocking In-Reply-To: <13426df10612061942x55cdf2b9va852608caef90b90@mail.gmail.com> References: <13426df10612061942x55cdf2b9va852608caef90b90@mail.gmail.com> Message-ID: ron minnich wrote: > we did this years ago, from linux, it worked fine. It's best to do > overclocking AFTER bios startup when you can, so that if you mess > things up you can get back via reset. But this makes dram overclocking > kinda hard. I would think that a recovery method would be one of the more important "overclocking features" to include... -- Bad - You get pulled over for doing 90 in a school zone and you're drunk off your ass again at three in the afternoon. Worse - The cop is drunk too, and he's a mean drunk. FUCK! - A mean drunk that's actually a swarm of semi-sentient flesh-eating beetles. OpenPGP key id: 51192FF2 @ subkeys.pgp.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From stepan at coresystems.de Thu Dec 7 13:48:08 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 7 Dec 2006 13:48:08 +0100 Subject: [LinuxBIOS] C3 Lightning Talk abstract In-Reply-To: <457806C5.8020705@gmx.net> References: <20061206163944.10830.qmail@cdy.org> <45776B7F.2050608@gmx.net> <20061207101824.31786.qmail@cdy.org> <457806C5.8020705@gmx.net> Message-ID: <20061207124807.GA29460@coresystems.de> * Carl-Daniel Hailfinger [061207 13:19]: > > Have BIOS check payload you mean? Or have payload check rootfs? I > > guess they blend into one. > > Both. But the BIOS checking the payload is IMO key to a secure boot > (if you don't trust the payload, you can't trust any assessment of > rootfs security by the payload). But: If you can't "trust" the payload, how can you trust the other 64k of LinuxBIOS in the flash? > >> * Automatic authenticated BIOS updates > > > > Are the details ironed out yet? Is userspace still involved? > > A paper was due a few weeks ago, but nothing has surfaced yet. Who is doing that? -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From stepan at coresystems.de Thu Dec 7 13:50:02 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 7 Dec 2006 13:50:02 +0100 Subject: [LinuxBIOS] Overclocking In-Reply-To: References: <13426df10612061942x55cdf2b9va852608caef90b90@mail.gmail.com> Message-ID: <20061207125002.GA29884@coresystems.de> * Alex L. Mauer [061207 13:42]: > I would think that a recovery method would be one of the more important > "overclocking features" to include... LinuxBIOS indeed includes a fallback mechanism, so whatever overclocking you would do with your "normal bios", you can always go back if you wish, and it will automatically go back, if you fail to boot the OS. Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From c-d.hailfinger.devel.2006 at gmx.net Thu Dec 7 14:00:16 2006 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 07 Dec 2006 14:00:16 +0100 Subject: [LinuxBIOS] C3 Lightning Talk abstract In-Reply-To: <20061207124807.GA29460@coresystems.de> References: <20061206163944.10830.qmail@cdy.org> <45776B7F.2050608@gmx.net> <20061207101824.31786.qmail@cdy.org> <457806C5.8020705@gmx.net> <20061207124807.GA29460@coresystems.de> Message-ID: <45781060.3060201@gmx.net> Stefan Reinauer wrote: > * Carl-Daniel Hailfinger [061207 13:19]: >>> Have BIOS check payload you mean? Or have payload check rootfs? I >>> guess they blend into one. >> Both. But the BIOS checking the payload is IMO key to a secure boot >> (if you don't trust the payload, you can't trust any assessment of >> rootfs security by the payload). > > But: If you can't "trust" the payload, how can you trust the other 64k > of LinuxBIOS in the flash? You're right. I was unclear with my terminology. >>>> * Automatic authenticated BIOS updates >>> Are the details ironed out yet? Is userspace still involved? >> A paper was due a few weeks ago, but nothing has surfaced yet. > > Who is doing that? Ivan Krstic and others. I'll keep you updated. Regards, Carl-Daniel -- http://www.hailfinger.org/ From smithbone at gmail.com Thu Dec 7 14:28:41 2006 From: smithbone at gmail.com (Richard Smith) Date: Thu, 07 Dec 2006 07:28:41 -0600 Subject: [LinuxBIOS] C3 Lightning Talk abstract In-Reply-To: <20061206163944.10830.qmail@cdy.org> References: <20061206163944.10830.qmail@cdy.org> Message-ID: <45781709.1080004@gmail.com> Peter Stuge wrote: > * Mention OLPC. (But what are the important points?) Flexibility. OLPC would have had a _much_ more difficult time getting things done if it was not using LinuxBIOS. We have had to do some pretty custom work under the hood. Size is another big issue. It interesting to note that code for the (8051 microcontroller) EC is *larger* than the LinuxBIOS code and thats even with romcc generating the LB code. Of course thats without a payload but an interesting data point. > * Show a demo. I think for a demo you want to show LaB (Linux as Bootloader, where linux is in the ROM) and boot linux directly to a shell prompt, as fast as you can make it. Thats a short, powerful demo. -- Richard A. Smith From smithbone at gmail.com Thu Dec 7 14:33:16 2006 From: smithbone at gmail.com (Richard Smith) Date: Thu, 07 Dec 2006 07:33:16 -0600 Subject: [LinuxBIOS] C3 Lightning Talk abstract In-Reply-To: <45776B7F.2050608@gmx.net> References: <20061206163944.10830.qmail@cdy.org> <45776B7F.2050608@gmx.net> Message-ID: <4578181C.7080104@gmail.com> Carl-Daniel Hailfinger wrote: > * BIOS bugs can be fixed even if upstream is not ready/cooperating > (not that I would want to suggest that upstream was uncooperative) > You mean upstream from OLPC here right? Without a developer key a user will not be able to reflash the BIOS. -- Richard A. Smith From stepan at coresystems.de Thu Dec 7 14:34:03 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 7 Dec 2006 14:34:03 +0100 Subject: [LinuxBIOS] C3 Lightning Talk abstract In-Reply-To: <45781709.1080004@gmail.com> References: <20061206163944.10830.qmail@cdy.org> <45781709.1080004@gmail.com> Message-ID: <20061207133403.GA7784@coresystems.de> * Richard Smith [061207 14:28]: > I think for a demo you want to show LaB (Linux as Bootloader, where > linux is in the ROM) and boot linux directly to a shell prompt, as fast > as you can make it. Thats a short, powerful demo. Whats the way to go here? Use the stuff with the nice OLPC graphics? Is that generically usable? buildrom needs tuning in a lot of places to be non-OLPC it seemed last time I looked at it. Is there some way to get it use vesafb (without bios callbacks, see x86_64 version) rather than a native chipset (ie. have graphics mode enabled before starting linux) Recompiling your bios if you change the graphics card is a little clumsy Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From smithbone at gmail.com Thu Dec 7 14:51:13 2006 From: smithbone at gmail.com (Richard Smith) Date: Thu, 07 Dec 2006 07:51:13 -0600 Subject: [LinuxBIOS] C3 Lightning Talk abstract In-Reply-To: <20061207133403.GA7784@coresystems.de> References: <20061206163944.10830.qmail@cdy.org> <45781709.1080004@gmail.com> <20061207133403.GA7784@coresystems.de> Message-ID: <45781C51.7000801@gmail.com> Stefan Reinauer wrote: > * Richard Smith [061207 14:28]: >> I think for a demo you want to show LaB (Linux as Bootloader, where >> linux is in the ROM) and boot linux directly to a shell prompt, as fast >> as you can make it. Thats a short, powerful demo. > > Whats the way to go here? Use the stuff with the nice OLPC graphics? > Is that generically usable? I /dev/fb0 is the only graphics dependency. So if you can get a framebuffer working then perhaps. I'm not sure if Jordan did some gxfb custom stuff in there. It was optimized for size on the OLPC platform. Should not be that hard though to make it generic. For the demo I was more thinking of just the kernel boot messages. To a geek like me I'm more impressed with that rather than flashy graphics. > buildrom needs tuning in a lot of places to be non-OLPC it seemed last > time I looked at it. It would need some tuning if you wanted to use buildrom. I was thinking he would just hand roll something. If someone wanted to try buildrom I can fix up things pretty quick. Just tell me what LB target to use. > Is there some way to get it use vesafb (without bios callbacks, see > x86_64 version) rather than a native chipset (ie. have graphics mode > enabled before starting linux) > Recompiling your bios if you change the graphics card is a little clumsy If you have run the video bios and you assume that the graphics mode has been set ahead of time then yes I think we should be able to include some vesafb code into linuxbios. The code for a single bit depth, 640x480, no mode changes, slow text, should be pretty small and fairly easy to maintain since it will not change much. -- Richard A. Smith From jon.dufresne at gmail.com Thu Dec 7 16:20:14 2006 From: jon.dufresne at gmail.com (Jon Dufresne) Date: Thu, 7 Dec 2006 10:20:14 -0500 Subject: [LinuxBIOS] vga bios troubles Message-ID: <376ea3380612070720i4c5fde3v7e5061a46ea75b31@mail.gmail.com> I followed the guide at this site http://linuxbios.org/VGA_support to get my onboard video to work. I have yet to be successful. I am a little confused about the Config.lb section. This is what the guid says: device pci 9.0 on # PCI chip drivers/pci/onboard device pci 9.0 on end register "rom_address" = "0xfff80000" #512k image end end I don't get why you list the "device pci 9.0" twice. I tried that and when I did my vga device never got the driver from onboard.c, instead it would always get the generic pci driver. So I changed it to only include the device below the chip line. This is what my Config.lb looks like chip northbridge/intel/i855gm chip cpu/intel/socket_mPGA479M device apic 0 on end end device pci_domain 0 on device pci 0.0 on end # host bridge device pci 0.1 on end # memory configuration device pci 0.3 on end # process configuration device pci 1.0 on end chip drivers/pci/onboard device pci 2.0 on end # vga controller register "rom_address" = "0xfff80000" #512k image end chip southbridge/intel/i82801dbm chip superio/ite/it8712f end end end end One thing that is also strange is that when I run "lspci" in a working environment I see two vga devices one at 0:2.0 and one at 0:2.1, I tried listing both but LB complained that I had a leftover static device at 0:2.1, it appears that only one of these devices is visible at boot. So I continued with the code above, and in the debug output I can see where linuxbios attempts to run the proprietary vga bios. I see: PCI: 00:02.0 init rom address for PCI: 00:02.0 = fff80000 PCI Expansion ROM, signature 0xaa55, INIT size 0xc800, data ptr 0x0040 PCI ROM Image, Vendor 8086, Device 3582, PCI ROM Image, Class Code 030000, Code Type 00 copying VGA ROM Image from 0xfff80000 to 0xc0000, 0xc800 bytes entering emulator Now, 0xC0000 is controlled by my PAM registers, so I took my best guess and set it read/write to SDRAM. When I do this LB stays inside the emulator for a while and eventually kicks out with this message: halt_sys: file /root/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4387 I never see anything on my monitor. I looked at the ops.c file but couldn't figure out what was going on. I have been fooling around with this for quite some time, changing every little thing I can think of, but no luck. My northbridge is an Intel 855 gme, I used the perl script to extract the vga bios which is 50KiB, I subtracted that size from the ROM_SIZE, and I concatenated it with the linuxBIOS. Anyone have an idea how to fix this? Thanks, Jon From luis.f.correia at gmail.com Thu Dec 7 16:33:18 2006 From: luis.f.correia at gmail.com (Luis Correia) Date: Thu, 7 Dec 2006 15:33:18 +0000 Subject: [LinuxBIOS] vga bios troubles In-Reply-To: <376ea3380612070720i4c5fde3v7e5061a46ea75b31@mail.gmail.com> References: <376ea3380612070720i4c5fde3v7e5061a46ea75b31@mail.gmail.com> Message-ID: Hi! On 12/7/06, Jon Dufresne wrote: > I followed the guide at this site http://linuxbios.org/VGA_support to > get my onboard video to work. I have yet to be successful. > > I am a little confused about the Config.lb section. This is what the guid says: > > device pci 9.0 on # PCI > chip drivers/pci/onboard > device pci 9.0 on end > register "rom_address" = "0xfff80000" #512k image > end > end > > I don't get why you list the "device pci 9.0" twice. I tried that and > when I did my vga device never got the driver from onboard.c, instead > it would always get the generic pci driver. So I changed it to only > include the device below the chip line. This is what my Config.lb > looks like > > chip northbridge/intel/i855gm > chip cpu/intel/socket_mPGA479M > device apic 0 on end > end > device pci_domain 0 on > device pci 0.0 on end # host bridge > device pci 0.1 on end # memory configuration > device pci 0.3 on end # process configuration > device pci 1.0 on end > > chip drivers/pci/onboard > device pci 2.0 on end # vga controller > register "rom_address" = "0xfff80000" #512k image > end > > chip southbridge/intel/i82801dbm > chip superio/ite/it8712f end > end > end > end > > One thing that is also strange is that when I run "lspci" in a working > environment I see two vga devices one at 0:2.0 and one at 0:2.1, I > tried listing both but LB complained that I had a leftover static > device at 0:2.1, it appears that only one of these devices is visible > at boot. Maybe it is the second head that is visible from PCI but un-implemented by hardware. > > So I continued with the code above, and in the debug output I can see > where linuxbios attempts to run the proprietary vga bios. I see: > > PCI: 00:02.0 init > rom address for PCI: 00:02.0 = fff80000 > PCI Expansion ROM, signature 0xaa55, INIT size 0xc800, data ptr 0x0040 > PCI ROM Image, Vendor 8086, Device 3582, > PCI ROM Image, Class Code 030000, Code Type 00 > copying VGA ROM Image from 0xfff80000 to 0xc0000, 0xc800 bytes > entering emulator > > Now, 0xC0000 is controlled by my PAM registers, so I took my best > guess and set it read/write to SDRAM. When I do this LB stays inside > the emulator for a while and eventually kicks out with this message: > > halt_sys: file /root/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4387 > > I never see anything on my monitor. I looked at the ops.c file but > couldn't figure out what was going on. I have been fooling around with > this for quite some time, changing every little thing I can think of, > but no luck. > > My northbridge is an Intel 855 gme, I used the perl script to extract > the vga bios which is 50KiB, I subtracted that size from the ROM_SIZE, > and I concatenated it with the linuxBIOS. > > Anyone have an idea how to fix this? > > Thanks, > Jon Luis From jon.dufresne at gmail.com Thu Dec 7 16:42:58 2006 From: jon.dufresne at gmail.com (Jon Dufresne) Date: Thu, 7 Dec 2006 10:42:58 -0500 Subject: [LinuxBIOS] vga bios troubles In-Reply-To: References: <376ea3380612070720i4c5fde3v7e5061a46ea75b31@mail.gmail.com> Message-ID: <376ea3380612070742mfe1bec9hb9d7ff1ea5200c82@mail.gmail.com> On 12/7/06, Luis Correia wrote: > Hi! > > On 12/7/06, Jon Dufresne wrote: > > I followed the guide at this site http://linuxbios.org/VGA_support to > > get my onboard video to work. I have yet to be successful. > > > > I am a little confused about the Config.lb section. This is what the guid says: > > > > device pci 9.0 on # PCI > > chip drivers/pci/onboard > > device pci 9.0 on end > > register "rom_address" = "0xfff80000" #512k image > > end > > end > > > > I don't get why you list the "device pci 9.0" twice. I tried that and > > when I did my vga device never got the driver from onboard.c, instead > > it would always get the generic pci driver. So I changed it to only > > include the device below the chip line. This is what my Config.lb > > looks like > > > > chip northbridge/intel/i855gm > > chip cpu/intel/socket_mPGA479M > > device apic 0 on end > > end > > device pci_domain 0 on > > device pci 0.0 on end # host bridge > > device pci 0.1 on end # memory configuration > > device pci 0.3 on end # process configuration > > device pci 1.0 on end > > > > chip drivers/pci/onboard > > device pci 2.0 on end # vga controller > > register "rom_address" = "0xfff80000" #512k image > > end > > > > chip southbridge/intel/i82801dbm > > chip superio/ite/it8712f end > > end > > end > > end > > > > One thing that is also strange is that when I run "lspci" in a working > > environment I see two vga devices one at 0:2.0 and one at 0:2.1, I > > tried listing both but LB complained that I had a leftover static > > device at 0:2.1, it appears that only one of these devices is visible > > at boot. > > Maybe it is the second head that is visible from PCI but > un-implemented by hardware. > > > > > > So I continued with the code above, and in the debug output I can see > > where linuxbios attempts to run the proprietary vga bios. I see: > > > > PCI: 00:02.0 init > > rom address for PCI: 00:02.0 = fff80000 > > PCI Expansion ROM, signature 0xaa55, INIT size 0xc800, data ptr 0x0040 > > PCI ROM Image, Vendor 8086, Device 3582, > > PCI ROM Image, Class Code 030000, Code Type 00 > > copying VGA ROM Image from 0xfff80000 to 0xc0000, 0xc800 bytes > > entering emulator > > > > Now, 0xC0000 is controlled by my PAM registers, so I took my best > > guess and set it read/write to SDRAM. When I do this LB stays inside > > the emulator for a while and eventually kicks out with this message: > > > > halt_sys: file /root/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4387 > > > > I never see anything on my monitor. I looked at the ops.c file but > > couldn't figure out what was going on. I have been fooling around with > > this for quite some time, changing every little thing I can think of, > > but no luck. > > > > My northbridge is an Intel 855 gme, I used the perl script to extract > > the vga bios which is 50KiB, I subtracted that size from the ROM_SIZE, > > and I concatenated it with the linuxBIOS. > > > > Anyone have an idea how to fix this? > > > > Thanks, > > Jon > > Luis > That makes sense, because many of the registers are documented the same including the exact same VID/DID. However, I don't understand why this shows up with an lspci but not with linuxbios. This could just be a peculiarity of pci that I don't understand. Jon From luis.f.correia at gmail.com Thu Dec 7 16:54:25 2006 From: luis.f.correia at gmail.com (Luis Correia) Date: Thu, 7 Dec 2006 15:54:25 +0000 Subject: [LinuxBIOS] vga bios troubles In-Reply-To: <376ea3380612070742mfe1bec9hb9d7ff1ea5200c82@mail.gmail.com> References: <376ea3380612070720i4c5fde3v7e5061a46ea75b31@mail.gmail.com> <376ea3380612070742mfe1bec9hb9d7ff1ea5200c82@mail.gmail.com> Message-ID: Hi! On 12/7/06, Jon Dufresne wrote: > On 12/7/06, Luis Correia wrote: > > That makes sense, because many of the registers are documented the > same including the exact same VID/DID. However, I don't understand why > this shows up with an lspci but not with linuxbios. This could just be > a peculiarity of pci that I don't understand. Define the PIC device twice with the proper ID's but describe only once the VGA BIOS. Maybe then it will show up with LB. BTW, does the board have two vga output devices? (even if one of them is a LVDS connector) > > Jon > Luis From jon.dufresne at gmail.com Thu Dec 7 16:59:59 2006 From: jon.dufresne at gmail.com (Jon Dufresne) Date: Thu, 7 Dec 2006 10:59:59 -0500 Subject: [LinuxBIOS] vga bios troubles In-Reply-To: References: <376ea3380612070720i4c5fde3v7e5061a46ea75b31@mail.gmail.com> <376ea3380612070742mfe1bec9hb9d7ff1ea5200c82@mail.gmail.com> Message-ID: <376ea3380612070759u19e6ffcem82d71745db99dd49@mail.gmail.com> The board is slightly custom, so when I looked at it I orignally thought it had one, but I looked at the manual for the board it is based on and I see this * Integrated Intel 855GME graphic engine with two LVDS channels So it does indeed look like there are two outputs. I just don't have physical access to the second one. Jon On 12/7/06, Luis Correia wrote: > Hi! > > On 12/7/06, Jon Dufresne wrote: > > On 12/7/06, Luis Correia wrote: > > > > That makes sense, because many of the registers are documented the > > same including the exact same VID/DID. However, I don't understand why > > this shows up with an lspci but not with linuxbios. This could just be > > a peculiarity of pci that I don't understand. > > Define the PIC device twice with the proper ID's but describe only > once the VGA BIOS. > > Maybe then it will show up with LB. > > BTW, does the board have two vga output devices? (even if one of them > is a LVDS connector) > > > > > Jon > > > > Luis > From jon.dufresne at gmail.com Thu Dec 7 17:26:06 2006 From: jon.dufresne at gmail.com (Jon Dufresne) Date: Thu, 7 Dec 2006 11:26:06 -0500 Subject: [LinuxBIOS] vga bios troubles In-Reply-To: <376ea3380612070759u19e6ffcem82d71745db99dd49@mail.gmail.com> References: <376ea3380612070720i4c5fde3v7e5061a46ea75b31@mail.gmail.com> <376ea3380612070742mfe1bec9hb9d7ff1ea5200c82@mail.gmail.com> <376ea3380612070759u19e6ffcem82d71745db99dd49@mail.gmail.com> Message-ID: <376ea3380612070826s401d96bfx983f69318d44e784@mail.gmail.com> > > Define the PIC device twice with the proper ID's but describe only > > once the VGA BIOS. > > > > Maybe then it will show up with LB. Sorry, I'm not sure exactly what you mean by this. Is ths in Config.lb or in a source file. I took a guess and I made this in the northbridge folder called i855gm_vga.c #include #include #include #include #include "i855gm.h" static struct device_operations vga_ops = { .read_resources = pci_dev_read_resources, .set_resources = pci_dev_set_resources, .enable_resources = pci_dev_enable_resources, .enable = i855gm_enable, .init = 0, .scan_bus = 0, }; static struct pci_driver vga_driver0 __pci_driver = { .ops = &vga_ops, .vendor = PCI_VENDOR_ID_INTEL, /* add into pci_ids.h PCI_DEVICE_ID_INTEL_855GME_VGA */ .device = 0x3582, }; static struct pci_driver vga_driver1 __pci_driver = { .ops = &vga_ops, .vendor = PCI_VENDOR_ID_INTEL, /* add into pci_ids.h PCI_DEVICE_ID_INTEL_855GME_VGA */ .device = 0x3582, }; From talbotx at comcast.net Thu Dec 7 17:31:11 2006 From: talbotx at comcast.net (Adam Talbot) Date: Thu, 07 Dec 2006 08:31:11 -0800 Subject: [LinuxBIOS] vga bios troubles In-Reply-To: <376ea3380612070826s401d96bfx983f69318d44e784@mail.gmail.com> References: <376ea3380612070720i4c5fde3v7e5061a46ea75b31@mail.gmail.com> <376ea3380612070742mfe1bec9hb9d7ff1ea5200c82@mail.gmail.com> <376ea3380612070759u19e6ffcem82d71745db99dd49@mail.gmail.com> <376ea3380612070826s401d96bfx983f69318d44e784@mail.gmail.com> Message-ID: <457841CF.6040603@comcast.net> Just asking the dumb question. Is the 855 chip set supported? -Adam Jon Dufresne wrote: >>> Define the PIC device twice with the proper ID's but describe only >>> once the VGA BIOS. >>> >>> Maybe then it will show up with LB. >>> > > Sorry, I'm not sure exactly what you mean by this. Is ths in Config.lb > or in a source file. I took a guess and I made this in the northbridge > folder called i855gm_vga.c > > #include > #include > #include > #include > #include "i855gm.h" > > static struct device_operations vga_ops = { > .read_resources = pci_dev_read_resources, > .set_resources = pci_dev_set_resources, > .enable_resources = pci_dev_enable_resources, > .enable = i855gm_enable, > .init = 0, > .scan_bus = 0, > }; > > static struct pci_driver vga_driver0 __pci_driver = { > .ops = &vga_ops, > .vendor = PCI_VENDOR_ID_INTEL, > /* add into pci_ids.h PCI_DEVICE_ID_INTEL_855GME_VGA */ > .device = 0x3582, > }; > > static struct pci_driver vga_driver1 __pci_driver = { > .ops = &vga_ops, > .vendor = PCI_VENDOR_ID_INTEL, > /* add into pci_ids.h PCI_DEVICE_ID_INTEL_855GME_VGA */ > .device = 0x3582, > }; > > From jon.dufresne at gmail.com Thu Dec 7 17:35:51 2006 From: jon.dufresne at gmail.com (Jon Dufresne) Date: Thu, 7 Dec 2006 11:35:51 -0500 Subject: [LinuxBIOS] vga bios troubles In-Reply-To: <457841CF.6040603@comcast.net> References: <376ea3380612070720i4c5fde3v7e5061a46ea75b31@mail.gmail.com> <376ea3380612070742mfe1bec9hb9d7ff1ea5200c82@mail.gmail.com> <376ea3380612070759u19e6ffcem82d71745db99dd49@mail.gmail.com> <376ea3380612070826s401d96bfx983f69318d44e784@mail.gmail.com> <457841CF.6040603@comcast.net> Message-ID: <376ea3380612070835p36c2f0e6y71e68e3fe9bd97aa@mail.gmail.com> There is an 855pm that looks incomplete, I took it and have been modifying it to work with my board which is 855gme (close but different). Are you saying there is code I need to write in the northbridge to get VGA to work beyond the guide? It is fine if I do and I will do it, I was just didn't realize there was more than what the guide mentions. Thanks, Jon On 12/7/06, Adam Talbot wrote: > Just asking the dumb question. Is the 855 chip set supported? > -Adam > > > Jon Dufresne wrote: > >>> Define the PIC device twice with the proper ID's but describe only > >>> once the VGA BIOS. > >>> > >>> Maybe then it will show up with LB. > >>> > > > > Sorry, I'm not sure exactly what you mean by this. Is ths in Config.lb > > or in a source file. I took a guess and I made this in the northbridge > > folder called i855gm_vga.c > > > > #include > > #include > > #include > > #include > > #include "i855gm.h" > > > > static struct device_operations vga_ops = { > > .read_resources = pci_dev_read_resources, > > .set_resources = pci_dev_set_resources, > > .enable_resources = pci_dev_enable_resources, > > .enable = i855gm_enable, > > .init = 0, > > .scan_bus = 0, > > }; > > > > static struct pci_driver vga_driver0 __pci_driver = { > > .ops = &vga_ops, > > .vendor = PCI_VENDOR_ID_INTEL, > > /* add into pci_ids.h PCI_DEVICE_ID_INTEL_855GME_VGA */ > > .device = 0x3582, > > }; > > > > static struct pci_driver vga_driver1 __pci_driver = { > > .ops = &vga_ops, > > .vendor = PCI_VENDOR_ID_INTEL, > > /* add into pci_ids.h PCI_DEVICE_ID_INTEL_855GME_VGA */ > > .device = 0x3582, > > }; > > > > > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From talbotx at comcast.net Thu Dec 7 17:41:52 2006 From: talbotx at comcast.net (Adam Talbot) Date: Thu, 07 Dec 2006 08:41:52 -0800 Subject: [LinuxBIOS] vga bios troubles In-Reply-To: <376ea3380612070835p36c2f0e6y71e68e3fe9bd97aa@mail.gmail.com> References: <376ea3380612070720i4c5fde3v7e5061a46ea75b31@mail.gmail.com> <376ea3380612070742mfe1bec9hb9d7ff1ea5200c82@mail.gmail.com> <376ea3380612070759u19e6ffcem82d71745db99dd49@mail.gmail.com> <376ea3380612070826s401d96bfx983f69318d44e784@mail.gmail.com> <457841CF.6040603@comcast.net> <376ea3380612070835p36c2f0e6y71e68e3fe9bd97aa@mail.gmail.com> Message-ID: <45784450.5000308@comcast.net> I could be wrong, but I think I was the last person to work on the 855 over a year ago. I was never able to get it running. I would start with getting the system to boot using a console connection. Once that is working, move on to VGA bios support. -Adam Jon Dufresne wrote: > There is an 855pm that looks incomplete, I took it and have been > modifying it to work with my board which is 855gme (close but > different). Are you saying there is code I need to write in the > northbridge to get VGA to work beyond the guide? It is fine if I do > and I will do it, I was just didn't realize there was more than what > the guide mentions. > > > Thanks, > Jon > > On 12/7/06, Adam Talbot wrote: >> Just asking the dumb question. Is the 855 chip set supported? >> -Adam >> >> >> Jon Dufresne wrote: >> >>> Define the PIC device twice with the proper ID's but describe only >> >>> once the VGA BIOS. >> >>> >> >>> Maybe then it will show up with LB. >> >>> >> > >> > Sorry, I'm not sure exactly what you mean by this. Is ths in Config.lb >> > or in a source file. I took a guess and I made this in the northbridge >> > folder called i855gm_vga.c >> > >> > #include >> > #include >> > #include >> > #include >> > #include "i855gm.h" >> > >> > static struct device_operations vga_ops = { >> > .read_resources = pci_dev_read_resources, >> > .set_resources = pci_dev_set_resources, >> > .enable_resources = pci_dev_enable_resources, >> > .enable = i855gm_enable, >> > .init = 0, >> > .scan_bus = 0, >> > }; >> > >> > static struct pci_driver vga_driver0 __pci_driver = { >> > .ops = &vga_ops, >> > .vendor = PCI_VENDOR_ID_INTEL, >> > /* add into pci_ids.h PCI_DEVICE_ID_INTEL_855GME_VGA */ >> > .device = 0x3582, >> > }; >> > >> > static struct pci_driver vga_driver1 __pci_driver = { >> > .ops = &vga_ops, >> > .vendor = PCI_VENDOR_ID_INTEL, >> > /* add into pci_ids.h PCI_DEVICE_ID_INTEL_855GME_VGA */ >> > .device = 0x3582, >> > }; >> > >> > >> >> >> -- >> linuxbios mailing list >> linuxbios at linuxbios.org >> http://www.openbios.org/mailman/listinfo/linuxbios >> > From jon.dufresne at gmail.com Thu Dec 7 17:44:52 2006 From: jon.dufresne at gmail.com (Jon Dufresne) Date: Thu, 7 Dec 2006 11:44:52 -0500 Subject: [LinuxBIOS] vga bios troubles In-Reply-To: <45784450.5000308@comcast.net> References: <376ea3380612070720i4c5fde3v7e5061a46ea75b31@mail.gmail.com> <376ea3380612070742mfe1bec9hb9d7ff1ea5200c82@mail.gmail.com> <376ea3380612070759u19e6ffcem82d71745db99dd49@mail.gmail.com> <376ea3380612070826s401d96bfx983f69318d44e784@mail.gmail.com> <457841CF.6040603@comcast.net> <376ea3380612070835p36c2f0e6y71e68e3fe9bd97aa@mail.gmail.com> <45784450.5000308@comcast.net> Message-ID: <376ea3380612070844p1292ff7bqc4ea892f516416d5@mail.gmail.com> ok, Thanks for the tip. Right now I can get into filo, and from there direct it to a livecd, however I am guessing the livecd doesn't deliver serial output and I think it dies somewhere booting the kernel. What should I do to watch the boot process over a serial connection? Thanks, Jon On 12/7/06, Adam Talbot wrote: > I could be wrong, but I think I was the last person to work on the 855 > over a year ago. I was never able to get it running. I would start > with getting the system to boot using a console connection. Once that > is working, move on to VGA bios support. > -Adam > > > Jon Dufresne wrote: > > There is an 855pm that looks incomplete, I took it and have been > > modifying it to work with my board which is 855gme (close but > > different). Are you saying there is code I need to write in the > > northbridge to get VGA to work beyond the guide? It is fine if I do > > and I will do it, I was just didn't realize there was more than what > > the guide mentions. > > > > > > Thanks, > > Jon > > > > On 12/7/06, Adam Talbot wrote: > >> Just asking the dumb question. Is the 855 chip set supported? > >> -Adam > >> > >> > >> Jon Dufresne wrote: > >> >>> Define the PIC device twice with the proper ID's but describe only > >> >>> once the VGA BIOS. > >> >>> > >> >>> Maybe then it will show up with LB. > >> >>> > >> > > >> > Sorry, I'm not sure exactly what you mean by this. Is ths in Config.lb > >> > or in a source file. I took a guess and I made this in the northbridge > >> > folder called i855gm_vga.c > >> > > >> > #include > >> > #include > >> > #include > >> > #include > >> > #include "i855gm.h" > >> > > >> > static struct device_operations vga_ops = { > >> > .read_resources = pci_dev_read_resources, > >> > .set_resources = pci_dev_set_resources, > >> > .enable_resources = pci_dev_enable_resources, > >> > .enable = i855gm_enable, > >> > .init = 0, > >> > .scan_bus = 0, > >> > }; > >> > > >> > static struct pci_driver vga_driver0 __pci_driver = { > >> > .ops = &vga_ops, > >> > .vendor = PCI_VENDOR_ID_INTEL, > >> > /* add into pci_ids.h PCI_DEVICE_ID_INTEL_855GME_VGA */ > >> > .device = 0x3582, > >> > }; > >> > > >> > static struct pci_driver vga_driver1 __pci_driver = { > >> > .ops = &vga_ops, > >> > .vendor = PCI_VENDOR_ID_INTEL, > >> > /* add into pci_ids.h PCI_DEVICE_ID_INTEL_855GME_VGA */ > >> > .device = 0x3582, > >> > }; > >> > > >> > > >> > >> > >> -- > >> linuxbios mailing list > >> linuxbios at linuxbios.org > >> http://www.openbios.org/mailman/listinfo/linuxbios > >> > > > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From talbotx at comcast.net Thu Dec 7 17:57:32 2006 From: talbotx at comcast.net (Adam Talbot) Date: Thu, 07 Dec 2006 08:57:32 -0800 Subject: [LinuxBIOS] vga bios troubles In-Reply-To: <376ea3380612070844p1292ff7bqc4ea892f516416d5@mail.gmail.com> References: <376ea3380612070720i4c5fde3v7e5061a46ea75b31@mail.gmail.com> <376ea3380612070742mfe1bec9hb9d7ff1ea5200c82@mail.gmail.com> <376ea3380612070759u19e6ffcem82d71745db99dd49@mail.gmail.com> <376ea3380612070826s401d96bfx983f69318d44e784@mail.gmail.com> <457841CF.6040603@comcast.net> <376ea3380612070835p36c2f0e6y71e68e3fe9bd97aa@mail.gmail.com> <45784450.5000308@comcast.net> <376ea3380612070844p1292ff7bqc4ea892f516416d5@mail.gmail.com> Message-ID: <457847FC.1030609@comcast.net> If you are able to get to filo some one has done some good work on the 855... ok, live CD. You need to pass console options to the kernel on the liveCD. Something like `kernel-version console=tty0 console=ttyS0,115200` But this can be a pain as you may not have a console at this point :-). Having had this exact problem, I found an old hard drive and installed a small version of Linux, just for testing. Setup my test Linux for console redirect and never used VGA bios until I got every thing else working. What board are you using? (web link) -Adam Jon Dufresne wrote: > ok, Thanks for the tip. > > Right now I can get into filo, and from there direct it to a livecd, > however I am guessing the livecd doesn't deliver serial output and I > think it dies somewhere booting the kernel. > > What should I do to watch the boot process over a serial connection? > > Thanks, > Jon > > On 12/7/06, Adam Talbot wrote: >> I could be wrong, but I think I was the last person to work on the 855 >> over a year ago. I was never able to get it running. I would start >> with getting the system to boot using a console connection. Once that >> is working, move on to VGA bios support. >> -Adam >> >> >> Jon Dufresne wrote: >> > There is an 855pm that looks incomplete, I took it and have been >> > modifying it to work with my board which is 855gme (close but >> > different). Are you saying there is code I need to write in the >> > northbridge to get VGA to work beyond the guide? It is fine if I do >> > and I will do it, I was just didn't realize there was more than what >> > the guide mentions. >> > >> > >> > Thanks, >> > Jon >> > >> > On 12/7/06, Adam Talbot wrote: >> >> Just asking the dumb question. Is the 855 chip set supported? >> >> -Adam >> >> >> >> >> >> Jon Dufresne wrote: >> >> >>> Define the PIC device twice with the proper ID's but describe >> only >> >> >>> once the VGA BIOS. >> >> >>> >> >> >>> Maybe then it will show up with LB. >> >> >>> >> >> > >> >> > Sorry, I'm not sure exactly what you mean by this. Is ths in >> Config.lb >> >> > or in a source file. I took a guess and I made this in the >> northbridge >> >> > folder called i855gm_vga.c >> >> > >> >> > #include >> >> > #include >> >> > #include >> >> > #include >> >> > #include "i855gm.h" >> >> > >> >> > static struct device_operations vga_ops = { >> >> > .read_resources = pci_dev_read_resources, >> >> > .set_resources = pci_dev_set_resources, >> >> > .enable_resources = pci_dev_enable_resources, >> >> > .enable = i855gm_enable, >> >> > .init = 0, >> >> > .scan_bus = 0, >> >> > }; >> >> > >> >> > static struct pci_driver vga_driver0 __pci_driver = { >> >> > .ops = &vga_ops, >> >> > .vendor = PCI_VENDOR_ID_INTEL, >> >> > /* add into pci_ids.h PCI_DEVICE_ID_INTEL_855GME_VGA */ >> >> > .device = 0x3582, >> >> > }; >> >> > >> >> > static struct pci_driver vga_driver1 __pci_driver = { >> >> > .ops = &vga_ops, >> >> > .vendor = PCI_VENDOR_ID_INTEL, >> >> > /* add into pci_ids.h PCI_DEVICE_ID_INTEL_855GME_VGA */ >> >> > .device = 0x3582, >> >> > }; >> >> > >> >> > >> >> >> >> >> >> -- >> >> linuxbios mailing list >> >> linuxbios at linuxbios.org >> >> http://www.openbios.org/mailman/listinfo/linuxbios >> >> >> > >> >> >> -- >> linuxbios mailing list >> linuxbios at linuxbios.org >> http://www.openbios.org/mailman/listinfo/linuxbios >> > From uwe at hermann-uwe.de Thu Dec 7 18:30:00 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 7 Dec 2006 18:30:00 +0100 Subject: [LinuxBIOS] C3 Lightning Talk abstract In-Reply-To: <4578181C.7080104@gmail.com> References: <20061206163944.10830.qmail@cdy.org> <45776B7F.2050608@gmx.net> <4578181C.7080104@gmail.com> Message-ID: <20061207173000.GA10625@greenwood> Hi, On Thu, Dec 07, 2006 at 07:33:16AM -0600, Richard Smith wrote: > > * BIOS bugs can be fixed even if upstream is not ready/cooperating > > (not that I would want to suggest that upstream was uncooperative) > > You mean upstream from OLPC here right? Without a developer key a user > will not be able to reflash the BIOS. Interesting. How does that work and on which level (hardware? software?). Is there some documentation about this? Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From uwe at hermann-uwe.de Thu Dec 7 18:30:16 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 7 Dec 2006 18:30:16 +0100 Subject: [LinuxBIOS] C3 Lightning Talk abstract In-Reply-To: <20061206205844.15218.qmail@cdy.org> References: <20061206163944.10830.qmail@cdy.org> <200612062117.24179.a1426z@gawab.com> <20061206205844.15218.qmail@cdy.org> Message-ID: <20061207173016.GB10625@greenwood> Hi, On Wed, Dec 06, 2006 at 09:58:44PM +0100, Peter Stuge wrote: > On Wed, Dec 06, 2006 at 09:17:24PM +0300, Al Boldi wrote: > > > * Describe what LinuxBIOS is and does, > > > > and does not (i.e: not backward-compatible with 16bit bios calls) > > Good point, thanks! Also mention ADLO and that you _could_ probably boot Windows with it etc. > Also: > > * Talk about all the improvements in v3. Yes, definately! Mention/show kconfig mockup. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From uwe at hermann-uwe.de Thu Dec 7 18:30:26 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 7 Dec 2006 18:30:26 +0100 Subject: [LinuxBIOS] C3 Lightning Talk abstract In-Reply-To: <45776B7F.2050608@gmx.net> References: <20061206163944.10830.qmail@cdy.org> <45776B7F.2050608@gmx.net> Message-ID: <20061207173026.GC10625@greenwood> Hi, On Thu, Dec 07, 2006 at 02:16:47AM +0100, Carl-Daniel Hailfinger wrote: > Peter Stuge wrote: > > * Describe what LinuxBIOS is and does, benefits and use cases off the > > excellent wiki welcome page. > > Since C3 is going to be frequented by security-conscious people and > general interest in tampering with hardware will be high, try this: > * SSH into BIOS for the paranoid > * Authenticated booting > * Using any TPM against the intention of the vendor Yep, that's great. However, make sure that you mention these are _possible_ future scenarios, I don't think this has been done yet. Am I wrong? Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From uwe at hermann-uwe.de Thu Dec 7 18:31:05 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 7 Dec 2006 18:31:05 +0100 Subject: [LinuxBIOS] C3 Lightning Talk abstract In-Reply-To: <20061207101824.31786.qmail@cdy.org> References: <20061206163944.10830.qmail@cdy.org> <45776B7F.2050608@gmx.net> <20061207101824.31786.qmail@cdy.org> Message-ID: <20061207173105.GD10625@greenwood> Hi, On Thu, Dec 07, 2006 at 11:18:24AM +0100, Peter Stuge wrote: > > * Using any TPM against the intention of the vendor > > By using a payload that does tricks before the TPM starts up? I don't know _too_ much about this topic yet, so I might be wrong, but I think the TPM chip doesn't actually _do_ anything by itself. It can be enabled/disabled and configured/used by the BIOS though, and as _we_ control the BIOS in this case we could do all kinds of funny stuff ;) As soon as I get that darn 440BX RAM init working I'll play a bit with this stuff, I think. There's the TPM emulator, http://tpm-emulator.berlios.de/, which will be useful even if you don't have a physical TPM chip. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From agarwal at videotron.ca Thu Dec 7 18:40:15 2006 From: agarwal at videotron.ca (Simon Labrecque) Date: Thu, 7 Dec 2006 12:40:15 -0500 Subject: [LinuxBIOS] Support for recent chipset and powerful desktop CPU In-Reply-To: <5986589C150B2F49A46483AC44C7BCA4907263@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA4907263@ssvlexmb2.amd.com> Message-ID: <00bc01c71a26$c11b4de0$4351e9a0$@ca> Any news regarding support for LinuxBIOS on one of the motherboard I listed? If someone needs me to buy the motherboard and ship it to him in order to work on it, I'm willing to do that. Just let me know; we'd like to get this working quickly, if possible. Simon Labrecque -----Original Message----- From: Lu, Yinghai [mailto:yinghai.lu at amd.com] Sent: Thursday, November 30, 2006 5:45 PM To: Simon Labrecque; ron minnich; Vlad C.; yhlu Cc: linuxbios at linuxbios.org Subject: RE: [LinuxBIOS] Support for recent chipset and powerful desktop CPU I'm trying to get one. YH From smithbone at gmail.com Thu Dec 7 19:02:16 2006 From: smithbone at gmail.com (Richard Smith) Date: Thu, 07 Dec 2006 12:02:16 -0600 Subject: [LinuxBIOS] C3 Lightning Talk abstract In-Reply-To: <20061207173000.GA10625@greenwood> References: <20061206163944.10830.qmail@cdy.org> <45776B7F.2050608@gmx.net> <4578181C.7080104@gmail.com> <20061207173000.GA10625@greenwood> Message-ID: <45785728.1060702@gmail.com> Forgot to copy the list: Uwe Hermann wrote: > Interesting. How does that work and on which level. (hardware? > software?). Both. There is a latch that controls the write line to the SPI flash chip. After looking in a special place for updates it will clear that latch and it can only be set again by a hard reset. Each BIOS update is signed with either the master OLPC key or a developer key unique to that person that will be issued to people by request. The BIOS will refuse to update unless the key is verified. Or you have to remove the SPI chip or reprogram it out of band. > Is there some documentation about this? There was a long thread many months ago on the olpc devel list and lwn.net did an article but thats about it. Its still in the works. Most of the crypto code has landed in the repository and should start seeing some testing around BTest 3. But I'm not sure of the exact timeframe yet. -- Richard A. Smith From ozcan at ug.bilkent.edu.tr Thu Dec 7 20:32:39 2006 From: ozcan at ug.bilkent.edu.tr (ozcan at ug.bilkent.edu.tr) Date: Thu, 07 Dec 2006 20:32:39 EET Subject: [LinuxBIOS] AMD PIC BIOS - Flashing on WinCE? Message-ID: Hello all, I have one of those AMD PIC Computers (Personal Internet Communicator). It has a Geode processor (x86). it comes with WIndows CE preinstalled and refuses to boot antthing else. I read on numerous places that there is some cryptographic handshaking going on between BIOS and the OS loader. Therefore at the moment I cannot boot it with Linux. And unfortunately the BIOS chip is soldered onto the mainboard. So my only bet is programming the chip with LinuxBIOS under Windows CE. Is this possible? I want it so bad, as this machine is garbage with Windows CE running. Thanks in advance. From shaddamcorrinoiv at gmail.com Thu Dec 7 20:02:17 2006 From: shaddamcorrinoiv at gmail.com (Shaddam Corrino IV) Date: Thu, 7 Dec 2006 20:02:17 +0100 Subject: [LinuxBIOS] Intel 440bx In-Reply-To: References: <20061121174225.GA1248@coresystems.de> <13426df10611211059u72b58d92k2153e009dd88ed9d@mail.gmail.com> <20061122065832.GA18195@greenwood> Message-ID: Any news on 440BX platform? I would hope to try to run it next week. PS: Are usb2serial adapters any good? I still need to assemble serial console. Even thought the 440bx has serial port, the other machine does not. -- Thanks! Shaddam IV -------------- next part -------------- An HTML attachment was scrubbed... URL: From uwe at hermann-uwe.de Thu Dec 7 20:30:36 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 7 Dec 2006 20:30:36 +0100 Subject: [LinuxBIOS] Intel 440bx In-Reply-To: References: <20061121174225.GA1248@coresystems.de> <13426df10611211059u72b58d92k2153e009dd88ed9d@mail.gmail.com> <20061122065832.GA18195@greenwood> Message-ID: <20061207193036.GA16394@greenwood> On Thu, Dec 07, 2006 at 08:02:17PM +0100, Shaddam Corrino IV wrote: > Any news on 440BX platform? Hm, not yet. I'm stuck a bit as I cannot get the RAM to work when hardcoding the registers. As soon as that works it's only a matter of (not too much) time to get the generic code to work. > PS: Are usb2serial adapters any good? I still need to assemble serial > console. Even thought the 440bx has serial port, the other machine does not. Yep, I'm using USB2Serial, too, and it works fine. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From shaddamcorrinoiv at gmail.com Thu Dec 7 21:15:53 2006 From: shaddamcorrinoiv at gmail.com (Shaddam Corrino IV) Date: Thu, 7 Dec 2006 21:15:53 +0100 Subject: [LinuxBIOS] Intel 440bx In-Reply-To: References: <20061121174225.GA1248@coresystems.de> <13426df10611211059u72b58d92k2153e009dd88ed9d@mail.gmail.com> <20061122065832.GA18195@greenwood> Message-ID: [please cc, I'm reading the list on web archives, so cc makes replying much easier] Uwe Hermann wrote : I'm stuck a bit as I cannot get the RAM to work when hardcoding the > registers. As soon as that works it's only a matter of (not too much) time > to get the generic code to work. An idea. Have you tried to run some incarnation of LBv1? It is my understanding that there exists some version of LBv1 that works on 440bx. Perhaps binary hash on versions would help to find it. -- Thanks! Shaddam IV -------------- next part -------------- An HTML attachment was scrubbed... URL: From acassis at gmail.com Thu Dec 7 21:46:07 2006 From: acassis at gmail.com (Alan Carvalho de Assis) Date: Thu, 7 Dec 2006 20:46:07 +0000 Subject: [LinuxBIOS] AMD PIC BIOS - Flashing on WinCE? In-Reply-To: References: Message-ID: <37367b3a0612071246s742d68bat7ef49f410b0d5ec2@mail.gmail.com> Hi, 2006/12/7, ozcan at ug.bilkent.edu.tr : > > Hello all, > I have one of those AMD PIC Computers (Personal Internet Communicator). It has a Geode processor (x86). it comes with WIndows CE preinstalled and refuses to boot antthing else. > I read on numerous places that there is some cryptographic handshaking going on between BIOS and the OS loader. > > Therefore at the moment I cannot boot it with Linux. And unfortunately the BIOS chip is soldered onto the mainboard. So my only bet is programming the chip with LinuxBIOS under Windows CE. Is this possible? I want it so bad, as this machine is garbage with Windows CE running. > > Thanks in advance. > Look at here: http://pclab.nectec.or.th/wiki/index.php/Hardware#AMD_Personal_Internet_Communicator They are running Linux on AMD FIC, but I don't know how they flashed the BIOS. Do you tried to compile flashrom to WinCE? I think it can be possible with very little modifications. Cheers, Alan From tsylla at gmail.com Thu Dec 7 22:02:05 2006 From: tsylla at gmail.com (Tom Sylla) Date: Thu, 7 Dec 2006 16:02:05 -0500 Subject: [LinuxBIOS] AMD PIC BIOS - Flashing on WinCE? In-Reply-To: References: Message-ID: <57947bf80612071302t5cfc3e60ob1213619b28c044c@mail.gmail.com> On 12/7/06, ozcan at ug.bilkent.edu.tr wrote: > Therefore at the moment I cannot boot it with Linux. And unfortunately the BIOS chip is soldered onto the mainboard. So my only bet is programming the chip with LinuxBIOS under Windows CE. Is this possible? I want it so bad, as this machine is garbage with Windows CE running. That is a very dangerous undertaking. Being able to flash the ROM is the least of your worries. Even if you somehow were able to flash the ROM from WinCE (extremely unlikely), you will certainly stop it from booting the first time you try and flash LinuxBIOS on it. GX LinuxBIOS requires a VSA binary to boot. The GX VSA code was actually released under GPL for the OLPC project, but the OLPC VSA binary does not work on all GX platforms (at least not on Rumba, and I would bet not on PIC) So you need to not only do the normal (hard) work of porting LinuxBIOS to the PIC, you also have to do the (harder) work of making a VSA binary for the machine. Also, I do not believe the PIC has a serial port sticking out, and the southbridge inside does not support the EHCI debug port. You could maybe get there, but doing it without a removable flash ROM is not reasonable. At a minumum, you need to de-solder the flash, solder on a socket, and figure out how to get a serial port. From tylerapohl at gmail.com Thu Dec 7 22:06:52 2006 From: tylerapohl at gmail.com (Tyler Pohl) Date: Thu, 7 Dec 2006 13:06:52 -0800 Subject: [LinuxBIOS] JTAG Message-ID: <503ab0210612071306x7fd095berc0e3daf5e918657a@mail.gmail.com> Does anyone know where I could get a parallel JTAG that works with openwince and EPIA boards? Thanks Tyler -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey_osgood at verizon.net Thu Dec 7 22:03:42 2006 From: corey_osgood at verizon.net (Corey Osgood) Date: Thu, 07 Dec 2006 16:03:42 -0500 Subject: [LinuxBIOS] AMD PIC BIOS - Flashing on WinCE? In-Reply-To: References: Message-ID: <457881AE.5060804@verizon.net> ozcan at ug.bilkent.edu.tr wrote: > Hello all, > I have one of those AMD PIC Computers (Personal Internet Communicator). It has a Geode processor (x86). it comes with WIndows CE preinstalled and refuses to boot antthing else. > I read on numerous places that there is some cryptographic handshaking going on between BIOS and the OS loader. > > Therefore at the moment I cannot boot it with Linux. And unfortunately the BIOS chip is soldered onto the mainboard. So my only bet is programming the chip with LinuxBIOS under Windows CE. Is this possible? I want it so bad, as this machine is garbage with Windows CE running. > > Thanks in advance. > IF you have a windows-based flash tool, you should be able to use that to flash linuxbios onto it. However, where your BIOS chip is sodiered on, I'd first worry about sodiering on a plcc socket onto the motherboard (if it has a plcc bios, the pics I've seen of them do) and getting a backup bios chip. Then, you should be able to flash with another PC running a BIOS chip of the same voltage (or else the windows flash option). This way, if something unexpected should happen, you're covered. My personal option: 2 extra chips, one for the original ROM, the other for your lb ROM, and the original chip in storage (in case you mess up). -Corey From yinghai.lu at amd.com Thu Dec 7 22:11:52 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Thu, 7 Dec 2006 13:11:52 -0800 Subject: [LinuxBIOS] Support for recent chipset and powerful desktop CPU Message-ID: <5986589C150B2F49A46483AC44C7BCA49072A2@ssvlexmb2.amd.com> Please wait one or two days. The usb debug cable should arrive my lab today. YH -----Original Message----- From: Simon Labrecque [mailto:agarwal at videotron.ca] Sent: Thursday, December 07, 2006 9:40 AM To: Lu, Yinghai; 'ron minnich'; 'Vlad C.'; 'yhlu' Cc: linuxbios at linuxbios.org Subject: RE: [LinuxBIOS] Support for recent chipset and powerful desktop CPU Any news regarding support for LinuxBIOS on one of the motherboard I listed? If someone needs me to buy the motherboard and ship it to him in order to work on it, I'm willing to do that. Just let me know; we'd like to get this working quickly, if possible. Simon Labrecque -----Original Message----- From: Lu, Yinghai [mailto:yinghai.lu at amd.com] Sent: Thursday, November 30, 2006 5:45 PM To: Simon Labrecque; ron minnich; Vlad C.; yhlu Cc: linuxbios at linuxbios.org Subject: RE: [LinuxBIOS] Support for recent chipset and powerful desktop CPU I'm trying to get one. YH From corey_osgood at verizon.net Thu Dec 7 22:32:31 2006 From: corey_osgood at verizon.net (Corey Osgood) Date: Thu, 07 Dec 2006 16:32:31 -0500 Subject: [LinuxBIOS] abandoning vt686a/amd75x, starting i815 Message-ID: <4578886F.9010402@verizon.net> So far, with the FIC SD11, I've been able to get serial output ONLY after a soft reboot from the original BIOS (in other words, my initialization isn't working right). Also, SPD has been completely uncooperative (can't read the ram at all), and I just don't have the knowledge/tools to properly debug it. So, I'm leaving it for now and going to work on the i815 northbridge, as it seems there is at least _some_ demand for this, and the southbridge/superio are already very nearly supported (i82801ba, lpc47m102). Has anyone looked at this in the past and have any suggestions? Also, is there somewhere a generic rundown of what exactly needs to be done by the northbridge, and what functions are supplied by linuxbios already, or just doxygen? Thanks, Corey From tylerapohl at gmail.com Thu Dec 7 23:03:04 2006 From: tylerapohl at gmail.com (Tyler Pohl) Date: Thu, 7 Dec 2006 14:03:04 -0800 Subject: [LinuxBIOS] serial debug Message-ID: <503ab0210612071403pf28cef3m6623bfe40052c019@mail.gmail.com> Are we able to use the serial port to single step linuxbios code? Where would I find documentation on this? Thanks TP -------------- next part -------------- An HTML attachment was scrubbed... URL: From stepan at coresystems.de Thu Dec 7 23:10:12 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 7 Dec 2006 23:10:12 +0100 Subject: [LinuxBIOS] serial debug In-Reply-To: <503ab0210612071403pf28cef3m6623bfe40052c019@mail.gmail.com> References: <503ab0210612071403pf28cef3m6623bfe40052c019@mail.gmail.com> Message-ID: <20061207221012.GA16357@coresystems.de> * Tyler Pohl [061207 23:03]: > Are we able to use the serial port to single step linuxbios code? Where would > I find documentation on this? there's a gdb interface in v2, but its not really documented I think (very cool feature though!) Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From yinghai.lu at amd.com Thu Dec 7 23:06:51 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Thu, 7 Dec 2006 14:06:51 -0800 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. Message-ID: <5986589C150B2F49A46483AC44C7BCA49072A4@ssvlexmb2.amd.com> Two side are identical if two side are connected. YH From tsylla at gmail.com Fri Dec 8 01:13:43 2006 From: tsylla at gmail.com (Tom Sylla) Date: Thu, 7 Dec 2006 19:13:43 -0500 Subject: [LinuxBIOS] XGI graphics Message-ID: <57947bf80612071613t48e49c7aw7dcec09d2c04d363@mail.gmail.com> Has anyone booted the video BIOS for an XGI Z7, Z9, or Z9S GPU with LinuxBIOS? We have a platform that mostly boots with its on-board ATI GPU, but if we do the voodoo to make it use a plug-in XGI PCI card, the emulator hangs running the ROM. Thanks for any input From yinghai.lu at amd.com Fri Dec 8 04:48:17 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Thu, 7 Dec 2006 19:48:17 -0800 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. Message-ID: <5986589C150B2F49A46483AC44C7BCA49072A5@ssvlexmb2.amd.com> -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of ebiederm at xmission.com >Ok due to popular demands here is the slightly fixed patch that works >on both i386 and x86_64. For the i386 version you must not have >HIGHMEM64G enabled. >I just rolled it all into one patch as I'm to lazy to transmit all >3 of them. I got Firmware type: LinuxBIOS Linux version 2.6.19-smp-gc9976797-dirty (root at lbsrv) (gcc version 4.0.2) #196 6 Command line: earlyprintk=ttyS0,115200 apic=debug pci=noacpi,routeirq snd-hda-i BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000001000 (reserved) BIOS-e820: 0000000000001000 - 00000000000a0000 (usable) BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 00000000c0000000 (usable) BIOS-e820: 0000000100000000 - 0000000240000000 (usable) dbgp_num: 0 Found EHCI debug port bar: 10 offset: 098 bar: 10 offset: 098 dbgp pre-set_fixmap_nocache PANIC: early exception rip ffffffff809c24b4 error 0 cr2 ffff810000203ff8 Call Trace: [] __set_fixmap+0x84/0x202 [] early_dbgp_init+0x259/0x55c [] __call_console_drivers+0x64/0x72 [] do_early_param+0x0/0x57 [] setup_early_printk+0x162/0x17e [] do_early_param+0x2e/0x57 [] parse_args+0x159/0x1f3 [] parse_early_param+0x40/0x4c [] setup_arch+0x1c1/0x636 [] start_kernel+0x55/0x208 [] _sinittext+0x173/0x177 RIP __set_fixmap+0x84/0x202 With Greg's USB Debug, host and target can talk. target with console=ttyUSB0,115200n8 host with cat /dev/ttyUSB0 But if use minicom in host, it will not show '\r', I guess the usb debug cable eat return char. Greg, Can you add that back in usb_debug by replacing '\n' with '\r', '\n'? With Eric code in LinuxBIOS, it will report "No device found in debug port" YH From gregkh at suse.de Fri Dec 8 08:14:37 2006 From: gregkh at suse.de (Greg KH) Date: Thu, 7 Dec 2006 23:14:37 -0800 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49072A5@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49072A5@ssvlexmb2.amd.com> Message-ID: <20061208071437.GA23173@suse.de> On Thu, Dec 07, 2006 at 07:48:17PM -0800, Lu, Yinghai wrote: > With Greg's USB Debug, host and target can talk. > target with console=ttyUSB0,115200n8 Ugh, no, never use the usb-serial driver as a console device. That was a bad hack done as a bet many years ago. For many obvious reasons it does not work well. > host with cat /dev/ttyUSB0 > But if use minicom in host, it will not show '\r', I guess the usb debug > cable eat return char. Greg, Can you add that back in usb_debug by > replacing '\n' with '\r', '\n'? The usb-serial console code should handle this, I thought we fixed it a while ago. But this kind of interface is not what these devices are good for. They are for the debug port information, not as a usb-serial console device. Otherwise they are way too expensive of a device... thanks, greg k-h From bxshi at msik.com.cn Fri Dec 8 08:28:27 2006 From: bxshi at msik.com.cn (bxshi at msik.com.cn) Date: Fri, 8 Dec 2006 15:28:27 +0800 Subject: [LinuxBIOS] I'd like to translate this article Message-ID: I find Uwe add a link to this fine article * http://www.linuxbios.org/Press * December 07, 2006: LinuxBIOS ready to go mainstream I'd like to translate it into chinese and pulish it on a chinese magazine.I do think that will make more chinese people know LinuxBIOS. But I don't know if there is copyright or if the author will agree? bxshi *****CONFIDENTIAL INFORMATION***** This email is intended only for the use of the person or entity to whom it is addressed and contains information that may be subject to and/or may be restricted from disclosure by contract or applicable law. If you are not the intended recipient of this email, be advised that any disclosure, copy, distribution or use of the contents of this message is strictly prohibited. If you are not the intended recipient of this email, please notify the sender that you have received this in error by replying to this message. Then, please delete it from your system. Thank you. From ebiederm at xmission.com Fri Dec 8 08:42:04 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Fri, 08 Dec 2006 00:42:04 -0700 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49072A5@ssvlexmb2.amd.com> (Yinghai Lu's message of "Thu, 7 Dec 2006 19:48:17 -0800") References: <5986589C150B2F49A46483AC44C7BCA49072A5@ssvlexmb2.amd.com> Message-ID: "Lu, Yinghai" writes: > -----Original Message----- > From: linuxbios-bounces at linuxbios.org > [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of > ebiederm at xmission.com > > >>Ok due to popular demands here is the slightly fixed patch that works >>on both i386 and x86_64. For the i386 version you must not have >>HIGHMEM64G enabled. > >>I just rolled it all into one patch as I'm to lazy to transmit all >>3 of them. > > > I got > > Firmware type: LinuxBIOS > Linux version 2.6.19-smp-gc9976797-dirty (root at lbsrv) (gcc version > 4.0.2) #196 6 > Command line: earlyprintk=ttyS0,115200 apic=debug pci=noacpi,routeirq > snd-hda-i > BIOS-provided physical RAM map: > BIOS-e820: 0000000000000000 - 0000000000001000 (reserved) > BIOS-e820: 0000000000001000 - 00000000000a0000 (usable) > BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable) > BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) > BIOS-e820: 0000000000100000 - 00000000c0000000 (usable) > BIOS-e820: 0000000100000000 - 0000000240000000 (usable) > dbgp_num: 0 > Found EHCI debug port > bar: 10 offset: 098 > bar: 10 offset: 098 > dbgp pre-set_fixmap_nocache > PANIC: early exception rip ffffffff809c24b4 error 0 cr2 ffff810000203ff8 > > Call Trace: > [] __set_fixmap+0x84/0x202 > [] early_dbgp_init+0x259/0x55c > [] __call_console_drivers+0x64/0x72 > [] do_early_param+0x0/0x57 > [] setup_early_printk+0x162/0x17e > [] do_early_param+0x2e/0x57 > [] parse_args+0x159/0x1f3 > [] parse_early_param+0x40/0x4c > [] setup_arch+0x1c1/0x636 > [] start_kernel+0x55/0x208 > [] _sinittext+0x173/0x177 > > RIP __set_fixmap+0x84/0x202 Ugh. I'd check the code. But it looks like my tweak to the early fixmap code. But my hunch is that my tweak to __fixmap so that it's pud and pmd were prepopulated didn't take on your build. > With Eric code in LinuxBIOS, it will report "No device found in debug > port" Hmm. At least this is partial progress :) Eric From tylerapohl at gmail.com Fri Dec 8 09:04:32 2006 From: tylerapohl at gmail.com (Tyler Pohl) Date: Fri, 8 Dec 2006 00:04:32 -0800 Subject: [LinuxBIOS] serial output Message-ID: <503ab0210612080004g1211a9c8g5fb4352f736d3a04@mail.gmail.com> Where is the code for serial output. For example if i wanted to change "Jumping to LinuxBios" to Jumping around" where would i find that code? -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinghai.lu at amd.com Fri Dec 8 09:52:26 2006 From: yinghai.lu at amd.com (Yinghai Lu) Date: Fri, 8 Dec 2006 00:52:26 -0800 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: <20061208071437.GA23173@suse.de> References: <5986589C150B2F49A46483AC44C7BCA49072A5@ssvlexmb2.amd.com> <20061208071437.GA23173@suse.de> Message-ID: <86802c440612080052x3704d767p8bfeb7fb723c9883@mail.gmail.com> On 12/7/06, Greg KH wrote: > Ugh, no, never use the usb-serial driver as a console device. > > That was a bad hack done as a bet many years ago. For many obvious > reasons it does not work well. understood, I found with usb_serial convertor could lose some chatacter. but the usb-debug cable seem it keep all character. > > > host with cat /dev/ttyUSB0 > > But if use minicom in host, it will not show '\r', I guess the usb debug > > cable eat return char. Greg, Can you add that back in usb_debug by > > replacing '\n' with '\r', '\n'? > > The usb-serial console code should handle this, I thought we fixed it a > while ago. Is it in the git tree? > > But this kind of interface is not what these devices are good for. They > are for the debug port information, not as a usb-serial console device. > Otherwise they are way too expensive of a device... the problem is some "modern" PC will left out serial port. then the cable could get cheap. YH From yinghai.lu at amd.com Fri Dec 8 09:53:53 2006 From: yinghai.lu at amd.com (Yinghai Lu) Date: Fri, 8 Dec 2006 00:53:53 -0800 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA49072A5@ssvlexmb2.amd.com> Message-ID: <86802c440612080053s13e5318eq7ae83aff4c7eb21c@mail.gmail.com> On 12/7/06, Eric W. Biederman wrote: > Ugh. I'd check the code. But it looks like my tweak to the > early fixmap code. But my hunch is that my tweak to __fixmap > so that it's pud and pmd were prepopulated didn't take on > your build. I missed some options? YH From ebiederm at xmission.com Fri Dec 8 10:07:53 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Fri, 08 Dec 2006 02:07:53 -0700 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: <86802c440612080053s13e5318eq7ae83aff4c7eb21c@mail.gmail.com> (Yinghai Lu's message of "Fri, 8 Dec 2006 00:53:53 -0800") References: <5986589C150B2F49A46483AC44C7BCA49072A5@ssvlexmb2.amd.com> <86802c440612080053s13e5318eq7ae83aff4c7eb21c@mail.gmail.com> Message-ID: "Yinghai Lu" writes: > On 12/7/06, Eric W. Biederman wrote: >> Ugh. I'd check the code. But it looks like my tweak to the >> early fixmap code. But my hunch is that my tweak to __fixmap >> so that it's pud and pmd were prepopulated didn't take on >> your build. > > I missed some options? Your or I missed a bug fix/enhancement in there somewhere. Basically my very early setup of the fixmap failed. Now. I thought I had that covered by preallocated the pud and the pmd entries. So the only thing missing was the pte entries. If that is not a big enough hint I will look into it in a bit... I'm starting to become a big fan of constant initializers. So our core subsystems don't need initialization code to be useful. All of these early things are just a pain. Eric From stepan at coresystems.de Fri Dec 8 13:33:59 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 8 Dec 2006 13:33:59 +0100 Subject: [LinuxBIOS] serial output In-Reply-To: <503ab0210612080004g1211a9c8g5fb4352f736d3a04@mail.gmail.com> References: <503ab0210612080004g1211a9c8g5fb4352f736d3a04@mail.gmail.com> Message-ID: <20061208123358.GA3044@coresystems.de> * Tyler Pohl [061208 09:04]: > Where is the code for serial output. For example if i wanted to change > "Jumping to LinuxBios" to Jumping around" where would i find that code? Depends on whether your port uses cache-as-ram: ./src/cpu/amd/car/copy_and_run.c: print_debug("Jumping to LinuxBIOS.\r\n"); ./src/cpu/x86/car/copy_and_run.c: print_debug("Jumping to LinuxBIOS.\r\n"); ./src/arch/i386/init/crt0.S.lb:str_pre_main: .string "Jumping to LinuxBIOS.\r\n" -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From stuge-linuxbios at cdy.org Fri Dec 8 14:59:23 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 8 Dec 2006 14:59:23 +0100 Subject: [LinuxBIOS] I'd like to translate this article In-Reply-To: References: Message-ID: <20061208135923.22521.qmail@cdy.org> On Fri, Dec 08, 2006 at 03:28:27PM +0800, bxshi at msik.com.cn wrote: > I find Uwe add a link to this fine article > * http://www.linuxbios.org/Press > * December 07, 2006: LinuxBIOS ready to go mainstream > I'd like to translate it into chinese and pulish it on a chinese > magazine.I do think that will make more chinese people know > LinuxBIOS. But I don't know if there is copyright or if the author > will agree? It seems the author, Bryce Byfield, can be contacted through an email link just after the article: http://www.linux.com/article.pl?sid=06/11/30/199208 It seems you need an account with linux.com, however. //Peter From rminnich at gmail.com Fri Dec 8 15:35:21 2006 From: rminnich at gmail.com (ron minnich) Date: Fri, 8 Dec 2006 07:35:21 -0700 Subject: [LinuxBIOS] I'd like to translate this article In-Reply-To: <20061208135923.22521.qmail@cdy.org> References: <20061208135923.22521.qmail@cdy.org> Message-ID: <13426df10612080635t55e9502fxb97818900c536971@mail.gmail.com> On 12/8/06, Peter Stuge wrote: > On Fri, Dec 08, 2006 at 03:28:27PM +0800, bxshi at msik.com.cn wrote: > > I find Uwe add a link to this fine article > > * http://www.linuxbios.org/Press > > * December 07, 2006: LinuxBIOS ready to go mainstream > > I'd like to translate it into chinese and pulish it on a chinese > > magazine.I do think that will make more chinese people know > > LinuxBIOS. But I don't know if there is copyright or if the author > > will agree? > > It seems the author, Bryce Byfield, can be contacted through an email > link just after the article: I have asked Bruce if this is possible. ron From u4110464 at anu.edu.au Fri Dec 8 15:36:51 2006 From: u4110464 at anu.edu.au (David Michael Barr) Date: Sat, 9 Dec 2006 01:36:51 +1100 (EST) Subject: [LinuxBIOS] Porting to Asus A8N-SLI Deluxe Message-ID: <44775.203.129.49.37.1165588611.squirrel@sqmail.anu.edu.au> Hi, I'm interested in porting LinuxBios to the Asus A8N-SLI Deluxe. It has an AMD K8 northbridge and IT8712f southbridge. I notice that some work has been done on these chipsets. I hoping the blood, sweat and tears will be minimal.The BIOS is the final frontier for this machine. Cheers, David M. Barr. From jon.dufresne at gmail.com Fri Dec 8 15:54:26 2006 From: jon.dufresne at gmail.com (Jon Dufresne) Date: Fri, 8 Dec 2006 09:54:26 -0500 Subject: [LinuxBIOS] serial output In-Reply-To: <503ab0210612080004g1211a9c8g5fb4352f736d3a04@mail.gmail.com> References: <503ab0210612080004g1211a9c8g5fb4352f736d3a04@mail.gmail.com> Message-ID: <376ea3380612080654t626096e6t4a5d5699c094915c@mail.gmail.com> I've found some of the debugging statements to be more unique than other parts of the code, so it makes grepping for it easy. For example, if I wanted to grep for that I would do $ cd LinuxBIOSv2/ $ grep -r -n "Jumping to LinuxBIOS" src/ and it will give the line number and file you can find it in, then you can change the statement and experiment. Keep in mind grep is case sensitive and unless you pass the "-i" option. Good luck! On 12/8/06, Tyler Pohl wrote: > Where is the code for serial output. For example if i wanted to change > "Jumping to LinuxBios" to Jumping around" where would i find that code? > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > > From rminnich at gmail.com Fri Dec 8 16:00:43 2006 From: rminnich at gmail.com (ron minnich) Date: Fri, 8 Dec 2006 08:00:43 -0700 Subject: [LinuxBIOS] serial output In-Reply-To: <376ea3380612080654t626096e6t4a5d5699c094915c@mail.gmail.com> References: <503ab0210612080004g1211a9c8g5fb4352f736d3a04@mail.gmail.com> <376ea3380612080654t626096e6t4a5d5699c094915c@mail.gmail.com> Message-ID: <13426df10612080700r283b9c5p628a9c89b7295ec8@mail.gmail.com> Bear in mind that if you start changing messages, and you have a question, nobody will know what you are talking about! thanks ron From rminnich at gmail.com Fri Dec 8 16:02:18 2006 From: rminnich at gmail.com (ron minnich) Date: Fri, 8 Dec 2006 08:02:18 -0700 Subject: [LinuxBIOS] XGI graphics In-Reply-To: <57947bf80612071613t48e49c7aw7dcec09d2c04d363@mail.gmail.com> References: <57947bf80612071613t48e49c7aw7dcec09d2c04d363@mail.gmail.com> Message-ID: <13426df10612080702h5b6e3326nfe8716c20a0703e6@mail.gmail.com> Tom, one good way to test this is not set up vga in linuxbios, and use the standalone emulator under linx to see if the same thing happens. Problems like this are often a case of the VGA BIOS guys getting cutesy with their code, requiring us to extend the emulator. If only .. the expected Forth expansion ROMs had worked out ... ron From jon.dufresne at gmail.com Fri Dec 8 16:06:14 2006 From: jon.dufresne at gmail.com (Jon Dufresne) Date: Fri, 8 Dec 2006 10:06:14 -0500 Subject: [LinuxBIOS] Porting to Asus A8N-SLI Deluxe In-Reply-To: <44775.203.129.49.37.1165588611.squirrel@sqmail.anu.edu.au> References: <44775.203.129.49.37.1165588611.squirrel@sqmail.anu.edu.au> Message-ID: <376ea3380612080706t5c295efenda9a519f1058e5d8@mail.gmail.com> If you're using the same ITE IT8712f that I am it is not a southbridge but a Superio chip. Super io controls (amoung other things) the serial ports. Look in your docs a little more or on the board itself to find what the southbridge is. Jon On 12/8/06, David Michael Barr wrote: > Hi, > I'm interested in porting LinuxBios to the Asus A8N-SLI Deluxe. It has an > AMD K8 northbridge and IT8712f southbridge. I notice that some work has > been done on these chipsets. I hoping the blood, sweat and tears will be > minimal.The BIOS is the final frontier for this machine. > Cheers, > David M. Barr. > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From kurtandre at gmail.com Fri Dec 8 16:59:35 2006 From: kurtandre at gmail.com (=?ISO-8859-1?Q?Kurt_Andr=E9_Selbach?=) Date: Fri, 8 Dec 2006 15:59:35 +0000 Subject: [LinuxBIOS] Linuxbios on epia motherboard Message-ID: <17cbe10f0612080759l32369f4bva81b1a0104f1509f@mail.gmail.com> Hi I've used linuxbios for about a month now, and now i even have it on two devices. But i've discovered some problems: On the epia-ml i can't whatsoever figure how to get the vga bios working, but this is not of importance to me, just a little annoying. i've tried extracting with awardeco and inserting via dd, i've also tried the old .BIN which a mail in the archive referred to. On my epia-ml everything seems to work except the vgabios and /dev/ttyS1 the internal rs232 port. It(ttyS1) works flawlessly on stock bios, and kernel recognizes it on bootup (checked via dmesg) exactly identically on both stock and linuxbios, since my epia doesnt like usb hubs, and i've ran out of usb ports i'd like to get the seconds rs232 port working within linuxbios, and hints/tips are welcome. Thanks in advance, Have a nice weekend Kurt. From rminnich at gmail.com Fri Dec 8 17:09:03 2006 From: rminnich at gmail.com (ron minnich) Date: Fri, 8 Dec 2006 09:09:03 -0700 Subject: [LinuxBIOS] Porting to Asus A8N-SLI Deluxe In-Reply-To: <376ea3380612080706t5c295efenda9a519f1058e5d8@mail.gmail.com> References: <44775.203.129.49.37.1165588611.squirrel@sqmail.anu.edu.au> <376ea3380612080706t5c295efenda9a519f1058e5d8@mail.gmail.com> Message-ID: <13426df10612080809k4eb9446cv3e7e091ab040817a@mail.gmail.com> On 12/8/06, Jon Dufresne wrote: > If you're using the same ITE IT8712f that I am it is not a southbridge > but a Superio chip. Super io controls (amoung other things) the serial > ports. Look in your docs a little more or on the board itself to find > what the southbridge is. or just send us an lspci ron From canderson at minotstateu.edu Fri Dec 8 17:27:06 2006 From: canderson at minotstateu.edu (Colin Anderson) Date: Fri, 8 Dec 2006 10:27:06 -0600 Subject: [LinuxBIOS] looking for RD1-PL bios savior for epia Message-ID: <2F8C81B56DDAE64F815A613A81576FFDB33C92@exchange2.poste.ad.misu.nodak.edu> I am seeking an RD1-PL Bios Savior for a Via EPIA board. IOSS no longer makes this model and I cannot find any for sale elsewhere. Does anybody here have an RD1-PL they could sell me? Do I have any other options for my Via EPIA boards and their oldschool 5v PLCC socket? TIA! -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinghai.lu at amd.com Fri Dec 8 19:28:22 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 8 Dec 2006 10:28:22 -0800 Subject: [LinuxBIOS] I'd like to translate this article Message-ID: <5986589C150B2F49A46483AC44C7BCA49072A7@ssvlexmb2.amd.com> Too bad, it didn't mention the great feature: Using linux Kernel as payload, and make use driver in kernel so can boot from Etherboot, AOE, Infiniband, myrinet, iscsi, ... EFI will need to re do driver for them. YH -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of ron minnich Sent: Friday, December 08, 2006 6:35 AM To: linuxbios at linuxbios.org Subject: Re: [LinuxBIOS] I'd like to translate this article On 12/8/06, Peter Stuge wrote: > On Fri, Dec 08, 2006 at 03:28:27PM +0800, bxshi at msik.com.cn wrote: > > I find Uwe add a link to this fine article > > * http://www.linuxbios.org/Press > > * December 07, 2006: LinuxBIOS ready to go mainstream > > I'd like to translate it into chinese and pulish it on a chinese > > magazine.I do think that will make more chinese people know > > LinuxBIOS. But I don't know if there is copyright or if the author > > will agree? > > It seems the author, Bryce Byfield, can be contacted through an email > link just after the article: I have asked Bruce if this is possible. ron -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios From jon.dufresne at gmail.com Fri Dec 8 20:53:14 2006 From: jon.dufresne at gmail.com (Jon Dufresne) Date: Fri, 8 Dec 2006 14:53:14 -0500 Subject: [LinuxBIOS] pc partitoin magic number not found? Message-ID: <376ea3380612081153t162133fbw983fceb5bd419584@mail.gmail.com> I am trying to boot a successfully system using LinuxBIOS + filo payload. Right now I can currently get to filo. I Can mostly boot off a livecd, but dies eventually because my root isn't specified correctly. Instead of messing with the CD boot (since my system will boot from a HD eventually anyway) I decided to install a minimal centos system on a spare hard drive. I partitioned the hard drive as follows: # fdisk -l /dev/hda Disk /dev/hda: 3166 MB, 3166765056 bytes 255 heads, 63 sectors/track, 385 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 287 2305296 83 Linux /dev/hda2 288 385 787185 82 Linux swap hda1 is formatted as ext2. When I get to filo I type the command to boot the kernel and I get some sort of partition error on hda1, here is the output: boot: hda1:/boot/vmlinuz-2.6.9-42.EL console=tty0 console=ttyS0,115200 malloc_diag: alloc: 408 bytes (5 blocks), free: 15968 bytes (1 blocks) malloc_diag: alloc: 424 bytes (6 blocks), free: 15952 bytes (1 blocks) file_open: dev=hda1, path=/boot/vmlinuz-2.6.9-42.EL find_ide_controller: found PCI IDE controller 8086:24cb prog_if=0x8a find_ide_controller: primary channel: compatibility mode find_ide_controller: cmd_base=0x1f0 ctrl_base=0x3f4 ide_software_reset: Waiting for ide0 to become ready for reset... ok init_drive: Testing for hda init_drive: Probing for hda init_drive: LBA mode, sectors=6185088 init_drive: Init device params... ok hda: LBA 3166MB: WDC AC33100H init_drive: Testing for hdb init_drive: Testing for hdb open_pc_partition: pc partition magic number not found open_eltorito_image: No El-Torito signature Unrecognized partitioning scheme malloc_diag: alloc: 408 bytes (5 blocks), free: 15968 bytes (1 blocks) malloc_diag: alloc: 328 bytes (4 blocks), free: 16048 bytes (1 blocks) Now, can boot this fine with the system bios using grub so I don't think my partition is corrupted. Do I need to do a special partition in order to boot with filo? I think my ide controller is configured fine because I can boot off the CD. Just in case it wasn't I attempted to fill registers with values from a working boot with lspci, same error. Anyone have any ideas? Thanks, Jon From stuge-linuxbios at cdy.org Fri Dec 8 21:51:43 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 8 Dec 2006 21:51:43 +0100 Subject: [LinuxBIOS] looking for RD1-PL bios savior for epia In-Reply-To: <2F8C81B56DDAE64F815A613A81576FFDB33C92@exchange2.poste.ad.misu.nodak.edu> References: <2F8C81B56DDAE64F815A613A81576FFDB33C92@exchange2.poste.ad.misu.nodak.edu> Message-ID: <20061208205143.16273.qmail@cdy.org> On Fri, Dec 08, 2006 at 10:27:06AM -0600, Colin Anderson wrote: > I am seeking an RD1-PL Bios Savior for a Via EPIA board. IOSS no > longer makes this model and I cannot find any for sale elsewhere. > Does anybody here have an RD1-PL they could sell me? Do I have any > other options for my Via EPIA boards and their oldschool 5v PLCC > socket? You could get a RD1-2M and a DIP->PLCC adapter. The latter may be hard to find at a reasonable price though. The ones that are easy to find probably go for $50-100 but since it's just a 1:1 socket adapter I think that's too much. If you look around you may be able to find a good deal. Note that space is tight around the PLCC socket on EPIA-MII at least, so make sure it fits physically before you order. //Peter From segher at kernel.crashing.org Fri Dec 8 22:33:18 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Fri, 8 Dec 2006 22:33:18 +0100 Subject: [LinuxBIOS] Intel 440bx In-Reply-To: References: <20061121174225.GA1248@coresystems.de> <13426df10611211059u72b58d92k2153e009dd88ed9d@mail.gmail.com> <20061122065832.GA18195@greenwood> Message-ID: > PS: Are usb2serial adapters any good? Most work okay at lower baud rates. Some handle higher rates well. A few can do hardware flow control correctly. There are two-or-so models that do all the above, and have a working serial break, too. For something like a serial console, you should be fine. If you want to do more complicated things, you want a *real* serial port. Segher From ben at hewson-venieri.com Fri Dec 8 23:02:14 2006 From: ben at hewson-venieri.com (Ben Hewson) Date: Fri, 08 Dec 2006 22:02:14 +0000 Subject: [LinuxBIOS] pc partitoin magic number not found? In-Reply-To: <376ea3380612081153t162133fbw983fceb5bd419584@mail.gmail.com> References: <376ea3380612081153t162133fbw983fceb5bd419584@mail.gmail.com> Message-ID: <4579E0E6.7000609@hewson-venieri.com> Jon Dufresne wrote: > I am trying to boot a successfully system using LinuxBIOS + filo > payload. Right now I can currently get to filo. I Can mostly boot off > a livecd, but dies eventually because my root isn't specified > correctly. Instead of messing with the CD boot (since my system will > boot from a HD eventually anyway) I decided to install a minimal > centos system on a spare hard drive. I partitioned the hard drive as > follows: > > # fdisk -l /dev/hda > > Disk /dev/hda: 3166 MB, 3166765056 bytes > 255 heads, 63 sectors/track, 385 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > > Device Boot Start End Blocks Id System > /dev/hda1 * 1 287 2305296 83 Linux > /dev/hda2 288 385 787185 82 Linux swap > > > hda1 is formatted as ext2. When I get to filo I type the command to > boot the kernel and I get some sort of partition error on hda1, here > is the output: > > boot: hda1:/boot/vmlinuz-2.6.9-42.EL console=tty0 console=ttyS0,115200 > malloc_diag: alloc: 408 bytes (5 blocks), free: 15968 bytes (1 blocks) > malloc_diag: alloc: 424 bytes (6 blocks), free: 15952 bytes (1 blocks) > file_open: dev=hda1, path=/boot/vmlinuz-2.6.9-42.EL > find_ide_controller: found PCI IDE controller 8086:24cb prog_if=0x8a > find_ide_controller: primary channel: compatibility mode > find_ide_controller: cmd_base=0x1f0 ctrl_base=0x3f4 > ide_software_reset: Waiting for ide0 to become ready for reset... ok > init_drive: Testing for hda > init_drive: Probing for hda > init_drive: LBA mode, sectors=6185088 > init_drive: Init device params... ok > hda: LBA 3166MB: WDC AC33100H > init_drive: Testing for hdb > init_drive: Testing for hdb > open_pc_partition: pc partition magic number not found > open_eltorito_image: No El-Torito signature > Unrecognized partitioning scheme > malloc_diag: alloc: 408 bytes (5 blocks), free: 15968 bytes (1 blocks) > malloc_diag: alloc: 328 bytes (4 blocks), free: 16048 bytes (1 blocks) > > Now, can boot this fine with the system bios using grub so I don't > think my partition is corrupted. Do I need to do a special partition > in order to boot with filo? I think my ide controller is configured > fine because I can boot off the CD. Just in case it wasn't I attempted > to fill registers with values from a working boot with lspci, same > error. > > Anyone have any ideas? > > Thanks, > Jon > > Ok just the obvious, have you enabled the relevant options in the filo Config file ? From jon.dufresne at gmail.com Fri Dec 8 23:12:11 2006 From: jon.dufresne at gmail.com (Jon Dufresne) Date: Fri, 8 Dec 2006 17:12:11 -0500 Subject: [LinuxBIOS] pc partitoin magic number not found? In-Reply-To: <4579E0E6.7000609@hewson-venieri.com> References: <376ea3380612081153t162133fbw983fceb5bd419584@mail.gmail.com> <4579E0E6.7000609@hewson-venieri.com> Message-ID: <376ea3380612081412x489e20d8i1161f709f4697e2e@mail.gmail.com> Thanks for the reply but after many headaches I figured it out. I forgot that ide encryption devices were installed on this motherboard. The system bios initialized them by default, where as LinuxBIOS did not. So LinuxBIOS tried to read an encrypted drive without decrypting it, obviously it was going to read junk data. After disabling this in the system bios and reinstalling CentOS filo can read the partition. Jon On 12/8/06, Ben Hewson wrote: > Jon Dufresne wrote: > > I am trying to boot a successfully system using LinuxBIOS + filo > > payload. Right now I can currently get to filo. I Can mostly boot off > > a livecd, but dies eventually because my root isn't specified > > correctly. Instead of messing with the CD boot (since my system will > > boot from a HD eventually anyway) I decided to install a minimal > > centos system on a spare hard drive. I partitioned the hard drive as > > follows: > > > > # fdisk -l /dev/hda > > > > Disk /dev/hda: 3166 MB, 3166765056 bytes > > 255 heads, 63 sectors/track, 385 cylinders > > Units = cylinders of 16065 * 512 = 8225280 bytes > > > > Device Boot Start End Blocks Id System > > /dev/hda1 * 1 287 2305296 83 Linux > > /dev/hda2 288 385 787185 82 Linux swap > > > > > > hda1 is formatted as ext2. When I get to filo I type the command to > > boot the kernel and I get some sort of partition error on hda1, here > > is the output: > > > > boot: hda1:/boot/vmlinuz-2.6.9-42.EL console=tty0 console=ttyS0,115200 > > malloc_diag: alloc: 408 bytes (5 blocks), free: 15968 bytes (1 blocks) > > malloc_diag: alloc: 424 bytes (6 blocks), free: 15952 bytes (1 blocks) > > file_open: dev=hda1, path=/boot/vmlinuz-2.6.9-42.EL > > find_ide_controller: found PCI IDE controller 8086:24cb prog_if=0x8a > > find_ide_controller: primary channel: compatibility mode > > find_ide_controller: cmd_base=0x1f0 ctrl_base=0x3f4 > > ide_software_reset: Waiting for ide0 to become ready for reset... ok > > init_drive: Testing for hda > > init_drive: Probing for hda > > init_drive: LBA mode, sectors=6185088 > > init_drive: Init device params... ok > > hda: LBA 3166MB: WDC AC33100H > > init_drive: Testing for hdb > > init_drive: Testing for hdb > > open_pc_partition: pc partition magic number not found > > open_eltorito_image: No El-Torito signature > > Unrecognized partitioning scheme > > malloc_diag: alloc: 408 bytes (5 blocks), free: 15968 bytes (1 blocks) > > malloc_diag: alloc: 328 bytes (4 blocks), free: 16048 bytes (1 blocks) > > > > Now, can boot this fine with the system bios using grub so I don't > > think my partition is corrupted. Do I need to do a special partition > > in order to boot with filo? I think my ide controller is configured > > fine because I can boot off the CD. Just in case it wasn't I attempted > > to fill registers with values from a working boot with lspci, same > > error. > > > > Anyone have any ideas? > > > > Thanks, > > Jon > > > > > Ok just the obvious, have you enabled the relevant options in the filo > Config file ? > From uwe at hermann-uwe.de Sat Dec 9 00:08:26 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 9 Dec 2006 00:08:26 +0100 Subject: [LinuxBIOS] Porting to Asus A8N-SLI Deluxe In-Reply-To: <13426df10612080809k4eb9446cv3e7e091ab040817a@mail.gmail.com> References: <44775.203.129.49.37.1165588611.squirrel@sqmail.anu.edu.au> <376ea3380612080706t5c295efenda9a519f1058e5d8@mail.gmail.com> <13426df10612080809k4eb9446cv3e7e091ab040817a@mail.gmail.com> Message-ID: <20061208230826.GE32611@greenwood> Hi, On Fri, Dec 08, 2006 at 09:09:03AM -0700, ron minnich wrote: > On 12/8/06, Jon Dufresne wrote: > > If you're using the same ITE IT8712f that I am it is not a southbridge > > but a Superio chip. Yep. > or just send us an lspci An example is here: http://www.linuxquestions.org/hcl/showproduct.php/product/3410 Seems to be a CK804, so it should be supported quite well, right? Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From uwe at hermann-uwe.de Sat Dec 9 00:32:09 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 9 Dec 2006 00:32:09 +0100 Subject: [LinuxBIOS] Linuxbios on epia motherboard In-Reply-To: <17cbe10f0612080759l32369f4bva81b1a0104f1509f@mail.gmail.com> References: <17cbe10f0612080759l32369f4bva81b1a0104f1509f@mail.gmail.com> Message-ID: <20061208233209.GF32611@greenwood> On Fri, Dec 08, 2006 at 03:59:35PM +0000, Kurt Andr? Selbach wrote: > On my epia-ml everything seems to work except the vgabios and > /dev/ttyS1 the internal rs232 port. > > It(ttyS1) works flawlessly on stock bios, Did you test that using minicom with 115200 Baud, 8N1? > and kernel recognizes it on > bootup (checked via dmesg) exactly identically on both stock and > linuxbios, since my epia doesnt like usb hubs, and i've ran out of usb > ports i'd like to get the seconds rs232 port working within linuxbios, > and hints/tips are welcome. I'm just guessing, but try to look at src/mainboard/via/epia-m/*.lb and src/superio/via/vt1211/vt1211.c. Either LinuxBIOS is simply not configured to enable ttyS1, or the code isn't there or incomplete or wrong (?) Maybe it's even simpler? Did you attach the cable to the correct port? Did you configure minicom to use ttyS1 instead of ttyS0? Etc. etc. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From niverson at 4dv.net Sat Dec 9 03:54:20 2006 From: niverson at 4dv.net (nate iverson) Date: Fri, 08 Dec 2006 19:54:20 -0700 Subject: [LinuxBIOS] LinuxBios for Tyan Tiger MPX (S2466) Message-ID: <1165632861.8003.9.camel@lanshark> Where do I find out what needs to be done for the porting of linuxbios for the Tyan Tiger MPX (S2466) motherboard? The website just says it isn't support in version1. Thanks, Nate From rminnich at gmail.com Sat Dec 9 04:14:01 2006 From: rminnich at gmail.com (ron minnich) Date: Fri, 8 Dec 2006 20:14:01 -0700 Subject: [LinuxBIOS] LinuxBios for Tyan Tiger MPX (S2466) In-Reply-To: <1165632861.8003.9.camel@lanshark> References: <1165632861.8003.9.camel@lanshark> Message-ID: <13426df10612081914s69fe3450v4bf38e356aa8244a@mail.gmail.com> On 12/8/06, nate iverson wrote: > Where do I find out what needs to be done for the porting of linuxbios > for the Tyan Tiger MPX (S2466) motherboard? The website just says it > isn't support in version1. what's on that board? ron From corey_osgood at verizon.net Sat Dec 9 04:21:41 2006 From: corey_osgood at verizon.net (Corey Osgood) Date: Fri, 08 Dec 2006 22:21:41 -0500 Subject: [LinuxBIOS] LinuxBios for Tyan Tiger MPX (S2466) In-Reply-To: <13426df10612081914s69fe3450v4bf38e356aa8244a@mail.gmail.com> References: <1165632861.8003.9.camel@lanshark> <13426df10612081914s69fe3450v4bf38e356aa8244a@mail.gmail.com> Message-ID: <457A2BC5.3050208@verizon.net> ron minnich wrote: > On 12/8/06, nate iverson wrote: >> Where do I find out what needs to be done for the porting of linuxbios >> for the Tyan Tiger MPX (S2466) motherboard? The website just says it >> isn't support in version1. > what's on that board? > > ron > http://www.tyan.com/products/html/tigermpx_spec.html all of which seem to be supported in v1, but northbridge/southbridge aren't in v2. From yinghai.lu at amd.com Sat Dec 9 04:16:09 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 8 Dec 2006 19:16:09 -0800 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. Message-ID: <5986589C150B2F49A46483AC44C7BCA49072AB@ssvlexmb2.amd.com> -----Original Message----- From: ebiederm at xmission.com [mailto:ebiederm at xmission.com] Sent: Thursday, December 07, 2006 11:42 PM >> With Eric code in LinuxBIOS, it will report "No device found in debug >> port" >Hmm. At least this is partial progress :) It works in LinuxBIOS now. It will loop all connected port and find debug device. Will check in the code together with MCP55. YH From niverson at 4dv.net Sat Dec 9 04:23:20 2006 From: niverson at 4dv.net (nate iverson) Date: Fri, 08 Dec 2006 20:23:20 -0700 Subject: [LinuxBIOS] LinuxBios for Tyan Tiger MPX (S2466) In-Reply-To: <13426df10612081914s69fe3450v4bf38e356aa8244a@mail.gmail.com> References: <1165632861.8003.9.camel@lanshark> <13426df10612081914s69fe3450v4bf38e356aa8244a@mail.gmail.com> Message-ID: <1165634601.8003.12.camel@lanshark> Northbridge Southbridge Super I/O AMD-762? AMD-768? Winbond? W83627HF Nate On Fri, 2006-12-08 at 20:14 -0700, ron minnich wrote: > On 12/8/06, nate iverson wrote: > > Where do I find out what needs to be done for the porting of linuxbios > > for the Tyan Tiger MPX (S2466) motherboard? The website just says it > > isn't support in version1. > what's on that board? > > ron From russ at ashlandhome.net Sat Dec 9 07:39:59 2006 From: russ at ashlandhome.net (Russ Whitaker) Date: Fri, 8 Dec 2006 22:39:59 -0800 (PST) Subject: [LinuxBIOS] LinuxBios for Tyan Tiger MPX (S2466) In-Reply-To: <457A2BC5.3050208@verizon.net> References: <1165632861.8003.9.camel@lanshark> <13426df10612081914s69fe3450v4bf38e356aa8244a@mail.gmail.com> <457A2BC5.3050208@verizon.net> Message-ID: On Fri, 8 Dec 2006, Corey Osgood wrote: > ron minnich wrote: >> On 12/8/06, nate iverson wrote: >>> Where do I find out what needs to be done for the porting of linuxbios >>> for the Tyan Tiger MPX (S2466) motherboard? The website just says it >>> isn't support in version1. >> what's on that board? >> >> ron >> > > http://www.tyan.com/products/html/tigermpx_spec.html > > all of which seem to be supported in v1, but northbridge/southbridge > aren't in v2. > The Tiger MPX comes in 2 flavors: 2M and 4M bios flash rom. From stuge-linuxbios at cdy.org Sat Dec 9 11:54:20 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Sat, 9 Dec 2006 11:54:20 +0100 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49072AB@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49072AB@ssvlexmb2.amd.com> Message-ID: <20061209105420.966.qmail@cdy.org> On Fri, Dec 08, 2006 at 07:16:09PM -0800, Lu, Yinghai wrote: > It works in LinuxBIOS now. Cool, can't wait to try it out. Good work! //Peter From piotrek4 at wp.pl Sat Dec 9 13:55:16 2006 From: piotrek4 at wp.pl (piotrek) Date: Sat, 09 Dec 2006 13:55:16 +0100 Subject: [LinuxBIOS] SIS648 Message-ID: <457AB234.6010003@wp.pl> Is the motherboard SIS648 supported by LinuxBIOS? From niverson at 4dv.net Sat Dec 9 16:04:09 2006 From: niverson at 4dv.net (nate iverson) Date: Sat, 09 Dec 2006 08:04:09 -0700 Subject: [LinuxBIOS] LinuxBios for Tyan Tiger MPX (S2466) In-Reply-To: References: <1165632861.8003.9.camel@lanshark> <13426df10612081914s69fe3450v4bf38e356aa8244a@mail.gmail.com> <457A2BC5.3050208@verizon.net> Message-ID: <1165676649.8003.16.camel@lanshark> Have you put LinuxBios on it? If you have, what version and how stable is it? Thanks, Nate On Fri, 2006-12-08 at 22:39 -0800, Russ Whitaker wrote: > > On Fri, 8 Dec 2006, Corey Osgood wrote: > > > ron minnich wrote: > >> On 12/8/06, nate iverson wrote: > >>> Where do I find out what needs to be done for the porting of linuxbios > >>> for the Tyan Tiger MPX (S2466) motherboard? The website just says it > >>> isn't support in version1. > >> what's on that board? > >> > >> ron > >> > > > > http://www.tyan.com/products/html/tigermpx_spec.html > > > > all of which seem to be supported in v1, but northbridge/southbridge > > aren't in v2. > > > The Tiger MPX comes in 2 flavors: 2M and 4M bios flash rom. > > >From the user's manual: > AMD 760MPX chipset > AMD 762 System Controler > AMD 768 Peripheral Bus Controler > Winbond 83627 Super I/O ASIC > Winbond W83782D hardware monitoring ASIC > 3COM 3C920C LAN controller (with 3C905 driver set) > > I have the 4M version - it's my main computer. > > What else would you like to know? > > Russ > > From russ at ashlandhome.net Sat Dec 9 17:41:51 2006 From: russ at ashlandhome.net (Russ Whitaker) Date: Sat, 9 Dec 2006 08:41:51 -0800 (PST) Subject: [LinuxBIOS] LinuxBios for Tyan Tiger MPX (S2466) In-Reply-To: <1165676649.8003.16.camel@lanshark> References: <1165632861.8003.9.camel@lanshark> <13426df10612081914s69fe3450v4bf38e356aa8244a@mail.gmail.com> <457A2BC5.3050208@verizon.net> <1165676649.8003.16.camel@lanshark> Message-ID: On Sat, 9 Dec 2006, nate iverson wrote: > Have you put LinuxBios on it? If you have, what version and how stable > is it? > Not yet: don't have a working backup system in case something goes wrong. However, quite some time ago I downloaded a factory bios update from Tyan's website and followed their directions. As I recall it was put the update on a floppy, boot the box with a ms windows bootdisk while holding down a key, and then insert the floppy. Russ > On Fri, 2006-12-08 at 22:39 -0800, Russ Whitaker wrote: >> >> On Fri, 8 Dec 2006, Corey Osgood wrote: >> >>> ron minnich wrote: >>>> On 12/8/06, nate iverson wrote: >>>>> Where do I find out what needs to be done for the porting of linuxbios >>>>> for the Tyan Tiger MPX (S2466) motherboard? The website just says it >>>>> isn't support in version1. >>>> what's on that board? >>>> >>>> ron >>>> >>> >>> http://www.tyan.com/products/html/tigermpx_spec.html >>> >>> all of which seem to be supported in v1, but northbridge/southbridge >>> aren't in v2. >>> >> The Tiger MPX comes in 2 flavors: 2M and 4M bios flash rom. >> >>> From the user's manual: >> AMD 760MPX chipset >> AMD 762 System Controler >> AMD 768 Peripheral Bus Controler >> Winbond 83627 Super I/O ASIC >> Winbond W83782D hardware monitoring ASIC >> 3COM 3C920C LAN controller (with 3C905 driver set) >> From uwe at hermann-uwe.de Sat Dec 9 18:28:20 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 9 Dec 2006 18:28:20 +0100 Subject: [LinuxBIOS] SIS648 In-Reply-To: <457AB234.6010003@wp.pl> References: <457AB234.6010003@wp.pl> Message-ID: <20061209172820.GA9827@greenwood> Hi, On Sat, Dec 09, 2006 at 01:55:16PM +0100, piotrek wrote: > Is the motherboard SIS648 supported by LinuxBIOS? What mainboard vendor and name is this exactly? SIS648 is the name of the chipset, I think. Also, if you can tell us the northbridge, southbridge and Super I/O names we can say more. If possible please send the output of 'lspci' and 'lspci -n' from a running Linux (or Knoppix Live-CD) on this mainboard. Look at http://linuxbios.org/Supported_Motherboards for a list of supported mainboards. Everything else is not yet supported and may need some work (more or less, that depends). Cheers, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From uwe at hermann-uwe.de Sat Dec 9 21:57:03 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 9 Dec 2006 21:57:03 +0100 Subject: [LinuxBIOS] [piotrek4@wp.pl: Re: SIS648] In-Reply-To: <457AB234.6010003@wp.pl> Message-ID: <20061209205703.GA19237@greenwood> ----- Forwarded message from piotrek ----- From: piotrek To: Uwe Hermann Subject: Re: [LinuxBIOS] SIS648 Date: Sat, 09 Dec 2006 18:55:38 +0100 Uwe Hermann napisa?(a): >Hi, > >On Sat, Dec 09, 2006 at 01:55:16PM +0100, piotrek wrote: > >>Is the motherboard SIS648 supported by LinuxBIOS? >> > >What mainboard vendor and name is this exactly? SIS648 is the name of >the chipset, I think. Also, if you can tell us the northbridge, >southbridge and Super I/O names we can say more. > >If possible please send the output of 'lspci' and 'lspci -n' from a >running Linux (or Knoppix Live-CD) on this mainboard. > >Look at http://linuxbios.org/Supported_Motherboards for a list of >supported mainboards. Everything else is not yet supported and may need >some work (more or less, that depends). > > >Cheers, Uwe. > 0000:00:00.0 Host bridge: Silicon Integrated Systems [SiS] 645xx (rev 71) 0000:00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SiS AGP Port (virtual PCI-to-PCI bridge) 0000:00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS963 [MuTIOL Media IO] (rev 25) 0000:00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller 0000:00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] 0000:00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] Sound Controller (rev a0) 0000:00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) 0000:00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) 0000:00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller 0000:00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 90) 0000:00:0a.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 46) 0000:00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 20) 0000:00:0c.0 Multimedia controller: Philips Semiconductors SAA7133 Video Broadcast Decoder (rev d0) 0000:01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1) 0000:00:00.0 0600: 1039:0648 (rev 71) 0000:00:01.0 0604: 1039:0003 0000:00:02.0 0601: 1039:0963 (rev 25) 0000:00:02.1 0c05: 1039:0016 0000:00:02.5 0101: 1039:5513 0000:00:02.7 0401: 1039:7012 (rev a0) 0000:00:03.0 0c03: 1039:7001 (rev 0f) 0000:00:03.1 0c03: 1039:7001 (rev 0f) 0000:00:03.3 0c03: 1039:7002 0000:00:04.0 0200: 1039:0900 (rev 90) 0000:00:0a.0 0c00: 1106:3044 (rev 46) 0000:00:0b.0 0200: 10ec:8139 (rev 20) 0000:00:0c.0 0480: 1131:7133 (rev d0) 0000:01:00.0 0300: 10de:0322 (rev a1) ----- End forwarded message ----- -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From tylerapohl at gmail.com Sat Dec 9 23:00:06 2006 From: tylerapohl at gmail.com (Tyler Pohl) Date: Sat, 9 Dec 2006 14:00:06 -0800 Subject: [LinuxBIOS] epia Message-ID: <503ab0210612091400o30447114uc502660d0e403bf@mail.gmail.com> What type of hardware and software would I need to step through LinuxBios code using the early usb debug? TP -------------- next part -------------- An HTML attachment was scrubbed... URL: From tylerapohl at gmail.com Sat Dec 9 23:04:59 2006 From: tylerapohl at gmail.com (Tyler Pohl) Date: Sat, 9 Dec 2006 14:04:59 -0800 Subject: [LinuxBIOS] development board Message-ID: <503ab0210612091404x11686cddo7e8f6321f0329332@mail.gmail.com> I am looking to buy what ever it is I need so I can just step through LinuxBios code on a separate machine. For example I have a 8051 micro controller board and I can download code to its flash via serial and step through the code one line at a time. Is there anything out there so I can do this with LinuxBios? TP -------------- next part -------------- An HTML attachment was scrubbed... URL: From uwe at hermann-uwe.de Sun Dec 10 00:01:52 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 10 Dec 2006 00:01:52 +0100 Subject: [LinuxBIOS] serial output In-Reply-To: <503ab0210612080004g1211a9c8g5fb4352f736d3a04@mail.gmail.com> References: <503ab0210612080004g1211a9c8g5fb4352f736d3a04@mail.gmail.com> Message-ID: <20061209230152.GA24780@greenwood> Change 'ram' to 'RAM' in user-visible output. Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann --- On Fri, Dec 08, 2006 at 12:04:32AM -0800, Tyler Pohl wrote: > Where is the code for serial output. For example if i wanted to change > "Jumping to LinuxBios" to Jumping around" where would i find that code? Apropos... this has been nagging me for a while now, so I'll just fix it once and for all: ram -> RAM. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: ram.patch Type: text/x-diff Size: 2019 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From c-d.hailfinger.devel.2006 at gmx.net Sun Dec 10 00:22:33 2006 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 10 Dec 2006 00:22:33 +0100 Subject: [LinuxBIOS] Signed-off-by versus Acked-by In-Reply-To: <20061209230152.GA24780@greenwood> References: <503ab0210612080004g1211a9c8g5fb4352f736d3a04@mail.gmail.com> <20061209230152.GA24780@greenwood> Message-ID: <457B4539.5030805@gmx.net> Hi, Uwe Hermann wrote: > > Signed-off-by: Uwe Hermann > Acked-by: Uwe Hermann I think this defeats the purpose of the Acked-by tag. If "Acked-by" means you agree with the patch and you need an "Acked-by" from the same person who added the "Signed-off-by", then "Signed-off-by" suddenly implies that you don't necessarily agree with the patch. Which leads to the question: Why did you sign it off when you don't agree with it? The Linux kernel developers either sign off a patch or ack it, but not both at the same time. We can of course differ from their habits, but the reasoning should be sound. Regards, Carl-Daniel From stepan at coresystems.de Sun Dec 10 01:42:20 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 10 Dec 2006 01:42:20 +0100 Subject: [LinuxBIOS] epia In-Reply-To: <503ab0210612091400o30447114uc502660d0e403bf@mail.gmail.com> References: <503ab0210612091400o30447114uc502660d0e403bf@mail.gmail.com> Message-ID: <20061210004219.GB16856@coresystems.de> * Tyler Pohl [061209 23:00]: > What type of hardware and software would I need to step through LinuxBios code > using the early usb debug? usb debug is not in the LinuxBIOS tree. It's also only a replacement for a serial console. On the Epia you dont need it, and you can't use it, since Epia does not have a USB debug port. Just use a serial connection instead and compile in the GDB extension by enabling CONFIG_GDB_STUB. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From uwe at hermann-uwe.de Sun Dec 10 02:37:28 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 10 Dec 2006 02:37:28 +0100 Subject: [LinuxBIOS] Signed-off-by versus Acked-by In-Reply-To: <457B4539.5030805@gmx.net> References: <503ab0210612080004g1211a9c8g5fb4352f736d3a04@mail.gmail.com> <20061209230152.GA24780@greenwood> <457B4539.5030805@gmx.net> Message-ID: <20061210013728.GA24401@greenwood> On Sun, Dec 10, 2006 at 12:22:33AM +0100, Carl-Daniel Hailfinger wrote: > > Signed-off-by: Uwe Hermann > > Acked-by: Uwe Hermann Whoa, sorry, I should not post patches late at night ;-) Of course this should only have contained the Signed-off-by. My bad. > The Linux kernel developers either sign off a patch or > ack it, but not both at the same time. We can of course > differ from their habits, but the reasoning should be > sound. No, that's fine, it was an error on my side. We _do_ sometimes use sign-off+ack from the same person, but only for very small/trivial patches (typos, cosmetic fixes etc) which are committed right away. Usually I would consider this to be one of them, but I wanted to post the patch for review anyway, just in case something depends on the exact output of a booting LinuxBIOS... Cheers, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ivans at isle.spb.ru Sun Dec 10 10:32:00 2006 From: ivans at isle.spb.ru (=?UTF-8?B?0JzQuNGF0LDQuNC7INCY0LLQsNC90L7Qsg==?=) Date: Sun, 10 Dec 2006 12:32:00 +0300 Subject: [LinuxBIOS] linux bios on turion laptops? Message-ID: <457BD410.1040906@isle.spb.ru> Greetings! Sorry if this is a known question - but I didn't find the information on the subject on FAQ page and mailing list archive seems not to be searchable online. Is it possible to use linuxbios on turion notebook, namely MSI magabook L715? Best regards! From ben at hewson-venieri.com Sun Dec 10 11:04:43 2006 From: ben at hewson-venieri.com (Ben Hewson) Date: Sun, 10 Dec 2006 10:04:43 +0000 Subject: [LinuxBIOS] epia Message-ID: <457BDBBB.5080501@hewson-venieri.com> After some reading on the PCI spec I am sure that enumerating of the PCI devices on my epia board is not working as it should be. I assume everyone here is using a recent version of the code. As no one other than those of us using the epia board are having problems, I must assume it is a problem with the VIA chipset and not a bug in Linuxbios. Booting using a current version, I get the following when enumerating the PCI devices (reading resources) PCI: 00:11.1 20 * [0x00000c00 - 0x00000c0f] io PCI: 00:11.1 10 * [0x00000c10 - 0x00000c17] io PCI: 00:11.1 18 * [0x00000c20 - 0x00000c27] io PCI: 00:11.1 14 * [0x00000c30 - 0x00000c33] io PCI: 00:11.1 1c * [0x00000c40 - 0x00000c43] io From stepan at coresystems.de Sun Dec 10 12:03:19 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 10 Dec 2006 12:03:19 +0100 Subject: [LinuxBIOS] epia In-Reply-To: <457BDBBB.5080501@hewson-venieri.com> References: <457BDBBB.5080501@hewson-venieri.com> Message-ID: <20061210110319.GA27548@coresystems.de> * Ben Hewson [061210 11:04]: > The EPIA code is more or less the same, just a few text changes in the > debug so was it just working by luck before ? Did you use the same compiler in both tries? S. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From segher at kernel.crashing.org Sun Dec 10 12:58:41 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 10 Dec 2006 12:58:41 +0100 Subject: [LinuxBIOS] epia In-Reply-To: <457BDBBB.5080501@hewson-venieri.com> References: <457BDBBB.5080501@hewson-venieri.com> Message-ID: > Booting using a current version, I get the following when enumerating > the PCI devices (reading resources) > > PCI: 00:11.1 20 * [0x00000c00 - 0x00000c0f] io > PCI: 00:11.1 10 * [0x00000c10 - 0x00000c17] io > PCI: 00:11.1 18 * [0x00000c20 - 0x00000c27] io > PCI: 00:11.1 14 * [0x00000c30 - 0x00000c33] io > PCI: 00:11.1 1c * [0x00000c40 - 0x00000c43] io That looks just fine. > 00:11.1 IDE interface: VIA Technologies, Inc. > VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) > (prog-if 8a [Master SecP PriP]) It's in legacy mode, the first four BARs are disabled (it uses legacy I/O 0x1f0 etc. instead, and the legacy IRQs too). > One thing I am curious about is that according > to the PCI spec (I only have version 2.1) the base address registers > start at 10h, so why, in the above , does the IDE controller, and in > fact most of the devices on the board use the higher base address > registers ? Look at , it'll take away your confusion hopefully. A device can use any BAR it wants, it is fine to skip 0x10. > Another question I have is the fact that 20h contians d001h. The PCI > spec does mention that a device may have don't care bits in the base > address. So can I assume that, that is the case here ? The low few bits are read-only; bits 01 mean it's an I/O BAR. The base address is 0xd000. > What confuses me is that on an earlier version (head version 2401) > this > worked. Comparing the two versions I can see there have been > changes to > the PCI parts of the code, but nothing to dramatic, and as I have said > no one else seems to be having problems. Since the code assigned all five BARs, the controller is in non-legacy mode; this means that LinuxBIOS set it up that way, since legacy mode is the boot-up default. Some controllers use legacy IRQs even in non-legacy mode, maybe that's your problem. What exactly isn't working? Segher From segher at kernel.crashing.org Sun Dec 10 13:06:16 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 10 Dec 2006 13:06:16 +0100 Subject: [LinuxBIOS] serial output In-Reply-To: <20061209230152.GA24780@greenwood> References: <503ab0210612080004g1211a9c8g5fb4352f736d3a04@mail.gmail.com> <20061209230152.GA24780@greenwood> Message-ID: <61B31ECA-5156-40F5-A54D-23556B93B5A7@kernel.crashing.org> On 10-dec-2006, at 0:01, Uwe Hermann wrote: > Change 'ram' to 'RAM' in user-visible output. As an aside... For any and all patches, please start a new mail thread, with [PATCH] in the title -- this ensures people will actually see the patch, and it makes life a whole lot easier for scripts listening to the mailing list (patch trackers, etc.) Segher From segher at kernel.crashing.org Sun Dec 10 13:12:07 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 10 Dec 2006 13:12:07 +0100 Subject: [LinuxBIOS] Signed-off-by versus Acked-by In-Reply-To: <457B4539.5030805@gmx.net> References: <503ab0210612080004g1211a9c8g5fb4352f736d3a04@mail.gmail.com> <20061209230152.GA24780@greenwood> <457B4539.5030805@gmx.net> Message-ID: >> Signed-off-by: Uwe Hermann >> Acked-by: Uwe Hermann > > I think this defeats the purpose of the Acked-by tag. If > "Acked-by" means you agree with the patch and you need an > "Acked-by" from the same person who added the "Signed-off-by", > then "Signed-off-by" suddenly implies that you don't > necessarily agree with the patch. Which leads to the > question: Why did you sign it off when you don't agree > with it? > The Linux kernel developers either sign off a patch or > ack it, but not both at the same time. We can of course > differ from their habits, but the reasoning should be > sound. Signed-off-by means the patch passed through your hands and you have the legal right to pass it on. Acked-by is just a comment saying who approved this going into the SVN tree, it is completely separate; it should probably be called Approved-by or something like that. I don't really see it having any real purpose, but maybe that's just me :-) Segher From ben at hewson-venieri.com Sun Dec 10 15:37:23 2006 From: ben at hewson-venieri.com (Ben Hewson) Date: Sun, 10 Dec 2006 14:37:23 +0000 Subject: [LinuxBIOS] epia In-Reply-To: References: <457BDBBB.5080501@hewson-venieri.com> Message-ID: <457C1BA3.7090905@hewson-venieri.com> Segher Boessenkool wrote: >> Booting using a current version, I get the following when enumerating >> the PCI devices (reading resources) >> >> PCI: 00:11.1 20 * [0x00000c00 - 0x00000c0f] io >> PCI: 00:11.1 10 * [0x00000c10 - 0x00000c17] io >> PCI: 00:11.1 18 * [0x00000c20 - 0x00000c27] io >> PCI: 00:11.1 14 * [0x00000c30 - 0x00000c33] io >> PCI: 00:11.1 1c * [0x00000c40 - 0x00000c43] io >> > > That looks just fine. > > >> 00:11.1 IDE interface: VIA Technologies, Inc. >> VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) >> (prog-if 8a [Master SecP PriP]) >> > > It's in legacy mode, the first four BARs are disabled (it uses > legacy I/O 0x1f0 etc. instead, and the legacy IRQs too). > > >> One thing I am curious about is that according >> to the PCI spec (I only have version 2.1) the base address registers >> start at 10h, so why, in the above , does the IDE controller, and in >> fact most of the devices on the board use the higher base address >> registers ? >> > > Look at , it'll take away > your confusion hopefully. A device can use any BAR it wants, > it is fine to skip 0x10. > > >> Another question I have is the fact that 20h contians d001h. The PCI >> spec does mention that a device may have don't care bits in the base >> address. So can I assume that, that is the case here ? >> > > The low few bits are read-only; bits 01 mean it's an I/O BAR. > The base address is 0xd000. > > >> What confuses me is that on an earlier version (head version 2401) >> this >> worked. Comparing the two versions I can see there have been >> changes to >> the PCI parts of the code, but nothing to dramatic, and as I have said >> no one else seems to be having problems. >> > > Since the code assigned all five BARs, the controller is in > non-legacy mode; this means that LinuxBIOS set it up that way, > since legacy mode is the boot-up default. Some controllers > use legacy IRQs even in non-legacy mode, maybe that's your > problem. What exactly isn't working? > Ok compiling LB for the same target using the same payload (filo), compiled on the same system, the earlier version works, baring the odd system hang. The later versions gets to filo, but it then comes back with FILO version 0.5 (root at localhost) Sun Nov 12 17:35:53 GMT 2006 boot: hda1:/kern root=/dev/hda3 console=ttyS0,115200 Detected floating bus No drive detected on IDE channel 0 I have attached the boot output from both versions. There are only a few differences in output, mostly to do with PCI 0.11.1 which is the IDE controller. The non working version seems to see more resources. Also when it comes to enabling the IDE controller in compatibilty mode (reg 0x42) the non working versions reports it contains 0xc9, the working version reports the same register as 0. According to the datasheet I have on the southbridge the bottom bits 5-0 in that register should be 0. It is if the non working version is looking at the wrong area of memory. One other thing perhaps you could explain to me, is what exactly is the "pci_routing_fixup" all about ? Thanks for the link btw. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lb_bad URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lb_good URL: From stepan at coresystems.de Sun Dec 10 15:39:32 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 10 Dec 2006 15:39:32 +0100 Subject: [LinuxBIOS] Purpose of Acked-by In-Reply-To: References: <503ab0210612080004g1211a9c8g5fb4352f736d3a04@mail.gmail.com> <20061209230152.GA24780@greenwood> <457B4539.5030805@gmx.net> Message-ID: <20061210143932.GB10842@coresystems.de> * Segher Boessenkool [061210 13:12]: > Acked-by is just a comment saying who approved this going into the SVN > tree, it is completely separate; it should probably be called > Approved-by or something like that. I don't really see it having any > real purpose, but maybe that's just me :-) In firmware development the risk of bricking your machine is very high, even with small changes that might have a side effect that the original author does not see or does not care about. We have had this case so many times and I've been spending many days fixing the tree after someone broke it like that and just stopped submitting patches after that. On the other hand, pointing fingers within a team is useless, it wont make teamwork any better. Thus we agreed on using a "second set of eyes" principle for all work, and expressing this by the Acked-by tag. I understand that amongs developers such a principle of control is observed distrustfully, or considered free of purpose, but in fact it is not. Instead it is a mere method of keeping the tree in the best possible state, and those who are sly dog enough to never break the tree do it to stand solidly united with the others. While inventing Acked-by we also started enforcing it. Using a 2 eyes principle without enforcing it makes absolutely no sense at all. Now the habit of Acking your own patches is a well-known workaround to this 2 eyes principle. It is _supposed_ to look stupid so that people normally dont do it, unless they fulfilled a couple of criteria 1) they waited for a review for an appropriate amount of time 2) they ran abuild 3) they are absolutely certain that the change is so trivial that it wont break anything 4) they are absolutely certain that the change is so trivial that noone would ever oppose. If people start misusing this method, we might just remove them from the list of committers. Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From jon.dufresne at gmail.com Sun Dec 10 15:54:04 2006 From: jon.dufresne at gmail.com (Jon Dufresne) Date: Sun, 10 Dec 2006 09:54:04 -0500 Subject: [LinuxBIOS] serial output In-Reply-To: <61B31ECA-5156-40F5-A54D-23556B93B5A7@kernel.crashing.org> References: <503ab0210612080004g1211a9c8g5fb4352f736d3a04@mail.gmail.com> <20061209230152.GA24780@greenwood> <61B31ECA-5156-40F5-A54D-23556B93B5A7@kernel.crashing.org> Message-ID: <376ea3380612100654y7e0c7fb5h76c8672c82cc6e5b@mail.gmail.com> I'm a little confused then. Are patches supposed to be submitted via trac or the mailing list? Jon On 12/10/06, Segher Boessenkool wrote: > On 10-dec-2006, at 0:01, Uwe Hermann wrote: > > > Change 'ram' to 'RAM' in user-visible output. > > As an aside... For any and all patches, please start a > new mail thread, with [PATCH] in the title -- this ensures > people will actually see the patch, and it makes life a > whole lot easier for scripts listening to the mailing list > (patch trackers, etc.) > > > Segher > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From rminnich at gmail.com Sun Dec 10 16:35:23 2006 From: rminnich at gmail.com (ron minnich) Date: Sun, 10 Dec 2006 08:35:23 -0700 Subject: [LinuxBIOS] linux bios on turion laptops? In-Reply-To: <457BD410.1040906@isle.spb.ru> References: <457BD410.1040906@isle.spb.ru> Message-ID: <13426df10612100735k7ae6530bg2aa2d75b79f7e742@mail.gmail.com> On 12/10/06, ?????? ?????? wrote: > Greetings! Sorry if this is a known question - but I didn't > find the information on the subject on FAQ page and mailing > list archive seems not to be searchable online. Is it possible > to use linuxbios on turion notebook, namely MSI magabook L715? send us an lspci please! thanks ron From stuge-linuxbios at cdy.org Sun Dec 10 17:26:19 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Sun, 10 Dec 2006 17:26:19 +0100 Subject: [LinuxBIOS] development board In-Reply-To: <503ab0210612091404x11686cddo7e8f6321f0329332@mail.gmail.com> References: <503ab0210612091404x11686cddo7e8f6321f0329332@mail.gmail.com> Message-ID: <20061210162619.4768.qmail@cdy.org> On Sat, Dec 09, 2006 at 02:04:59PM -0800, Tyler Pohl wrote: > I am looking to buy what ever it is I need so I can just step through > LinuxBios code on a separate machine. For example I have a 8051 micro > controller board and I can download code to its flash via serial and > step through the code one line at a time. Is there anything out > there so I can do this with LinuxBios? Sure, but I guess an ICE/ICD (In-Circuit-Emulator/Debugger) for a modern CPU will cost a couple of hundred thousand dollars. //Peter From rminnich at gmail.com Sun Dec 10 17:35:56 2006 From: rminnich at gmail.com (ron minnich) Date: Sun, 10 Dec 2006 09:35:56 -0700 Subject: [LinuxBIOS] development board In-Reply-To: <20061210162619.4768.qmail@cdy.org> References: <503ab0210612091404x11686cddo7e8f6321f0329332@mail.gmail.com> <20061210162619.4768.qmail@cdy.org> Message-ID: <13426df10612100835o5a859204x47909bac541e8412@mail.gmail.com> On 12/10/06, Peter Stuge wrote: > Sure, but I guess an ICE/ICD (In-Circuit-Emulator/Debugger) for a > modern CPU will cost a couple of hundred thousand dollars. True, but they're incredibly cheap if you can use JTAG. You can nice ones for several $K, and you can build one for parallel port for much less: http://joule.bu.edu/~hazen/mezz_jtag/ http://www.corelis.com/products/JTAG_Test_Products.htm http://www.simtec.co.uk/products/DTJTAGPAR/ (note: I have NO IDEA which of these work :-) tools: http://openwince.sourceforge.net/jtag/ From tsylla at gmail.com Sun Dec 10 17:44:44 2006 From: tsylla at gmail.com (Tom Sylla) Date: Sun, 10 Dec 2006 11:44:44 -0500 Subject: [LinuxBIOS] development board In-Reply-To: <20061210162619.4768.qmail@cdy.org> References: <503ab0210612091404x11686cddo7e8f6321f0329332@mail.gmail.com> <20061210162619.4768.qmail@cdy.org> Message-ID: <457C397C.4000807@gmail.com> Peter Stuge wrote: > On Sat, Dec 09, 2006 at 02:04:59PM -0800, Tyler Pohl wrote: >> I am looking to buy what ever it is I need so I can just step through >> LinuxBios code on a separate machine. For example I have a 8051 micro >> controller board and I can download code to its flash via serial and >> step through the code one line at a time. Is there anything out >> there so I can do this with LinuxBios? > > Sure, but I guess an ICE/ICD (In-Circuit-Emulator/Debugger) for a > modern CPU will cost a couple of hundred thousand dollars. For a modern processor, "ICE" means something different than what you are thinking of. NO one debugs with a true "ICE" any more, everyone uses JTAG. JTAG debuggers are cheaper now: http://www.macraigor.com/raven.htm is a commercial product that works with K8 series processors. It is $750. You can see the coverage map at: http://www.macraigor.com/cpus.htm American Arium also sells ITP for lots of processors: http://www.arium.com/products/hwdebugtools.html They don't have quotes on their website, but you can probably get one for a couple of thousand dollars. FS2 is the JTAG ICE supplier for Geode GX and LX, it is available for a similar price. Adding to Ron's homebrew stuff: http://www.mouser.com/search/refine.aspx?Ntt=DLP-2232M-G is a $35 board that very easily talks JTAG from USB. From ivans at isle.spb.ru Sun Dec 10 17:50:33 2006 From: ivans at isle.spb.ru (=?KOI8-R?Q?=ED=C9=C8=C1=C9=CC_=E9=D7=C1=CE=CF=D7?=) Date: Sun, 10 Dec 2006 19:50:33 +0300 Subject: [LinuxBIOS] linux bios on turion laptops? In-Reply-To: <13426df10612100735k7ae6530bg2aa2d75b79f7e742@mail.gmail.com> References: <457BD410.1040906@isle.spb.ru> <13426df10612100735k7ae6530bg2aa2d75b79f7e742@mail.gmail.com> Message-ID: <457C3AD9.2080704@isle.spb.ru> ron minnich ?????: > On 12/10/06, ?????? ?????? wrote: >> Greetings! Sorry if this is a known question - but I didn't >> find the information on the subject on FAQ page and mailing >> list archive seems not to be searchable online. Is it possible >> to use linuxbios on turion notebook, namely MSI magabook L715? > > > send us an lspci please! > Here it is: island:[~]> sudo lspci -v 00:00.0 Host bridge: ATI Technologies Inc ATI Radeon Xpress 200 (RS480/RS482/RX480/RX482) Chipset - Host bridge (rev 01) Subsystem: Micro-Star International Co., Ltd. Unknown device 0361 Flags: bus master, 66MHz, medium devsel, latency 0 00:02.0 PCI bridge: ATI Technologies Inc RS480 PCI-X Root Port (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 00009000-00009fff Memory behind bridge: fd500000-fd5fffff Prefetchable memory behind bridge: bbf00000-dbefffff Capabilities: [50] Power Management version 3 Capabilities: [58] Express Root Port (Slot-) IRQ 0 Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [b0] Subsystem: ATI Technologies Inc Unknown device 5951 Capabilities: [b8] HyperTransport: MSI Mapping 00:04.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=03, sec-latency=0 I/O behind bridge: 0000a000-0000afff Memory behind bridge: fd600000-fddfffff Prefetchable memory behind bridge: dbf00000-ddefffff Capabilities: [50] Power Management version 3 Capabilities: [58] Express Root Port (Slot-) IRQ 0 Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [b0] Subsystem: ATI Technologies Inc Unknown device 5951 Capabilities: [b8] HyperTransport: MSI Mapping 00:05.0 PCI bridge: ATI Technologies Inc Unknown device 5a37 (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 Memory behind bridge: fde00000-fe1fffff Capabilities: [50] Power Management version 3 Capabilities: [58] Express Root Port (Slot-) IRQ 0 Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [b0] Subsystem: ATI Technologies Inc Unknown device 5951 Capabilities: [b8] HyperTransport: MSI Mapping 00:13.0 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller (rev 80) (prog-if 10 [OHCI]) Subsystem: ATI Technologies Inc IXP SB400 USB Host Controller Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11 Memory at febff000 (32-bit, non-prefetchable) [size=4K] Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- 00:13.1 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller (rev 80) (prog-if 10 [OHCI]) Subsystem: ATI Technologies Inc IXP SB400 USB Host Controller Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11 Memory at febfe000 (32-bit, non-prefetchable) [size=4K] Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- 00:13.2 USB Controller: ATI Technologies Inc IXP SB400 USB2 Host Controller (rev 80) (prog-if 20 [EHCI]) Subsystem: ATI Technologies Inc IXP SB400 USB2 Host Controller Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11 Memory at febfd000 (32-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- 00:14.0 SMBus: ATI Technologies Inc IXP SB400 SMBus Controller (rev 81) Subsystem: Micro-Star International Co., Ltd. Unknown device 0361 Flags: 66MHz, medium devsel I/O ports at 0b00 [size=16] Memory at 50000000 (32-bit, non-prefetchable) [size=1K] Capabilities: [b0] HyperTransport: MSI Mapping 00:14.1 IDE interface: ATI Technologies Inc Standard Dual Channel PCI IDE Controller ATI (rev 80) (prog-if 8a [Master SecP PriP]) Subsystem: Micro-Star International Co., Ltd. Unknown device 0361 Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 5 I/O ports at I/O ports at I/O ports at I/O ports at I/O ports at ff00 [size=16] Capabilities: [70] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- 00:14.2 Audio device: ATI Technologies Inc SB450 HDA Audio (rev 01) Subsystem: Micro-Star International Co., Ltd. Unknown device 0361 Flags: bus master, slow devsel, latency 64, IRQ 5 Memory at febf8000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- 00:14.3 ISA bridge: ATI Technologies Inc IXP SB400 PCI-ISA Bridge (rev 80) Flags: bus master, 66MHz, medium devsel, latency 0 00:14.4 PCI bridge: ATI Technologies Inc IXP SB400 PCI-PCI Bridge (rev 80) (prog-if 01 [Subtractive decode]) Flags: bus master, 66MHz, medium devsel, latency 64 Bus: primary=00, secondary=05, subordinate=06, sec-latency=64 I/O behind bridge: 0000b000-0000bfff Memory behind bridge: fe200000-feafffff Prefetchable memory behind bridge: ddf00000-dfefffff 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration Flags: fast devsel Capabilities: [80] HyperTransport: Host or Secondary Interface 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map Flags: fast devsel 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller Flags: fast devsel 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control Flags: fast devsel 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility X700 (PCIE) (prog-if 00 [VGA]) Subsystem: Micro-Star International Co., Ltd. Unknown device 0361 Flags: bus master, fast devsel, latency 0, IRQ 10 Memory at c0000000 (32-bit, prefetchable) [size=256M] I/O ports at 9800 [size=256] Memory at fd5f0000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at fd5c0000 [disabled] [size=128K] Capabilities: [50] Power Management version 2 Capabilities: [58] Express Endpoint IRQ 0 Capabilities: [80] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- 04:00.0 Ethernet controller: Agere Systems ET-131x PCI-E Ethernet Controller (rev 01) Subsystem: Micro-Star International Co., Ltd. Unknown device 0361 Flags: bus master, fast devsel, latency 0, IRQ 3 Memory at fe000000 (64-bit, non-prefetchable) [size=2M] Capabilities: [40] Power Management version 2 Capabilities: [48] Express Endpoint IRQ 0 Capabilities: [5c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- 05:04.0 CardBus bridge: O2 Micro, Inc. OZ711MP1/MS1 MemoryCardBus Controller (rev 21) Subsystem: Micro-Star International Co., Ltd. Unknown device 0361 Flags: bus master, stepping, slow devsel, latency 168, IRQ 11 Memory at fe200000 (32-bit, non-prefetchable) [size=4K] Bus: primary=05, secondary=06, subordinate=09, sec-latency=176 Memory window 0: 52000000-53fff000 (prefetchable) Memory window 1: 54000000-55fff000 I/O window 0: 0000b000-0000b0ff I/O window 1: 0000b400-0000b4ff 16-bit legacy interface ports at 0001 05:04.2 Generic system peripheral [0805]: O2 Micro, Inc. Integrated MMC/SD Controller (rev 01) Subsystem: Micro-Star International Co., Ltd. Unknown device 0361 Flags: slow devsel, IRQ 11 Memory at feaffc00 (32-bit, non-prefetchable) [size=256] Capabilities: [a0] Power Management version 2 05:04.3 Bridge: O2 Micro, Inc. Integrated MS/xD Controller (rev 01) Subsystem: Micro-Star International Co., Ltd. Unknown device 0361 Flags: slow devsel, IRQ 11 Memory at feafe000 (32-bit, non-prefetchable) [size=4K] Capabilities: [a0] Power Management version 2 05:04.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02) (prog-if 10 [OHCI]) Subsystem: O2 Micro, Inc. Firewire (IEEE 1394) Flags: bus master, medium devsel, latency 64, IRQ 11 Memory at feafd000 (32-bit, non-prefetchable) [size=4K] Memory at feaff000 (32-bit, non-prefetchable) [size=2K] Capabilities: [60] Power Management version 2 05:09.0 Network controller: RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01) Subsystem: Micro-Star International Co., Ltd. Unknown device 6833 Flags: bus master, slow devsel, latency 64, IRQ 5 Memory at feafa000 (32-bit, non-prefetchable) [size=8K] Capabilities: [40] Power Management version 2 From svn at openbios.org Sun Dec 10 18:25:07 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 10 Dec 2006 17:25:07 -0000 Subject: [LinuxBIOS] #51: flashrom: create a Debian package In-Reply-To: <060.fefec4b686059e06d7e2b3e7f59d2b46@openbios.org> References: <060.fefec4b686059e06d7e2b3e7f59d2b46@openbios.org> Message-ID: <069.26ad7c0207c4eb9024055d6799784a91@openbios.org> #51: flashrom: create a Debian package ----------------------------+----------------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: closed Priority: major | Milestone: Enhance the flashrom utility Component: flashrom | Version: Resolution: fixed | Keywords: debian Dependencies: | Patchstatus: there is no patch ----------------------------+----------------------------------------------- Changes (by uwe): * status: new => closed * resolution: => fixed Comment: Done now. My package has entered Debian unstable today, so you can now install it with a simple {{{ apt-get install flashrom }}} -- Ticket URL: LinuxBIOS From uwe at hermann-uwe.de Sun Dec 10 18:30:57 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 10 Dec 2006 18:30:57 +0100 Subject: [LinuxBIOS] serial output In-Reply-To: <376ea3380612100654y7e0c7fb5h76c8672c82cc6e5b@mail.gmail.com> References: <503ab0210612080004g1211a9c8g5fb4352f736d3a04@mail.gmail.com> <20061209230152.GA24780@greenwood> <61B31ECA-5156-40F5-A54D-23556B93B5A7@kernel.crashing.org> <376ea3380612100654y7e0c7fb5h76c8672c82cc6e5b@mail.gmail.com> Message-ID: <20061210173056.GA17239@greenwood> On Sun, Dec 10, 2006 at 09:54:04AM -0500, Jon Dufresne wrote: > I'm a little confused then. Are patches supposed to be submitted via > trac or the mailing list? Do as you see fit, we don't want to force any method on people. We _recommend_ to use Trac, but currently it has two bugs which really make it hard to work with Trac properly: * You cannot attach patches ;-) http://trac.edgewall.org/ticket/4311 * The notification emails sent by Trac to the mailing list don't contain the patches. http://trac.edgewall.org/ticket/2259 When those are fixed, working with Trac (either via web or via email interface) should be convenient enough for all/most people. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From nbc at pisem.net Sun Dec 10 19:32:55 2006 From: nbc at pisem.net (=?windows-1251?B?wOvl6vHg7eTw?=) Date: Sun, 10 Dec 2006 21:32:55 +0300 Subject: [LinuxBIOS] LinuxBIOS works with chipsets INTEL 865 & 875 ??? Message-ID: <675415539.20061210213255@pisem.net> subj Chipset INTEL 865 lspci -v: 00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02) Subsystem: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub Interface Flags: bus master, fast devsel, latency 0 Memory at fe800000 (32-bit, prefetchable) [size=4M] Capabilities: [e4] Vendor Specific Information 00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02) (prog-if 00 [VGA]) Subsystem: Intel Corporation Unknown device 4c43 Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at f0000000 (32-bit, prefetchable) [size=128M] Memory at ffa80000 (32-bit, non-prefetchable) [size=512K] I/O ports at ec00 [size=8] Capabilities: [d0] Power Management version 1 00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation Unknown device 4c43 Flags: bus master, medium devsel, latency 0, IRQ 193 I/O ports at dc00 [size=32] 00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation Unknown device 4c43 Flags: bus master, medium devsel, latency 0, IRQ 201 I/O ports at e000 [size=32] 00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation Unknown device 4c43 Flags: bus master, medium devsel, latency 0, IRQ 169 I/O ports at e400 [size=32] 00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation Unknown device 4c43 Flags: bus master, medium devsel, latency 0, IRQ 193 I/O ports at e800 [size=32] 00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI]) Subsystem: Intel Corporation Unknown device 4c43 Flags: bus master, medium devsel, latency 0, IRQ 185 Memory at ffa7fc00 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 I/O behind bridge: 0000c000-0000cfff Memory behind bridge: ff800000-ff8fffff 00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02) Flags: bus master, medium devsel, latency 0 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02) (prog-if 8a [Master SecP PriP]) Subsystem: Intel Corporation Unknown device 4c43 Flags: bus master, medium devsel, latency 0, IRQ 169 I/O ports at I/O ports at I/O ports at I/O ports at I/O ports at ffa0 [size=16] Memory at 40000000 (32-bit, non-prefetchable) [size=1K] 00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02) Subsystem: Intel Corporation Unknown device 4c43 Flags: medium devsel, IRQ 3 I/O ports at d800 [size=32] 01:08.0 Ethernet controller: Intel Corporation 82562EZ 10/100 Ethernet Controller (rev 01) Subsystem: Intel Corporation Unknown device 303a Flags: bus master, medium devsel, latency 32, IRQ 177 Memory at ff8ff000 (32-bit, non-prefetchable) [size=4K] I/O ports at cc00 [size=64] Capabilities: [dc] Power Management version 2 From talbotx at comcast.net Mon Dec 11 08:17:17 2006 From: talbotx at comcast.net (Adam Talbot) Date: Sun, 10 Dec 2006 23:17:17 -0800 Subject: [LinuxBIOS] Crazy idea? LinuxBios+Suspend 2 In-Reply-To: <675415539.20061210213255@pisem.net> References: <675415539.20061210213255@pisem.net> Message-ID: <457D05FD.1060408@comcast.net> Like always I am looking for a faster boot time. So an idea came to me. My current "speed system" loads Linuxbios. Then the 2.6.18 kernel, until it reaches the suspend2 code (www.suspend2.net). At that point it resumes from the suspend file, hiding out in swap space. How hard would it be to build in a "suspend to disk" function into linuxbios? I could see a great use for this in laptops running linuxbios, like the OLPC project. Just an idea. -Adam Talbot From svn at openbios.org Mon Dec 11 10:26:19 2006 From: svn at openbios.org (LinuxBIOS) Date: Mon, 11 Dec 2006 09:26:19 -0000 Subject: [LinuxBIOS] #59: Support for SMSC FDC37M60X Super I/O Message-ID: <060.1a58a28db7ce63bcc4fe01aaa59fc30c@openbios.org> #59: Support for SMSC FDC37M60X Super I/O ----------------------------------+----------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: new Priority: major | Milestone: Component: code | Version: v2 Keywords: superio | Dependencies: Patchstatus: patch needs review | ----------------------------------+----------------------------------------- Add support for the SMSC FDC37M60x Super I/O (tested on FDC37M602). Serial output on serial port 1 is tested and works, the rest probably not yet. Signed-off-by: Uwe Hermann --- Patch is available at http://www.openbios.org/pipermail/linuxbios/2006-December/017494.html for now, as Trac currently has problems with attachments. -- Ticket URL: LinuxBIOS From svn at openbios.org Mon Dec 11 10:32:15 2006 From: svn at openbios.org (LinuxBIOS) Date: Mon, 11 Dec 2006 09:32:15 -0000 Subject: [LinuxBIOS] #60: Change 'ram' to 'RAM' in user-visible output Message-ID: <060.45dc2426c21ad9b63b9bde7ba6da46fa@openbios.org> #60: Change 'ram' to 'RAM' in user-visible output ----------------------------------+----------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: new Priority: minor | Milestone: Cosmetic fixes Component: code | Version: v2 Keywords: | Dependencies: Patchstatus: patch needs review | ----------------------------------+----------------------------------------- Change 'ram' to 'RAM' in user-visible output. Signed-off-by: Uwe Hermann --- Patch is available at http://www.openbios.org/pipermail/linuxbios/2006-December/017610.html or directly at http://www.openbios.org/pipermail/linuxbios/attachments/20061210/c82afdec/attachment.bin -- Ticket URL: LinuxBIOS From segher at kernel.crashing.org Mon Dec 11 14:41:37 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Mon, 11 Dec 2006 14:41:37 +0100 Subject: [LinuxBIOS] epia In-Reply-To: <457C1BA3.7090905@hewson-venieri.com> References: <457BDBBB.5080501@hewson-venieri.com> <457C1BA3.7090905@hewson-venieri.com> Message-ID: <16B26BE8-9549-4613-874F-436338899454@kernel.crashing.org> > Also when it comes to enabling the IDE controller in compatibilty mode > (reg 0x42) the non working versions reports it contains 0xc9, the > working version reports the same register as 0. You need to set the prog-if field in the PCI config space for the controller to 0x8a, not 0x8f, before doing the BAR allocation to get legacy mode. Did you do this? Segher From rminnich at gmail.com Mon Dec 11 15:29:51 2006 From: rminnich at gmail.com (ron minnich) Date: Mon, 11 Dec 2006 07:29:51 -0700 Subject: [LinuxBIOS] Crazy idea? LinuxBios+Suspend 2 In-Reply-To: <457D05FD.1060408@comcast.net> References: <675415539.20061210213255@pisem.net> <457D05FD.1060408@comcast.net> Message-ID: <13426df10612110629v51c99cedt86b1017c1fecb935@mail.gmail.com> On 12/11/06, Adam Talbot wrote: > Like always I am looking for a faster boot time. So an idea came to > me. My current "speed system" loads Linuxbios. Then the 2.6.18 kernel, > until it reaches the suspend2 code (www.suspend2.net). At that point it > resumes from the suspend file, hiding out in swap space. How hard would > it be to build in a "suspend to disk" function into linuxbios? > http://www.openbios.org/mailman/listinfo/linuxbios > is your 2.6.18 system loaded in flash or via filo? It would be nice if suspend2 could dump the image into an elfimage on a partition specially set up for, instead of hidden in swap. Then you could even load it from filo ... but on fast machines, linux is going to go faster than most things; could we load 2.6.18 or whatever in flash instead of filo and have it load the magic suspend file? The problem there is that I thought that the suspend kernel and the boot kernel had to be the same kernel; is that true or not? thanks ron From segher at kernel.crashing.org Mon Dec 11 17:03:53 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Mon, 11 Dec 2006 17:03:53 +0100 Subject: [LinuxBIOS] development board In-Reply-To: <457C397C.4000807@gmail.com> References: <503ab0210612091404x11686cddo7e8f6321f0329332@mail.gmail.com> <20061210162619.4768.qmail@cdy.org> <457C397C.4000807@gmail.com> Message-ID: <005FA570-32B7-4FCC-A922-026754911DD4@kernel.crashing.org> >> Sure, but I guess an ICE/ICD (In-Circuit-Emulator/Debugger) for a >> modern CPU will cost a couple of hundred thousand dollars. > > For a modern processor, "ICE" means something different than what you > are thinking of. NO one debugs with a true "ICE" any more, Not "no one" -- but for the purposes we're talking about here, it's pretty close yes. > Adding to Ron's homebrew stuff: > > http://www.mouser.com/search/refine.aspx?Ntt=DLP-2232M-G > > is a $35 board that very easily talks JTAG from USB. Ooh, nice! And a bunch of CPIOs and a 232 port at the same time, too. With drivers and example code and everything. Do note that for debugging a "modern" processor you still need to know what JTAG commands to send (and many manufacturers don't publicly document this). Segher From segher at kernel.crashing.org Mon Dec 11 17:13:43 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Mon, 11 Dec 2006 17:13:43 +0100 Subject: [LinuxBIOS] Purpose of Acked-by In-Reply-To: <20061210143932.GB10842@coresystems.de> References: <503ab0210612080004g1211a9c8g5fb4352f736d3a04@mail.gmail.com> <20061209230152.GA24780@greenwood> <457B4539.5030805@gmx.net> <20061210143932.GB10842@coresystems.de> Message-ID: >> Acked-by is just a comment saying who approved this going into the >> SVN >> tree, it is completely separate; it should probably be called >> Approved-by or something like that. I don't really see it having any >> real purpose, but maybe that's just me :-) > > In firmware development the risk of bricking your machine is very > high, > even with small changes that might have a side effect that the > original > author does not see or does not care about. We have had this case so > many times and I've been spending many days fixing the tree after > someone broke it like that and just stopped submitting patches after > that. > > On the other hand, pointing fingers within a team is useless, it wont > make teamwork any better. Thus we agreed on using a "second set of > eyes" > principle for all work, and expressing this by the Acked-by tag. Oh, I fully understand why patches should be reviewed by other people, and why someone "senior" should approve patches before they are committed to the SVN tree. I'm just challenging the usefulness of the Acked-by tag in the commit message. > I understand that amongs developers such a principle of control is > observed distrustfully, or considered free of purpose, but in fact > it is > not. I don't disagree. > Now the habit of Acking your own patches is a well-known workaround to > this 2 eyes principle. It is _supposed_ to look stupid so that people > normally dont do it, unless they fulfilled a couple of criteria > 1) they waited for a review for an appropriate amount of time This is failing recently in my observation. > 2) they ran abuild As soon as abuild works for everyone, this should be made a requirement. Even now already, we should encourage people to say with their patch submissions "abuild ran with no new failures" or similar. > 3) they are absolutely certain that the change is so trivial > that it wont break anything Yeah right :-) > 4) they are absolutely certain that the change is so trivial > that noone would ever oppose. Heh right :-) There are a 5) and 6) also: 5) Emergency fixes. Hopefully never needed and better discussed widely before committing. This should really just be treated as an exception outside of the normal framework I guess. 6) Revert of one's own recent commits, if problems show up after the fact. > If people start misusing this method, we might just remove them > from the > list of committers. Of course. Misuse is a separate problem :-) Segher From segher at kernel.crashing.org Mon Dec 11 17:16:12 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Mon, 11 Dec 2006 17:16:12 +0100 Subject: [LinuxBIOS] serial output In-Reply-To: <20061210173056.GA17239@greenwood> References: <503ab0210612080004g1211a9c8g5fb4352f736d3a04@mail.gmail.com> <20061209230152.GA24780@greenwood> <61B31ECA-5156-40F5-A54D-23556B93B5A7@kernel.crashing.org> <376ea3380612100654y7e0c7fb5h76c8672c82cc6e5b@mail.gmail.com> <20061210173056.GA17239@greenwood> Message-ID: <70A27441-13AA-4E93-99EF-1F10E3264BC8@kernel.crashing.org> > * The notification emails sent by Trac to the mailing list don't > contain the patches. > http://trac.edgewall.org/ticket/2259 Until this is fixed, it is nice to send the patches you put in Trac to the ML separately, for discussion. Please note the ticket number too then :-) Segher From stepan at coresystems.de Mon Dec 11 17:32:39 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 11 Dec 2006 17:32:39 +0100 Subject: [LinuxBIOS] Purpose of Acked-by In-Reply-To: References: <503ab0210612080004g1211a9c8g5fb4352f736d3a04@mail.gmail.com> <20061209230152.GA24780@greenwood> <457B4539.5030805@gmx.net> <20061210143932.GB10842@coresystems.de> Message-ID: <20061211163239.GA367@coresystems.de> * Segher Boessenkool [061211 17:13]: > Oh, I fully understand why patches should be reviewed by > other people, and why someone "senior" should approve > patches before they are committed to the SVN tree. > > I'm just challenging the usefulness of the Acked-by tag > in the commit message. Oh this is simple: The commit message is used as the interface to the subversion server. There is no other way of easily handling a successful review on basis of commit hooks. The whole magic behind these rules is that they're _automatically enforced. > As soon as abuild works for everyone, this should be made > a requirement. Even now already, we should encourage people > to say with their patch submissions "abuild ran with no new > failures" or similar. abuild runs great. I have not seen any bug reports in a whole while. And I am sure no developer is overstrained by running a bash shell script. Having people explicitly state they ran abuild could do some of the trick. > 5) Emergency fixes. Hopefully never needed and better discussed > widely before committing. This should really just be treated as > an exception outside of the normal framework I guess. This is a hot topic. What would qualify as such an emergency? > 6) Revert of one's own recent commits, if problems show up after > the fact. Ack. Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From segher at kernel.crashing.org Mon Dec 11 18:07:56 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Mon, 11 Dec 2006 18:07:56 +0100 Subject: [LinuxBIOS] Purpose of Acked-by In-Reply-To: <20061211163239.GA367@coresystems.de> References: <503ab0210612080004g1211a9c8g5fb4352f736d3a04@mail.gmail.com> <20061209230152.GA24780@greenwood> <457B4539.5030805@gmx.net> <20061210143932.GB10842@coresystems.de> <20061211163239.GA367@coresystems.de> Message-ID: <27218556-D1E6-4750-8031-DED596664763@kernel.crashing.org> >> I'm just challenging the usefulness of the Acked-by tag >> in the commit message. > > Oh this is simple: The commit message is used as the interface to > the subversion server. There is no other way of easily handling a > successful review on basis of commit hooks. Ah okay, got it. >> As soon as abuild works for everyone, this should be made >> a requirement. Even now already, we should encourage people >> to say with their patch submissions "abuild ran with no new >> failures" or similar. > > abuild runs great. I have not seen any bug reports in a whole > while. It won't do crossbuilds still no? >> 5) Emergency fixes. Hopefully never needed and better discussed >> widely before committing. This should really just be treated as >> an exception outside of the normal framework I guess. > > This is a hot topic. What would qualify as such an emergency? Dunno. Something exceptional. A high-profile security issue or a "brick everything!" bug or something. Something insanely important to fix _right now_. There's no need to have any protocol for this, or document it in the check-in rules; just as long as the automated tools don't stand in the way in such a case all is fine :-) Segher From talbotx at comcast.net Mon Dec 11 18:57:52 2006 From: talbotx at comcast.net (Adam Talbot) Date: Mon, 11 Dec 2006 09:57:52 -0800 Subject: [LinuxBIOS] Crazy idea? LinuxBios+Suspend 2 In-Reply-To: <13426df10612110629v51c99cedt86b1017c1fecb935@mail.gmail.com> References: <675415539.20061210213255@pisem.net> <457D05FD.1060408@comcast.net> <13426df10612110629v51c99cedt86b1017c1fecb935@mail.gmail.com> Message-ID: <457D9C20.1060905@comcast.net> My 2.6.18 kernel comes off the disk, so filo. Currently the 2.6.18 kernel need to load, just a little, to set up memory and disk in order to access the disk and the suspend file. Also, you must use the same kernel rev. But I am thinking much lower. This perhaps would be best as a patch to filo, as we will need disk access. Forget the nice way that suspens2 works, by only pulling the used RAM to the suspend image; just grab all the ram. So a call goes out from the OS to Linuxbios (filo). From there linuxbios freezes the OS (Stopping the Program Counter (PC)). At this point linuxbios has free rain of the RAM. Start at the beginning of the RAM and spool it off to disk. We would need a "suspend" partition. Once the ram image is on disk, set a suspended flag in the cmos, for linuxbios on the next boot. Power the system off. On the next boot linuxbios (or filo, depending on where this code goes) sees the suspended flag in cmos and takes the ram image and puts it back into memory, then restores the PC and starts it counting again. Logical step order. Freeze system. Linuxbios takes over and copies ram to disk+ current PC cmos "suspended" flag is set. System powers off System powers on Linuxbios loads and see the "suspended" flag. Remove the suspended flag from cmos. Load the ram image off disk and back into ram, reload the PC Unfreeze the system. Now the big problem here is I am just a collage student, which mean I have learned lots to comp theory and nothing useful. So I can give you the theory and hope its a good idea, but I will not be much good past that. Is this a workable idea? -Adam Talbot ron minnich wrote: > On 12/11/06, Adam Talbot wrote: >> Like always I am looking for a faster boot time. So an idea came to >> me. My current "speed system" loads Linuxbios. Then the 2.6.18 kernel, >> until it reaches the suspend2 code (www.suspend2.net). At that point it >> resumes from the suspend file, hiding out in swap space. How hard would >> it be to build in a "suspend to disk" function into linuxbios? >> http://www.openbios.org/mailman/listinfo/linuxbios >> > > is your 2.6.18 system loaded in flash or via filo? > > It would be nice if suspend2 could dump the image into an elfimage on > a partition specially set up for, instead of hidden in swap. Then you > could even load it from filo ... but on fast machines, linux is going > to go faster than most things; could we load 2.6.18 or whatever in > flash instead of filo and have it load the magic suspend file? > > The problem there is that I thought that the suspend kernel and the > boot kernel had to be the same kernel; is that true or not? > > thanks > > ron > From stepan at coresystems.de Mon Dec 11 18:58:04 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 11 Dec 2006 18:58:04 +0100 Subject: [LinuxBIOS] Purpose of Acked-by In-Reply-To: <27218556-D1E6-4750-8031-DED596664763@kernel.crashing.org> References: <503ab0210612080004g1211a9c8g5fb4352f736d3a04@mail.gmail.com> <20061209230152.GA24780@greenwood> <457B4539.5030805@gmx.net> <20061210143932.GB10842@coresystems.de> <20061211163239.GA367@coresystems.de> <27218556-D1E6-4750-8031-DED596664763@kernel.crashing.org> Message-ID: <20061211175804.GA3272@coresystems.de> * Segher Boessenkool [061211 18:07]: > >abuild runs great. I have not seen any bug reports in a whole > >while. > > It won't do crossbuilds still no? It did from the very first day. You need an appropriate cross compiler installed and in your path though. S. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From yinghai.lu at amd.com Mon Dec 11 19:48:33 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Mon, 11 Dec 2006 10:48:33 -0800 Subject: [LinuxBIOS] linux bios on turion laptops? Message-ID: <5986589C150B2F49A46483AC44C7BCA49072AF@ssvlexmb2.amd.com> That is on ATI chipset. I am working on one AM2+MCP55 based MB and then someone could use that for PVR or DTC. For laptop support, I need to double check the code about mem support. I only verify the code for AM2 and socket F for Rev F CPU. YH From gfiala at s.netic.de Mon Dec 11 19:57:13 2006 From: gfiala at s.netic.de (Guido Fiala) Date: Mon, 11 Dec 2006 19:57:13 +0100 Subject: [LinuxBIOS] Crazy idea? LinuxBios+Suspend 2 In-Reply-To: <457D9C20.1060905@comcast.net> References: <675415539.20061210213255@pisem.net> <13426df10612110629v51c99cedt86b1017c1fecb935@mail.gmail.com> <457D9C20.1060905@comcast.net> Message-ID: <200612111957.13678.gfiala@s.netic.de> On Monday 11 December 2006 18:57, Adam Talbot wrote: > Forget the nice way > that suspens2 works, by only pulling the used RAM to the suspend image; I always hated the silly way windows works on hibernation - at least you can use a list of used pages and just write them out to speed it up, eventually even use a fast compression algorithm for easy to compress pages or similar ideas. At least Windows takes longer to boot from disk image (for large RAM as today) than normal boot, no gain there - would that be better for LinuxBios? I doubt it. So what is so great to not boot from swap-image? Wouldn't it be easier to patch filo to be able to boot the swap than to reprogram suspend2 ? BTW - i thought suspend2 can also boot from a file instead of swap? But i'am curious what timing one could expect when using suspend2 and LinuxBios, the time to graphical interface wouldn't be much longer than to console - just the time to swap in the X-server, i guess? From jon.dufresne at gmail.com Mon Dec 11 19:59:34 2006 From: jon.dufresne at gmail.com (Jon Dufresne) Date: Mon, 11 Dec 2006 13:59:34 -0500 Subject: [LinuxBIOS] trouble with cpu cache Message-ID: <376ea3380612111059q52ccd7b7q5dbfd6eaf7f99b46@mail.gmail.com> I am having a great deal of difficulty figuring out how to enable the cache on my board. Using memtest86 it is quite obvious that the cache is not running at its correct speed. Is this something I enable in the chipset code or the mainboard code? I tried grepping through the source and I couldn't find a good example of enabling the cache. I noticed the function enable_cache(). I tried executing this somehwere in northbridge.c, but it didn't speed things up. Either I'm using wrong or it is the wrong function to use. I also searched my chipset (intel 855gme) and cpu (pentium m) datasheets for something useful on the subject and found references to MTRR, but no explaination of how to enable cache. Is this along the right track? Any help is much appreciated, Jon From yinghai.lu at amd.com Mon Dec 11 19:59:26 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Mon, 11 Dec 2006 10:59:26 -0800 Subject: [LinuxBIOS] Crazy idea? LinuxBios+Suspend 2 Message-ID: <5986589C150B2F49A46483AC44C7BCA49072B2@ssvlexmb2.amd.com> Is the suspend be the job of OS instead of firmware? I wonder if kexec or kdump could load another kernel to dump previous kernel to disk partition or file. Also wonder if you have one kernel to use kexec reload one dumped image? YH From ward at gnu.org Mon Dec 11 20:17:02 2006 From: ward at gnu.org (Ward Vandewege) Date: Mon, 11 Dec 2006 14:17:02 -0500 Subject: [LinuxBIOS] Crazy idea? LinuxBios+Suspend 2 In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49072B2@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49072B2@ssvlexmb2.amd.com> Message-ID: <20061211191702.GA9491@countzero.vandewege.net> On Mon, Dec 11, 2006 at 10:59:26AM -0800, Lu, Yinghai wrote: > Is the suspend be the job of OS instead of firmware? That's an interesting question. Proprietary BIOSes used to do suspend to disk - I had a laptop 7 years ago that did it (HP Omnibook XE2). Every laptop I've owned since then does not have a suspend feature. Would having the BIOS do suspend require a BIOS callback? What was described in this thread made it sound like a callback is necessary. Thanks, Ward. From segher at kernel.crashing.org Mon Dec 11 20:35:13 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Mon, 11 Dec 2006 20:35:13 +0100 Subject: [LinuxBIOS] Purpose of Acked-by In-Reply-To: <20061211175804.GA3272@coresystems.de> References: <503ab0210612080004g1211a9c8g5fb4352f736d3a04@mail.gmail.com> <20061209230152.GA24780@greenwood> <457B4539.5030805@gmx.net> <20061210143932.GB10842@coresystems.de> <20061211163239.GA367@coresystems.de> <27218556-D1E6-4750-8031-DED596664763@kernel.crashing.org> <20061211175804.GA3272@coresystems.de> Message-ID: <316DCAAA-5975-40D4-840B-182A88281F1D@kernel.crashing.org> >>> abuild runs great. I have not seen any bug reports in a whole >>> while. >> >> It won't do crossbuilds still no? > > It did from the very first day. Heh, not for me ;-) > You need an appropriate cross compiler > installed and in your path though. I'll try it out again, I have *many* (100 or so) cross-compilers in my path, maybe it gets confused a bit :-) Segher From ebiederm at xmission.com Mon Dec 11 20:48:56 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Mon, 11 Dec 2006 12:48:56 -0700 Subject: [LinuxBIOS] Crazy idea? LinuxBios+Suspend 2 In-Reply-To: <20061211191702.GA9491@countzero.vandewege.net> (Ward Vandewege's message of "Mon, 11 Dec 2006 14:17:02 -0500") References: <5986589C150B2F49A46483AC44C7BCA49072B2@ssvlexmb2.amd.com> <20061211191702.GA9491@countzero.vandewege.net> Message-ID: Ward Vandewege writes: > On Mon, Dec 11, 2006 at 10:59:26AM -0800, Lu, Yinghai wrote: >> Is the suspend be the job of OS instead of firmware? > > That's an interesting question. Proprietary BIOSes used to do suspend to disk > - I had a laptop 7 years ago that did it (HP Omnibook XE2). Every laptop I've > owned since then does not have a suspend feature. > > Would having the BIOS do suspend require a BIOS callback? What was described > in this thread made it sound like a callback is necessary. Suspend to RAM currently appears to be something that the OS cannot do alone. At least because cpu wakeup has to go through the BIOS. Beyond that I think you are likely to get a lot more users and a lot more debugging and testing if you put the work in the OS. Eric From stepan at coresystems.de Mon Dec 11 21:36:40 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 11 Dec 2006 21:36:40 +0100 Subject: [LinuxBIOS] Crazy idea? LinuxBios+Suspend 2 In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49072B2@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49072B2@ssvlexmb2.amd.com> Message-ID: <20061211203639.GA26906@coresystems.de> * Lu, Yinghai [061211 19:59]: > Is the suspend be the job of OS instead of firmware? LinuxBIOS' effort has indeed been the other way around: Move everything into the OS that is not necessarily a task of the firmware. Since we have this no-callback paradigm in the LLFW we should probably stick with that. > I wonder if kexec or kdump could load another kernel to dump previous > kernel to disk partition or file. Why would you want to load another kernel first? Can you return from a kexec call and have the original kernel dump the virtual environment of the freshly loaded one? S. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From stepan at coresystems.de Mon Dec 11 21:39:53 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 11 Dec 2006 21:39:53 +0100 Subject: [LinuxBIOS] Crazy idea? LinuxBios+Suspend 2 In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA49072B2@ssvlexmb2.amd.com> <20061211191702.GA9491@countzero.vandewege.net> Message-ID: <20061211203953.GB26906@coresystems.de> * Eric W. Biederman [061211 20:48]: > Beyond that I think you are likely to get a lot more users and a lot > more debugging and testing if you put the work in the OS. One drawback with Linux suspend is both suspend and recover speed. Or the lack thereof. I have not seen a laptop in years where Linux suspend would have a noticable gain over a reboot+shutdown cycle, if there was a gain at all. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From ebiederm at xmission.com Mon Dec 11 22:05:22 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Mon, 11 Dec 2006 14:05:22 -0700 Subject: [LinuxBIOS] Crazy idea? LinuxBios+Suspend 2 In-Reply-To: <20061211203639.GA26906@coresystems.de> (Stefan Reinauer's message of "Mon, 11 Dec 2006 21:36:40 +0100") References: <5986589C150B2F49A46483AC44C7BCA49072B2@ssvlexmb2.amd.com> <20061211203639.GA26906@coresystems.de> Message-ID: Stefan Reinauer writes: > * Lu, Yinghai [061211 19:59]: >> Is the suspend be the job of OS instead of firmware? > > LinuxBIOS' effort has indeed been the other way around: Move everything > into the OS that is not necessarily a task of the firmware. > > Since we have this no-callback paradigm in the LLFW we should probably > stick with that. > >> I wonder if kexec or kdump could load another kernel to dump previous >> kernel to disk partition or file. > > Why would you want to load another kernel first? Can you return from a > kexec call and have the original kernel dump the virtual environment of > the freshly loaded one? Nope kexec has no provision for returning. There is some small argument that standing outside the kernel might make the problem easier, but I don't think that helps much. Eric From rminnich at gmail.com Mon Dec 11 22:30:12 2006 From: rminnich at gmail.com (ron minnich) Date: Mon, 11 Dec 2006 14:30:12 -0700 Subject: [LinuxBIOS] Crazy idea? LinuxBios+Suspend 2 In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA49072B2@ssvlexmb2.amd.com> <20061211191702.GA9491@countzero.vandewege.net> Message-ID: <13426df10612111330h2f6fd18j5ac97b71494ed126@mail.gmail.com> On 12/11/06, Eric W. Biederman wrote: > Suspend to RAM currently appears to be something that the OS cannot do alone. At > least because cpu wakeup has to go through the BIOS. > > Beyond that I think you are likely to get a lot more users and a lot more debugging > and testing if you put the work in the OS. we're working on a mostly OS-based approach for OLPC; stay tuned. The handshake with BIOS should be minimal, and require 0 callbacks. ron From talbotx at comcast.net Mon Dec 11 23:39:26 2006 From: talbotx at comcast.net (Adam Talbot) Date: Mon, 11 Dec 2006 14:39:26 -0800 Subject: [LinuxBIOS] Crazy idea? LinuxBios+Suspend 2 In-Reply-To: <13426df10612111330h2f6fd18j5ac97b71494ed126@mail.gmail.com> References: <5986589C150B2F49A46483AC44C7BCA49072B2@ssvlexmb2.amd.com> <20061211191702.GA9491@countzero.vandewege.net> <13426df10612111330h2f6fd18j5ac97b71494ed126@mail.gmail.com> Message-ID: <457DDE1E.7070409@comcast.net> Well, I am very glad to see all the input on this idea. Lets see if I can add some info and sort what we have. Current speeds. My current system takes about 3 seconds for Linuxbios, then 2 more for kernel, to the suspend2 code, then 7~12sec depending on how much compression I am using on the suspend2 image. So a total boot time of about 15 seconds. Up and playing music, with full X. A normal boot is 33 sec, to get to a full X + music playing. I want sub 10. Dont care about suspending time, just resume. All this is suspend to disk. I need to be able to power the system off of N time. Could we make suspend be a hybrid process? Taking both firmware and the OS? No BIOS call backs, I think we can get away with suspending from the OS, and setting a cmos flag for linuxbios to catch on the way up. This would allow us to just restore the "needed" memory, instead of hibernation mess of windows. So place this such code in filo and boot from swap. (Thanks Guido) Things I dont know. Does Suspend2 replace the kernel? Is it a true full image of RAM? Could we use a version of the suspend2 code for resuming only? Could we use ACPI in order to deal with a call back issue? Make this a power call? Suspend times VS RAM. In the Suspend2 configs, you can tell it to keep the image size down, and it will place most of the ram in swap before making the image. Thus cutting the boot time way down. Even in the case of larger systems with GB+ of ram. Some idea -Adam ron minnich wrote: > On 12/11/06, Eric W. Biederman wrote: > >> Suspend to RAM currently appears to be something that the OS cannot >> do alone. At >> least because cpu wakeup has to go through the BIOS. >> >> Beyond that I think you are likely to get a lot more users and a lot >> more debugging >> and testing if you put the work in the OS. > > we're working on a mostly OS-based approach for OLPC; stay tuned. The > handshake with BIOS should be minimal, and require 0 callbacks. > > ron > From piotrek4 at wp.pl Mon Dec 11 23:41:29 2006 From: piotrek4 at wp.pl (piotrek) Date: Mon, 11 Dec 2006 23:41:29 +0100 Subject: [LinuxBIOS] Motherboard Message-ID: <457DDE99.5080604@wp.pl> Is this motherboard supported by Linux BIOS? lspci -v output 0000:00:00.0 Host bridge: Silicon Integrated Systems [SiS] 645xx (rev 71) Subsystem: Silicon Integrated Systems [SiS] 645xx Flags: bus master, medium devsel, latency 32 Memory at e0000000 (32-bit, non-prefetchable) [size=64M] Capabilities: [c0] AGP version 3.5 0000:00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SiS AGP Port (virtual PCI-to-PCI bridge) (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, fast devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 Memory behind bridge: e4000000-e5ffffff Prefetchable memory behind bridge: d0000000-dfffffff 0000:00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS963 [MuTIOL Media IO] (rev 25) Flags: bus master, medium devsel, latency 0 0000:00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller Flags: medium devsel I/O ports at 1400 [size=32] 0000:00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (prog-if 80 [Master]) Subsystem: Silicon Integrated Systems [SiS] SiS5513 EIDE Controller (A,B step) Flags: bus master, medium devsel, latency 128 I/O ports at f000 [size=16] 0000:00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] Sound Controller (rev a0) Subsystem: Giga-byte Technology: Unknown device a205 Flags: bus master, medium devsel, latency 32, IRQ 185 I/O ports at d800 [size=256] I/O ports at dc00 [size=128] Capabilities: [48] Power Management version 2 0000:00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) (prog-if 10 [OHCI]) Subsystem: Silicon Integrated Systems [SiS] USB 1.0 Controller Flags: bus master, medium devsel, latency 32, IRQ 169 Memory at e7003000 (32-bit, non-prefetchable) [size=4K] 0000:00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) (prog-if 10 [OHCI]) Subsystem: Silicon Integrated Systems [SiS] USB 1.0 Controller Flags: bus master, medium devsel, latency 32, IRQ 177 Memory at e7000000 (32-bit, non-prefetchable) [size=4K] 0000:00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller (prog-if 20 [EHCI]) Subsystem: Giga-byte Technology: Unknown device 5004 Flags: bus master, medium devsel, latency 32, IRQ 193 Memory at e7001000 (32-bit, non-prefetchable) [size=4K] Capabilities: [50] Power Management version 2 0000:00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 90) Subsystem: Giga-byte Technology: Unknown device e000 Flags: bus master, medium devsel, latency 32, IRQ 201 I/O ports at e000 [size=256] Memory at e7002000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at 40000000 [disabled] [size=128K] Capabilities: [40] Power Management version 2 0000:00:0a.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 46) (prog-if 10 [OHCI]) Subsystem: VIA Technologies, Inc. IEEE 1394 Host Controller Flags: bus master, medium devsel, latency 32, IRQ 185 Memory at e7004000 (32-bit, non-prefetchable) [size=2K] I/O ports at e400 [size=128] Capabilities: [50] Power Management version 2 0000:00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 20) Subsystem: Realtek Semiconductor Co., Ltd. RT8139 Flags: bus master, medium devsel, latency 32, IRQ 201 I/O ports at e800 [size=256] Memory at e7005000 (32-bit, non-prefetchable) [size=256] Expansion ROM at 40020000 [disabled] [size=128K] Capabilities: [50] Power Management version 2 0000:00:0c.0 Multimedia controller: Philips Semiconductors SAA7133 Video Broadcast Decoder (rev d0) Subsystem: Avermedia Technologies Inc Avermedia AVerTV GO 007 FM Flags: bus master, medium devsel, latency 32, IRQ 209 Memory at e7006000 (32-bit, non-prefetchable) [size=2K] Capabilities: [40] Power Management version 2 0000:01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1) (prog-if 00 [VGA]) Flags: bus master, 66MHz, medium devsel, latency 248, IRQ 209 Memory at e4000000 (32-bit, non-prefetchable) [size=16M] Memory at d0000000 (32-bit, prefetchable) [size=256M] Expansion ROM at e5000000 [disabled] [size=128K] Capabilities: [60] Power Management version 2 Capabilities: [44] AGP version 3.0 lspci -n output 0000:00:00.0 0600: 1039:0648 (rev 71) 0000:00:01.0 0604: 1039:0003 0000:00:02.0 0601: 1039:0963 (rev 25) 0000:00:02.1 0c05: 1039:0016 0000:00:02.5 0101: 1039:5513 0000:00:02.7 0401: 1039:7012 (rev a0) 0000:00:03.0 0c03: 1039:7001 (rev 0f) 0000:00:03.1 0c03: 1039:7001 (rev 0f) 0000:00:03.3 0c03: 1039:7002 0000:00:04.0 0200: 1039:0900 (rev 90) 0000:00:0a.0 0c00: 1106:3044 (rev 46) 0000:00:0b.0 0200: 10ec:8139 (rev 20) 0000:00:0c.0 0480: 1131:7133 (rev d0) 0000:01:00.0 0300: 10de:0322 (rev a1) Peter From svn at openbios.org Mon Dec 11 23:44:30 2006 From: svn at openbios.org (LinuxBIOS) Date: Mon, 11 Dec 2006 22:44:30 -0000 Subject: [LinuxBIOS] #61: Add mtrr support for pentium m cpus Message-ID: <060.03c40551c978f5758a2002cd5ebd9157@openbios.org> #61: Add mtrr support for pentium m cpus -----------------------------------------------------+---------------------- Reporter: Jon Dufresne | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Keywords: | Dependencies: Patchstatus: patch needs review | -----------------------------------------------------+---------------------- For cache to work the x86_setup_mtrrs() must be called. My cache would not work without adding this to the cpu/intel/model_*/model_*_init.c file. My cpu is a model_6dx I added this line to the other cpu's but only tested model_6dx (that is the only one I have). However, they should work. -- Ticket URL: LinuxBIOS From stepan at coresystems.de Tue Dec 12 00:09:49 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 12 Dec 2006 00:09:49 +0100 Subject: [LinuxBIOS] [ANNOUNCE] Automated and Distributed Test System for LinuxBIOS Message-ID: <20061211230949.GA26855@coresystems.de> Dear LinuxBIOS community, it's about time to release the automated and distributed test system for LinuxBIOS. The test system creates a framework to run images created by the automatic build system (known from http://snapshots.linuxbios.org/ a.k.a http://qa.linuxbios.org/) on real hardware. So from now on LinuxBIOS binary images can be downloaded from http://qa.linuxbios.org/ that are known to work on at least one mainboard of the given type. I started a page gathering all the information about the test system in the Wiki. Please help completing it: http://linuxbios.org/Distributed_and_Automated_Testsystem Get a short overview on the test system from the slides of the talk I held at the LinuxBIOS symposium 2006: http://www.coresystems.de/PDFs/LinuxBIOS-testing/Slides-LinuxBIOS-QA.pdf Since nobody is supposed to have the 50+ mainboards supported by LinuxBIOSv2 at a single place, the system works distributed and single boards can be hooked up to the test system with relatively cheap components. So please do understand this announcement as a call for participation. This test system is only of value if we get many boards tested on a regular basis. Are you working for a mainboard or system vendor that supports LinuxBIOS? Are you a developer that has a spare board supported by LinuxBIOS sitting at your office? Then please have a look at the Test Integration Manual to find out how you can help the LinuxBIOS project to improve its quality: http://www.coresystems.de/PDFs/LinuxBIOS-testing/TestIntegrationManual.pdf The Test Integration Manual also explains how you can add new tests and test components to the test system. Are you developing LinuxBIOS, and just want to know how to use the test system without setting up your own dedicated test hardware? Make sure a bios image you build works on real hardware? Then have a glance at the Developer's Manual: http://www.coresystems.de/PDFs/LinuxBIOS-testing/DevelopersManual.pdf An exercise that some of you might know from safety critical and embedded software is test and project documentation. Basically the goal should be to have (at least) one test for each requirement of the software system. There are two IEEE standards for writing specifications for such requirements and test specifications: IEEE Std 829-1998: IEEE Standard for Software Test Documentation IEEE Std 830-1998: IEEE Recommended Practice for Software Requirements Specifications I wrote a requirements specification for LinuxBIOS which is rather incomplete and only scratches the top of the iceberg. (Not to mention that not all of the requirements are properly tested, while some tests dont have a requirement yet) While I tried to keep close to the standard, there are some differences and inaccuracies that might be fine for most projects, unless LinuxBIOS is taking a relevant part in a mission critical application that requires strict compliance (in which case it should be easy to fix that) Find the documents here: http://www.coresystems.de/PDFs/LinuxBIOS-testing/RequirementsSpecification.pdf http://www.coresystems.de/PDFs/LinuxBIOS-testing/TestSpecification.pdf Any ideas, add-ons, patches, hints, flames, questions are of course welcome. Again: If you have a chance to participate in the LinuxBIOS testing, please have a glimpse at the Test Integration Manual and contact me to get things going. Best regards, Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From stepan at coresystems.de Tue Dec 12 00:19:57 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 12 Dec 2006 00:19:57 +0100 Subject: [LinuxBIOS] Crazy idea? LinuxBios+Suspend 2 In-Reply-To: <457DDE1E.7070409@comcast.net> References: <5986589C150B2F49A46483AC44C7BCA49072B2@ssvlexmb2.amd.com> <20061211191702.GA9491@countzero.vandewege.net> <13426df10612111330h2f6fd18j5ac97b71494ed126@mail.gmail.com> <457DDE1E.7070409@comcast.net> Message-ID: <20061211231956.GA17830@coresystems.de> * Adam Talbot [061211 23:39]: > My current system takes about 3 seconds for Linuxbios, then 2 more for > kernel, to the suspend2 code, then 7~12sec depending on how much > compression I am using on the suspend2 image. Just a thought, the firmware level IDE driver is usually not using DMA or any advanced reading methods, and as such a lot slower than the according Linux driver. You might have a hard time keeping the 2s the kernel needs. > So a total boot time of about 15 seconds. Up and playing music, with > full X. A normal boot is 33 sec, to get to a full X + music playing. > I want sub 10. Your calculation goes with 3+2+10s - Instead of tuning the 3s or 2s, you might instead start improving on the biggest piece of the cake: the 10s. I would assume the 2s kernel do some initialization that are expected to happen for the suspend code to work. So even if you manage to win 2s by not booting a kernel, you might have quite some other things to "fix". S. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From uwe at hermann-uwe.de Tue Dec 12 00:56:15 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Tue, 12 Dec 2006 00:56:15 +0100 Subject: [LinuxBIOS] LinuxBIOS works with chipsets INTEL 865 & 875 ??? In-Reply-To: <675415539.20061210213255@pisem.net> References: <675415539.20061210213255@pisem.net> Message-ID: <20061211235615.GB27834@greenwood> Hi, On Sun, Dec 10, 2006 at 09:32:55PM +0300, ????????? wrote: > Chipset INTEL 865 lspci -v: > > 00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02) Not yet supported as far as I can see, but the 855PM might be similar. > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2) (prog-if 00 [Normal decode]) > 00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02) This seems to be supported. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From uwe at hermann-uwe.de Tue Dec 12 00:58:02 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Tue, 12 Dec 2006 00:58:02 +0100 Subject: [LinuxBIOS] Motherboard In-Reply-To: <457DDE99.5080604@wp.pl> References: <457DDE99.5080604@wp.pl> Message-ID: <20061211235802.GC27834@greenwood> Hi, On Mon, Dec 11, 2006 at 11:41:29PM +0100, piotrek wrote: > 0000:00:00.0 Host bridge: Silicon Integrated Systems [SiS] 645xx (rev 71) > 0000:00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS963 [MuTIOL Both are not supported yet, as far as I can tell. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From mcqmcqmcq at fastmail.fm Tue Dec 12 01:05:58 2006 From: mcqmcqmcq at fastmail.fm (mcqmcqmcq at fastmail.fm) Date: Mon, 11 Dec 2006 16:05:58 -0800 Subject: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled Message-ID: <1165881958.16691.279986199@webmail.messagingengine.com> Hi, guys, I've just started playing with LinuxBIOS on the IWill DK8-HTX with a PathScale InfiniPath HTX card in the HTX slot. Long story short: boots with HTX card unplugged, hangs early in boot with it plugged in. Same for both r2520 (head today) and r2481. The latter is the supposedly known-working here: http://linuxbios.eu/DK8HTX_Build_Tutorial Same behavior on multiple machines, one of which has been in realiable service with LB sans HTX card for a few days, so I suspect it's not a problem of hardware flakiness. Before I dive in and try to track it down (perhaps on Wednesday), does anybody know of something obvious I need to do/hardcode/whatever to use the HTX slot? Thanks for any insight you may have! -mcq --- With the InfiniPath HTX card installed, hangs very early: [---POWER APPLIED---] LinuxBIOS-2.0.0_dk8_htx_Fallback Mon Dec 11 14:49:16 MST 2006 starting... *sysinfo range: [000cf000,000cf2c0) bsp_apicid=00 (0,1) link=01 (1,0) link=01 02 nodes initialized. core0 started: 01 started ap apicid: SBLink=02 NC node|link=00 busn=40 NC node|link=02 ht reset - [---PAUSE ca. 5 SECONDS---] LinuxBIOS-2.0.0_dk8_htx_Fallback Mon Dec 11 14:49:16 MST 2006 starting... *sysinfo range: [000cf000,000cf2c0) bsp_apicid=00 (0,1) link=01 (1,0) link=01 02 nodes initialized. core0 started: 01 started ap apicid: SBLink=02 NC node|link=00 busn=40 NC node|link=02 [---PERMANENT HANG---] With the InfiniPath HTX card removed: [---POWER APPLIED---] LinuxBIOS-2.0.0_dk8_htx_Fallback Mon Dec 11 14:49:16 MST 2006 starting... *sysinfo range: [000cf000,000cf2c0) bsp_apicid=00 (0,1) link=01 (1,0) link=01 02 nodes initialized. core0 started: 01 started ap apicid: SBLink=02 NC node|link=02 ht reset - LinuxBIOS-2.0.0_dk8_htx_Fallback Mon Dec 11 14:49:16 MST 2006 starting... *sysinfo range: [000cf000,000cf2c0) bsp_apicid=00 (0,1) link=01 (1,0) link=01 02 nodes initialized. core0 started: 01 started ap apicid: SBLink=02 NC node|link=02 Ram1.00 Ram1.01 Ram2.00 Ram2.01 Ram3 Initializing memory: done Initializing memory: done Ram4 v_esp=000cefe8 testx = 5a5a5a5a Copying data from cache to ram -- switching to use ram as stack... Done testx = 5a5a5a5a Disabling cache as ram now Clearing initial memory region: Done Copying LinuxBIOS to ram. src=fffdf000 ... [---NORMAL SUCCESSFUL BOOT CONTINUES---] [tweek.mcq] gcc-3.3 -v Reading specs from /usr/lib/gcc-lib/i486-linux-gnu/3.3.6/specs Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --enable-__cxa_atexit --with-system-zlib --enable-nls --without-included-gettext --enable-clocale=gnu --enable-debug i486-linux-gnu Thread model: posix gcc version 3.3.6 (Debian 1:3.3.6-13) -- mcqmcqmcq at fastmail.fm -- http://www.fastmail.fm - And now for something completely different From yinghai.lu at amd.com Tue Dec 12 01:23:55 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Mon, 11 Dec 2006 16:23:55 -0800 Subject: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled Message-ID: <5986589C150B2F49A46483AC44C7BCA49072B5@ssvlexmb2.amd.com> How about remove the soft_reset_x in cache_as_ram_auto.c? YH From mcqmcqmcq at fastmail.fm Tue Dec 12 01:39:58 2006 From: mcqmcqmcq at fastmail.fm (mcqmcqmcq at fastmail.fm) Date: Mon, 11 Dec 2006 16:39:58 -0800 Subject: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49072B5@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49072B5@ssvlexmb2.amd.com> Message-ID: <1165883998.19837.279990331@webmail.messagingengine.com> YH> How about remove the soft_reset_x in cache_as_ram_auto.c? That indeed got it to boot, but the HTX card doesn't show up in lspci in Linux, so it's still not coming up quite right. Any more ideas to try? I'm thankful for your help and happy to keep banging on it as long as you are. :) -mcq -- mcqmcqmcq at fastmail.fm -- http://www.fastmail.fm - Send your email first class From yinghai.lu at amd.com Tue Dec 12 02:09:28 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Mon, 11 Dec 2006 17:09:28 -0800 Subject: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled Message-ID: <5986589C150B2F49A46483AC44C7BCA49072B7@ssvlexmb2.amd.com> Bootlog? YH From mcqmcqmcq at fastmail.fm Tue Dec 12 03:02:18 2006 From: mcqmcqmcq at fastmail.fm (mcqmcqmcq at fastmail.fm) Date: Mon, 11 Dec 2006 18:02:18 -0800 Subject: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49072B7@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49072B7@ssvlexmb2.amd.com> Message-ID: <1165888938.27855.280000827@webmail.messagingengine.com> > Bootlog? Attached at 8. Lemme know if you want the full spew. -mcq -- mcqmcqmcq at fastmail.fm -- http://www.fastmail.fm - Faster than the air-speed velocity of an unladen european swallow -------------- next part -------------- A non-text attachment was scrubbed... Name: minicom.cap.gz Type: application/x-gzip Size: 3323 bytes Desc: not available URL: From svn at openbios.org Tue Dec 12 03:58:38 2006 From: svn at openbios.org (LinuxBIOS) Date: Tue, 12 Dec 2006 02:58:38 -0000 Subject: [LinuxBIOS] #6: Add support for 10 cheap, mainstream motherboards In-Reply-To: <060.4056def32ed57b9135e2feadecdf45dc@openbios.org> References: <060.4056def32ed57b9135e2feadecdf45dc@openbios.org> Message-ID: <069.c030f35b3d226cfcede2cbcfa44f0fdc@openbios.org> #6: Add support for 10 cheap, mainstream motherboards ----------------------+----------------------------------------------------- Reporter: uwe | Owner: somebody Type: task | Status: new Priority: major | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: Dependencies: | ----------------------+----------------------------------------------------- Comment (by i underscore am underscore nitrogen at hotmail dot com): I have an Asus A7V8X-X. I'd like to contribute to supporting it. How much does it cost to get started? -- Ticket URL: LinuxBIOS From yinghai.lu at amd.com Tue Dec 12 04:44:00 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Mon, 11 Dec 2006 19:44:00 -0800 Subject: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled Message-ID: <5986589C150B2F49A46483AC44C7BCA49072B9@ssvlexmb2.amd.com> Try acpi=off for kernel command line. Or disable acpi in linuxbios in you MB Options.lb YH -----Original Message----- From: mcqmcqmcq at fastmail.fm [mailto:mcqmcqmcq at fastmail.fm] Sent: Monday, December 11, 2006 6:02 PM To: Lu, Yinghai; linuxbios at linuxbios.org Subject: RE: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled > Bootlog? Attached at 8. Lemme know if you want the full spew. -mcq -- mcqmcqmcq at fastmail.fm -- http://www.fastmail.fm - Faster than the air-speed velocity of an unladen european swallow From u4110464 at anu.edu.au Tue Dec 12 06:40:33 2006 From: u4110464 at anu.edu.au (David Michael Barr) Date: Tue, 12 Dec 2006 16:40:33 +1100 (EST) Subject: [LinuxBIOS] Porting to Asus A8N-SLI Deluxe In-Reply-To: <13426df10612080809k4eb9446cv3e7e091ab040817a@mail.gmail.com> References: <44775.203.129.49.37.1165588611.squirrel@sqmail.anu.edu.au> <376ea3380612080706t5c295efenda9a519f1058e5d8@mail.gmail.com> <13426df10612080809k4eb9446cv3e7e091ab040817a@mail.gmail.com> Message-ID: <62349.150.203.2.85.1165902033.squirrel@sqmail.anu.edu.au> My bad. The southbridge is an NVIDIA CK804. Unfortunately there's a few km between my PC and Internet access right now, so I'll have to get back to you about lspci. Does the CK804 come in many flavours? From jrydberg at gnu.org Tue Dec 12 14:30:36 2006 From: jrydberg at gnu.org (Johan Rydberg) Date: Tue, 12 Dec 2006 14:30:36 +0100 Subject: [LinuxBIOS] [ANNOUNCE] GNUFI Message-ID: <873b7lckcj.fsf@gnu.org> [Initial announcement of GNUFI. First and final cross-post.] The GNU Firmware Implementation (GNUFI) ======================================= GNUFI is designed to be a firmware compatible with the Unified Extensible Firmware Interface [1] specification. GNUFI is designed so that it can be adopted to different runtime environments; such as a legacy BIOS or U-boot environment, or as a LinuxBIOS payload. GNUFI is released under the GNU General Public License (GNU GPL). GNUFI has a web page: http://www.gnu.org/software/gnufi/ Availability ============ At this point there has not been any official releases of GNUFI. The sources is available through a Bazaar [2] version controlled repository: http://gnufi.openbios.org/gnufi.dev Mailing lists ============= The main discussion list is , and is used to discuss all aspects of GNUFI, including its development and porting. Subscribe by visiting the web page bug-gnufi [3]. [1] http://www.uefi.org/ [2] http://www.bazaar-vcs.org/ [3] http://lists.gnu.org/mailman/listinfo/bug-gnufi -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From eswierk at arastra.com Tue Dec 12 19:50:46 2006 From: eswierk at arastra.com (Ed Swierk) Date: Tue, 12 Dec 2006 10:50:46 -0800 Subject: [LinuxBIOS] More MCP55 hacking Message-ID: I've resumed hacking on LinuxBIOS on an Athlon socket AM2 board with an nVidia MCP55 southbridge and a C51XE between the two. I'm using the CK804 southbridge code with updated PCI IDs, and Yinghai's socket AM2 code. I've gotten a Linux kernel to boot, but I am stuck on a few issues: 1. I haven't gotten interrupt routing to work yet, and the IRQ routing table I extract from the factory BIOS seems broken. When I boot with the factory BIOS, however, Linux uses ACPI for interrupt routing, which I think bypasses the routing table altogether. Should I try to fix the routing table or try to get ACPI working? Linux searches for a device to act as an interrupt router; which device on my board would play that role? 2. The HT bridge configuration seems messed up. Linux complains "Unable to handle 64-bit address space" for each bridge because the limit register is still 0. How do I get these registers configured properly? 3. I'm not sure whether HT unitid assignment is correct; the meanings of HT_CHAIN_UNITID_BASE, HT_CHAIN_END_UNITID_BASE, SB_HT_CHAIN_ON_BUS0 and SB_HT_CHAIN_UNITID_OFFSET_ONLY are very unclear despite comments in the code. 4. The PCI device IDs assigned during HyperTransport device enumeration don't match up with those assigned by the factory BIOS, e.g. the southbridge HT interface (device 10de:0369) is assigned to device 1 on LinuxBIOS but device 8 on the factory BIOS. I'm not sure whether this is a big deal, but is there some way to get them assigned in the same way? I've attached a boot dump (boot.txt), various lspci dumps, and my mainboard Options.lb and Config.lb. Any help would be appreciated. --Ed -------------- next part -------------- LinuxBIOS-2.0.0-FILO Tue Dec 12 09:36:24 PST 2006 starting... Enabling routing table for node 00 done. Enabling UP settings coherent_ht_finalize done core0 started: started ap apicid: 01 SBLink=00 NC node|link=00 SMBus controller enabled Ram1.00 setting up CPU00 northbridge registers done. Ram2.00 Unbuffered 333Mhz 333Mhz RAM: 0x00080000 KB Ram3 dimm_mask = 00000001 x4_mask = 00000000 x16_mask = 00000000 single_rank_mask = 00000001 ODC = 00111222 Addr Timing= 00202220 Initializing memory: done Setting variable MTRR 02, base: 0000MB, range: 0200MB, type WB DQS Training:RcvrEn:Pass1: 00 CTLRMaxDelay=17 done DQS Training:DQSPos: 00 done DQS Training:RcvrEn:Pass2: 00 CTLRMaxDelay=49 done DQS Training:tsc[00]=000000001052d24a DQS Training:tsc[01]=0000000011006146 DQS Training:tsc[02]=000000001104f42f DQS Training:tsc[03]=00000000205c1930 DQS Training:tsc[04]=00000000214ce745 Ram4 v_esp=000ceebc testx = 5a5a5a5a Copying data from cache to ram -- switching to use ram as stack... Done testx = 5a5a5a5a Disabling cache as ram now Clearing initial memory region: Done Copying LinuxBIOS to ram. src=fffe0000 dst=00004000 linxbios_ram.nrv2b length = 00008a80 linxbios_ram.bin length = 00013e44 Jumping to LinuxBIOS. LinuxBIOS-2.0.0-FILO Tue Dec 12 09:36:24 PST 2006 booting... Enumerating buses... scan_static_bus for Root Device APIC_CLUSTER: 0 enabled PCI_DOMAIN: 0000 enabled APIC_CLUSTER: 0 scanning... PCI: 00:18.3 siblings=1 CPU: APIC: 00 enabled malloc Enter, size 668, free_mem_ptr 0003a000 malloc 0x0003a000 CPU: APIC: 01 enabled PCI_DOMAIN: 0000 scanning... PCI: pci_scan_bus for bus 00 PCI: 00:18.0 [1022/1100] bus ops PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] ops PCI: 00:18.3 [1022/1103] enabled PCI: devfn 0xc4, bad id 0xffffffff PCI: devfn 0xc5, bad id 0xffffffff PCI: devfn 0xc6, bad id 0xffffffff PCI: devfn 0xc7, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff Capability: 0x08 @ 0x44 flags: 0x01e1 Collapsing PCI: 00:01.0 [10de/0369] Capability: 0x08 @ 0x44 Capability: 0x08 @ 0x44 Capability: 0x08 @ 0x44 Capability: 0x08 @ 0xb0 Capability: 0x08 @ 0xcc flags: 0xa802 Capability: 0x08 @ 0x44 Capability: 0x08 @ 0xb0 Capability: 0x08 @ 0xcc Capability: 0x08 @ 0x44 flags: 0x01e6 Collapsing PCI: 00:06.0 [10de/02f4] Capability: 0x08 @ 0x44 Capability: 0x08 @ 0x70 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x6c flags: 0xa802 Capability: 0x08 @ 0x44 Capability: 0x08 @ 0x70 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x6c Capability: 0x08 @ 0x44 Capability: 0x08 @ 0x70 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x6c flags: 0xa802 Capability: 0x08 @ 0x44 Capability: 0x08 @ 0x70 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x6c Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 flags: 0xa800 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 flags: 0xa800 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 flags: 0xa800 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 flags: 0xa800 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 flags: 0xa800 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x08 @ 0x80 flags: 0x2101 Capability: 0x08 @ 0x80 PCI: 00:00.0 [10de/02f4] enabled Capability: 0x08 @ 0x44 flags: 0x01e0 PCI: 00:06.0 count: 000f static_count: 0001 PCI: 00:06.0 [10de/02f4] enabled next_unitid: 0015 malloc Enter, size 668, free_mem_ptr 0003a29c malloc 0x0003a29c PCI: 00:00.0 [10de/0369] ops PCI: 00:00.0 [10de/0369] enabled Capability: 0x08 @ 0x44 flags: 0x01e0 PCI: 00:15.0 count: 000f static_count: 0001 PCI: 00:15.0 [10de/0369] enabled next_unitid: 0024 PCI: pci_scan_bus for bus 00 PCI: devfn 0x0, bad id 0xffffffff PCI: 00:01.0 [10de/0369] enabled malloc Enter, size 668, free_mem_ptr 0003a538 malloc 0x0003a538 PCI: 00:02.0 [10de/0360] bus ops PCI: 00:02.0 [10de/0360] enabled malloc Enter, size 668, free_mem_ptr 0003a7d4 malloc 0x0003a7d4 PCI: 00:02.1 [10de/0368] bus ops PCI: 00:02.1 [10de/0368] enabled malloc Enter, size 668, free_mem_ptr 0003aa70 malloc 0x0003aa70 PCI: 00:02.2 [10de/036a] enabled PCI: devfn 0x13, bad id 0xffffffff PCI: devfn 0x14, bad id 0xffffffff PCI: devfn 0x15, bad id 0xffffffff PCI: devfn 0x16, bad id 0xffffffff PCI: devfn 0x17, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0003ad0c malloc 0x0003ad0c PCI: 00:03.0 [10de/036c] ops PCI: 00:03.0 [10de/036c] enabled malloc Enter, size 668, free_mem_ptr 0003afa8 malloc 0x0003afa8 PCI: 00:03.1 [10de/036d] ops PCI: 00:03.1 [10de/036d] enabled PCI: devfn 0x1a, bad id 0xffffffff PCI: devfn 0x1b, bad id 0xffffffff PCI: devfn 0x1c, bad id 0xffffffff PCI: devfn 0x1d, bad id 0xffffffff PCI: devfn 0x1e, bad id 0xffffffff PCI: devfn 0x1f, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0003b244 malloc 0x0003b244 PCI: 00:05.0 [10de/036e] ops PCI: 00:05.0 [10de/036e] enabled PCI: 00:06.0 [10de/02f4] enabled malloc Enter, size 668, free_mem_ptr 0003b4e0 malloc 0x0003b4e0 PCI: 00:06.1 [10de/02fa] enabled malloc Enter, size 668, free_mem_ptr 0003b77c malloc 0x0003b77c PCI: 00:06.2 [10de/02fe] enabled malloc Enter, size 668, free_mem_ptr 0003ba18 malloc 0x0003ba18 PCI: 00:06.3 [10de/02f8] enabled malloc Enter, size 668, free_mem_ptr 0003bcb4 malloc 0x0003bcb4 PCI: 00:06.4 [10de/02f9] enabled malloc Enter, size 668, free_mem_ptr 0003bf50 malloc 0x0003bf50 PCI: 00:06.5 [10de/02ff] enabled malloc Enter, size 668, free_mem_ptr 0003c1ec malloc 0x0003c1ec PCI: 00:06.6 [10de/027f] enabled malloc Enter, size 668, free_mem_ptr 0003c488 malloc 0x0003c488 PCI: 00:06.7 [10de/027e] enabled malloc Enter, size 668, free_mem_ptr 0003c724 malloc 0x0003c724 PCI: 00:07.0 [10de/0370] bus ops PCI: 00:07.0 [10de/0370] enabled malloc Enter, size 668, free_mem_ptr 0003c9c0 malloc 0x0003c9c0 PCI: 00:07.1 [10de/0371] ops PCI: 00:07.1 [10de/0371] enabled PCI: devfn 0x3a, bad id 0xffffffff PCI: devfn 0x3b, bad id 0xffffffff PCI: devfn 0x3c, bad id 0xffffffff PCI: devfn 0x3d, bad id 0xffffffff PCI: devfn 0x3e, bad id 0xffffffff PCI: devfn 0x3f, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0003cc5c malloc 0x0003cc5c Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 00:08.0 subbordinate bus PCI Express PCI: 00:08.0 [10de/02fc] enabled malloc Enter, size 668, free_mem_ptr 0003cef8 malloc 0x0003cef8 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 00:09.0 subbordinate bus PCI Express PCI: 00:09.0 [10de/02fd] enabled malloc Enter, size 668, free_mem_ptr 0003d194 malloc 0x0003d194 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 00:0a.0 subbordinate bus PCI Express PCI: 00:0a.0 [10de/02fb] enabled malloc Enter, size 668, free_mem_ptr 0003d430 malloc 0x0003d430 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 00:0b.0 subbordinate bus PCI Express PCI: 00:0b.0 [10de/0376] enabled malloc Enter, size 668, free_mem_ptr 0003d6cc malloc 0x0003d6cc PCI: 00:0c.0 [10de/0374] bus ops PCI: 00:0c.0 [10de/0374] enabled PCI: devfn 0x68, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0003d968 malloc 0x0003d968 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 00:0e.0 subbordinate bus PCI Express PCI: 00:0e.0 [10de/0378] enabled malloc Enter, size 668, free_mem_ptr 0003dc04 malloc 0x0003dc04 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 00:0f.0 subbordinate bus PCI Express PCI: 00:0f.0 [10de/0375] enabled malloc Enter, size 668, free_mem_ptr 0003dea0 malloc 0x0003dea0 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 00:10.0 subbordinate bus PCI Express PCI: 00:10.0 [10de/0377] enabled PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff scan_static_bus for PCI: 00:02.0 scan_static_bus for PCI: 00:02.0 done scan_static_bus for PCI: 00:02.1 scan_static_bus for PCI: 00:02.1 done do_pci_scan_bridge for PCI: 00:07.0 PCI: pci_scan_bus for bus 01 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0003e13c malloc 0x0003e13c PCI: 01:09.0 [1106/3044] enabled PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=001 do_pci_scan_bridge returns max 1 do_pci_scan_bridge for PCI: 00:08.0 PCI: pci_scan_bus for bus 02 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=002 do_pci_scan_bridge returns max 2 do_pci_scan_bridge for PCI: 00:09.0 PCI: pci_scan_bus for bus 03 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=003 do_pci_scan_bridge returns max 3 do_pci_scan_bridge for PCI: 00:0a.0 PCI: pci_scan_bus for bus 04 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=004 do_pci_scan_bridge returns max 4 do_pci_scan_bridge for PCI: 00:0b.0 PCI: pci_scan_bus for bus 05 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=005 do_pci_scan_bridge returns max 5 do_pci_scan_bridge for PCI: 00:0c.0 PCI: pci_scan_bus for bus 06 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=006 do_pci_scan_bridge returns max 6 do_pci_scan_bridge for PCI: 00:0e.0 PCI: pci_scan_bus for bus 07 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=007 do_pci_scan_bridge returns max 7 do_pci_scan_bridge for PCI: 00:0f.0 PCI: pci_scan_bus for bus 08 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=008 do_pci_scan_bridge returns max 8 do_pci_scan_bridge for PCI: 00:10.0 PCI: pci_scan_bus for bus 09 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=009 do_pci_scan_bridge returns max 9 PCI: pci_scan_bus returning with max=009 PCI: pci_scan_bus returning with max=009 PCI_DOMAIN: 0000 passpw: enabled scan_static_bus for Root Device done done Allocating resources... Reading resources... Root Device compute_allocate_io: base: 00000400 size: 00000000 align: 0 gran: 0 Root Device read_resources bus 0 link: 0 PCI_DOMAIN: 0000 read_resources bus 0 link: 0 PCI: 00:18.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:18.0 read_resources bus 0 link: 0 PCI: 00:02.0 read_resources bus 0 link: 0 PCI: 00:02.0 read_resources bus 0 link: 0 done PCI: 00:07.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:07.0 read_resources bus 1 link: 0 PCI: 00:07.0 read_resources bus 1 link: 0 done PCI: 01:09.0 14 * [0x00000000 - 0x0000007f] io PCI: 00:07.0 compute_allocate_io: base: 00000080 size: 00001000 align: 12 gran: 12 done PCI: 00:07.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:07.0 read_resources bus 1 link: 0 PCI: 00:07.0 read_resources bus 1 link: 0 done PCI: 00:07.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:07.0 compute_allocate_prefmem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:07.0 read_resources bus 1 link: 0 PCI: 00:07.0 read_resources bus 1 link: 0 done PCI: 00:07.0 compute_allocate_prefmem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:07.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 01 prefmem PCI: 00:07.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:07.0 read_resources bus 1 link: 0 PCI: 00:07.0 read_resources bus 1 link: 0 done PCI: 01:09.0 10 * [0x00000000 - 0x000007ff] mem PCI: 00:07.0 compute_allocate_mem: base: 00000800 size: 00100000 align: 20 gran: 20 done PCI: 00:08.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:08.0 read_resources bus 2 link: 0 PCI: 00:08.0 read_resources bus 2 link: 0 done PCI: 00:08.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:08.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 00:08.0 read_resources bus 2 link: 0 PCI: 00:08.0 read_resources bus 2 link: 0 done PCI: 00:08.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 00:08.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 02 io PCI: 00:08.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:08.0 read_resources bus 2 link: 0 PCI: 00:08.0 read_resources bus 2 link: 0 done PCI: 00:08.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:08.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 00:08.0 read_resources bus 2 link: 0 PCI: 00:08.0 read_resources bus 2 link: 0 done PCI: 00:08.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:08.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 02 prefmem PCI: 00:08.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:08.0 read_resources bus 2 link: 0 PCI: 00:08.0 read_resources bus 2 link: 0 done PCI: 00:08.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:08.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:08.0 read_resources bus 2 link: 0 PCI: 00:08.0 read_resources bus 2 link: 0 done PCI: 00:08.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:08.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 02 mem PCI: 00:09.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:09.0 read_resources bus 3 link: 0 PCI: 00:09.0 read_resources bus 3 link: 0 done PCI: 00:09.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:09.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 00:09.0 read_resources bus 3 link: 0 PCI: 00:09.0 read_resources bus 3 link: 0 done PCI: 00:09.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 00:09.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 03 io PCI: 00:09.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:09.0 read_resources bus 3 link: 0 PCI: 00:09.0 read_resources bus 3 link: 0 done PCI: 00:09.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:09.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 00:09.0 read_resources bus 3 link: 0 PCI: 00:09.0 read_resources bus 3 link: 0 done PCI: 00:09.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:09.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 03 prefmem PCI: 00:09.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:09.0 read_resources bus 3 link: 0 PCI: 00:09.0 read_resources bus 3 link: 0 done PCI: 00:09.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:09.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:09.0 read_resources bus 3 link: 0 PCI: 00:09.0 read_resources bus 3 link: 0 done PCI: 00:09.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:09.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 03 mem PCI: 00:0a.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:0a.0 read_resources bus 4 link: 0 PCI: 00:0a.0 read_resources bus 4 link: 0 done PCI: 00:0a.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:0a.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 00:0a.0 read_resources bus 4 link: 0 PCI: 00:0a.0 read_resources bus 4 link: 0 done PCI: 00:0a.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 00:0a.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 04 io PCI: 00:0a.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:0a.0 read_resources bus 4 link: 0 PCI: 00:0a.0 read_resources bus 4 link: 0 done PCI: 00:0a.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:0a.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 00:0a.0 read_resources bus 4 link: 0 PCI: 00:0a.0 read_resources bus 4 link: 0 done PCI: 00:0a.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:0a.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 04 prefmem PCI: 00:0a.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:0a.0 read_resources bus 4 link: 0 PCI: 00:0a.0 read_resources bus 4 link: 0 done PCI: 00:0a.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:0a.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:0a.0 read_resources bus 4 link: 0 PCI: 00:0a.0 read_resources bus 4 link: 0 done PCI: 00:0a.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:0a.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 04 mem PCI: 00:0b.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:0b.0 read_resources bus 5 link: 0 PCI: 00:0b.0 read_resources bus 5 link: 0 done PCI: 00:0b.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:0b.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 00:0b.0 read_resources bus 5 link: 0 PCI: 00:0b.0 read_resources bus 5 link: 0 done PCI: 00:0b.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 00:0b.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 05 io PCI: 00:0b.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:0b.0 read_resources bus 5 link: 0 PCI: 00:0b.0 read_resources bus 5 link: 0 done PCI: 00:0b.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:0b.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 00:0b.0 read_resources bus 5 link: 0 PCI: 00:0b.0 read_resources bus 5 link: 0 done PCI: 00:0b.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:0b.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 05 prefmem PCI: 00:0b.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:0b.0 read_resources bus 5 link: 0 PCI: 00:0b.0 read_resources bus 5 link: 0 done PCI: 00:0b.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:0b.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:0b.0 read_resources bus 5 link: 0 PCI: 00:0b.0 read_resources bus 5 link: 0 done PCI: 00:0b.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:0b.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 05 mem PCI: 00:0c.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:0c.0 read_resources bus 6 link: 0 PCI: 00:0c.0 read_resources bus 6 link: 0 done PCI: 00:0c.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:0c.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 00:0c.0 read_resources bus 6 link: 0 PCI: 00:0c.0 read_resources bus 6 link: 0 done PCI: 00:0c.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 00:0c.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 06 io PCI: 00:0c.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:0c.0 read_resources bus 6 link: 0 PCI: 00:0c.0 read_resources bus 6 link: 0 done PCI: 00:0c.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:0c.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 00:0c.0 read_resources bus 6 link: 0 PCI: 00:0c.0 read_resources bus 6 link: 0 done PCI: 00:0c.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:0c.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 06 prefmem PCI: 00:0c.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:0c.0 read_resources bus 6 link: 0 PCI: 00:0c.0 read_resources bus 6 link: 0 done PCI: 00:0c.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:0c.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:0c.0 read_resources bus 6 link: 0 PCI: 00:0c.0 read_resources bus 6 link: 0 done PCI: 00:0c.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:0c.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 06 mem PCI: 00:0e.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:0e.0 read_resources bus 7 link: 0 PCI: 00:0e.0 read_resources bus 7 link: 0 done PCI: 00:0e.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:0e.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 00:0e.0 read_resources bus 7 link: 0 PCI: 00:0e.0 read_resources bus 7 link: 0 done PCI: 00:0e.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 00:0e.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 07 io PCI: 00:0e.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:0e.0 read_resources bus 7 link: 0 PCI: 00:0e.0 read_resources bus 7 link: 0 done PCI: 00:0e.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:0e.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 00:0e.0 read_resources bus 7 link: 0 PCI: 00:0e.0 read_resources bus 7 link: 0 done PCI: 00:0e.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:0e.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 07 prefmem PCI: 00:0e.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:0e.0 read_resources bus 7 link: 0 PCI: 00:0e.0 read_resources bus 7 link: 0 done PCI: 00:0e.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:0e.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:0e.0 read_resources bus 7 link: 0 PCI: 00:0e.0 read_resources bus 7 link: 0 done PCI: 00:0e.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:0e.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 07 mem PCI: 00:0f.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:0f.0 read_resources bus 8 link: 0 PCI: 00:0f.0 read_resources bus 8 link: 0 done PCI: 00:0f.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:0f.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 00:0f.0 read_resources bus 8 link: 0 PCI: 00:0f.0 read_resources bus 8 link: 0 done PCI: 00:0f.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 00:0f.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 08 io PCI: 00:0f.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:0f.0 read_resources bus 8 link: 0 PCI: 00:0f.0 read_resources bus 8 link: 0 done PCI: 00:0f.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:0f.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 00:0f.0 read_resources bus 8 link: 0 PCI: 00:0f.0 read_resources bus 8 link: 0 done PCI: 00:0f.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:0f.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 08 prefmem PCI: 00:0f.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:0f.0 read_resources bus 8 link: 0 PCI: 00:0f.0 read_resources bus 8 link: 0 done PCI: 00:0f.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:0f.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:0f.0 read_resources bus 8 link: 0 PCI: 00:0f.0 read_resources bus 8 link: 0 done PCI: 00:0f.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:0f.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 08 mem PCI: 00:10.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:10.0 read_resources bus 9 link: 0 PCI: 00:10.0 read_resources bus 9 link: 0 done PCI: 00:10.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:10.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 00:10.0 read_resources bus 9 link: 0 PCI: 00:10.0 read_resources bus 9 link: 0 done PCI: 00:10.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 00:10.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 09 io PCI: 00:10.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:10.0 read_resources bus 9 link: 0 PCI: 00:10.0 read_resources bus 9 link: 0 done PCI: 00:10.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:10.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 00:10.0 read_resources bus 9 link: 0 PCI: 00:10.0 read_resources bus 9 link: 0 done PCI: 00:10.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:10.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 09 prefmem PCI: 00:10.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:10.0 read_resources bus 9 link: 0 PCI: 00:10.0 read_resources bus 9 link: 0 done PCI: 00:10.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:10.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:10.0 read_resources bus 9 link: 0 PCI: 00:10.0 read_resources bus 9 link: 0 done PCI: 00:10.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:10.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 09 mem PCI: 00:18.0 read_resources bus 0 link: 0 done PCI: 00:07.0 1c * [0x00000000 - 0x00000fff] io PCI: 00:02.1 20 * [0x00001000 - 0x0000103f] io PCI: 00:02.1 24 * [0x00001040 - 0x0000107f] io PCI: 00:05.0 20 * [0x00001080 - 0x0000108f] io PCI: 00:18.0 compute_allocate_io: base: 00001090 size: 00002000 align: 12 gran: 12 done PCI: 00:18.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:18.0 read_resources bus 0 link: 0 PCI: 00:18.0 read_resources bus 0 link: 0 done PCI: 00:18.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:18.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:18.0 read_resources bus 0 link: 0 PCI: 00:18.0 read_resources bus 0 link: 0 done PCI: 00:07.0 20 * [0x00000000 - 0x000fffff] mem PCI: 00:07.1 10 * [0x00100000 - 0x00103fff] mem PCI: 00:03.0 10 * [0x00104000 - 0x00104fff] mem PCI: 00:03.1 10 * [0x00105000 - 0x001050ff] mem PCI: 00:18.0 compute_allocate_mem: base: 00105100 size: 00200000 align: 20 gran: 20 done PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done Root Device read_resources bus 0 link: 0 done PCI: 00:18.0 1c0 * [0x00001000 - 0x00002fff] io Root Device compute_allocate_io: base: 00003000 size: 00002c00 align: 12 gran: 0 done Root Device compute_allocate_mem: base: 00000000 size: 00000000 align: 0 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:18.3 94 * [0x00000000 - 0x03ffffff] mem PCI: 00:18.0 1b0 * [0x04000000 - 0x041fffff] mem PCI: 00:18.0 1b8 * [0x04200000 - 0x041fffff] prefmem Root Device compute_allocate_mem: base: 04200000 size: 04200000 align: 26 gran: 0 done Done reading resources. Setting resources... Root Device compute_allocate_io: base: 00001000 size: 00002c00 align: 12 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:18.0 1c0 * [0x00001000 - 0x00002fff] io Root Device compute_allocate_io: base: 00003000 size: 00002000 align: 12 gran: 0 done Root Device compute_allocate_mem: base: f8000000 size: 04200000 align: 26 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:18.3 94 * [0xf8000000 - 0xfbffffff] mem PCI: 00:18.0 1b0 * [0xfc000000 - 0xfc1fffff] mem PCI: 00:18.0 1b8 * [0xfc200000 - 0xfc1fffff] prefmem Root Device compute_allocate_mem: base: fc200000 size: 04200000 align: 26 gran: 0 done Root Device assign_resources, bus 0 link: 0 PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 PCI: 00:18.0 compute_allocate_io: base: 00001000 size: 00002000 align: 12 gran: 12 PCI: 00:18.0 read_resources bus 0 link: 0 PCI: 00:18.0 read_resources bus 0 link: 0 done PCI: 00:07.0 1c * [0x00001000 - 0x00001fff] io PCI: 00:02.1 20 * [0x00002000 - 0x0000203f] io PCI: 00:02.1 24 * [0x00002040 - 0x0000207f] io PCI: 00:05.0 20 * [0x00002080 - 0x0000208f] io PCI: 00:18.0 compute_allocate_io: base: 00002090 size: 00002000 align: 12 gran: 12 done PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000002fff] io PCI: 00:18.0 compute_allocate_prefmem: base: fc200000 size: 00000000 align: 20 gran: 20 PCI: 00:18.0 read_resources bus 0 link: 0 PCI: 00:18.0 read_resources bus 0 link: 0 done PCI: 00:18.0 compute_allocate_prefmem: base: fc200000 size: 00000000 align: 20 gran: 20 done PCI: 00:18.0 1b8 <- [0x00fc200000 - 0x00fc1fffff] prefmem PCI: 00:18.0 compute_allocate_mem: base: fc000000 size: 00200000 align: 20 gran: 20 PCI: 00:18.0 read_resources bus 0 link: 0 PCI: 00:18.0 read_resources bus 0 link: 0 done PCI: 00:07.0 20 * [0xfc000000 - 0xfc0fffff] mem PCI: 00:07.1 10 * [0xfc100000 - 0xfc103fff] mem PCI: 00:03.0 10 * [0xfc104000 - 0xfc104fff] mem PCI: 00:03.1 10 * [0xfc105000 - 0xfc1050ff] mem PCI: 00:18.0 compute_allocate_mem: base: fc105100 size: 00200000 align: 20 gran: 20 done PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fc1fffff] mem PCI: 00:18.0 assign_resources, bus 0 link: 0 PCI: 00:02.1 20 <- [0x0000002000 - 0x000000203f] io PCI: 00:02.1 24 <- [0x0000002040 - 0x000000207f] io PCI: 00:03.0 10 <- [0x00fc104000 - 0x00fc104fff] mem PCI: 00:03.1 10 <- [0x00fc105000 - 0x00fc1050ff] mem PCI: 00:05.0 20 <- [0x0000002080 - 0x000000208f] io PCI: 00:07.0 compute_allocate_io: base: 00001000 size: 00001000 align: 12 gran: 12 PCI: 00:07.0 read_resources bus 1 link: 0 PCI: 00:07.0 read_resources bus 1 link: 0 done PCI: 01:09.0 14 * [0x00001000 - 0x0000107f] io PCI: 00:07.0 compute_allocate_io: base: 00001080 size: 00001000 align: 12 gran: 12 done PCI: 00:07.0 1c <- [0x0000001000 - 0x0000001fff] bus 01 io PCI: 00:07.0 compute_allocate_mem: base: fc000000 size: 00100000 align: 20 gran: 20 PCI: 00:07.0 read_resources bus 1 link: 0 PCI: 00:07.0 read_resources bus 1 link: 0 done PCI: 01:09.0 10 * [0xfc000000 - 0xfc0007ff] mem PCI: 00:07.0 compute_allocate_mem: base: fc000800 size: 00100000 align: 20 gran: 20 done PCI: 00:07.0 20 <- [0x00fc000000 - 0x00fc0fffff] bus 01 mem PCI: 00:07.0 assign_resources, bus 1 link: 0 PCI: 01:09.0 10 <- [0x00fc000000 - 0x00fc0007ff] mem PCI: 01:09.0 14 <- [0x0000001000 - 0x000000107f] io PCI: 00:07.0 assign_resources, bus 1 link: 0 PCI: 00:07.1 10 <- [0x00fc100000 - 0x00fc103fff] mem PCI: 00:18.0 assign_resources, bus 0 link: 0 PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 Root Device assign_resources, bus 0 link: 0 Done setting resources. Done allocating resources. Enabling resources... PCI: 00:18.0 cmd <- 140 PCI: 00:01.0 cmd <- 146 PCI: 00:02.0 cmd <- 14f PCI: 00:02.1 cmd <- 141 PCI: 00:02.2 cmd <- 540 PCI: 00:03.0 cmd <- 142 PCI: 00:03.1 cmd <- 142 PCI: 00:05.0 cmd <- 141 PCI: 00:06.0 subsystem <- 10de/cb84 PCI: 00:06.0 cmd <- 146 PCI: 00:06.1 cmd <- 140 PCI: 00:06.2 cmd <- 140 PCI: 00:06.3 cmd <- 140 PCI: 00:06.4 cmd <- 146 PCI: 00:06.5 cmd <- 146 PCI: 00:06.6 cmd <- 140 PCI: 00:06.7 cmd <- 140 PCI: 00:07.0 bridge ctrl <- 0003 PCI: 00:07.0 cmd <- 147 PCI: 01:09.0 cmd <- 1c3 PCI: 00:07.1 cmd <- 142 PCI: 00:08.0 bridge ctrl <- 0003 PCI: 00:08.0 cmd <- 140 PCI: 00:09.0 bridge ctrl <- 0003 PCI: 00:09.0 cmd <- 140 PCI: 00:0a.0 bridge ctrl <- 0003 PCI: 00:0a.0 cmd <- 140 PCI: 00:0b.0 bridge ctrl <- 0003 PCI: 00:0b.0 cmd <- 140 PCI: 00:0c.0 bridge ctrl <- 0003 PCI: 00:0c.0 cmd <- 140 PCI: 00:0e.0 bridge ctrl <- 0003 PCI: 00:0e.0 cmd <- 140 PCI: 00:0f.0 bridge ctrl <- 0003 PCI: 00:0f.0 cmd <- 140 PCI: 00:10.0 bridge ctrl <- 0003 PCI: 00:10.0 cmd <- 140 PCI: 00:18.1 subsystem <- 10de/cb84 PCI: 00:18.1 cmd <- 140 PCI: 00:18.2 subsystem <- 10de/cb84 PCI: 00:18.2 cmd <- 140 PCI: 00:18.3 cmd <- 140 done. Initializing devices... Root Device init APIC_CLUSTER: 0 init Initializing CPU #0 CPU: vendor AMD device 40fb2 CPU: family 0f, model 4b, stepping 02 Enabling cache Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 512MB, type WB ADDRESS_MASK_HIGH=0xff DONE variable MTRRs Clear out the extra MTRR's call enable_var_mtrr() Leave x86_setup_var_mtrrs MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled CPU model AMD Athlon(tm) 64 FX-37 Processor Setting up local apic... apic_id: 0x00 done. ECC Disabled CPU #0 Initialized Asserting INIT. Waiting for send to finish... +Deasserting INIT. Waiting for send to finish... +#startup loops: 2. Sending STARTUP #1 to 1. After apic_write. Startup point 1. Waiting for send to finish... +Sending STARTUP #2 to 1. After apic_write. Startup point 1. Waiting for send to finish... +After Startup. Initializing CPU #1 Waiting for 1 CPUS to stop CPU: vendor AMD device 40fb2 CPU: family 0f, model 4b, stepping 02 Enabling cache Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 512MB, type WB ADDRESS_MASK_HIGH=0xff DONE variable MTRRs Clear out the extra MTRR's call enable_var_mtrr() Leave x86_setup_var_mtrrs MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled CPU model AMD Athlon(tm) 64 FX-37 Processor Setting up local apic... apic_id: 0x01 done. CPU #1 Initialized All AP CPUs stopped PCI: 00:18.0 init PCI: 00:06.0 init PCI: 00:18.1 init PCI: 00:18.2 init PCI: 00:18.3 init NB: Function 3 Misc Control.. done. PCI: 00:02.0 init for IRQ, reg 0x00000000 value 0x00000700 0x00000000 for IRQ, reg 0x00000001 value 0x00010000 0x00000000 for IRQ, reg 0x00000002 value 0x00010000 0x00000000 for IRQ, reg 0x00000003 value 0x00010000 0x00000000 for IRQ, reg 0x00000004 value 0x00010000 0x00000000 for IRQ, reg 0x00000005 value 0x00010000 0x00000000 for IRQ, reg 0x00000006 value 0x00010000 0x00000000 for IRQ, reg 0x00000007 value 0x00010000 0x00000000 for IRQ, reg 0x00000008 value 0x00010000 0x00000000 for IRQ, reg 0x00000009 value 0x00010000 0x00000000 for IRQ, reg 0x0000000a value 0x00010000 0x00000000 for IRQ, reg 0x0000000b value 0x00010000 0x00000000 for IRQ, reg 0x0000000c value 0x00010000 0x00000000 for IRQ, reg 0x0000000d value 0x00010000 0x00000000 for IRQ, reg 0x0000000e value 0x00010000 0x00000000 for IRQ, reg 0x0000000f value 0x00010000 0x00000000 for IRQ, reg 0x00000010 value 0x00010000 0x00000000 for IRQ, reg 0x00000011 value 0x00010000 0x00000000 for IRQ, reg 0x00000012 value 0x00010000 0x00000000 for IRQ, reg 0x00000013 value 0x00010000 0x00000000 for IRQ, reg 0x00000014 value 0x00010000 0x00000000 for IRQ, reg 0x00000015 value 0x00010000 0x00000000 for IRQ, reg 0x00000016 value 0x00010000 0x00000000 for IRQ, reg 0x00000017 value 0x00010000 0x00000000 set power on after power fail RTC Init PCI: 00:02.2 init PCI: 00:03.1 init PCI: 00:05.0 init IDE1 IDE0 PCI: 00:06.1 init PCI: 00:06.2 init PCI: 00:06.3 init PCI: 00:06.4 init PCI: 00:06.5 init PCI: 00:06.6 init PCI: 00:06.7 init PCI: 00:07.0 init dev_root mem base = 0x00f8000000 [0x50] <-- 0xf8000000 PCI: 00:0c.0 init PCI: 01:09.0 init Devices initialized Copying IRQ routing tables to 0xf0000...done. Verifing copy of IRQ routing tables at 0xf0000...done Checking IRQ routing table consistency... check_pirq_routing_table() - irq_routing_table located at: 0x000f0000 done. Wrote the mp table end at: 00000020 - 0000012c Moving GDT to 0x500...ok Wrote linuxbios table at: 00000530 - 000006dc checksum f914 Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3 serial_stream: downloading to 0x03000000; start XMODEM transfer now! CC transfer complete; 1731968 bytes received serial_stream: copying to 0x02000000 Found ELF candidate at offset 0 header_offset is 0 Try to load at offset 0x0 n_type: 00000001 n_name(8): ELFBoot n_desc(6): Linux n_type: 00000002 n_name(8): ELFBoot n_desc(100): 2.6.17.11-ArosKernel-main-11945 (arastra at bs2.arastra.com) #1 SMP PREEMPT Tue Dec 5 11:04:26 PST 2006 malloc Enter, size 20, free_mem_ptr 0003e3d8 malloc 0x0003e3d8 n_type: 00000003 n_name(8): ELFBoot n_desc(2): .@ Dropping non PT_LOAD segment malloc Enter, size 32, free_mem_ptr 0003e3ec malloc 0x0003e3ec New segment addr 0x10000 size 0x12204 offset 0x180 filesize 0x118c (cleaned up) New segment addr 0x10000 size 0x12204 offset 0x180 filesize 0x118c lb: [0x0000000000004000, 0x0000000000042000) segment: [0x0000000000010000, 0x000000000001118c, 0x0000000000022204) bounce: [0x000000001ff90000, 0x000000001ff9118c, 0x000000001ffa2204) malloc Enter, size 32, free_mem_ptr 0003e40c malloc 0x0003e40c New segment addr 0x20000 size 0x1070 offset 0x130c filesize 0x0 (cleaned up) New segment addr 0x20000 size 0x1070 offset 0x130c filesize 0x0 lb: [0x0000000000004000, 0x0000000000042000) segment: [0x0000000000020000, 0x0000000000020000, 0x0000000000021070) bounce: [0x000000001ffa0000, 0x000000001ffa0000, 0x000000001ffa1070) malloc Enter, size 32, free_mem_ptr 0003e42c malloc 0x0003e42c New segment addr 0x100000 size 0x700000 offset 0x130c filesize 0x14a139 (cleaned up) New segment addr 0x100000 size 0x700000 offset 0x130c filesize 0x14a139 lb: [0x0000000000004000, 0x0000000000042000) malloc Enter, size 32, free_mem_ptr 0003e44c malloc 0x0003e44c New segment addr 0x800000 size 0x5b915 offset 0x14b445 filesize 0x5b915 (cleaned up) New segment addr 0x800000 size 0x5b915 offset 0x14b445 filesize 0x5b915 lb: [0x0000000000004000, 0x0000000000042000) Loading Segment: addr: 0x000000001ff90000 memsz: 0x0000000000012204 filesz: 0x000000000000118c [ 0x000000001ff90000, 000000001ff9118c, 0x000000001ffa2204) <- 0000000000000180 Clearing Segment: addr: 0x000000001ff9118c memsz: 0x0000000000011078 Loading Segment: addr: 0x000000001ffa0000 memsz: 0x0000000000001070 filesz: 0x0000000000000000 [ 0x000000001ffa0000, 000000001ffa0000, 0x000000001ffa1070) <- 000000000000130c Clearing Segment: addr: 0x000000001ffa0000 memsz: 0x0000000000001070 Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000700000 filesz: 0x000000000014a139 [ 0x0000000000100000, 000000000024a139, 0x0000000000800000) <- 000000000000130c Clearing Segment: addr: 0x000000000024a139 memsz: 0x00000000005b5ec7 Loading Segment: addr: 0x0000000000800000 memsz: 0x000000000005b915 filesz: 0x000000000005b915 [ 0x0000000000800000, 000000000085b915, 0x000000000085b915) <- 000000000014b445 Loaded segments verified segments closed down stream Jumping to boot code at 0x10000 entry = 0x00010000 lb_start = 0x00004000 lb_size = 0x0003e000 adjust = 0x1ffbe000 buffer = 0x1ff84000 elf_boot_notes = 0x00017de0 adjusted_boot_notes = 0x1ffd5de0 Firmware type: LinuxBIOS Linux version 2.6.17.11-ArosKernel-main-11945 (arastra at bs2.arastra.com) (gcc version 4.0.2 20051125 (Red Hat 4. 0.2-8)) #1 SMP PREEMPT Tue Dec 5 11:04:26 PST 2006 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000000748 (reserved) BIOS-e820: 0000000000000748 - 00000000000a0000 (usable) BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved) BIOS-e820: 0000000000100000 - 0000000020000000 (usable) 0MB HIGHMEM available. 512MB LOWMEM available. found SMP MP-table at 00000010 DMI not present or invalid. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: DFI Product ID: LP_UT_NF590 APIC at: 0xFEE00000 Processor #0 15:11 APIC version 16 Processor #1 15:11 APIC version 16 I/O APIC #2 Version 32 at 0xFEC00000. Enabling APIC mode: Flat. Using 1 I/O APICs Processors: 2 Allocating PCI resources starting at 30000000 (gap: 20000000:e0000000) Built 1 zonelists Kernel command line: console=ttyS0,115200 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c039d000 soft=c039f000 PID hash table entries: 4096 (order: 12, 16384 bytes) Detected 1000.108 MHz processor. Using tsc for high-res timesource Console: colour dummy device 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 516000k/524288k available (1535k kernel code, 7880k reserved, 953k data, 148k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 2005.79 BogoMIPS (lpj=4011596) Mount-cache hash table entries: 512 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU 0(2) -> Core 0 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Checking 'hlt' instruction... OK. Freeing SMP alternatives: 12k freed CPU0: AMD Athlon(tm) 64 FX-37 Processor stepping 02 Booting processor 1/1 eip 2000 CPU 1 irqstacks, hard=c039e000 soft=c03a0000 Initializing CPU#1 Calibrating delay using timer specific routine.. 2000.18 BogoMIPS (lpj=4000378) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU 1(2) -> Core 1 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#1. CPU1: AMD Athlon(tm) 64 FX-37 Processor stepping 02 Total of 2 processors activated (4005.98 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=-1 pin1=-1 apic2=-1 pin2=-1 ...trying to set up timer (IRQ0) through the 8259A ... failed. ...trying to set up timer as Virtual Wire IRQ... failed. ...trying to set up timer as ExtINT IRQ... works. checking TSC synchronization across 2 CPUs: passed. Brought up 2 CPUs migration_cost=341 Unpacking initramfs... done Freeing initrd memory: 366k freed NET: Registered protocol family 16 PCI: Using configuration type 1 Setting up standard PCI resources SCSI subsystem initialized usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Probing PCI hardware PCI: Transparent bridge - 0000:00:07.0 PCI: Unable to handle 64-bit address space for bridge 0000:00:08.0 PCI: Unable to handle 64-bit address space for bridge 0000:00:09.0 PCI: Unable to handle 64-bit address space for bridge 0000:00:0a.0 PCI: Unable to handle 64-bit address space for bridge 0000:00:0b.0 PCI: Unable to handle 64-bit address space for bridge 0000:00:0c.0 PCI: Unable to handle 64-bit address space for bridge 0000:00:0e.0 PCI: Unable to handle 64-bit address space for bridge 0000:00:0f.0 PCI: Unable to handle 64-bit address space for bridge 0000:00:10.0 PCI: Discovered primary peer bus ff [IRQ] TC classifier action (bugs to netdev at vger.kernel.org cc hadi at cyberus.ca) PCI: Bridge: 0000:00:07.0 IO window: 1000-1fff MEM window: fc000000-fc0fffff PREFETCH window: disabled. PCI: Bridge: 0000:00:08.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:09.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:0a.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:0b.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:0c.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:0e.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:0f.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:10.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. NET: Registered protocol family 2 IP route cache hash table entries: 16384 (order: 4, 65536 bytes) TCP established hash table entries: 65536 (order: 8, 1572864 bytes) TCP bind hash table entries: 32768 (order: 7, 786432 bytes) TCP: Hash tables configured (established 65536 bind 32768) TCP reno registered Initializing Cryptographic API io scheduler noop registered (default) pcie_portdrv_probe->Dev[02fc:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability pcie_portdrv_probe->Dev[02fd:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability pcie_portdrv_probe->Dev[02fb:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability pcie_portdrv_probe->Dev[0376:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability pcie_portdrv_probe->Dev[0374:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability pcie_portdrv_probe->Dev[0378:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability pcie_portdrv_probe->Dev[0375:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability pcie_portdrv_probe->Dev[0377:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability ipmi message handler version 39.0 ipmi device interface IPMI System Interface driver. ipmi_si: Unable to find any System Interface(s) IPMI Watchdog: driver initialized Copyright (C) 2004 MontaVista Software - IPMI Powerdown via sys_reboot. Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.54. Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx hda: CD-ROM CDU311, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 PCI: No IRQ known for interrupt pin B of device 0000:00:03.1. Probably buggy MP table. ehci_hcd 0000:00:03.1: Found HC with no IRQ. Check BIOS/PCI 0000:00:03.1 setup! ehci_hcd 0000:00:03.1: init 0000:00:03.1 fail, -19 PCI: No IRQ known for interrupt pin A of device 0000:00:03.0. Probably buggy MP table. ohci_hcd 0000:00:03.0: Found HC with no IRQ. Check BIOS/PCI 0000:00:03.0 setup! ohci_hcd 0000:00:03.0: init 0000:00:03.0 fail, -19 USB Universal Host Controller Interface driver v3.0 Initializing USB Mass Storage driver... usbcore: registered new driver usb-storage USB Mass Storage support registered. serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 mice: PS/2 mouse device common for all mice TCP bic registered NET: Registered protocol family 1 Starting balanced_irq Using IPI Shortcut mode Freeing unused kernel memory: 148k freed Write protecting the kernel read-only data: 612k init started: BusyBox v1.2.2 (2006.12.12-01:00+0000) multi-call binary -------------- next part -------------- # lspci 00:01.0 Class 0500: 10de:0369 (rev a1) 00:02.0 Class 0601: 10de:0360 (rev a2) 00:02.1 Class 0c05: 10de:0368 (rev a2) 00:02.2 Class 0500: 10de:036a (rev a2) 00:03.0 Class 0c03: 10de:036c (rev a1) 00:03.1 Class 0c03: 10de:036d (rev a2) 00:05.0 Class 0101: 10de:036e (rev a1) 00:06.0 Class 0500: 10de:02f4 (rev a2) 00:06.1 Class 0500: 10de:02fa (rev a2) 00:06.2 Class 0500: 10de:02fe (rev a2) 00:06.3 Class 0500: 10de:02f8 (rev a2) 00:06.4 Class 0500: 10de:02f9 (rev a2) 00:06.5 Class 0500: 10de:02ff (rev a2) 00:06.6 Class 0500: 10de:027f (rev a2) 00:06.7 Class 0500: 10de:027e (rev a2) 00:07.0 Class 0604: 10de:0370 (rev a2) 00:07.1 Class 0403: 10de:0371 (rev a2) 00:08.0 Class 0604: 10de:02fc (rev a1) 00:09.0 Class 0604: 10de:02fd (rev a1) 00:0a.0 Class 0604: 10de:02fb (rev a1) 00:0b.0 Class 0604: 10de:0376 (rev a2) 00:0c.0 Class 0604: 10de:0374 (rev a2) 00:0e.0 Class 0604: 10de:0378 (rev a2) 00:0f.0 Class 0604: 10de:0375 (rev a2) 00:10.0 Class 0604: 10de:0377 (rev a2) 00:18.0 Class 0600: 1022:1100 00:18.1 Class 0600: 1022:1101 00:18.2 Class 0600: 1022:1102 00:18.3 Class 0600: 1022:1103 01:09.0 Class 0c00: 1106:3044 (rev 80) -------------- next part -------------- # lspci -tv -[00]-+-01.0 10de:0369 +-02.0 10de:0360 +-02.1 10de:0368 +-02.2 10de:036a +-03.0 10de:036c +-03.1 10de:036d +-05.0 10de:036e +-06.0 10de:02f4 +-06.1 10de:02fa +-06.2 10de:02fe +-06.3 10de:02f8 +-06.4 10de:02f9 +-06.5 10de:02ff +-06.6 10de:027f +-06.7 10de:027e +-07.0-[01]----09.0 1106:3044 +-07.1 10de:0371 +-08.0-[02]-- +-09.0-[03]-- +-0a.0-[04]-- +-0b.0-[05]-- +-0c.0-[06]-- +-0e.0-[07]-- +-0f.0-[08]-- +-10.0-[09]-- +-18.0 1022:1100 +-18.1 1022:1101 +-18.2 1022:1102 \-18.3 1022:1103 -------------- next part -------------- # lspci -v 00:01.0 Class 0500: 10de:0369 (rev a1) Flags: bus master, 66Mhz, fast devsel, latency 0 Capabilities: [44] #08 [01e1] Capabilities: [e0] #00 [fee0] 00:02.0 Class 0601: 10de:0360 (rev a2) Flags: bus master, 66Mhz, fast devsel, latency 0 00:02.1 Class 0c05: 10de:0368 (rev a2) Flags: 66Mhz, fast devsel I/O ports at 2000 [size=64] I/O ports at 2040 [size=64] Capabilities: [44] Power Management version 2 00:02.2 Class 0500: 10de:036a (rev a2) Flags: 66Mhz, fast devsel 00:03.0 Class 0c03: 10de:036c (rev a1) (prog-if 10) Flags: 66Mhz, fast devsel Memory at fc104000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:03.1 Class 0c03: 10de:036d (rev a2) (prog-if 20) Flags: 66Mhz, fast devsel Memory at fc105000 (32-bit, non-prefetchable) [size=256] Capabilities: [44] #0a [2098] Capabilities: [80] Power Management version 2 00:05.0 Class 0101: 10de:036e (rev a1) (prog-if 8a [Master SecP PriP]) Flags: 66Mhz, fast devsel I/O ports at 2080 [size=16] Capabilities: [44] Power Management version 2 00:06.0 Class 0500: 10de:02f4 (rev a2) Flags: bus master, 66Mhz, fast devsel, latency 0 Capabilities: [44] #08 [01e6] Capabilities: [e0] #08 [a800] 00:06.1 Class 0500: 10de:02fa (rev a2) Flags: 66Mhz, fast devsel 00:06.2 Class 0500: 10de:02fe (rev a2) Flags: 66Mhz, fast devsel 00:06.3 Class 0500: 10de:02f8 (rev a2) Flags: 66Mhz, fast devsel 00:06.4 Class 0500: 10de:02f9 (rev a2) Flags: bus master, 66Mhz, fast devsel, latency 0 00:06.5 Class 0500: 10de:02ff (rev a2) Flags: bus master, 66Mhz, fast devsel, latency 0 Capabilities: [44] #00 [0000] 00:06.6 Class 0500: 10de:027f (rev a2) Flags: 66Mhz, fast devsel 00:06.7 Class 0500: 10de:027e (rev a2) Flags: 66Mhz, fast devsel 00:07.0 Class 0604: 10de:0370 (rev a2) (prog-if 01) Flags: bus master, 66Mhz, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: 00001000-00001fff Memory behind bridge: fc000000-fc0fffff Capabilities: [b8] #0d [0000] Capabilities: [8c] #08 [a800] 00:07.1 Class 0403: 10de:0371 (rev a2) Flags: 66Mhz, fast devsel Memory at fc100000 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Capabilities: [6c] #08 [a802] 00:08.0 Class 0604: 10de:02fc (rev a1) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 Capabilities: [40] #0d [0000] Capabilities: [48] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable- Capabilities: [60] #08 [a800] Capabilities: [80] #10 [0141] 00:09.0 Class 0604: 10de:02fd (rev a1) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 Capabilities: [40] #0d [0000] Capabilities: [48] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable- Capabilities: [60] #08 [a800] Capabilities: [80] #10 [0141] 00:0a.0 Class 0604: 10de:02fb (rev a1) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 Capabilities: [40] #0d [0000] Capabilities: [48] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable- Capabilities: [60] #08 [a800] Capabilities: [80] #10 [0141] 00:0b.0 Class 0604: 10de:0376 (rev a2) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=05, subordinate=05, sec-latency=0 Capabilities: [40] #0d [0000] Capabilities: [48] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable- Capabilities: [60] #08 [a800] Capabilities: [80] #10 [0141] 00:0c.0 Class 0604: 10de:0374 (rev a2) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=06, subordinate=06, sec-latency=0 Capabilities: [40] #0d [0000] Capabilities: [48] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable- Capabilities: [60] #08 [a800] Capabilities: [80] #10 [0141] 00:0e.0 Class 0604: 10de:0378 (rev a2) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=07, subordinate=07, sec-latency=0 Capabilities: [40] #0d [0000] Capabilities: [48] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable- Capabilities: [60] #08 [a800] Capabilities: [80] #10 [0141] 00:0f.0 Class 0604: 10de:0375 (rev a2) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=08, subordinate=08, sec-latency=0 Capabilities: [40] #0d [0000] Capabilities: [48] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable- Capabilities: [60] #08 [a800] Capabilities: [80] #10 [0141] 00:10.0 Class 0604: 10de:0377 (rev a2) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=09, subordinate=09, sec-latency=0 Capabilities: [40] #0d [0000] Capabilities: [48] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable- Capabilities: [60] #08 [a800] Capabilities: [80] #10 [0141] 00:18.0 Class 0600: 1022:1100 Flags: fast devsel Capabilities: [80] #08 [2101] 00:18.1 Class 0600: 1022:1101 Flags: fast devsel 00:18.3 Class 0600: 1022:1103 Flags: fast devsel Capabilities: [f0] #0f [0010] 01:09.0 Class 0c00: 1106:3044 (rev 80) (prog-if 10) Subsystem: 15bd:1006 Flags: stepping, medium devsel Memory at fc000000 (32-bit, non-prefetchable) [size=2K] I/O ports at 1000 [size=128] Capabilities: [50] Power Management version 2 -------------- next part -------------- A non-text attachment was scrubbed... Name: Config.lb Type: application/octet-stream Size: 4798 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Options.lb Type: application/octet-stream Size: 5846 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cache_as_ram_auto.c Type: text/x-csrc Size: 5096 bytes Desc: not available URL: From mcqmcqmcq at fastmail.fm Tue Dec 12 20:08:48 2006 From: mcqmcqmcq at fastmail.fm (mcqmcqmcq at fastmail.fm) Date: Tue, 12 Dec 2006 11:08:48 -0800 Subject: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49072B9@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49072B9@ssvlexmb2.amd.com> Message-ID: <1165950528.23859.280133817@webmail.messagingengine.com> > Try acpi=off for kernel command line. > Or disable acpi in linuxbios in you MB Options.lb Disabled ACPI in Options.lb. Now it boots and Linux sees it in lspci: 40:01.0 InfiniBand: PathScale, Inc InfiniPath HT-400 (rev 02) But the driver complains at module loadtime that IRQs aren't set up: sh-3.1# modprobe ib_ipath PCI: No IRQ known for interrupt pin C of device 0000:40:01.0. Probably buggy MP table. ipath_core 0000:40:01.0: infinipath0: irq is 0, BIOS error? Interrupts won't work mtrr: type mismatch for fd500000,100000 old: write-back new: write-combining ipath_core 0000:40:01.0: mtrr_add() WC for PIO bufs failed (-22) ipath_core 0000:40:01.0: infinipath0: Write combining not enabled (err 22): performance may be poor Looks like we'll have to fix the actual problem. I'm happy to try to do so remotely if you have the patience to walk thru it with me in email or IM (aim: tricamfetish). Best, -mcq -- mcqmcqmcq at fastmail.fm -- http://www.fastmail.fm - Email service worth paying for. Try it for free From stepan at coresystems.de Tue Dec 12 20:16:37 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 12 Dec 2006 20:16:37 +0100 Subject: [LinuxBIOS] More MCP55 hacking In-Reply-To: References: Message-ID: <20061212191637.GA11885@coresystems.de> * Ed Swierk [061212 19:50]: > 1. > Should I try to fix the routing table or try to get ACPI working? Get a simple version of ACPI working. Its much more complete and still cleaner than having to implement _both_ of mp and pirq to get things right. pirq handling in linux is broken, too. Have a look at the acpi implementation of the epia-m. its simple and clean. The one of some Opteron mainboards might be a better fit, since they're more modular and already contain most of what you need. The factory bios DSDT knows the interrupt routing. > 3. I'm not sure whether HT unitid assignment is correct; the meanings > of HT_CHAIN_UNITID_BASE, HT_CHAIN_END_UNITID_BASE, SB_HT_CHAIN_ON_BUS0 > and SB_HT_CHAIN_UNITID_OFFSET_ONLY are very unclear despite comments > in the code. Nobody except Yinghai really knows what their valid parameters are ;-) If you copied the values from an existing board, its probably fine though. > 4. The PCI device IDs assigned during HyperTransport device > enumeration don't match up with those assigned by the factory BIOS, > e.g. the southbridge HT interface (device 10de:0369) is assigned to > device 1 on LinuxBIOS but device 8 on the factory BIOS. I'm not sure > whether this is a big deal, but is there some way to get them assigned > in the same way? The variables of 3. have something to do with it. Also, parts of this is a breadth-first vs depth-first algorithm issue. Its really no big deal though. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From yinghai.lu at amd.com Tue Dec 12 20:24:00 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 12 Dec 2006 11:24:00 -0800 Subject: [LinuxBIOS] More MCP55 hacking Message-ID: <5986589C150B2F49A46483AC44C7BCA49072BF@ssvlexmb2.amd.com> -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Ed Swierk Sent: Tuesday, December 12, 2006 10:51 AM To: LinuxBIOS Subject: [LinuxBIOS] More MCP55 hacking >I've resumed hacking on LinuxBIOS on an Athlon socket AM2 board with >an nVidia MCP55 southbridge and a C51XE between the two. I'm using the >CK804 southbridge code with updated PCI IDs, and Yinghai's socket AM2 >code. That is called 590 by Nvidia. (C51+MCP55) >I've gotten a Linux kernel to boot, but I am stuck on a few issues: >1. I haven't gotten interrupt routing to work yet, and the IRQ routing >table I extract from the factory BIOS seems broken. When I boot with >the factory BIOS, however, Linux uses ACPI for interrupt routing, >which I think bypasses the routing table altogether. Should I try to >fix the routing table or try to get ACPI working? Linux searches for a >device to act as an interrupt router; which device on my board would >play that role? Forget about ACPI for irq routing, They said dsdt is under IBV copyright. I don't think you can prove to implement one dsdt in clean room. (If you can access the system with BIOS, you are contaminated.) >3. I'm not sure whether HT unitid assignment is correct; the meanings >of HT_CHAIN_UNITID_BASE, HT_CHAIN_END_UNITID_BASE, SB_HT_CHAIN_ON_BUS0 >and SB_HT_CHAIN_UNITID_OFFSET_ONLY are very unclear despite comments >in the code. >4. The PCI device IDs assigned during HyperTransport device >enumeration don't match up with those assigned by the factory BIOS, >e.g. the southbridge HT interface (device 10de:0369) is assigned to >device 1 on LinuxBIOS but device 8 on the factory BIOS. I'm not sure >whether this is a big deal, but is there some way to get them assigned >in the same way? ##HT Unit ID offset, default is 1, the typical one default HT_CHAIN_UNITID_BASE=0x06 ##real SB Unit ID, default is 0x20, mean dont touch it at last default HT_CHAIN_END_UNITID_BASE=0x01 (it will put c51 on unitid 6, and mcp55 on unitid 1), there will be some device overlap. ===> ##HT Unit ID offset, default is 1, the typical one #default HT_CHAIN_UNITID_BASE=0x06 ##real SB Unit ID, default is 0x20, mean dont touch it at last #default HT_CHAIN_END_UNITID_BASE=0x01 (it will put c51 on unitid 1, and mcp55 on unitid ?) YH From yinghai.lu at amd.com Tue Dec 12 20:35:31 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 12 Dec 2006 11:35:31 -0800 Subject: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled Message-ID: <5986589C150B2F49A46483AC44C7BCA49072C0@ssvlexmb2.amd.com> You can use 2.6.19 later kernel and enable HT_IRQ in it. --- Eric worked it out, and I didn't have chance to test it. YH From stepan at coresystems.de Tue Dec 12 21:21:37 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 12 Dec 2006 21:21:37 +0100 Subject: [LinuxBIOS] More MCP55 hacking In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49072BF@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49072BF@ssvlexmb2.amd.com> Message-ID: <20061212202137.GA25477@coresystems.de> * Lu, Yinghai [061212 20:24]: > Forget about ACPI for irq routing, They said dsdt is under IBV > copyright. I don't think you can prove to implement one dsdt in clean > room. (If you can access the system with BIOS, you are contaminated.) We need to be very careful here. So, since ACPI is also used for bus enumeration these days, am I contaminated after running lspci on such a system? I can draw conclusions on their bus mapping from that. If I look at their interrupt mapping because my linux kernel prints it out with a debug option, am I contaminated then? How can we _reliably_ find out where the border is here? -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From mcqmcqmcq at fastmail.fm Tue Dec 12 21:21:37 2006 From: mcqmcqmcq at fastmail.fm (mcqmcqmcq at fastmail.fm) Date: Tue, 12 Dec 2006 12:21:37 -0800 Subject: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49072C0@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49072C0@ssvlexmb2.amd.com> Message-ID: <1165954897.32319.280146445@webmail.messagingengine.com> > You can use 2.6.19 later kernel and enable HT_IRQ in it. --- Eric worked > it out, and I didn't have chance to test it. Hey, 2.6.19.1 actually boots (better than 2.6.19)! 2.6.19.1 with HT_IRQ turned on yields: sh-3.1# modprobe ib_ipath PCI: No IRQ known for interrupt pin C of device 0000:40:01.0. Probably buggy MP table. mtrr: type mismatch for fd500000,100000 old: write-back new: write-combining ib_ipath 0000:40:01.0: mtrr_add() WC for PIO bufs failed (-22) ib_ipath 0000:40:01.0: infinipath0: Write combining not enabled (err 22): performance may be poor Note that HT_IRQ removes the complaint (formerly right before the mtrr complaints): ipath_core 0000:40:01.0: infinipath0: irq is 0, BIOS error? Interrupts won't work Further fun stuff to try? I am your board monkey. -mcq -- mcqmcqmcq at fastmail.fm -- http://www.fastmail.fm - Same, same, but different From yinghai.lu at amd.com Tue Dec 12 21:47:20 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 12 Dec 2006 12:47:20 -0800 Subject: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled Message-ID: <5986589C150B2F49A46483AC44C7BCA49072C4@ssvlexmb2.amd.com> Interrupts still doesn't work? Try cat /proc/interrupts or /var/log/messages to see if it get interrupt. YH -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of mcqmcqmcq at fastmail.fm Sent: Tuesday, December 12, 2006 12:22 PM To: Lu, Yinghai; linuxbios at linuxbios.org Subject: Re: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled > You can use 2.6.19 later kernel and enable HT_IRQ in it. --- Eric worked > it out, and I didn't have chance to test it. Hey, 2.6.19.1 actually boots (better than 2.6.19)! 2.6.19.1 with HT_IRQ turned on yields: sh-3.1# modprobe ib_ipath PCI: No IRQ known for interrupt pin C of device 0000:40:01.0. Probably buggy MP table. mtrr: type mismatch for fd500000,100000 old: write-back new: write-combining ib_ipath 0000:40:01.0: mtrr_add() WC for PIO bufs failed (-22) ib_ipath 0000:40:01.0: infinipath0: Write combining not enabled (err 22): performance may be poor Note that HT_IRQ removes the complaint (formerly right before the mtrr complaints): ipath_core 0000:40:01.0: infinipath0: irq is 0, BIOS error? Interrupts won't work Further fun stuff to try? I am your board monkey. -mcq -- mcqmcqmcq at fastmail.fm -- http://www.fastmail.fm - Same, same, but different... -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios From mcqmcqmcq at fastmail.fm Tue Dec 12 22:11:43 2006 From: mcqmcqmcq at fastmail.fm (mcqmcqmcq at fastmail.fm) Date: Tue, 12 Dec 2006 13:11:43 -0800 Subject: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49072C4@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49072C4@ssvlexmb2.amd.com> Message-ID: <1165957903.6182.280154169@webmail.messagingengine.com> > Try cat /proc/interrupts or /var/log/messages to see if it get > interrupt. Seems to have one: sh-3.1# cat /proc/interrupts CPU0 CPU1 0: 4906 0 IO-APIC-edge timer 1: 2 0 IO-APIC-edge i8042 2: 0 0 XT-PIC-XT cascade 4: 90 0 IO-APIC-edge serial 8: 0 0 IO-APIC-edge rtc 12: 4 0 IO-APIC-edge i8042 19: 71 0 IO-APIC-fasteoi ohci_hcd:usb1, ohci_hcd:usb2 27: 6 0 IO-APIC-fasteoi eth0 1279: 62 0 PCI-HT-edge ib_ipath NMI: 72 31 LOC: 4826 4819 ERR: 0 I have to cart it to the rack to actually try the IB, and since I'm having to hot-swap from the Iwill bios every time I flash (any clue why flashrom -w when booting under LB fails immediately with "ERASE FAILED" and trashes the image in flash?) I was hoping we could get the MTRR thing licked too before I actually do a 'does it really work and how fast' test. The MTRR complaints are not normal and don't happen under the Iwill bios. Full bootlog including /proc/interrupts, iomem, mtrr, ioports attached. -mcq -- mcqmcqmcq at fastmail.fm -- http://www.fastmail.fm - I mean, what is it about a decent email service? -------------- next part -------------- A non-text attachment was scrubbed... Name: minicom.cap.gz Type: application/x-gzip Size: 7537 bytes Desc: not available URL: From yinghai.lu at amd.com Tue Dec 12 22:21:22 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 12 Dec 2006 13:21:22 -0800 Subject: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled Message-ID: <5986589C150B2F49A46483AC44C7BCA49072C6@ssvlexmb2.amd.com> For MTRR error, I think the kernel is not happy with the uncachable entry for the memory hole. Try to install only 2G to see if the problem will go away. Then we can 1. modify the kernel to make it like mtrr layout for setting. 2. or change mtrr to increase style..., if the kernel is too .. YH From svn at openbios.org Tue Dec 12 22:31:07 2006 From: svn at openbios.org (LinuxBIOS) Date: Tue, 12 Dec 2006 21:31:07 -0000 Subject: [LinuxBIOS] #62: Wrong variable causes a compile error Message-ID: <060.059f40c036f2712b5793018f74558faf@openbios.org> #62: Wrong variable causes a compile error -----------------------------------------------------+---------------------- Reporter: Jon Dufresne | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Keywords: | Dependencies: Patchstatus: patch needs review | -----------------------------------------------------+---------------------- In the file mainboard/intel/i82801dbm/i82801dbm.c the variable southbridge_intel_i82801dbm_control should be named southbridge_intel_i82801dbm_ops. Otherwise a compile error occurs if this device is included in Config.lb of the mainboard. -- Ticket URL: LinuxBIOS From rminnich at gmail.com Tue Dec 12 22:40:17 2006 From: rminnich at gmail.com (ron minnich) Date: Tue, 12 Dec 2006 14:40:17 -0700 Subject: [LinuxBIOS] More MCP55 hacking In-Reply-To: <20061212202137.GA25477@coresystems.de> References: <5986589C150B2F49A46483AC44C7BCA49072BF@ssvlexmb2.amd.com> <20061212202137.GA25477@coresystems.de> Message-ID: <13426df10612121340n12148bfdv21233cae5e8a3d56@mail.gmail.com> On 12/12/06, Stefan Reinauer wrote: > * Lu, Yinghai [061212 20:24]: > > Forget about ACPI for irq routing, They said dsdt is under IBV > > copyright. I don't think you can prove to implement one dsdt in clean > > room. (If you can access the system with BIOS, you are contaminated.) > > We need to be very careful here. > > So, since ACPI is also used for bus enumeration these days, am I > contaminated after running lspci on such a system? I can draw > conclusions on their bus mapping from that. There are two lines. There is the line that is real, and the line that the IBV will want you to think is real. Obviously, since they don't like the idea of a free bios, they are going to want you to think that they own everything in ACPI, and that you violate a copyright everytime you do an lspci. But, ACPI represents real hardware. The hardware is wired as it is wired .If you learn about how a wire is connected from ACPI, it is hard for me to see how an IBV can own that datum. > > If I look at their interrupt mapping because my linux kernel prints it > out with a debug option, am I contaminated then? I am sure the IBV would love for you to to think so. I don't see how this is possible. That said, can we poke at hardware registers etc. to determine what we need? It's not surprising that ACPI is turning into another form of DRM. It's a lousy standard, designed to make the world ever safer for the status quo of proprietary BIOS and OS implementations. I'm not surprised that the IBV's are now using it as a cudgel. > > How can we _reliably_ find out where the border is here? who knows ... ron From yinghai.lu at amd.com Tue Dec 12 22:45:00 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 12 Dec 2006 13:45:00 -0800 Subject: [LinuxBIOS] More MCP55 hacking Message-ID: <5986589C150B2F49A46483AC44C7BCA49072C9@ssvlexmb2.amd.com> For later AMD CPU, you could acpi for SRAT, SLIT..., plus irq routing in mptable. And not use DSDT for irq routing. Anyway table is good, AML or other byte code are bad. YH From yinghai.lu at amd.com Tue Dec 12 23:05:18 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 12 Dec 2006 14:05:18 -0800 Subject: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled Message-ID: <5986589C150B2F49A46483AC44C7BCA49072CB@ssvlexmb2.amd.com> Please check the patch. Add option CONFIG_VAR_MTRR_HOLE to enable hole in mtrr by subtracting. Signed-off-by: Yinghai Lu -------------- next part -------------- A non-text attachment was scrubbed... Name: fb2_var_mtrr_hole.patch Type: application/octet-stream Size: 2595 bytes Desc: fb2_var_mtrr_hole.patch URL: From mcqmcqmcq at fastmail.fm Tue Dec 12 23:09:06 2006 From: mcqmcqmcq at fastmail.fm (mcqmcqmcq at fastmail.fm) Date: Tue, 12 Dec 2006 14:09:06 -0800 Subject: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49072C6@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49072C6@ssvlexmb2.amd.com> Message-ID: <1165961346.12543.280160853@webmail.messagingengine.com> > For MTRR error, I think the kernel is not happy with the uncachable > entry for the memory hole. > > Try to install only 2G to see if the problem will go away. > > Then we can > 1. modify the kernel to make it like mtrr layout for setting. > 2. or change mtrr to increase style..., if the kernel is too .. Yep, that's the ticket. All remaining is the message: PCI: No IRQ known for interrupt pin C of device 0000:40:01.0. Probably buggy MP table. which seems plausibly ignorable since it seems to actually be getting interrupts. sh-3.1# cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 reg01: base=0xfd500000 (4053MB), size= 1MB: write-combining, count=1 fd400000-fd5fffff : 0000:40:01.0 fd400000-fd5fffff : ib_ipath Given that, how do you want to go forward? I've got compute nodes with nothing but the HTX installed and storage nodes with HTX and a couple PCI-X 3ware cards, so only two cases for me admits hardcoding hacks. Of course, it would be nice to solve the problem in general and call the DK8-HTX 'working' and I'm happy to spend effort to get there rather than the hack. :) Best, -mcq -- mcqmcqmcq at fastmail.fm -- http://www.fastmail.fm - I mean, what is it about a decent email service? From shaddamcorrinoiv at gmail.com Tue Dec 12 23:32:12 2006 From: shaddamcorrinoiv at gmail.com (Shaddam Corrino IV) Date: Tue, 12 Dec 2006 23:32:12 +0100 Subject: [LinuxBIOS] Intel 440bx In-Reply-To: References: <20061121174225.GA1248@coresystems.de> <13426df10611211059u72b58d92k2153e009dd88ed9d@mail.gmail.com> <20061122065832.GA18195@greenwood> Message-ID: Any idea what kind of times I could expect with 440BX + LB ? Right now I have time of about 36 seconds for power-on-to-play-video. This is about evently split between Award bios ~21 seconds ~15 seconds for grub/kernel. -- Thanks! Shaddam IV -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinghai.lu at amd.com Tue Dec 12 23:43:11 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 12 Dec 2006 14:43:11 -0800 Subject: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled Message-ID: <5986589C150B2F49A46483AC44C7BCA49072CC@ssvlexmb2.amd.com> I'm trying to get one HTX IB card, to check why soft_reset does not work. YH From mcqmcqmcq at fastmail.fm Wed Dec 13 00:02:59 2006 From: mcqmcqmcq at fastmail.fm (mcqmcqmcq at fastmail.fm) Date: Tue, 12 Dec 2006 15:02:59 -0800 Subject: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49072CB@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49072CB@ssvlexmb2.amd.com> Message-ID: <1165964579.18657.280173101@webmail.messagingengine.com> > Please check the patch. > > Add option CONFIG_VAR_MTRR_HOLE to enable hole in mtrr by subtracting. Did that, does nothing. I added the option=1 but wasn't sure it was making it into mtrr.c, so I also hard-set it there to 1 and 0 and none of those three tries affected the MTRR errors at driver load nor the contents of /proc/mtrr. -mcq -- mcqmcqmcq at fastmail.fm -- http://www.fastmail.fm - And now for something completely different From mcqmcqmcq at fastmail.fm Wed Dec 13 00:03:43 2006 From: mcqmcqmcq at fastmail.fm (mcqmcqmcq at fastmail.fm) Date: Tue, 12 Dec 2006 15:03:43 -0800 Subject: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49072CC@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49072CC@ssvlexmb2.amd.com> Message-ID: <1165964623.18730.280173299@webmail.messagingengine.com> > I'm trying to get one HTX IB card, to check why soft_reset does not > work. The supply chain seems to be in ~1 month backorder at the moment. I can fedex you one of mine if you don't have one onhand. -mcq -- mcqmcqmcq at fastmail.fm -- http://www.fastmail.fm - One of many happy users: http://www.fastmail.fm/docs/quotes.html From yinghai.lu at amd.com Wed Dec 13 00:08:39 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 12 Dec 2006 15:08:39 -0800 Subject: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled Message-ID: <5986589C150B2F49A46483AC44C7BCA49072CD@ssvlexmb2.amd.com> With that patch, you can use 4G RAM or more. YH -----Original Message----- From: linuxbios-bounces+yinghai.lu=amd.com at linuxbios.org [mailto:linuxbios-bounces+yinghai.lu=amd.com at linuxbios.org] On Behalf Of mcqmcqmcq at fastmail.fm Sent: Tuesday, December 12, 2006 3:03 PM To: Lu, Yinghai; linuxbios at linuxbios.org Subject: Re: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled > Please check the patch. > > Add option CONFIG_VAR_MTRR_HOLE to enable hole in mtrr by subtracting. Did that, does nothing. I added the option=1 but wasn't sure it was making it into mtrr.c, so I also hard-set it there to 1 and 0 and none of those three tries affected the MTRR errors at driver load nor the contents of /proc/mtrr. -mcq -- mcqmcqmcq at fastmail.fm -- http://www.fastmail.fm - And now for something completely different... -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios From mcqmcqmcq at fastmail.fm Wed Dec 13 00:29:36 2006 From: mcqmcqmcq at fastmail.fm (mcqmcqmcq at fastmail.fm) Date: Tue, 12 Dec 2006 15:29:36 -0800 Subject: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49072CD@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49072CD@ssvlexmb2.amd.com> Message-ID: <1165966176.21255.280176823@webmail.messagingengine.com> > With that patch, you can use 4G RAM or more. I have 4GB installed. I added printks to your patch thusly: /* Write the range mtrrs */ if (state->range_sizek != 0) { #if CONFIG_VAR_MTRR_HOLE printk_debug("write range mtrr w/_HOLE set\n"); if (state->hole_sizek == 0) { /* We need to put that on to hole */ unsigned long endk = basek + sizek; state->hole_startk = state->range_startk + state->range_sizek; state->hole_sizek = basek - state->hole_startk; state->range_sizek = endk - state->range_startk; return; } #endif state->reg = range_to_mtrr(state->reg, state->range_startk, state->range_sizek, basek, MTRR_TYPE_WRBACK, state->address_bits); #if CONFIG_VAR_MTRR_HOLE printk_debug("write range mtrr 2 w/_HOLE set\n"); state->reg = range_to_mtrr(state->reg, state->hole_startk, state->hole_sizek, basek, MTRR_TYPE_UNCACHEABLE, state->address_bits); #endif state->range_startk = 0; state->range_sizek = 0; #if CONFIG_VAR_MTRR_HOLE printk_debug("write range mtrr 3 w/_HOLE set\n"); state->hole_startk = 0; state->hole_sizek = 0; #endif } /* Allocate an msr */ And booted, seeing: DONE fixed MTRRs DONE fixed MTRRs write range mtrr w/_HOLE set write range mtrr w/_HOLE set Setting variable MTRR 0, base: 0MB, range: 4096MB, type WB Setting variable MTRR 0, base: 0MB, range: 4096MB, type WB Setting variable MTRR 1, base: 4096MB, range: 512MB, type WB Setting variable MTRR 1, base: 4096MB, range: 512MB, type WB Setting variable MTRR 2, base: 3584MB, range: 512MB, type UC Setting variable MTRR 2, base: 3584MB, range: 512MB, type UC DONE variable MTRRs which means that the if(sizek!=0) branch...return; is always the path taken. When linux comes up: sh-3.1# modprobe ib_ipath PCI: No IRQ known for interrupt pin C of device 0000:40:01.0. Probably buggy MP.mtrr: type mismatch for fd500000,100000 old: write-back new: write-combining ib_ipath 0000:40:01.0: mtrr_add() WC for PIO bufs failed (-22) ib_ipath 0000:40:01.0: infinipath0: Write combining not enabled (err 22): perfor And /proc/mtrr: reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 reg01: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 reg02: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 -mcq -- mcqmcqmcq at fastmail.fm -- http://www.fastmail.fm - Access all of your messages and folders wherever you are From eswierk at arastra.com Wed Dec 13 00:41:03 2006 From: eswierk at arastra.com (Ed Swierk) Date: Tue, 12 Dec 2006 15:41:03 -0800 Subject: [LinuxBIOS] More MCP55 hacking In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49072BF@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49072BF@ssvlexmb2.amd.com> Message-ID: On 12/12/06, Lu, Yinghai wrote: > ===> > > ##HT Unit ID offset, default is 1, the typical one > #default HT_CHAIN_UNITID_BASE=0x06 > > ##real SB Unit ID, default is 0x20, mean dont touch it at last > #default HT_CHAIN_END_UNITID_BASE=0x01 > > (it will put c51 on unitid 1, and mcp55 on unitid ?) After commenting out these two options as you suggest, it looks like a lot more devices are getting initialized; I had to increase HEAPSIZE to 64 KB to avoid overflowing the heap. Now, I'm getting an exception during PCI device init; see the attached boot log. Does it make sense that the same devices (e.g. 10de:0378) are showing up on both bus 0 and bus 4? --Ed -------------- next part -------------- LinuxBIOS-2.0.0-FILO Tue Dec 12 15:10:33 PST 2006 starting... Enabling routing table for node 00 done. Enabling UP settings coherent_ht_finalize done core0 started: started ap apicid: 01 SBLink=00 NC node|link=00 SMBus controller enabled Ram1.00 setting up CPU00 northbridge registers done. Ram2.00 Unbuffered 333Mhz 333Mhz RAM: 0x00080000 KB Ram3 dimm_mask = 00000001 x4_mask = 00000000 x16_mask = 00000000 single_rank_mask = 00000001 ODC = 00111222 Addr Timing= 00202220 Initializing memory: done Setting variable MTRR 02, base: 0000MB, range: 0200MB, type WB DQS Training:RcvrEn:Pass1: 00 CTLRMaxDelay=18 done DQS Training:DQSPos: 00 done DQS Training:RcvrEn:Pass2: 00 CTLRMaxDelay=4a done DQS Training:tsc[00]=00000000111a0f36 DQS Training:tsc[01]=000000001236cc3a DQS Training:tsc[02]=00000000123baa6c DQS Training:tsc[03]=00000000453b179c DQS Training:tsc[04]=000000004784f6fd Ram4 v_esp=000ceecc testx = 5a5a5a5a Copying data from cache to ram -- switching to use ram as stack... Done testx = 5a5a5a5a Disabling cache as ram now Clearing initial memory region: Done Copying LinuxBIOS to ram. src=fffe0000 dst=00004000 linxbios_ram.nrv2b length = 000089fd linxbios_ram.bin length = 00013e44 Jumping to LinuxBIOS. LinuxBIOS-2.0.0-FILO Tue Dec 12 15:10:33 PST 2006 booting... Enumerating buses... scan_static_bus for Root Device APIC_CLUSTER: 0 enabled PCI_DOMAIN: 0000 enabled APIC_CLUSTER: 0 scanning... PCI: 00:18.3 siblings=1 CPU: APIC: 00 enabled malloc Enter, size 668, free_mem_ptr 0003a000 malloc 0x0003a000 CPU: APIC: 01 enabled PCI_DOMAIN: 0000 scanning... PCI: pci_scan_bus for bus 00 PCI: 00:18.0 [1022/1100] bus ops PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] ops PCI: 00:18.3 [1022/1103] enabled PCI: devfn 0xc4, bad id 0xffffffff PCI: devfn 0xc5, bad id 0xffffffff PCI: devfn 0xc6, bad id 0xffffffff PCI: devfn 0xc7, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0003a29c malloc 0x0003a29c PCI: 00:19.0 [10de/0372] enabled malloc Enter, size 668, free_mem_ptr 0003a538 malloc 0x0003a538 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 00:1a.0 subbordinate bus PCI Express PCI: 00:1a.0 [10de/0376] enabled malloc Enter, size 668, free_mem_ptr 0003a7d4 malloc 0x0003a7d4 PCI: 00:1b.0 [10de/0374] bus ops PCI: 00:1b.0 [10de/0374] enabled malloc Enter, size 668, free_mem_ptr 0003aa70 malloc 0x0003aa70 PCI: 00:1c.0 [10de/0374] bus ops PCI: 00:1c.0 [10de/0374] enabled malloc Enter, size 668, free_mem_ptr 0003ad0c malloc 0x0003ad0c Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 00:1d.0 subbordinate bus PCI Express PCI: 00:1d.0 [10de/0378] enabled malloc Enter, size 668, free_mem_ptr 0003afa8 malloc 0x0003afa8 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 00:1e.0 subbordinate bus PCI Express PCI: 00:1e.0 [10de/0375] enabled malloc Enter, size 668, free_mem_ptr 0003b244 malloc 0x0003b244 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 00:1f.0 subbordinate bus PCI Express PCI: 00:1f.0 [10de/0377] enabled Capability: 0x08 @ 0x44 flags: 0x01e1 Collapsing PCI: 00:01.0 [10de/02f4] Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 flags: 0xa800 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 flags: 0xa800 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 flags: 0xa800 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x08 @ 0x44 flags: 0x01f0 Collapsing PCI: 00:10.0 [10de/0369] Capability: 0x08 @ 0x80 flags: 0x2101 Capability: 0x08 @ 0x80 PCI: 00:00.0 [10de/02f4] enabled Capability: 0x08 @ 0x44 flags: 0x01e0 PCI: 00:01.0 count: 000f static_count: 0001 PCI: 00:01.0 [10de/02f4] enabled next_unitid: 0010 malloc Enter, size 668, free_mem_ptr 0003b4e0 malloc 0x0003b4e0 PCI: 00:00.0 [10de/0369] ops PCI: 00:00.0 [10de/0369] enabled Capability: 0x08 @ 0x44 flags: 0x01e0 PCI: 00:10.0 count: 000f static_count: 0001 PCI: 00:10.0 [10de/0369] enabled next_unitid: 001f PCI: pci_scan_bus for bus 00 PCI: devfn 0x0, bad id 0xffffffff PCI: 00:01.0 [10de/02f4] enabled malloc Enter, size 668, free_mem_ptr 0003b77c malloc 0x0003b77c PCI: 00:01.1 [10de/02fa] enabled malloc Enter, size 668, free_mem_ptr 0003ba18 malloc 0x0003ba18 PCI: 00:01.2 [10de/02fe] enabled malloc Enter, size 668, free_mem_ptr 0003bcb4 malloc 0x0003bcb4 PCI: 00:01.3 [10de/02f8] enabled malloc Enter, size 668, free_mem_ptr 0003bf50 malloc 0x0003bf50 PCI: 00:01.4 [10de/02f9] enabled malloc Enter, size 668, free_mem_ptr 0003c1ec malloc 0x0003c1ec PCI: 00:01.5 [10de/02ff] enabled malloc Enter, size 668, free_mem_ptr 0003c488 malloc 0x0003c488 PCI: 00:01.6 [10de/027f] enabled malloc Enter, size 668, free_mem_ptr 0003c724 malloc 0x0003c724 PCI: 00:01.7 [10de/027e] enabled PCI: devfn 0x10, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0003c9c0 malloc 0x0003c9c0 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 00:03.0 subbordinate bus PCI Express PCI: 00:03.0 [10de/02fc] enabled malloc Enter, size 668, free_mem_ptr 0003cc5c malloc 0x0003cc5c Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 00:04.0 subbordinate bus PCI Express PCI: 00:04.0 [10de/02fd] enabled malloc Enter, size 668, free_mem_ptr 0003cef8 malloc 0x0003cef8 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 00:05.0 subbordinate bus PCI Express PCI: 00:05.0 [10de/02fb] enabled PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: 00:10.0 [10de/0369] enabled malloc Enter, size 668, free_mem_ptr 0003d194 malloc 0x0003d194 PCI: 00:11.0 [10de/0360] bus ops PCI: 00:11.0 [10de/0360] enabled malloc Enter, size 668, free_mem_ptr 0003d430 malloc 0x0003d430 PCI: 00:11.1 [10de/0368] bus ops PCI: 00:11.1 [10de/0368] enabled malloc Enter, size 668, free_mem_ptr 0003d6cc malloc 0x0003d6cc PCI: 00:11.2 [10de/036a] enabled malloc Enter, size 668, free_mem_ptr 0003d968 malloc 0x0003d968 PCI: 00:11.3 [10de/036b] enabled PCI: devfn 0x8c, bad id 0xffffffff PCI: devfn 0x8d, bad id 0xffffffff PCI: devfn 0x8e, bad id 0xffffffff PCI: devfn 0x8f, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0003dc04 malloc 0x0003dc04 PCI: 00:12.0 [10de/036c] ops PCI: 00:12.0 [10de/036c] enabled malloc Enter, size 668, free_mem_ptr 0003dea0 malloc 0x0003dea0 PCI: 00:12.1 [10de/036d] ops PCI: 00:12.1 [10de/036d] enabled PCI: devfn 0x92, bad id 0xffffffff PCI: devfn 0x93, bad id 0xffffffff PCI: devfn 0x94, bad id 0xffffffff PCI: devfn 0x95, bad id 0xffffffff PCI: devfn 0x96, bad id 0xffffffff PCI: devfn 0x97, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0003e13c malloc 0x0003e13c PCI: 00:14.0 [10de/036e] ops PCI: 00:14.0 [10de/036e] enabled malloc Enter, size 668, free_mem_ptr 0003e3d8 malloc 0x0003e3d8 PCI: 00:15.0 [10de/037f] ops PCI: 00:15.0 [10de/037f] enabled malloc Enter, size 668, free_mem_ptr 0003e674 malloc 0x0003e674 PCI: 00:15.1 [10de/037f] ops PCI: 00:15.1 [10de/037f] enabled malloc Enter, size 668, free_mem_ptr 0003e910 malloc 0x0003e910 PCI: 00:15.2 [10de/037f] ops PCI: 00:15.2 [10de/037f] enabled PCI: devfn 0xab, bad id 0xffffffff PCI: devfn 0xac, bad id 0xffffffff PCI: devfn 0xad, bad id 0xffffffff PCI: devfn 0xae, bad id 0xffffffff PCI: devfn 0xaf, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0003ebac malloc 0x0003ebac PCI: 00:16.0 [10de/0370] bus ops PCI: 00:16.0 [10de/0370] enabled malloc Enter, size 668, free_mem_ptr 0003ee48 malloc 0x0003ee48 PCI: 00:16.1 [10de/0371] ops PCI: 00:16.1 [10de/0371] enabled PCI: devfn 0xb2, bad id 0xffffffff PCI: devfn 0xb3, bad id 0xffffffff PCI: devfn 0xb4, bad id 0xffffffff PCI: devfn 0xb5, bad id 0xffffffff PCI: devfn 0xb6, bad id 0xffffffff PCI: devfn 0xb7, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0003f0e4 malloc 0x0003f0e4 PCI: 00:18.0 [1022/1100] bus ops PCI: 00:18.0 [1022/1100] enabled malloc Enter, size 668, free_mem_ptr 0003f380 malloc 0x0003f380 PCI: 00:18.1 [1022/1101] enabled malloc Enter, size 668, free_mem_ptr 0003f61c malloc 0x0003f61c PCI: 00:18.2 [1022/1102] enabled malloc Enter, size 668, free_mem_ptr 0003f8b8 malloc 0x0003f8b8 PCI: 00:18.3 [1022/1103] ops PCI: 00:18.3 [1022/1103] enabled PCI: devfn 0xc4, bad id 0xffffffff PCI: devfn 0xc5, bad id 0xffffffff PCI: devfn 0xc6, bad id 0xffffffff PCI: devfn 0xc7, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0003fb54 malloc 0x0003fb54 PCI: 00:19.0 [10de/0372] enabled malloc Enter, size 668, free_mem_ptr 0003fdf0 malloc 0x0003fdf0 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 00:1a.0 subbordinate bus PCI Express PCI: 00:1a.0 [10de/0376] enabled malloc Enter, size 668, free_mem_ptr 0004008c malloc 0x0004008c PCI: 00:1b.0 [10de/0374] bus ops PCI: 00:1b.0 [10de/0374] enabled malloc Enter, size 668, free_mem_ptr 00040328 malloc 0x00040328 PCI: 00:1c.0 [10de/0374] bus ops PCI: 00:1c.0 [10de/0374] enabled malloc Enter, size 668, free_mem_ptr 000405c4 malloc 0x000405c4 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 00:1d.0 subbordinate bus PCI Express PCI: 00:1d.0 [10de/0378] enabled malloc Enter, size 668, free_mem_ptr 00040860 malloc 0x00040860 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 00:1e.0 subbordinate bus PCI Express PCI: 00:1e.0 [10de/0375] enabled malloc Enter, size 668, free_mem_ptr 00040afc malloc 0x00040afc Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 00:1f.0 subbordinate bus PCI Express PCI: 00:1f.0 [10de/0377] enabled do_pci_scan_bridge for PCI: 00:03.0 PCI: pci_scan_bus for bus 01 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=001 do_pci_scan_bridge returns max 1 do_pci_scan_bridge for PCI: 00:04.0 PCI: pci_scan_bus for bus 02 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=002 do_pci_scan_bridge returns max 2 do_pci_scan_bridge for PCI: 00:05.0 PCI: pci_scan_bus for bus 03 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=003 do_pci_scan_bridge returns max 3 scan_static_bus for PCI: 00:11.0 scan_static_bus for PCI: 00:11.0 done scan_static_bus for PCI: 00:11.1 scan_static_bus for PCI: 00:11.1 done do_pci_scan_bridge for PCI: 00:16.0 PCI: pci_scan_bus for bus 04 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 00040d98 malloc 0x00040d98 PCI: 04:09.0 [1106/3044] enabled PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=004 do_pci_scan_bridge returns max 4 Capability: 0x08 @ 0x44 flags: 0x01e1 Collapsing PCI: 04:01.0 [10de/02f4] Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 flags: 0xa800 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 flags: 0xa800 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 flags: 0xa800 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x08 @ 0x44 flags: 0x01f0 Collapsing PCI: 04:10.0 [10de/0369] malloc Enter, size 668, free_mem_ptr 00041034 malloc 0x00041034 PCI: 04:00.0 [10de/02f4] enabled Capability: 0x08 @ 0x44 flags: 0x01e0 PCI: 04:01.0 count: 000f static_count: 0001 PCI: 04:01.0 [10de/02f4] enabled next_unitid: 0010 malloc Enter, size 668, free_mem_ptr 000412d0 malloc 0x000412d0 PCI: 04:00.0 [10de/0369] ops PCI: 04:00.0 [10de/0369] enabled Capability: 0x08 @ 0x44 flags: 0x01e0 PCI: 04:10.0 count: 000f static_count: 0001 PCI: 04:10.0 [10de/0369] enabled next_unitid: 001f PCI: pci_scan_bus for bus 04 PCI: devfn 0x0, bad id 0xffffffff PCI: 04:01.0 [10de/02f4] enabled malloc Enter, size 668, free_mem_ptr 0004156c malloc 0x0004156c PCI: 04:01.1 [10de/02fa] enabled malloc Enter, size 668, free_mem_ptr 00041808 malloc 0x00041808 PCI: 04:01.2 [10de/02fe] enabled malloc Enter, size 668, free_mem_ptr 00041aa4 malloc 0x00041aa4 PCI: 04:01.3 [10de/02f8] enabled malloc Enter, size 668, free_mem_ptr 00041d40 malloc 0x00041d40 PCI: 04:01.4 [10de/02f9] enabled malloc Enter, size 668, free_mem_ptr 00041fdc malloc 0x00041fdc PCI: 04:01.5 [10de/02ff] enabled malloc Enter, size 668, free_mem_ptr 00042278 malloc 0x00042278 PCI: 04:01.6 [10de/027f] enabled malloc Enter, size 668, free_mem_ptr 00042514 malloc 0x00042514 PCI: 04:01.7 [10de/027e] enabled PCI: devfn 0x10, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 000427b0 malloc 0x000427b0 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 04:03.0 subbordinate bus PCI Express PCI: 04:03.0 [10de/02fc] enabled malloc Enter, size 668, free_mem_ptr 00042a4c malloc 0x00042a4c Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 04:04.0 subbordinate bus PCI Express PCI: 04:04.0 [10de/02fd] enabled malloc Enter, size 668, free_mem_ptr 00042ce8 malloc 0x00042ce8 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 04:05.0 subbordinate bus PCI Express PCI: 04:05.0 [10de/02fb] enabled PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: 04:10.0 [10de/0369] enabled malloc Enter, size 668, free_mem_ptr 00042f84 malloc 0x00042f84 PCI: 04:11.0 [10de/0360] bus ops PCI: 04:11.0 [10de/0360] enabled malloc Enter, size 668, free_mem_ptr 00043220 malloc 0x00043220 PCI: 04:11.1 [10de/0368] bus ops PCI: 04:11.1 [10de/0368] enabled malloc Enter, size 668, free_mem_ptr 000434bc malloc 0x000434bc PCI: 04:11.2 [10de/036a] enabled malloc Enter, size 668, free_mem_ptr 00043758 malloc 0x00043758 PCI: 04:11.3 [10de/036b] enabled PCI: devfn 0x8c, bad id 0xffffffff PCI: devfn 0x8d, bad id 0xffffffff PCI: devfn 0x8e, bad id 0xffffffff PCI: devfn 0x8f, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 000439f4 malloc 0x000439f4 PCI: 04:12.0 [10de/036c] ops PCI: 04:12.0 [10de/036c] enabled malloc Enter, size 668, free_mem_ptr 00043c90 malloc 0x00043c90 PCI: 04:12.1 [10de/036d] ops PCI: 04:12.1 [10de/036d] enabled PCI: devfn 0x92, bad id 0xffffffff PCI: devfn 0x93, bad id 0xffffffff PCI: devfn 0x94, bad id 0xffffffff PCI: devfn 0x95, bad id 0xffffffff PCI: devfn 0x96, bad id 0xffffffff PCI: devfn 0x97, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 00043f2c malloc 0x00043f2c PCI: 04:14.0 [10de/036e] ops PCI: 04:14.0 [10de/036e] enabled malloc Enter, size 668, free_mem_ptr 000441c8 malloc 0x000441c8 PCI: 04:15.0 [10de/037f] ops PCI: 04:15.0 [10de/037f] enabled malloc Enter, size 668, free_mem_ptr 00044464 malloc 0x00044464 PCI: 04:15.1 [10de/037f] ops PCI: 04:15.1 [10de/037f] enabled malloc Enter, size 668, free_mem_ptr 00044700 malloc 0x00044700 PCI: 04:15.2 [10de/037f] ops PCI: 04:15.2 [10de/037f] enabled PCI: devfn 0xab, bad id 0xffffffff PCI: devfn 0xac, bad id 0xffffffff PCI: devfn 0xad, bad id 0xffffffff PCI: devfn 0xae, bad id 0xffffffff PCI: devfn 0xaf, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0004499c malloc 0x0004499c PCI: 04:16.0 [10de/0370] bus ops PCI: 04:16.0 [10de/0370] enabled malloc Enter, size 668, free_mem_ptr 00044c38 malloc 0x00044c38 PCI: 04:16.1 [10de/0371] ops PCI: 04:16.1 [10de/0371] enabled PCI: devfn 0xb2, bad id 0xffffffff PCI: devfn 0xb3, bad id 0xffffffff PCI: devfn 0xb4, bad id 0xffffffff PCI: devfn 0xb5, bad id 0xffffffff PCI: devfn 0xb6, bad id 0xffffffff PCI: devfn 0xb7, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 00044ed4 malloc 0x00044ed4 PCI: 04:18.0 [10de/0372] enabled malloc Enter, size 668, free_mem_ptr 00045170 malloc 0x00045170 PCI: 04:19.0 [10de/0372] enabled malloc Enter, size 668, free_mem_ptr 0004540c malloc 0x0004540c Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 04:1a.0 subbordinate bus PCI Express PCI: 04:1a.0 [10de/0376] enabled malloc Enter, size 668, free_mem_ptr 000456a8 malloc 0x000456a8 PCI: 04:1b.0 [10de/0374] bus ops PCI: 04:1b.0 [10de/0374] enabled malloc Enter, size 668, free_mem_ptr 00045944 malloc 0x00045944 PCI: 04:1c.0 [10de/0374] bus ops PCI: 04:1c.0 [10de/0374] enabled malloc Enter, size 668, free_mem_ptr 00045be0 malloc 0x00045be0 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 04:1d.0 subbordinate bus PCI Express PCI: 04:1d.0 [10de/0378] enabled malloc Enter, size 668, free_mem_ptr 00045e7c malloc 0x00045e7c Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 04:1e.0 subbordinate bus PCI Express PCI: 04:1e.0 [10de/0375] enabled malloc Enter, size 668, free_mem_ptr 00046118 malloc 0x00046118 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 04:1f.0 subbordinate bus PCI Express PCI: 04:1f.0 [10de/0377] enabled do_pci_scan_bridge for PCI: 04:03.0 PCI: pci_scan_bus for bus 05 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=005 do_pci_scan_bridge returns max 5 do_pci_scan_bridge for PCI: 04:04.0 PCI: pci_scan_bus for bus 06 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=006 do_pci_scan_bridge returns max 6 do_pci_scan_bridge for PCI: 04:05.0 PCI: pci_scan_bus for bus 07 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=007 do_pci_scan_bridge returns max 7 scan_static_bus for PCI: 04:11.0 scan_static_bus for PCI: 04:11.0 done scan_static_bus for PCI: 04:11.1 scan_static_bus for PCI: 04:11.1 done do_pci_scan_bridge for PCI: 04:16.0 PCI: pci_scan_bus for bus 08 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 000463b4 malloc 0x000463b4 PCI: 08:09.0 [1106/3044] enabled PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=008 do_pci_scan_bridge returns max 8 do_pci_scan_bridge for PCI: 04:1a.0 PCI: pci_scan_bus for bus 09 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=009 do_pci_scan_bridge returns max 9 do_pci_scan_bridge for PCI: 04:1b.0 PCI: pci_scan_bus for bus 0a PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=00a do_pci_scan_bridge returns max 10 do_pci_scan_bridge for PCI: 04:1c.0 PCI: pci_scan_bus for bus 0b PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=00b do_pci_scan_bridge returns max 11 do_pci_scan_bridge for PCI: 04:1d.0 PCI: pci_scan_bus for bus 0c PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=00c do_pci_scan_bridge returns max 12 do_pci_scan_bridge for PCI: 04:1e.0 PCI: pci_scan_bus for bus 0d PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=00d do_pci_scan_bridge returns max 13 do_pci_scan_bridge for PCI: 04:1f.0 PCI: pci_scan_bus for bus 0e PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=00e do_pci_scan_bridge returns max 14 PCI: pci_scan_bus returning with max=00e do_pci_scan_bridge for PCI: 00:1a.0 PCI: pci_scan_bus for bus 0f PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=00f do_pci_scan_bridge returns max 15 do_pci_scan_bridge for PCI: 00:1b.0 PCI: pci_scan_bus for bus 10 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=010 do_pci_scan_bridge returns max 16 do_pci_scan_bridge for PCI: 00:1c.0 PCI: pci_scan_bus for bus 11 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=011 do_pci_scan_bridge returns max 17 do_pci_scan_bridge for PCI: 00:1d.0 PCI: pci_scan_bus for bus 12 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=012 do_pci_scan_bridge returns max 18 do_pci_scan_bridge for PCI: 00:1e.0 PCI: pci_scan_bus for bus 13 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=013 do_pci_scan_bridge returns max 19 do_pci_scan_bridge for PCI: 00:1f.0 PCI: pci_scan_bus for bus 14 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=014 do_pci_scan_bridge returns max 20 PCI: pci_scan_bus returning with max=014 do_pci_scan_bridge for PCI: 00:1a.0 PCI: pci_scan_bus for bus 15 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=015 do_pci_scan_bridge returns max 21 do_pci_scan_bridge for PCI: 00:1b.0 PCI: pci_scan_bus for bus 16 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=016 do_pci_scan_bridge returns max 22 do_pci_scan_bridge for PCI: 00:1c.0 PCI: pci_scan_bus for bus 17 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=017 do_pci_scan_bridge returns max 23 do_pci_scan_bridge for PCI: 00:1d.0 PCI: pci_scan_bus for bus 18 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=018 do_pci_scan_bridge returns max 24 do_pci_scan_bridge for PCI: 00:1e.0 PCI: pci_scan_bus for bus 19 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=019 do_pci_scan_bridge returns max 25 do_pci_scan_bridge for PCI: 00:1f.0 PCI: pci_scan_bus for bus 1a PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=01a do_pci_scan_bridge returns max 26 PCI: pci_scan_bus returning with max=01a PCI_DOMAIN: 0000 passpw: enabled scan_static_bus for Root Device done done Allocating resources... Reading resources... Root Device compute_allocate_io: base: 00000400 size: 00000000 align: 0 gran: 0 Root Device read_resources bus 0 link: 0 PCI_DOMAIN: 0000 read_resources bus 0 link: 0 PCI: 00:18.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:18.0 read_resources bus 0 link: 0 PCI: 00:03.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:03.0 read_resources bus 1 link: 0 PCI: 00:03.0 read_resources bus 1 link: 0 done PCI: 00:03.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:03.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 00:03.0 read_resources bus 1 link: 0 PCI: 00:03.0 read_resources bus 1 link: 0 done PCI: 00:03.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 00:03.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 01 io PCI: 00:03.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:03.0 read_resources bus 1 link: 0 PCI: 00:03.0 read_resources bus 1 link: 0 done PCI: 00:03.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:03.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 00:03.0 read_resources bus 1 link: 0 PCI: 00:03.0 read_resources bus 1 link: 0 done PCI: 00:03.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:03.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 01 prefmem PCI: 00:03.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:03.0 read_resources bus 1 link: 0 PCI: 00:03.0 read_resources bus 1 link: 0 done PCI: 00:03.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:03.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:03.0 read_resources bus 1 link: 0 PCI: 00:03.0 read_resources bus 1 link: 0 done PCI: 00:03.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:03.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 01 mem PCI: 00:04.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:04.0 read_resources bus 2 link: 0 PCI: 00:04.0 read_resources bus 2 link: 0 done PCI: 00:04.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:04.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 00:04.0 read_resources bus 2 link: 0 PCI: 00:04.0 read_resources bus 2 link: 0 done PCI: 00:04.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 00:04.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 02 io PCI: 00:04.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:04.0 read_resources bus 2 link: 0 PCI: 00:04.0 read_resources bus 2 link: 0 done PCI: 00:04.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:04.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 00:04.0 read_resources bus 2 link: 0 PCI: 00:04.0 read_resources bus 2 link: 0 done PCI: 00:04.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:04.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 02 prefmem PCI: 00:04.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:04.0 read_resources bus 2 link: 0 PCI: 00:04.0 read_resources bus 2 link: 0 done PCI: 00:04.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:04.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:04.0 read_resources bus 2 link: 0 PCI: 00:04.0 read_resources bus 2 link: 0 done PCI: 00:04.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:04.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 02 mem PCI: 00:05.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:05.0 read_resources bus 3 link: 0 PCI: 00:05.0 read_resources bus 3 link: 0 done PCI: 00:05.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:05.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 00:05.0 read_resources bus 3 link: 0 PCI: 00:05.0 read_resources bus 3 link: 0 done PCI: 00:05.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 00:05.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 03 io PCI: 00:05.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:05.0 read_resources bus 3 link: 0 PCI: 00:05.0 read_resources bus 3 link: 0 done PCI: 00:05.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:05.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 00:05.0 read_resources bus 3 link: 0 PCI: 00:05.0 read_resources bus 3 link: 0 done PCI: 00:05.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:05.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 03 prefmem PCI: 00:05.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:05.0 read_resources bus 3 link: 0 PCI: 00:05.0 read_resources bus 3 link: 0 done PCI: 00:05.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:05.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:05.0 read_resources bus 3 link: 0 PCI: 00:05.0 read_resources bus 3 link: 0 done PCI: 00:05.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:05.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 03 mem PCI: 00:11.0 read_resources bus 0 link: 0 PCI: 00:11.0 read_resources bus 0 link: 0 done PCI: 00:16.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:16.0 read_resources bus 4 link: 0 PCI: 04:09.0 register 10(ffffffff), read-only ignoring it PCI: 04:09.0 register 14(ffffffff), read-only ignoring it PCI: 04:09.0 register 18(ffffffff), read-only ignoring it PCI: 04:09.0 register 1c(ffffffff), read-only ignoring it PCI: 04:09.0 register 20(ffffffff), read-only ignoring it PCI: 04:09.0 register 24(ffffffff), read-only ignoring it PCI: 04:09.0 register 30(ffffffff), read-only ignoring it PCI: 00:16.0 read_resources bus 4 link: 0 done PCI: 00:16.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:16.0 compute_allocate_io: base: 0000f000 size: 00000000 align: 12 gran: 12 PCI: 00:16.0 read_resources bus 4 link: 0 PCI: 00:16.0 read_resources bus 4 link: 0 done PCI: 00:16.0 compute_allocate_io: base: 0000f000 size: 00000000 align: 12 gran: 12 done PCI: 00:16.0 1c <- [0x000000f000 - 0x000000efff] bus 04 io PCI: 00:16.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:16.0 read_resources bus 4 link: 0 PCI: 00:16.0 read_resources bus 4 link: 0 done PCI: 00:16.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:16.0 compute_allocate_prefmem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:16.0 read_resources bus 4 link: 0 PCI: 00:16.0 read_resources bus 4 link: 0 done PCI: 00:16.0 compute_allocate_prefmem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:16.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 04 prefmem PCI: 00:16.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:16.0 read_resources bus 4 link: 0 PCI: 00:16.0 read_resources bus 4 link: 0 done PCI: 00:16.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:16.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:16.0 read_resources bus 4 link: 0 PCI: 00:16.0 read_resources bus 4 link: 0 done PCI: 00:16.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:16.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 04 mem PCI: 00:1a.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:1a.0 read_resources bus 15 link: 0 PCI: 00:1a.0 read_resources bus 15 link: 0 done PCI: 00:1a.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:1a.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 00:1a.0 read_resources bus 15 link: 0 PCI: 00:1a.0 read_resources bus 15 link: 0 done PCI: 00:1a.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 00:1a.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 0f io PCI: 00:1a.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1a.0 read_resources bus 15 link: 0 PCI: 00:1a.0 read_resources bus 15 link: 0 done PCI: 00:1a.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1a.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1a.0 read_resources bus 15 link: 0 PCI: 00:1a.0 read_resources bus 15 link: 0 done PCI: 00:1a.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1a.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 0f prefmem PCI: 00:1a.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1a.0 read_resources bus 15 link: 0 PCI: 00:1a.0 read_resources bus 15 link: 0 done PCI: 00:1a.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1a.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1a.0 read_resources bus 15 link: 0 PCI: 00:1a.0 read_resources bus 15 link: 0 done PCI: 00:1a.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1a.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 0f mem PCI: 00:1b.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:1b.0 read_resources bus 16 link: 0 PCI: 00:1b.0 read_resources bus 16 link: 0 done PCI: 00:1b.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:1b.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 00:1b.0 read_resources bus 16 link: 0 PCI: 00:1b.0 read_resources bus 16 link: 0 done PCI: 00:1b.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 00:1b.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 10 io PCI: 00:1b.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1b.0 read_resources bus 16 link: 0 PCI: 00:1b.0 read_resources bus 16 link: 0 done PCI: 00:1b.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1b.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1b.0 read_resources bus 16 link: 0 PCI: 00:1b.0 read_resources bus 16 link: 0 done PCI: 00:1b.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1b.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 10 prefmem PCI: 00:1b.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1b.0 read_resources bus 16 link: 0 PCI: 00:1b.0 read_resources bus 16 link: 0 done PCI: 00:1b.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1b.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1b.0 read_resources bus 16 link: 0 PCI: 00:1b.0 read_resources bus 16 link: 0 done PCI: 00:1b.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1b.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 10 mem PCI: 00:1c.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:1c.0 read_resources bus 17 link: 0 PCI: 00:1c.0 read_resources bus 17 link: 0 done PCI: 00:1c.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:1c.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 00:1c.0 read_resources bus 17 link: 0 PCI: 00:1c.0 read_resources bus 17 link: 0 done PCI: 00:1c.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 00:1c.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 11 io PCI: 00:1c.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1c.0 read_resources bus 17 link: 0 PCI: 00:1c.0 read_resources bus 17 link: 0 done PCI: 00:1c.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1c.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1c.0 read_resources bus 17 link: 0 PCI: 00:1c.0 read_resources bus 17 link: 0 done PCI: 00:1c.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1c.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 11 prefmem PCI: 00:1c.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1c.0 read_resources bus 17 link: 0 PCI: 00:1c.0 read_resources bus 17 link: 0 done PCI: 00:1c.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1c.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1c.0 read_resources bus 17 link: 0 PCI: 00:1c.0 read_resources bus 17 link: 0 done PCI: 00:1c.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1c.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 11 mem PCI: 00:1d.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:1d.0 read_resources bus 18 link: 0 PCI: 00:1d.0 read_resources bus 18 link: 0 done PCI: 00:1d.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:1d.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 00:1d.0 read_resources bus 18 link: 0 PCI: 00:1d.0 read_resources bus 18 link: 0 done PCI: 00:1d.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 00:1d.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 12 io PCI: 00:1d.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1d.0 read_resources bus 18 link: 0 PCI: 00:1d.0 read_resources bus 18 link: 0 done PCI: 00:1d.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1d.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1d.0 read_resources bus 18 link: 0 PCI: 00:1d.0 read_resources bus 18 link: 0 done PCI: 00:1d.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1d.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 12 prefmem PCI: 00:1d.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1d.0 read_resources bus 18 link: 0 PCI: 00:1d.0 read_resources bus 18 link: 0 done PCI: 00:1d.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1d.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1d.0 read_resources bus 18 link: 0 PCI: 00:1d.0 read_resources bus 18 link: 0 done PCI: 00:1d.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1d.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 12 mem PCI: 00:1e.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:1e.0 read_resources bus 19 link: 0 PCI: 00:1e.0 read_resources bus 19 link: 0 done PCI: 00:1e.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:1e.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 00:1e.0 read_resources bus 19 link: 0 PCI: 00:1e.0 read_resources bus 19 link: 0 done PCI: 00:1e.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 00:1e.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 13 io PCI: 00:1e.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 19 link: 0 PCI: 00:1e.0 read_resources bus 19 link: 0 done PCI: 00:1e.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1e.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 19 link: 0 PCI: 00:1e.0 read_resources bus 19 link: 0 done PCI: 00:1e.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1e.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 13 prefmem PCI: 00:1e.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 19 link: 0 PCI: 00:1e.0 read_resources bus 19 link: 0 done PCI: 00:1e.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1e.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 19 link: 0 PCI: 00:1e.0 read_resources bus 19 link: 0 done PCI: 00:1e.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1e.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 13 mem PCI: 00:1f.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:1f.0 read_resources bus 20 link: 0 PCI: 00:1f.0 read_resources bus 20 link: 0 done PCI: 00:1f.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:1f.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 00:1f.0 read_resources bus 20 link: 0 PCI: 00:1f.0 read_resources bus 20 link: 0 done PCI: 00:1f.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 00:1f.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 14 io PCI: 00:1f.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1f.0 read_resources bus 20 link: 0 PCI: 00:1f.0 read_resources bus 20 link: 0 done PCI: 00:1f.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1f.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1f.0 read_resources bus 20 link: 0 PCI: 00:1f.0 read_resources bus 20 link: 0 done PCI: 00:1f.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1f.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 14 prefmem PCI: 00:1f.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1f.0 read_resources bus 20 link: 0 PCI: 00:1f.0 read_resources bus 20 link: 0 done PCI: 00:1f.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1f.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1f.0 read_resources bus 20 link: 0 PCI: 00:1f.0 read_resources bus 20 link: 0 done PCI: 00:1f.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1f.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 14 mem PCI: 00:18.0 read_resources bus 0 link: 0 done PCI: 00:11.1 20 * [0x00000000 - 0x0000003f] io PCI: 00:11.1 24 * [0x00000040 - 0x0000007f] io PCI: 00:14.0 20 * [0x00000080 - 0x0000008f] io PCI: 00:15.0 20 * [0x00000090 - 0x0000009f] io PCI: 00:15.1 20 * [0x000000a0 - 0x000000af] io PCI: 00:15.2 20 * [0x000000b0 - 0x000000bf] io PCI: 00:15.0 10 * [0x000000c0 - 0x000000c7] io PCI: 00:15.0 18 * [0x000000d0 - 0x000000d7] io PCI: 00:15.1 10 * [0x000000e0 - 0x000000e7] io PCI: 00:15.1 18 * [0x000000f0 - 0x000000f7] io PCI: 00:15.2 10 * [0x00000100 - 0x00000107] io PCI: 00:15.2 18 * [0x00000400 - 0x00000407] io PCI: 00:19.0 14 * [0x00000410 - 0x00000417] io PCI: 00:15.0 14 * [0x00000420 - 0x00000423] io PCI: 00:15.0 1c * [0x00000430 - 0x00000433] io PCI: 00:15.1 14 * [0x00000440 - 0x00000443] io PCI: 00:15.1 1c * [0x00000450 - 0x00000453] io PCI: 00:15.2 14 * [0x00000460 - 0x00000463] io PCI: 00:15.2 1c * [0x00000470 - 0x00000473] io PCI: 00:18.0 compute_allocate_io: base: 00000474 size: 00001000 align: 12 gran: 12 done PCI: 00:18.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:18.0 read_resources bus 0 link: 0 PCI: 00:18.0 read_resources bus 0 link: 0 done PCI: 00:18.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:18.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:18.0 read_resources bus 0 link: 0 PCI: 00:18.0 read_resources bus 0 link: 0 done PCI: 00:18.3 94 * [0x00000000 - 0x03ffffff] mem PCI: 00:11.3 10 * [0x04000000 - 0x0403ffff] mem PCI: 00:16.1 10 * [0x04040000 - 0x04043fff] mem PCI: 00:12.0 10 * [0x04044000 - 0x04044fff] mem PCI: 00:15.0 24 * [0x04045000 - 0x04045fff] mem PCI: 00:15.1 24 * [0x04046000 - 0x04046fff] mem PCI: 00:15.2 24 * [0x04047000 - 0x04047fff] mem PCI: 00:19.0 10 * [0x04048000 - 0x04048fff] mem PCI: 00:12.1 10 * [0x04049000 - 0x040490ff] mem PCI: 00:19.0 18 * [0x0404a000 - 0x0404a0ff] mem PCI: 00:19.0 1c * [0x0404b000 - 0x0404b00f] mem PCI: 00:18.0 compute_allocate_mem: base: 0404b010 size: 04100000 align: 26 gran: 20 done PCI: 00:1a.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:1a.0 read_resources bus 21 link: 0 PCI: 00:1a.0 read_resources bus 21 link: 0 done PCI: 00:1a.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:1a.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 00:1a.0 read_resources bus 21 link: 0 PCI: 00:1a.0 read_resources bus 21 link: 0 done PCI: 00:1a.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 00:1a.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 15 io PCI: 00:1a.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1a.0 read_resources bus 21 link: 0 PCI: 00:1a.0 read_resources bus 21 link: 0 done PCI: 00:1a.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1a.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1a.0 read_resources bus 21 link: 0 PCI: 00:1a.0 read_resources bus 21 link: 0 done PCI: 00:1a.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1a.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 15 prefmem PCI: 00:1a.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1a.0 read_resources bus 21 link: 0 PCI: 00:1a.0 read_resources bus 21 link: 0 done PCI: 00:1a.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1a.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1a.0 read_resources bus 21 link: 0 PCI: 00:1a.0 read_resources bus 21 link: 0 done PCI: 00:1a.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1a.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 15 mem PCI: 00:1b.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:1b.0 read_resources bus 22 link: 0 PCI: 00:1b.0 read_resources bus 22 link: 0 done PCI: 00:1b.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:1b.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 00:1b.0 read_resources bus 22 link: 0 PCI: 00:1b.0 read_resources bus 22 link: 0 done PCI: 00:1b.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 00:1b.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 16 io PCI: 00:1b.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1b.0 read_resources bus 22 link: 0 PCI: 00:1b.0 read_resources bus 22 link: 0 done PCI: 00:1b.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1b.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1b.0 read_resources bus 22 link: 0 PCI: 00:1b.0 read_resources bus 22 link: 0 done PCI: 00:1b.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1b.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 16 prefmem PCI: 00:1b.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1b.0 read_resources bus 22 link: 0 PCI: 00:1b.0 read_resources bus 22 link: 0 done PCI: 00:1b.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1b.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1b.0 read_resources bus 22 link: 0 PCI: 00:1b.0 read_resources bus 22 link: 0 done PCI: 00:1b.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1b.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 16 mem PCI: 00:1c.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:1c.0 read_resources bus 23 link: 0 PCI: 00:1c.0 read_resources bus 23 link: 0 done PCI: 00:1c.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:1c.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 00:1c.0 read_resources bus 23 link: 0 PCI: 00:1c.0 read_resources bus 23 link: 0 done PCI: 00:1c.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 00:1c.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 17 io PCI: 00:1c.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1c.0 read_resources bus 23 link: 0 PCI: 00:1c.0 read_resources bus 23 link: 0 done PCI: 00:1c.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1c.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1c.0 read_resources bus 23 link: 0 PCI: 00:1c.0 read_resources bus 23 link: 0 done PCI: 00:1c.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1c.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 17 prefmem PCI: 00:1c.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1c.0 read_resources bus 23 link: 0 PCI: 00:1c.0 read_resources bus 23 link: 0 done PCI: 00:1c.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1c.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1c.0 read_resources bus 23 link: 0 PCI: 00:1c.0 read_resources bus 23 link: 0 done PCI: 00:1c.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1c.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 17 mem PCI: 00:1d.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:1d.0 read_resources bus 24 link: 0 PCI: 00:1d.0 read_resources bus 24 link: 0 done PCI: 00:1d.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:1d.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 00:1d.0 read_resources bus 24 link: 0 PCI: 00:1d.0 read_resources bus 24 link: 0 done PCI: 00:1d.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 00:1d.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 18 io PCI: 00:1d.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1d.0 read_resources bus 24 link: 0 PCI: 00:1d.0 read_resources bus 24 link: 0 done PCI: 00:1d.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1d.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1d.0 read_resources bus 24 link: 0 PCI: 00:1d.0 read_resources bus 24 link: 0 done PCI: 00:1d.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1d.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 18 prefmem PCI: 00:1d.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1d.0 read_resources bus 24 link: 0 PCI: 00:1d.0 read_resources bus 24 link: 0 done PCI: 00:1d.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1d.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1d.0 read_resources bus 24 link: 0 PCI: 00:1d.0 read_resources bus 24 link: 0 done PCI: 00:1d.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1d.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 18 mem PCI: 00:1e.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:1e.0 read_resources bus 25 link: 0 PCI: 00:1e.0 read_resources bus 25 link: 0 done PCI: 00:1e.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:1e.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 00:1e.0 read_resources bus 25 link: 0 PCI: 00:1e.0 read_resources bus 25 link: 0 done PCI: 00:1e.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 00:1e.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 19 io PCI: 00:1e.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 25 link: 0 PCI: 00:1e.0 read_resources bus 25 link: 0 done PCI: 00:1e.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1e.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 25 link: 0 PCI: 00:1e.0 read_resources bus 25 link: 0 done PCI: 00:1e.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1e.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 19 prefmem PCI: 00:1e.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 25 link: 0 PCI: 00:1e.0 read_resources bus 25 link: 0 done PCI: 00:1e.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1e.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 25 link: 0 PCI: 00:1e.0 read_resources bus 25 link: 0 done PCI: 00:1e.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1e.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 19 mem PCI: 00:1f.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:1f.0 read_resources bus 26 link: 0 PCI: 00:1f.0 read_resources bus 26 link: 0 done PCI: 00:1f.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 00:1f.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 00:1f.0 read_resources bus 26 link: 0 PCI: 00:1f.0 read_resources bus 26 link: 0 done PCI: 00:1f.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 00:1f.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 1a io PCI: 00:1f.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1f.0 read_resources bus 26 link: 0 PCI: 00:1f.0 read_resources bus 26 link: 0 done PCI: 00:1f.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1f.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1f.0 read_resources bus 26 link: 0 PCI: 00:1f.0 read_resources bus 26 link: 0 done PCI: 00:1f.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1f.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 1a prefmem PCI: 00:1f.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1f.0 read_resources bus 26 link: 0 PCI: 00:1f.0 read_resources bus 26 link: 0 done PCI: 00:1f.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:1f.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1f.0 read_resources bus 26 link: 0 PCI: 00:1f.0 read_resources bus 26 link: 0 done PCI: 00:1f.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1f.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 1a mem PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done Root Device read_resources bus 0 link: 0 done PCI: 00:18.0 1c0 * [0x00001000 - 0x00001fff] io PCI: 00:19.0 14 * [0x00002000 - 0x00002007] io Root Device compute_allocate_io: base: 00002008 size: 00001c08 align: 12 gran: 0 done Root Device compute_allocate_mem: base: 00000000 size: 00000000 align: 0 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:18.0 1b0 * [0x00000000 - 0x040fffff] mem PCI: 00:18.3 94 * [0x08000000 - 0x0bffffff] mem PCI: 00:18.0 1b8 * [0x0c000000 - 0x0bffffff] prefmem PCI: 00:19.0 10 * [0x0c000000 - 0x0c000fff] mem PCI: 00:19.0 18 * [0x0c001000 - 0x0c0010ff] mem PCI: 00:19.0 1c * [0x0c002000 - 0x0c00200f] mem Root Device compute_allocate_mem: base: 0c002010 size: 0c002010 align: 26 gran: 0 done Done reading resources. Setting resources... Root Device compute_allocate_io: base: 00001000 size: 00001c08 align: 12 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:18.0 1c0 * [0x00001000 - 0x00001fff] io PCI: 00:19.0 14 * [0x00002000 - 0x00002007] io Root Device compute_allocate_io: base: 00002008 size: 00001008 align: 12 gran: 0 done Root Device compute_allocate_mem: base: f0000000 size: 0c002010 align: 26 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:18.0 1b0 * [0xf0000000 - 0xf40fffff] mem PCI: 00:18.3 94 * [0xf8000000 - 0xfbffffff] mem PCI: 00:18.0 1b8 * [0xfc000000 - 0xfbffffff] prefmem PCI: 00:19.0 10 * [0xfc000000 - 0xfc000fff] mem PCI: 00:19.0 18 * [0xfc001000 - 0xfc0010ff] mem PCI: 00:19.0 1c * [0xfc002000 - 0xfc00200f] mem Root Device compute_allocate_mem: base: fc002010 size: 0c002010 align: 26 gran: 0 done Root Device assign_resources, bus 0 link: 0 PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 PCI: 00:18.0 compute_allocate_io: base: 00001000 size: 00001000 align: 12 gran: 12 PCI: 00:18.0 read_resources bus 0 link: 0 PCI: 00:18.0 read_resources bus 0 link: 0 done PCI: 00:11.1 20 * [0x00001000 - 0x0000103f] io PCI: 00:11.1 24 * [0x00001040 - 0x0000107f] io PCI: 00:14.0 20 * [0x00001080 - 0x0000108f] io PCI: 00:15.0 20 * [0x00001090 - 0x0000109f] io PCI: 00:15.1 20 * [0x000010a0 - 0x000010af] io PCI: 00:15.2 20 * [0x000010b0 - 0x000010bf] io PCI: 00:15.0 10 * [0x000010c0 - 0x000010c7] io PCI: 00:15.0 18 * [0x000010d0 - 0x000010d7] io PCI: 00:15.1 10 * [0x000010e0 - 0x000010e7] io PCI: 00:15.1 18 * [0x000010f0 - 0x000010f7] io PCI: 00:15.2 10 * [0x00001100 - 0x00001107] io PCI: 00:15.2 18 * [0x00001400 - 0x00001407] io PCI: 00:19.0 14 * [0x00001410 - 0x00001417] io PCI: 00:15.0 14 * [0x00001420 - 0x00001423] io PCI: 00:15.0 1c * [0x00001430 - 0x00001433] io PCI: 00:15.1 14 * [0x00001440 - 0x00001443] io PCI: 00:15.1 1c * [0x00001450 - 0x00001453] io PCI: 00:15.2 14 * [0x00001460 - 0x00001463] io PCI: 00:15.2 1c * [0x00001470 - 0x00001473] io PCI: 00:18.0 compute_allocate_io: base: 00001474 size: 00001000 align: 12 gran: 12 done PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000001fff] io PCI: 00:18.0 compute_allocate_prefmem: base: fc000000 size: 00000000 align: 20 gran: 20 PCI: 00:18.0 read_resources bus 0 link: 0 PCI: 00:18.0 read_resources bus 0 link: 0 done PCI: 00:18.0 compute_allocate_prefmem: base: fc000000 size: 00000000 align: 20 gran: 20 done PCI: 00:18.0 1b8 <- [0x00fc000000 - 0x00fbffffff] prefmem PCI: 00:18.0 compute_allocate_mem: base: f0000000 size: 04100000 align: 26 gran: 20 PCI: 00:18.0 read_resources bus 0 link: 0 PCI: 00:18.0 read_resources bus 0 link: 0 done PCI: 00:18.3 94 * [0xf0000000 - 0xf3ffffff] mem PCI: 00:11.3 10 * [0xf4000000 - 0xf403ffff] mem PCI: 00:16.1 10 * [0xf4040000 - 0xf4043fff] mem PCI: 00:12.0 10 * [0xf4044000 - 0xf4044fff] mem PCI: 00:15.0 24 * [0xf4045000 - 0xf4045fff] mem PCI: 00:15.1 24 * [0xf4046000 - 0xf4046fff] mem PCI: 00:15.2 24 * [0xf4047000 - 0xf4047fff] mem PCI: 00:19.0 10 * [0xf4048000 - 0xf4048fff] mem PCI: 00:12.1 10 * [0xf4049000 - 0xf40490ff] mem PCI: 00:19.0 18 * [0xf404a000 - 0xf404a0ff] mem PCI: 00:19.0 1c * [0xf404b000 - 0xf404b00f] mem PCI: 00:18.0 compute_allocate_mem: base: f404b010 size: 04100000 align: 26 gran: 20 done PCI: 00:18.0 1b0 <- [0x00f0000000 - 0x00f40fffff] mem PCI: 00:18.0 assign_resources, bus 0 link: 0 PCI: 00:11.1 20 <- [0x0000001000 - 0x000000103f] io PCI: 00:11.1 24 <- [0x0000001040 - 0x000000107f] io PCI: 00:11.3 10 <- [0x00f4000000 - 0x00f403ffff] mem PCI: 00:12.0 10 <- [0x00f4044000 - 0x00f4044fff] mem PCI: 00:12.1 10 <- [0x00f4049000 - 0x00f40490ff] mem PCI: 00:14.0 20 <- [0x0000001080 - 0x000000108f] io PCI: 00:15.0 10 <- [0x00000010c0 - 0x00000010c7] io PCI: 00:15.0 14 <- [0x0000001420 - 0x0000001423] io PCI: 00:15.0 18 <- [0x00000010d0 - 0x00000010d7] io PCI: 00:15.0 1c <- [0x0000001430 - 0x0000001433] io PCI: 00:15.0 20 <- [0x0000001090 - 0x000000109f] io PCI: 00:15.0 24 <- [0x00f4045000 - 0x00f4045fff] mem PCI: 00:15.1 10 <- [0x00000010e0 - 0x00000010e7] io PCI: 00:15.1 14 <- [0x0000001440 - 0x0000001443] io PCI: 00:15.1 18 <- [0x00000010f0 - 0x00000010f7] io PCI: 00:15.1 1c <- [0x0000001450 - 0x0000001453] io PCI: 00:15.1 20 <- [0x00000010a0 - 0x00000010af] io PCI: 00:15.1 24 <- [0x00f4046000 - 0x00f4046fff] mem PCI: 00:15.2 10 <- [0x0000001100 - 0x0000001107] io PCI: 00:15.2 14 <- [0x0000001460 - 0x0000001463] io PCI: 00:15.2 18 <- [0x0000001400 - 0x0000001407] io PCI: 00:15.2 1c <- [0x0000001470 - 0x0000001473] io PCI: 00:15.2 20 <- [0x00000010b0 - 0x00000010bf] io PCI: 00:15.2 24 <- [0x00f4047000 - 0x00f4047fff] mem PCI: 00:16.1 10 <- [0x00f4040000 - 0x00f4043fff] mem PCI: 00:18.3 94 <- [0x00f0000000 - 0x00f3ffffff] mem PCI: 00:18.3 94 <- [0x00f0000000 - 0x00f3ffffff] mem PCI: 00:19.0 10 <- [0x00f4048000 - 0x00f4048fff] mem PCI: 00:19.0 14 <- [0x0000001410 - 0x0000001417] io PCI: 00:19.0 18 <- [0x00f404a000 - 0x00f404a0ff] mem PCI: 00:19.0 1c <- [0x00f404b000 - 0x00f404b00f] mem PCI: 00:18.0 assign_resources, bus 0 link: 0 PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem PCI: 00:19.0 10 <- [0x00fc000000 - 0x00fc000fff] mem PCI: 00:19.0 14 <- [0x0000002000 - 0x0000002007] io PCI: 00:19.0 18 <- [0x00fc001000 - 0x00fc0010ff] mem PCI: 00:19.0 1c <- [0x00fc002000 - 0x00fc00200f] mem PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 Root Device assign_resources, bus 0 link: 0 Done setting resources. Done allocating resources. Enabling resources... PCI: 00:18.0 cmd <- 140 PCI: 00:01.0 subsystem <- 10de/cb84 PCI: 00:01.0 cmd <- 146 PCI: 00:01.1 cmd <- 140 PCI: 00:01.2 cmd <- 140 PCI: 00:01.3 cmd <- 140 PCI: 00:01.4 cmd <- 146 PCI: 00:01.5 cmd <- 146 PCI: 00:01.6 cmd <- 140 PCI: 00:01.7 cmd <- 140 PCI: 00:03.0 bridge ctrl <- 0003 PCI: 00:03.0 cmd <- 140 PCI: 00:04.0 bridge ctrl <- 0003 PCI: 00:04.0 cmd <- 140 PCI: 00:05.0 bridge ctrl <- 0003 PCI: 00:05.0 cmd <- 140 PCI: 00:10.0 cmd <- 146 PCI: 00:11.0 cmd <- 14f PCI: 00:11.1 cmd <- 141 PCI: 00:11.2 cmd <- 540 PCI: 00:11.3 cmd <- 142 PCI: 00:12.0 cmd <- 142 PCI: 00:12.1 cmd <- 142 PCI: 00:14.0 cmd <- 141 PCI: 00:15.0 cmd <- 143 PCI: 00:15.1 cmd <- 143 PCI: 00:15.2 cmd <- 143 PCI: 00:16.0 bridge ctrl <- 0003 PCI: 00:16.0 cmd <- 140 PCI: 04:09.0 cmd <- ffff PCI: 00:16.1 cmd <- 142 PCI: 00:18.0 cmd <- 140 PCI: 00:18.1 cmd <- 140 PCI: 00:18.2 cmd <- 140 PCI: 00:18.3 cmd <- 140 PCI: 00:19.0 cmd <- 143 PCI: 00:1a.0 bridge ctrl <- 0003 PCI: 00:1a.0 cmd <- 140 PCI: 00:1b.0 bridge ctrl <- 0003 PCI: 00:1b.0 cmd <- 140 PCI: 00:1c.0 bridge ctrl <- 0003 PCI: 00:1c.0 cmd <- 140 PCI: 00:1d.0 bridge ctrl <- 0003 PCI: 00:1d.0 cmd <- 140 PCI: 00:1e.0 bridge ctrl <- 0003 PCI: 00:1e.0 cmd <- 140 PCI: 00:1f.0 bridge ctrl <- 0003 PCI: 00:1f.0 cmd <- 140 PCI: 00:18.1 subsystem <- 10de/cb84 PCI: 00:18.1 cmd <- 140 PCI: 00:18.2 subsystem <- 10de/cb84 PCI: 00:18.2 cmd <- 140 PCI: 00:18.3 cmd <- 140 PCI: 00:19.0 cmd <- 143 PCI: 00:1a.0 bridge ctrl <- 0003 PCI: 00:1a.0 cmd <- 140 PCI: 00:1b.0 bridge ctrl <- 0003 PCI: 00:1b.0 cmd <- 140 PCI: 00:1c.0 bridge ctrl <- 0003 PCI: 00:1c.0 cmd <- 140 PCI: 00:1d.0 bridge ctrl <- 0003 PCI: 00:1d.0 cmd <- 140 PCI: 00:1e.0 bridge ctrl <- 0003 PCI: 00:1e.0 cmd <- 140 PCI: 00:1f.0 bridge ctrl <- 0003 PCI: 00:1f.0 cmd <- 140 done. Initializing devices... Root Device init APIC_CLUSTER: 0 init Initializing CPU #0 CPU: vendor AMD device 40fb2 CPU: family 0f, model 4b, stepping 02 Enabling cache Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 512MB, type WB ADDRESS_MASK_HIGH=0xff DONE variable MTRRs Clear out the extra MTRR's call enable_var_mtrr() Leave x86_setup_var_mtrrs MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled CPU model AMD Athlon(tm) 64 FX-37 Processor Setting up local apic... apic_id: 0x00 done. ECC Disabled CPU #0 Initialized Asserting INIT. Waiting for send to finish... +Deasserting INIT. Waiting for send to finish... +#startup loops: 2. Sending STARTUP #1 to 1. After apic_write. Startup point 1. Waiting for send to finish... +Sending STARTUP #2 to 1. After apic_write. Startup point 1. Waiting for send to finish... +After Startup. Initializing CPU #1 Waiting for 1 CPUS to stop CPU: vendor AMD device 40fb2 CPU: family 0f, model 4b, stepping 02 Enabling cache Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 512MB, type WB ADDRESS_MASK_HIGH=0xff DONE variable MTRRs Clear out the extra MTRR's call enable_var_mtrr() Leave x86_setup_var_mtrrs MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled CPU model AMD Athlon(tm) 64 FX-37 Processor Setting up local apic... apic_id: 0x01 done. CPU #1 Initialized All AP CPUs stopped PCI: 00:18.0 init PCI: 00:01.0 init PCI: 00:18.1 init PCI: 00:18.2 init PCI: 00:18.3 init NB: Function 3 Misc Control.. done. PCI: 00:19.0 init PCI: 00:1b.0 init PCI: 00:1c.0 init PCI: 00:01.1 init PCI: 00:01.2 init PCI: 00:01.3 init PCI: 00:01.4 init PCI: 00:01.5 init PCI: 00:01.6 init PCI: 00:01.7 init PCI: 00:11.0 init for IRQ, reg 0x00000000 value 0x00000700 0x00000000 for IRQ, reg 0x00000001 value 0x00010000 0x00000000 for IRQ, reg 0x00000002 value 0x00010000 0x00000000 for IRQ, reg 0x00000003 value 0x00010000 0x00000000 for IRQ, reg 0x00000004 value 0x00010000 0x00000000 for IRQ, reg 0x00000005 value 0x00010000 0x00000000 for IRQ, reg 0x00000006 value 0x00010000 0x00000000 for IRQ, reg 0x00000007 value 0x00010000 0x00000000 for IRQ, reg 0x00000008 value 0x00010000 0x00000000 for IRQ, reg 0x00000009 value 0x00010000 0x00000000 for IRQ, reg 0x0000000a value 0x00010000 0x00000000 for IRQ, reg 0x0000000b value 0x00010000 0x00000000 for IRQ, reg 0x0000000c value 0x00010000 0x00000000 for IRQ, reg 0x0000000d value 0x00010000 0x00000000 for IRQ, reg 0x0000000e value 0x00010000 0x00000000 for IRQ, reg 0x0000000f value 0x00010000 0x00000000 for IRQ, reg 0x00000010 value 0x00010000 0x00000000 for IRQ, reg 0x00000011 value 0x00010000 0x00000000 for IRQ, reg 0x00000012 value 0x00010000 0x00000000 for IRQ, reg 0x00000013 value 0x00010000 0x00000000 for IRQ, reg 0x00000014 value 0x00010000 0x00000000 for IRQ, reg 0x00000015 value 0x00010000 0x00000000 for IRQ, reg 0x00000016 value 0x00010000 0x00000000 for IRQ, reg 0x00000017 value 0x00010000 0x00000000 set power on after power fail RTC Init PCI: 00:11.2 init PCI: 00:11.3 init PCI: 00:12.1 init PCI: 00:14.0 init IDE1 IDE0 PCI: 00:15.0 init SATA S SATA P PCI: 00:15.1 init SATA S SATA P PCI: 00:15.2 init SATA S SATA P PCI: 00:16.0 init dev_root mem base = 0x00f0000000 [0x50] <-- 0xf0000000 PCI: 00:18.0 init PCI: 00:18.1 init PCI: 00:18.2 init PCI: 00:18.3 init NB: Function 3 Misc Control.. done. PCI: 00:19.0 init PCI: 00:1b.0 init PCI: 00:1c.0 init PCI: 04:09.0 init PCI: 04:01.0 init PCI: 04:01.1 init PCI: 04:01.2 init PCI: 04:01.3 init PCI: 04:01.4 init PCI: 04:01.5 init PCI: 04:01.6 init PCI: 04:01.7 init PCI: 04:11.0 init Unexpected Exception: 13 @ 10:000052e9 - Halting Code: 0 eflags: 00010006 eax: 00000010 ebx: 00000000 ecx: 00042f84 edx: 00000011 edi: 00042f84 esi: ffffffff ebp: 00039f9c esp: 00039f84 From stepan at coresystems.de Wed Dec 13 00:45:45 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 13 Dec 2006 00:45:45 +0100 Subject: [LinuxBIOS] More MCP55 hacking In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49072C9@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49072C9@ssvlexmb2.amd.com> Message-ID: <20061212234545.GA23636@coresystems.de> * Lu, Yinghai [061212 22:45]: > For later AMD CPU, you could acpi for SRAT, SLIT..., plus irq routing in > mptable. > And not use DSDT for irq routing. Are you certain that Linux reads PIRQ at all when it finds an SRAT/SLIT/..? If you implement enough of ACPI to have Linux use the HPET timer, you need all IRQ routing in ACPI as well. I had cases where Linux would use the PIRQ/MP table values but never ever read a PIRQ/MP table since it found a little bit of ACPI. Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From yinghai.lu at amd.com Wed Dec 13 00:47:55 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 12 Dec 2006 15:47:55 -0800 Subject: [LinuxBIOS] More MCP55 hacking Message-ID: <5986589C150B2F49A46483AC44C7BCA49072CF@ssvlexmb2.amd.com> Please check the patch Avoid device overlap with pci 0:0x18.0 Signed-off-by: Yinghai Lu -------------- next part -------------- A non-text attachment was scrubbed... Name: get_one_more_unitid.patch Type: application/octet-stream Size: 502 bytes Desc: get_one_more_unitid.patch URL: From yinghai.lu at amd.com Wed Dec 13 00:51:14 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 12 Dec 2006 15:51:14 -0800 Subject: [LinuxBIOS] More MCP55 hacking Message-ID: <5986589C150B2F49A46483AC44C7BCA49072D0@ssvlexmb2.amd.com> -----Original Message----- From: linuxbios-bounces+yinghai.lu=amd.com at linuxbios.org [mailto:linuxbios-bounces+yinghai.lu=amd.com at linuxbios.org] On Behalf Of Stefan Reinauer >Are you certain that Linux reads PIRQ at all when it finds an >SRAT/SLIT/..? Need pci=noacpi. I produced one kernel about making it work with that, the kernel acpi maintainer doesn't take it. (He is from I company) >If you implement enough of ACPI to have Linux use the HPET timer, you >need all IRQ routing in ACPI as well. I had cases where Linux would use >the PIRQ/MP table values but never ever read a PIRQ/MP table since it >found a little bit of ACPI. HPET is used in that case. YH From yinghai.lu at amd.com Wed Dec 13 01:07:20 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 12 Dec 2006 16:07:20 -0800 Subject: [LinuxBIOS] More MCP55 hacking Message-ID: <5986589C150B2F49A46483AC44C7BCA49072D2@ssvlexmb2.amd.com> If still has problem 1. #make the SB HT chain on bus 0, default is not (0) #default SB_HT_CHAIN_ON_BUS0=1 2. Power off your target for a while. You may drive it nuts. YH -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Ed Swierk Sent: Tuesday, December 12, 2006 3:41 PM To: LinuxBIOS Subject: Re: [LinuxBIOS] More MCP55 hacking On 12/12/06, Lu, Yinghai wrote: > ===> > > ##HT Unit ID offset, default is 1, the typical one > #default HT_CHAIN_UNITID_BASE=0x06 > > ##real SB Unit ID, default is 0x20, mean dont touch it at last > #default HT_CHAIN_END_UNITID_BASE=0x01 > > (it will put c51 on unitid 1, and mcp55 on unitid ?) After commenting out these two options as you suggest, it looks like a lot more devices are getting initialized; I had to increase HEAPSIZE to 64 KB to avoid overflowing the heap. Now, I'm getting an exception during PCI device init; see the attached boot log. Does it make sense that the same devices (e.g. 10de:0378) are showing up on both bus 0 and bus 4? --Ed From c-d.hailfinger.devel.2006 at gmx.net Wed Dec 13 01:33:47 2006 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 13 Dec 2006 01:33:47 +0100 Subject: [LinuxBIOS] More MCP55 hacking In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49072D0@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49072D0@ssvlexmb2.amd.com> Message-ID: <457F4A6B.20605@gmx.net> Lu, Yinghai wrote: > Stefan Reinauer wrote: > >> Are you certain that Linux reads PIRQ at all when it finds an >> SRAT/SLIT/..? > > Need pci=noacpi. I produced one kernel about making it work with that, > the kernel acpi maintainer doesn't take it. (He is from I company) Do you still have that patch? Maybe we can get it into the kernel and bypass the acpi maintainer. Regards, Carl-Daniel From eswierk at arastra.com Wed Dec 13 01:37:13 2006 From: eswierk at arastra.com (Ed Swierk) Date: Tue, 12 Dec 2006 16:37:13 -0800 Subject: [LinuxBIOS] More MCP55 hacking In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49072D2@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49072D2@ssvlexmb2.amd.com> Message-ID: On 12/12/06, Lu, Yinghai wrote: > If still has problem > 1. > #make the SB HT chain on bus 0, default is not (0) > #default SB_HT_CHAIN_ON_BUS0=1 > 2. > Power off your target for a while. You may drive it nuts. The patch didn't help, but commenting out SB_HT_CHAIN_ON_BUS0 did. Now the SB is on bus 1 and the devices are getting initialized only once. Any idea what those "Unable to handle 64-bit address space for bridge 0000:01:03.0" errors are about? The stuff about IO/MEM/PREFETCH windows being disabled doesn't look good either. I suppose the first order of business is to get interrupts going, though. --Ed From yinghai.lu at amd.com Wed Dec 13 02:06:57 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 12 Dec 2006 17:06:57 -0800 Subject: [LinuxBIOS] More MCP55 hacking Message-ID: <5986589C150B2F49A46483AC44C7BCA49072D4@ssvlexmb2.amd.com> You need to use 64 bit kernel if you enable pref64 in LinuxBIOS. YH -----Original Message----- From: linuxbios-bounces+yinghai.lu=amd.com at linuxbios.org [mailto:linuxbios-bounces+yinghai.lu=amd.com at linuxbios.org] On Behalf Of Ed Swierk Sent: Tuesday, December 12, 2006 4:37 PM To: LinuxBIOS Subject: Re: [LinuxBIOS] More MCP55 hacking On 12/12/06, Lu, Yinghai wrote: > If still has problem > 1. > #make the SB HT chain on bus 0, default is not (0) > #default SB_HT_CHAIN_ON_BUS0=1 > 2. > Power off your target for a while. You may drive it nuts. The patch didn't help, but commenting out SB_HT_CHAIN_ON_BUS0 did. Now the SB is on bus 1 and the devices are getting initialized only once. Any idea what those "Unable to handle 64-bit address space for bridge 0000:01:03.0" errors are about? The stuff about IO/MEM/PREFETCH windows being disabled doesn't look good either. I suppose the first order of business is to get interrupts going, though. --Ed -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios From eswierk at arastra.com Wed Dec 13 02:41:08 2006 From: eswierk at arastra.com (Ed Swierk) Date: Tue, 12 Dec 2006 17:41:08 -0800 Subject: [LinuxBIOS] More MCP55 hacking In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49072D4@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49072D4@ssvlexmb2.amd.com> Message-ID: On 12/12/06, Lu, Yinghai wrote: > You need to use 64 bit kernel if you enable pref64 in LinuxBIOS. CONFIG_PCI_64BIT_PREF_MEM is 0, so it's not clear to me why Linux is seeing the PCI_PREF_RANGE_TYPE_64 bit set in the configuration registers of those bridges. Perhaps the pref64 bit is set by default by the hardware; if so, is there a way to clear it in LinuxBIOS? --Ed From yinghai.lu at amd.com Wed Dec 13 08:00:25 2006 From: yinghai.lu at amd.com (Yinghai Lu) Date: Tue, 12 Dec 2006 23:00:25 -0800 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA49072A5@ssvlexmb2.amd.com> <86802c440612080053s13e5318eq7ae83aff4c7eb21c@mail.gmail.com> Message-ID: <86802c440612122300k36e84f96x85ef25ebbf27077d@mail.gmail.com> On 12/8/06, Eric W. Biederman wrote: > > Your or I missed a bug fix/enhancement in there somewhere. > I found the problem. the __set_fixmap need to __va, so the entries will be referred from PAGE_OFFSET. solution will be 1. move enable_dbgp_console from setup_early_printk, and call it from setup_arch after init_memory_mapping. 2. or make __set_fixmap can use __pa or pa()+__START_KERNEL_map in addtion to _va. please check attached updated patch that is your patch plus 1. YH -------------- next part -------------- A non-text attachment was scrubbed... Name: usb_debug.patch Type: text/x-patch Size: 21884 bytes Desc: not available URL: From ebiederm at xmission.com Wed Dec 13 08:29:49 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Wed, 13 Dec 2006 00:29:49 -0700 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: <86802c440612122300k36e84f96x85ef25ebbf27077d@mail.gmail.com> (Yinghai Lu's message of "Tue, 12 Dec 2006 23:00:25 -0800") References: <5986589C150B2F49A46483AC44C7BCA49072A5@ssvlexmb2.amd.com> <86802c440612080053s13e5318eq7ae83aff4c7eb21c@mail.gmail.com> <86802c440612122300k36e84f96x85ef25ebbf27077d@mail.gmail.com> Message-ID: "Yinghai Lu" writes: > On 12/8/06, Eric W. Biederman wrote: >> >> Your or I missed a bug fix/enhancement in there somewhere. >> > > I found the problem. the __set_fixmap need to __va, so the entries > will be referred from PAGE_OFFSET. > > solution will be > 1. move enable_dbgp_console from setup_early_printk, and call it from > setup_arch after init_memory_mapping. > 2. or make __set_fixmap can use __pa or pa()+__START_KERNEL_map in > addtion to _va. 3. Make __va always work. I had this in my tree and I guess it didn't get into my big rollup patch. Eric x86_64: Fix the memory mapping in the early page table diff --git a/arch/x86_64/kernel/head.S b/arch/x86_64/kernel/head.S index 1e6f808..2f65469 100644 --- a/arch/x86_64/kernel/head.S +++ b/arch/x86_64/kernel/head.S @@ -328,9 +328,9 @@ ENTRY(wakeup_level4_pgt) .align PAGE_SIZE ENTRY(boot_level4_pgt) .quad phys_level3_ident_pgt | 0x007 - .fill 255,8,0 + .fill 257,8,0 .quad phys_level3_physmem_pgt | 0x007 - .fill 254,8,0 + .fill 252,8,0 /* (2^48-(2*1024*1024*1024))/(2^39) = 511 */ .quad phys_level3_kernel_pgt | 0x007 From talbotx at comcast.net Wed Dec 13 08:34:39 2006 From: talbotx at comcast.net (Adam Talbot) Date: Tue, 12 Dec 2006 23:34:39 -0800 Subject: [LinuxBIOS] Crazy idea? LinuxBios+Suspend 2 In-Reply-To: <20061211231956.GA17830@coresystems.de> References: <5986589C150B2F49A46483AC44C7BCA49072B2@ssvlexmb2.amd.com> <20061211191702.GA9491@countzero.vandewege.net> <13426df10612111330h2f6fd18j5ac97b71494ed126@mail.gmail.com> <457DDE1E.7070409@comcast.net> <20061211231956.GA17830@coresystems.de> Message-ID: <457FAD0F.3030802@comcast.net> Ouch... well that just shot me down in flames. But, VERY good point. Stefan Reinauer wrote: > * Adam Talbot [061211 23:39]: > >> My current system takes about 3 seconds for Linuxbios, then 2 more for >> kernel, to the suspend2 code, then 7~12sec depending on how much >> compression I am using on the suspend2 image. >> > > Just a thought, the firmware level IDE driver is usually not using DMA > or any advanced reading methods, and as such a lot slower than the > according Linux driver. You might have a hard time keeping the 2s the > kernel needs. > > >> So a total boot time of about 15 seconds. Up and playing music, with >> full X. A normal boot is 33 sec, to get to a full X + music playing. >> I want sub 10. >> > > Your calculation goes with 3+2+10s - Instead of tuning the 3s or 2s, you > might instead start improving on the biggest piece of the cake: the 10s. > > I would assume the 2s kernel do some initialization that are expected to > happen for the suspend code to work. So even if you manage to win 2s > by not booting a kernel, you might have quite some other things to > "fix". > > S. > > > From nuessle at uni-mannheim.de Wed Dec 13 09:12:00 2006 From: nuessle at uni-mannheim.de (Mondrian Nuessle) Date: Wed, 13 Dec 2006 09:12:00 +0100 Subject: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled Message-ID: <457FB5D0.9020006@uni-mannheim.de> > I have to cart it to the rack to actually try the IB, and since I'm > having to hot-swap from the Iwill bios every time I flash (any clue > why flashrom -w when booting under LB fails immediately with "ERASE > FAILED" and trashes the image in flash?) Try to add the following io statements to your src/mainboard/iwill/dk8_htx/Config.lb at the point where the logical device 8 of the superio is intialized: device pnp 2e.8 on # GPIO2 io 0x07 = 0x08ff io 0x30 = 0x01ff io 0x2b = 0xd0ff io 0xf0 = 0xef16 end I hope this does the flash trick :-) Regards, Mondrian -- Mondrian Nuessle University of Mannheim Phone: +49 621 181 2717 Computer Architecture Group Fax: +49 621 181 2713 http://ra.ti.uni-mannheim.de mailto:nuessle at uni-mannheim.de From yinghai.lu at amd.com Wed Dec 13 11:09:06 2006 From: yinghai.lu at amd.com (Yinghai Lu) Date: Wed, 13 Dec 2006 02:09:06 -0800 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA49072A5@ssvlexmb2.amd.com> <86802c440612080053s13e5318eq7ae83aff4c7eb21c@mail.gmail.com> <86802c440612122300k36e84f96x85ef25ebbf27077d@mail.gmail.com> Message-ID: <86802c440612130209r5fab0de7q5dcda00c6c01cd13@mail.gmail.com> On 12/12/06, Eric W. Biederman wrote: > diff --git a/arch/x86_64/kernel/head.S b/arch/x86_64/kernel/head.S > index 1e6f808..2f65469 100644 > --- a/arch/x86_64/kernel/head.S > +++ b/arch/x86_64/kernel/head.S > @@ -328,9 +328,9 @@ ENTRY(wakeup_level4_pgt) > .align PAGE_SIZE > ENTRY(boot_level4_pgt) > .quad phys_level3_ident_pgt | 0x007 > - .fill 255,8,0 > + .fill 257,8,0 > .quad phys_level3_physmem_pgt | 0x007 > - .fill 254,8,0 > + .fill 252,8,0 > /* (2^48-(2*1024*1024*1024))/(2^39) = 511 */ > .quad phys_level3_kernel_pgt | 0x007 > Good, it seems __PAGE_OFFSET used to be 0xfff800000000000 and then 1<<40, and then 0xfff810000000000 YH From yinghai.lu at amd.com Wed Dec 13 11:41:10 2006 From: yinghai.lu at amd.com (Yinghai Lu) Date: Wed, 13 Dec 2006 02:41:10 -0800 Subject: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support. In-Reply-To: <86802c440612130209r5fab0de7q5dcda00c6c01cd13@mail.gmail.com> References: <5986589C150B2F49A46483AC44C7BCA49072A5@ssvlexmb2.amd.com> <86802c440612080053s13e5318eq7ae83aff4c7eb21c@mail.gmail.com> <86802c440612122300k36e84f96x85ef25ebbf27077d@mail.gmail.com> <86802c440612130209r5fab0de7q5dcda00c6c01cd13@mail.gmail.com> Message-ID: <86802c440612130241i21a0cf25k14aaf2a145c094c6@mail.gmail.com> wakeup_level4_pgt need to be updated in addtion to boot_level4_pgt? also comment could be updated for good unstanding too. YH From segher at kernel.crashing.org Wed Dec 13 17:14:54 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Wed, 13 Dec 2006 17:14:54 +0100 Subject: [LinuxBIOS] More MCP55 hacking In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA49072D4@ssvlexmb2.amd.com> Message-ID: <7B7ECB91-AF7D-4154-9FDB-FD938FB63AD0@kernel.crashing.org> > CONFIG_PCI_64BIT_PREF_MEM is 0, so it's not clear to me why Linux is > seeing the PCI_PREF_RANGE_TYPE_64 bit set in the configuration > registers of those bridges. Because it's a hardware property. The error means a single bar needed 4GB or more of address space, btw. Sounds like something is wrong :-) > Perhaps the pref64 bit is set by default by the hardware; if so, is > there a way to clear it in LinuxBIOS? No. BARs are 64-bit or not, there's no way to change that. It doesn't matter however; if the top half of a 64-bit BAR is set to zeroes, it works fine on a 32-bit system. Segher From ben at hewson-venieri.com Wed Dec 13 18:23:20 2006 From: ben at hewson-venieri.com (Ben Hewson) Date: Wed, 13 Dec 2006 17:23:20 +0000 Subject: [LinuxBIOS] epia In-Reply-To: <16B26BE8-9549-4613-874F-436338899454@kernel.crashing.org> References: <457BDBBB.5080501@hewson-venieri.com> <457C1BA3.7090905@hewson-venieri.com> <16B26BE8-9549-4613-874F-436338899454@kernel.crashing.org> Message-ID: <45803708.1040403@hewson-venieri.com> Segher Boessenkool wrote: >> Also when it comes to enabling the IDE controller in compatibilty mode >> (reg 0x42) the non working versions reports it contains 0xc9, the >> working version reports the same register as 0. >> > > You need to set the prog-if field in the PCI config space > for the controller to 0x8a, not 0x8f, before doing the BAR > allocation to get legacy mode. Did you do this? > > > Segher > > > I am not sure about the order of things, however according to the PCI IDE controller document you pointed me to 0x8a is fine as bits 0 & 2 are don't care. Incidentally both working and non working version set the same values. The biggest change that I can see is that 2 of the elements in the bus structure have changed from unsigned char's to unsigned 16 bit types. Also in all of the pci read/write functions, the where parameter has changed from a char to an int. So my initial thoughts is that one of these changes has had a nasty side effect someplace but I can't find anything as yet. Apart from those changes the code is mostly the same. Of course something may be causing a condition #define to compile in something different, although I can't see anything different in any of the config files. I am only comparing files that I think are being used, so it is possible that I am missing something. Anyway I am going to add alot of debug prints to the pci read/write functions in both working and non working versions and then do a file compare to see if anything is different. It is probably the sort of bug that is so obvious once you see it, but look perfectly ok until then Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From uwe at hermann-uwe.de Wed Dec 13 18:53:06 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Wed, 13 Dec 2006 18:53:06 +0100 Subject: [LinuxBIOS] pc partitoin magic number not found? Message-ID: <20061213175306.GC19078@greenwood> Hi Jon, you noted that you work on the Intel 82801DB: http://linuxbios.org/index.php?title=Supported_Chipsets_and_Devices&curid=1002&diff=3747&oldid=3739&rcid=1296 Please have a look at the 82801DBM code before, that's at the very least very similar, maybe it even already supports the 82801DB, too(?) Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From mcqmcqmcq at fastmail.fm Wed Dec 13 20:17:34 2006 From: mcqmcqmcq at fastmail.fm (mcqmcqmcq at fastmail.fm) Date: Wed, 13 Dec 2006 11:17:34 -0800 Subject: [LinuxBIOS] DK8-HTX Early Hang with HTX Card Intsalled In-Reply-To: <457FB5D0.9020006@uni-mannheim.de> References: <457FB5D0.9020006@uni-mannheim.de> Message-ID: <1166037454.2615.280328693@webmail.messagingengine.com> > Try to add the following io statements to your > src/mainboard/iwill/dk8_htx/Config.lb at the point where the logical > device 8 of the superio is intialized: > > device pnp 2e.8 on # GPIO2 > io 0x07 = 0x08ff > io 0x30 = 0x01ff > io 0x2b = 0xd0ff > io 0xf0 = 0xef16 > end > > I hope this does the flash trick :-) Yep, that fixed it! That makes life _way_ less screwdriver/paperclip- intensive. Many thanks, -mcq -- mcqmcqmcq at fastmail.fm -- http://www.fastmail.fm - Choose from over 50 domains or use your own From mcqmcqmcq at fastmail.fm Wed Dec 13 20:58:14 2006 From: mcqmcqmcq at fastmail.fm (mcqmcqmcq at fastmail.fm) Date: Wed, 13 Dec 2006 11:58:14 -0800 Subject: [LinuxBIOS] DK8-HTX: 8131 B-bus IRQ problem? Message-ID: <1166039894.7233.280334929@webmail.messagingengine.com> Hi guys, There is a problem (I believe the _last_ problem) with the DK8-HTX's IRQs on the 8131's B-bus. I have two 3ware 9550's. If they're both on the A-bus, things work fine and the relevant slice of /proc/interrupts looks like: CPU0 CPU1 CPU2 CPU3 25: 41 0 0 0 IO-APIC-fasteoi 3w-9xxx 30: 17 0 0 0 IO-APIC-fasteoi 3w-9xxx If I move one of them to the B-bus (there's only one physical slot on B), then this becomes: 26: 36650 0 0 0 IO-APIC-fasteoi 3w-9xxx 30: 17 0 0 0 IO-APIC-fasteoi 3w-9xxx The 36650 number increases by about 20000 or so all at once every few minutes. The timer appears to still be ticking away correctly. Accesses to the RAID on the B-bus immediately (deterministically; not 'once every few minutes') lead to a nobody cared that takes the card offline: irq 26: nobody cared (try booting with the "irqpoll" option) Call Trace: [] __report_bad_irq+0x30/0x7d [] note_interrupt+0x1e1/0x223 [] handle_fasteoi_irq+0x9e/0xc5 [] call_softirq+0x1c/0x28 [] do_IRQ+0x7b/0xc8 [] default_idle+0x0/0x47 [] ret_from_intr+0x0/0xa [] default_idle+0x29/0x47 [] cpu_idle+0x8a/0xad [] start_kernel+0x202/0x207 [] _sinittext+0x15a/0x15e handlers: [] (twa_interrupt+0x0/0x5d8 [3w_9xxx]) Disabling IRQ #26 Interestingly enough, the behavior is the _same_ in the Iwill BIOS. I'm wondering if the LB routings are just a copy of broken Iwill routings? Can anybody think of anything to try other than concluding 'bad mobo/noisy wire'? (If a board swap is the next thing to try, that's possible but disruptive.) Bootlogs attached. Thanks again, -mcq -- mcqmcqmcq at fastmail.fm -- http://www.fastmail.fm - Or how I learned to stop worrying and love email again -------------- next part -------------- A non-text attachment was scrubbed... Name: minicom-lb-bothA.cap.gz Type: application/x-gzip Size: 7896 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: minicom-lb-AB.cap.gz Type: application/x-gzip Size: 9659 bytes Desc: not available URL: From yinghai.lu at amd.com Wed Dec 13 21:04:19 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Wed, 13 Dec 2006 12:04:19 -0800 Subject: [LinuxBIOS] DK8-HTX: 8131 B-bus IRQ problem? Message-ID: <5986589C150B2F49A46483AC44C7BCA49072DA@ssvlexmb2.amd.com> Do you have Broadcom tg3 card? Try it on that slot to see if it works well. YH From jon.dufresne at gmail.com Wed Dec 13 21:13:10 2006 From: jon.dufresne at gmail.com (Jon Dufresne) Date: Wed, 13 Dec 2006 15:13:10 -0500 Subject: [LinuxBIOS] pc partitoin magic number not found? In-Reply-To: <20061213175306.GC19078@greenwood> References: <20061213175306.GC19078@greenwood> Message-ID: <376ea3380612131213l13f1008tc4465381094a05cc@mail.gmail.com> Thanks, Uwe. I used the 82801dbm as a starting ground. I've already had to change a few things such as device IDs. I know something somewhere isn't right because I get a kernel panic anytime I modprobe a kernel module that relates to a device in the southbridge. Since I'm responding I'll post the kernel panic in case someone has an idea. This example is trying to bring up the sound device. If I remove all module loading during init, I can get to a single user prompt. Anyway thanks for the tip. Unable to handle kernel paging request at virtual address 019b2005 printing eip: *pde = 00000000 Oops: 0000 [#1] Modules linked in: snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore floppy ext3 jbd CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010202 (2.6.9-42.EL) EIP is at __request_resource+0x24/0x41 eax: 019b2001 ebx: c1ab0460 ecx: c036849c edx: c0004014 esi: f02021ff edi: f0202000 ebp: f0202000 esp: c1a1de80 ds: 007b es: 007b ss: 0068 Process modprobe (pid: 1186, threadinfo=c1a1d000 task=c1a2c170) Stack: c1ab0460 c036849c c1ab047c c012a27c dff4c800 00000200 000001ff 00000002 dff4c800 c1a7dc24 c01f02a0 c1a7dc24 00000002 c1a7dc24 dff4c800 f885d270 c01f033c c1a7dc00 dfce2400 dff4c800 f8858c73 00000001 c1a7dc00 c1a7dc00 Call Trace: [] __request_region+0x52/0x74 [] pci_request_region+0x82/0xf2 [] pci_request_regions+0x14/0x37 [] snd_intel8x0_create+0x104/0x403 [snd_intel8x0] [] snd_intel8x0_probe+0xca/0x21a [snd_intel8x0] [] pci_device_probe_static+0x2a/0x3d [] __pci_device_probe+0x1b/0x2c [] pci_device_probe+0x1b/0x2d [] bus_match+0x27/0x45 [] driver_attach+0x37/0x66 [] bus_add_driver+0x77/0x97 [] driver_register+0x51/0x58 [] pci_register_driver+0x85/0xa1 [] alsa_card_intel8x0_init+0xa/0x39 [snd_intel8x0] [] sys_init_module+0xe9/0x1d0 [] syscall_call+0x7/0xb Code: 84 36 c0 5b 89 d0 c3 57 89 c1 56 53 8b 7a 04 89 d3 8b 72 08 39 fe 72 2c 3b 79 04 72 27 3b 71 08 77 22 8d 51 18 8b 02 85 c0 74 05 <39> 70 04 76 0c 89 43 14 31 c0 89 1a 89 4b 10 eb 08 39 78 08 <0>Fatal exception: panic in 5 seconds Kernel panic - not syncing: Fatal exception Thanks for the tip. On 12/13/06, Uwe Hermann wrote: > Hi Jon, > > you noted that you work on the Intel 82801DB: > http://linuxbios.org/index.php?title=Supported_Chipsets_and_Devices&curid=1002&diff=3747&oldid=3739&rcid=1296 > > Please have a look at the 82801DBM code before, that's at the very least > very similar, maybe it even already supports the 82801DB, too(?) > > > Uwe. > -- > http://www.hermann-uwe.de | http://www.holsham-traders.de > http://www.crazy-hacks.org | http://www.unmaintained-free-software.org > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFFgD4CXdVoV3jWIbQRAk0KAJ9J8VboHY4II7umgiNPmS1TIVDynQCfT+sh > IcESivY9FsYMzj1HaUQdhP4= > =JSxz > -----END PGP SIGNATURE----- > > > From mcqmcqmcq at fastmail.fm Wed Dec 13 21:24:55 2006 From: mcqmcqmcq at fastmail.fm (mcqmcqmcq at fastmail.fm) Date: Wed, 13 Dec 2006 12:24:55 -0800 Subject: [LinuxBIOS] DK8-HTX: 8131 B-bus IRQ problem? In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49072DA@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49072DA@ssvlexmb2.amd.com> Message-ID: <1166041495.10037.280339275@webmail.messagingengine.com> > Do you have Broadcom tg3 card? Try it on that slot to see if it works > well. I can loop a dual-port e1000 back to itself in that slot and pump some bytes. What are we hoping to learn from this (so I can make sure I test for the theory you have in mind)? Toodles, -mcq -- mcqmcqmcq at fastmail.fm -- http://www.fastmail.fm - Choose from over 50 domains or use your own From yinghai.lu at amd.com Wed Dec 13 21:34:46 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Wed, 13 Dec 2006 12:34:46 -0800 Subject: [LinuxBIOS] DK8-HTX: 8131 B-bus IRQ problem? Message-ID: <5986589C150B2F49A46483AC44C7BCA49072DE@ssvlexmb2.amd.com> It could be some bug in your 3w-9xxx driver. Or I noticed that Irq 26 is used by card on slot 4 (8131 a) Irq 25 is used by card on slot 3 (8131 a) Irq 30 is used by card on slot 2 (8131 b) Slot 1: is HTX So try to find which one cause problem? YH -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of mcqmcqmcq at fastmail.fm Sent: Wednesday, December 13, 2006 12:25 PM To: Lu, Yinghai; linuxbios at linuxbios.org Subject: Re: [LinuxBIOS] DK8-HTX: 8131 B-bus IRQ problem? > Do you have Broadcom tg3 card? Try it on that slot to see if it works > well. I can loop a dual-port e1000 back to itself in that slot and pump some bytes. What are we hoping to learn from this (so I can make sure I test for the theory you have in mind)? Toodles, -mcq -- mcqmcqmcq at fastmail.fm -- http://www.fastmail.fm - Choose from over 50 domains or use your own -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios From brian.kemp at gmail.com Wed Dec 13 22:16:47 2006 From: brian.kemp at gmail.com (Brian Kemp) Date: Wed, 13 Dec 2006 16:16:47 -0500 Subject: [LinuxBIOS] Tyan Tiger 133 (S1834) port to v2 Message-ID: <296e05160612131316p75a37127me96e78a66e7a53d6@mail.gmail.com> Hello all! I was doing a web search for the latest BIOS for some old motherboards I have lying around when I came across your supported hardware list. I happen to have two Tyan Tiger 133 (S1834) SMP Slot-1 motherboards. I just pulled one from a machine today, complete with P3-500 and terminator card (for the other slot) and I have no plans for it...so I figured I'd try to assist with your efforts. I'm not much of a low-level programmer, but if anyone would like me to ship the motherboard (and enough mounting hardware to get it set up in a blank case) to them, please let me know--I'd be happy to do so. If not, perhaps I can get involved in some low-level stuff, although I lack most of the specific hardware tools and expertise. (I have a Tyan Tiger 100 (S1832) as well, but it's completely different...) Thanks! --Brian From mcqmcqmcq at fastmail.fm Wed Dec 13 22:42:44 2006 From: mcqmcqmcq at fastmail.fm (mcqmcqmcq at fastmail.fm) Date: Wed, 13 Dec 2006 13:42:44 -0800 Subject: [LinuxBIOS] DK8-HTX: 8131 B-bus IRQ problem? In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49072DE@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49072DE@ssvlexmb2.amd.com> Message-ID: <1166046164.18541.280350585@webmail.messagingengine.com> > It could be some bug in your 3w-9xxx driver. Nope. e1000 does the same thing in that slot; "nobody cared" immediately on driver load. Definately not unique to the 3w-9xxx driver. > I noticed that > Irq 26 is used by card on slot 4 (8131 a) > Irq 25 is used by card on slot 3 (8131 a) > Irq 30 is used by card on slot 2 (8131 b) > Slot 1: is HTX Ahh. Closer inspection of the mobo artwork reveals that there are two sockets on the B-bus and one on the A labelled (in order: HTX, PCIX2, PCI64_1, PCI64_2). I thought there were two on the A and one on the B (well, that's how _I_ would have built it... ;-)). So the problem isn't a B-bus problem it's a B-bus 2nd slot (slot 4) problem. I think your 'a' and 'b' in the quoted text above are backwards from reality (or at least from the board artwork). This means it's a non-issue for me practically; I can get away with never plugging anything into slot 4, like ever. But if it _is_ an LB problem, it'd be nice to get it licked so the board can be declared 'working'. :) Might there be some mystery hardware that I just don't know about that's initted by LB/etherboot+filo, still running, and sharing the IRQ with slot 4? Does linux generate 'nobody cared' for IRQs with zero drivers attached or does it silently drop them? Thanks again, -mcq -- mcqmcqmcq at fastmail.fm -- http://www.fastmail.fm - Does exactly what it says on the tin From corey_osgood at verizon.net Wed Dec 13 22:41:46 2006 From: corey_osgood at verizon.net (Corey Osgood) Date: Wed, 13 Dec 2006 16:41:46 -0500 Subject: [LinuxBIOS] Handling different chipset versions: the right way? Message-ID: <4580739A.5000405@verizon.net> I'm looking at working on via vt82c686b for tyan s2507, and I'm wondering what the best way to handle the differences between 686a and 686b is. The only difference I can see is a single PCI ID for ACPI. Would it be better to use some sort of runtime detection for this single PCI ID to differentiate, or seperate the two entirely? Also, should I use the whole name of the chipset, vt82c686b, or just shorten it to vt686b (which is commonly used by via)? BTW, I'm putting off i815 again, because I can't get the test rig out of its current use. -Corey From talbotx at comcast.net Wed Dec 13 23:35:40 2006 From: talbotx at comcast.net (Adam Talbot) Date: Wed, 13 Dec 2006 14:35:40 -0800 Subject: [LinuxBIOS] pc partitoin magic number not found? In-Reply-To: <376ea3380612131213l13f1008tc4465381094a05cc@mail.gmail.com> References: <20061213175306.GC19078@greenwood> <376ea3380612131213l13f1008tc4465381094a05cc@mail.gmail.com> Message-ID: <4580803C.6090102@comcast.net> Point filo to boot off of memtest. I would look at memory. Just an idea, and its an easy test. -Adam Jon Dufresne wrote: > Thanks, Uwe. > > I used the 82801dbm as a starting ground. I've already had to change a > few things such as device IDs. > > I know something somewhere isn't right because I get a kernel panic > anytime I modprobe a kernel module that relates to a device in the > southbridge. Since I'm responding I'll post the kernel panic in case > someone has an idea. This example is trying to bring up the sound > device. If I remove all module loading during init, I can get to a > single user prompt. > > Anyway thanks for the tip. > > Unable to handle kernel paging request at virtual address 019b2005 > printing eip: > *pde = 00000000 > Oops: 0000 [#1] > Modules linked in: snd_intel8x0 snd_ac97_codec snd_pcm_oss > snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart > snd_rawmidi snd_seq_device snd soundcore floppy ext3 jbd > CPU: 0 > EIP: 0060:[] Not tainted VLI > EFLAGS: 00010202 (2.6.9-42.EL) > EIP is at __request_resource+0x24/0x41 > eax: 019b2001 ebx: c1ab0460 ecx: c036849c edx: c0004014 > esi: f02021ff edi: f0202000 ebp: f0202000 esp: c1a1de80 > ds: 007b es: 007b ss: 0068 > Process modprobe (pid: 1186, threadinfo=c1a1d000 task=c1a2c170) > Stack: c1ab0460 c036849c c1ab047c c012a27c dff4c800 00000200 000001ff 00000002 > dff4c800 c1a7dc24 c01f02a0 c1a7dc24 00000002 c1a7dc24 dff4c800 f885d270 > c01f033c c1a7dc00 dfce2400 dff4c800 f8858c73 00000001 c1a7dc00 c1a7dc00 > Call Trace: > [] __request_region+0x52/0x74 > [] pci_request_region+0x82/0xf2 > [] pci_request_regions+0x14/0x37 > [] snd_intel8x0_create+0x104/0x403 [snd_intel8x0] > [] snd_intel8x0_probe+0xca/0x21a [snd_intel8x0] > [] pci_device_probe_static+0x2a/0x3d > [] __pci_device_probe+0x1b/0x2c > [] pci_device_probe+0x1b/0x2d > [] bus_match+0x27/0x45 > [] driver_attach+0x37/0x66 > [] bus_add_driver+0x77/0x97 > [] driver_register+0x51/0x58 > [] pci_register_driver+0x85/0xa1 > [] alsa_card_intel8x0_init+0xa/0x39 [snd_intel8x0] > [] sys_init_module+0xe9/0x1d0 > [] syscall_call+0x7/0xb > Code: 84 36 c0 5b 89 d0 c3 57 89 c1 56 53 8b 7a 04 89 d3 8b 72 08 39 > fe 72 2c 3b 79 04 72 27 3b 71 08 77 22 8d 51 18 8b 02 85 c0 74 05 <39> > 70 04 76 0c 89 43 14 31 c0 89 1a 89 4b 10 eb 08 39 78 08 > <0>Fatal exception: panic in 5 seconds > Kernel panic - not syncing: Fatal exception > > > Thanks for the tip. > > On 12/13/06, Uwe Hermann wrote: > >> Hi Jon, >> >> you noted that you work on the Intel 82801DB: >> http://linuxbios.org/index.php?title=Supported_Chipsets_and_Devices&curid=1002&diff=3747&oldid=3739&rcid=1296 >> >> Please have a look at the 82801DBM code before, that's at the very least >> very similar, maybe it even already supports the 82801DB, too(?) >> >> >> Uwe. >> -- >> http://www.hermann-uwe.de | http://www.holsham-traders.de >> http://www.crazy-hacks.org | http://www.unmaintained-free-software.org >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.6 (GNU/Linux) >> >> iD8DBQFFgD4CXdVoV3jWIbQRAk0KAJ9J8VboHY4II7umgiNPmS1TIVDynQCfT+sh >> IcESivY9FsYMzj1HaUQdhP4= >> =JSxz >> -----END PGP SIGNATURE----- >> >> >> >> > > From yinghai.lu at amd.com Wed Dec 13 23:41:24 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Wed, 13 Dec 2006 14:41:24 -0800 Subject: [LinuxBIOS] DK8-HTX: 8131 B-bus IRQ problem? Message-ID: <5986589C150B2F49A46483AC44C7BCA49072DF@ssvlexmb2.amd.com> Check your mptable.c to try other irq for slot 4. Current it is (2+i)%4 Try (3+i)%4 and Try (0+i)%4 YH From svn at openbios.org Thu Dec 14 00:46:34 2006 From: svn at openbios.org (LinuxBIOS) Date: Wed, 13 Dec 2006 23:46:34 -0000 Subject: [LinuxBIOS] #63: make flashrom work on Iwill DK8-HTX Message-ID: <060.1c7329440e0182d10e759ab8648855af@openbios.org> #63: make flashrom work on Iwill DK8-HTX ---------------------------------------------------+------------------------ Reporter: stuge | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Keywords: flashrom iwill dk8-htx flash enable | Dependencies: Patchstatus: patch needs review | ---------------------------------------------------+------------------------ flashrom does not work after booting LinuxBIOS on the Iwill DK8-HTX board, according to mcqmcqmcq at fastmail.fm. -- Ticket URL: LinuxBIOS From jon.dufresne at gmail.com Thu Dec 14 00:46:42 2006 From: jon.dufresne at gmail.com (Jon Dufresne) Date: Wed, 13 Dec 2006 18:46:42 -0500 Subject: [LinuxBIOS] pc partitoin magic number not found? In-Reply-To: <4580803C.6090102@comcast.net> References: <20061213175306.GC19078@greenwood> <376ea3380612131213l13f1008tc4465381094a05cc@mail.gmail.com> <4580803C.6090102@comcast.net> Message-ID: <376ea3380612131546t4b0b1b58m758ae4e48e272dd5@mail.gmail.com> I did run a memtest and after 1 pass I received 0 errors. Should I run it longer than one pass? Jon On 12/13/06, Adam Talbot wrote: > Point filo to boot off of memtest. I would look at memory. Just an > idea, and its an easy test. > -Adam > > > Jon Dufresne wrote: > > Thanks, Uwe. > > > > I used the 82801dbm as a starting ground. I've already had to change a > > few things such as device IDs. > > > > I know something somewhere isn't right because I get a kernel panic > > anytime I modprobe a kernel module that relates to a device in the > > southbridge. Since I'm responding I'll post the kernel panic in case > > someone has an idea. This example is trying to bring up the sound > > device. If I remove all module loading during init, I can get to a > > single user prompt. > > > > Anyway thanks for the tip. > > > > Unable to handle kernel paging request at virtual address 019b2005 > > printing eip: > > *pde = 00000000 > > Oops: 0000 [#1] > > Modules linked in: snd_intel8x0 snd_ac97_codec snd_pcm_oss > > snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart > > snd_rawmidi snd_seq_device snd soundcore floppy ext3 jbd > > CPU: 0 > > EIP: 0060:[] Not tainted VLI > > EFLAGS: 00010202 (2.6.9-42.EL) > > EIP is at __request_resource+0x24/0x41 > > eax: 019b2001 ebx: c1ab0460 ecx: c036849c edx: c0004014 > > esi: f02021ff edi: f0202000 ebp: f0202000 esp: c1a1de80 > > ds: 007b es: 007b ss: 0068 > > Process modprobe (pid: 1186, threadinfo=c1a1d000 task=c1a2c170) > > Stack: c1ab0460 c036849c c1ab047c c012a27c dff4c800 00000200 000001ff 00000002 > > dff4c800 c1a7dc24 c01f02a0 c1a7dc24 00000002 c1a7dc24 dff4c800 f885d270 > > c01f033c c1a7dc00 dfce2400 dff4c800 f8858c73 00000001 c1a7dc00 c1a7dc00 > > Call Trace: > > [] __request_region+0x52/0x74 > > [] pci_request_region+0x82/0xf2 > > [] pci_request_regions+0x14/0x37 > > [] snd_intel8x0_create+0x104/0x403 [snd_intel8x0] > > [] snd_intel8x0_probe+0xca/0x21a [snd_intel8x0] > > [] pci_device_probe_static+0x2a/0x3d > > [] __pci_device_probe+0x1b/0x2c > > [] pci_device_probe+0x1b/0x2d > > [] bus_match+0x27/0x45 > > [] driver_attach+0x37/0x66 > > [] bus_add_driver+0x77/0x97 > > [] driver_register+0x51/0x58 > > [] pci_register_driver+0x85/0xa1 > > [] alsa_card_intel8x0_init+0xa/0x39 [snd_intel8x0] > > [] sys_init_module+0xe9/0x1d0 > > [] syscall_call+0x7/0xb > > Code: 84 36 c0 5b 89 d0 c3 57 89 c1 56 53 8b 7a 04 89 d3 8b 72 08 39 > > fe 72 2c 3b 79 04 72 27 3b 71 08 77 22 8d 51 18 8b 02 85 c0 74 05 <39> > > 70 04 76 0c 89 43 14 31 c0 89 1a 89 4b 10 eb 08 39 78 08 > > <0>Fatal exception: panic in 5 seconds > > Kernel panic - not syncing: Fatal exception > > > > > > Thanks for the tip. > > > > On 12/13/06, Uwe Hermann wrote: > > > >> Hi Jon, > >> > >> you noted that you work on the Intel 82801DB: > >> http://linuxbios.org/index.php?title=Supported_Chipsets_and_Devices&curid=1002&diff=3747&oldid=3739&rcid=1296 > >> > >> Please have a look at the 82801DBM code before, that's at the very least > >> very similar, maybe it even already supports the 82801DB, too(?) > >> > >> > >> Uwe. > >> -- > >> http://www.hermann-uwe.de | http://www.holsham-traders.de > >> http://www.crazy-hacks.org | http://www.unmaintained-free-software.org > >> > >> > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v1.4.6 (GNU/Linux) > >> > >> iD8DBQFFgD4CXdVoV3jWIbQRAk0KAJ9J8VboHY4II7umgiNPmS1TIVDynQCfT+sh > >> IcESivY9FsYMzj1HaUQdhP4= > >> =JSxz > >> -----END PGP SIGNATURE----- > >> > >> > >> > >> > > > > > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From svn at openbios.org Thu Dec 14 00:51:39 2006 From: svn at openbios.org (LinuxBIOS) Date: Wed, 13 Dec 2006 23:51:39 -0000 Subject: [LinuxBIOS] #63: make flashrom work on Iwill DK8-HTX In-Reply-To: <060.1c7329440e0182d10e759ab8648855af@openbios.org> References: <060.1c7329440e0182d10e759ab8648855af@openbios.org> Message-ID: <069.d2455d487d1656d1629a054cdc4447fa@openbios.org> #63: make flashrom work on Iwill DK8-HTX -----------------------+---------------------------------------------------- Reporter: stuge | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Resolution: | Keywords: flashrom iwill dk8-htx flash enable Dependencies: | Patchstatus: patch needs review -----------------------+---------------------------------------------------- Comment (by stuge): Signed-off-by: Mondrian Nuessle Acked-by: mcq -- Ticket URL: LinuxBIOS From mcqmcqmcq at fastmail.fm Thu Dec 14 00:53:57 2006 From: mcqmcqmcq at fastmail.fm (mcqmcqmcq at fastmail.fm) Date: Wed, 13 Dec 2006 15:53:57 -0800 Subject: [LinuxBIOS] DK8-HTX: 8131 B-bus IRQ problem? In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49072DF@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49072DF@ssvlexmb2.amd.com> Message-ID: <1166054037.1246.280368717@webmail.messagingengine.com> > Check your mptable.c to try other irq for slot 4. > Current it is (2+i)%4 > > Try (3+i)%4 and Try (0+i)%4 (0+i)%4==24 is the onboard eth1 -- using this generates a driver blowup during init and 0 interrupts come in on 24, pretty much ever (eth1 is down) (3+i)%4==27 is the onboard eth0 -- using this doesn't explode, but it appears that the 3w drivers only gets the interrupt it's waiting for when packets happen to come in on the ether (just a guess). The symptom is that the 3ware driver chunks along super-slow and takes about 2 minutes to actually probe in. But it does so _right_ and /proc/interrupts only shows 60 interrupts or so after it finally finishes. I'll try a board swap tomorrow and rule out a flaky/ringy wire. Happy to try anything else you can think of. I fly Friday morning, so that's our window. Also you'd have to let me know if you want to borrow one of my HTX cards by then too. Unrelated unimportant questions: mptable.c has all this stuff about 8132s when the chip on the board is actually an 8131 (or so says lspci in Iwill bios as well as all the Iwill literature; I haven't pulled off the heatsink to verify). I assume this doesn't matter? So what's the story on A/B naming? I thought that the A-bus was the one that everybody runs at 133 and the B was the one that had some problem that maxed it out at 100. The names appear to be used in the opposite sense in the mptable.c -- can somebody correct my misconception here? Thanks again, -mcq -- mcqmcqmcq at fastmail.fm -- http://www.fastmail.fm - mmm... Fastmail... From rminnich at gmail.com Thu Dec 14 00:57:50 2006 From: rminnich at gmail.com (ron minnich) Date: Wed, 13 Dec 2006 16:57:50 -0700 Subject: [LinuxBIOS] pc partitoin magic number not found? In-Reply-To: <376ea3380612131546t4b0b1b58m758ae4e48e272dd5@mail.gmail.com> References: <20061213175306.GC19078@greenwood> <376ea3380612131213l13f1008tc4465381094a05cc@mail.gmail.com> <4580803C.6090102@comcast.net> <376ea3380612131546t4b0b1b58m758ae4e48e272dd5@mail.gmail.com> Message-ID: <13426df10612131557g37dc0501pbef1bc0ea0b56514@mail.gmail.com> On 12/13/06, Jon Dufresne wrote: > I did run a memtest and after 1 pass I received 0 errors. Should I run > it longer than one pass? run it for 24 hours ... that's always a good test ron From yinghai.lu at amd.com Thu Dec 14 01:01:33 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Wed, 13 Dec 2006 16:01:33 -0800 Subject: [LinuxBIOS] DK8-HTX: 8131 B-bus IRQ problem? Message-ID: <5986589C150B2F49A46483AC44C7BCA49072E0@ssvlexmb2.amd.com> -----Original Message----- From: mcqmcqmcq at fastmail.fm [mailto:mcqmcqmcq at fastmail.fm] Sent: Wednesday, December 13, 2006 3:54 PM > mptable.c has all this stuff about 8132s when the chip on the board > is actually an 8131 (or so says lspci in Iwill bios as well as all the > Iwill literature; I haven't pulled off the heatsink to verify). I > assume this doesn't matter? Just a symbol, the GSI for 8132 is 7, and 4 for 8131. > So what's the story on A/B naming? I thought that the A-bus was the > one that everybody runs at 133 and the B was the one that had some > problem that maxed it out at 100. The names appear to be used in the > opposite sense in the mptable.c -- can somebody correct my > misconception here? If you have two pcix device on one, you need to downgrade the speed from 133 to 100 by jump, or... YH From svn at openbios.org Thu Dec 14 01:07:29 2006 From: svn at openbios.org (LinuxBIOS) Date: Thu, 14 Dec 2006 00:07:29 -0000 Subject: [LinuxBIOS] #64: Epia-M COM2 does not work Message-ID: <060.a609dec0afeb29e34d0fecae2e1212a7@openbios.org> #64: Epia-M COM2 does not work ---------------------------------+------------------------------------------ Reporter: stepan | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Keywords: | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ COM2 is not initialized correctly on the Via Epia-M. It looks like 2090 broke it: [http://tracker.linuxbios.org/trac/LinuxBIOS/changeset?old_path=trunk%2FLinuxBIOSv2%2Fsrc%2Fsuperio%2Fvia%2Fvt1211%2Fvt1211.c&old=2089&new_path=trunk%2FLinuxBIOSv2%2Fsrc%2Fsuperio%2Fvia%2Fvt1211%2Fvt1211.c&new=2090 diff of the superio changes in 2090] -- Ticket URL: LinuxBIOS From svn at openbios.org Thu Dec 14 01:15:09 2006 From: svn at openbios.org (LinuxBIOS) Date: Thu, 14 Dec 2006 00:15:09 -0000 Subject: [LinuxBIOS] #59: Support for SMSC FDC37M60X Super I/O In-Reply-To: <060.1a58a28db7ce63bcc4fe01aaa59fc30c@openbios.org> References: <060.1a58a28db7ce63bcc4fe01aaa59fc30c@openbios.org> Message-ID: <069.54b04f9157e6298224faae78838e1564@openbios.org> #59: Support for SMSC FDC37M60X Super I/O ----------------------------+----------------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: new Priority: major | Milestone: Component: code | Version: v2 Resolution: | Keywords: superio Dependencies: | Patchstatus: patch is ready to be committed ----------------------------+----------------------------------------------- Changes (by stepan): * patchstatus: patch needs review => patch is ready to be committed Comment: Acked-by: Stefan Reinauer -- Ticket URL: LinuxBIOS From svn at openbios.org Thu Dec 14 01:22:49 2006 From: svn at openbios.org (LinuxBIOS) Date: Thu, 14 Dec 2006 00:22:49 -0000 Subject: [LinuxBIOS] #65: Unify SuperIO code? Message-ID: <060.d75671ede28f17a0bcf95c4d046fcff5@openbios.org> #65: Unify SuperIO code? ---------------------------------+------------------------------------------ Reporter: stepan | Owner: somebody Type: enhancement | Status: new Priority: minor | Milestone: Cosmetic fixes Component: code | Version: v2 Keywords: | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ One thing I've been noticing in the current superio implementations: A lot of differences come from having the part names used in variable and macro names. {{{ #define FDC37M60X_CONFIG_REG_CC 0x02 }}} Maybe we should change that to some unique names {{{ #define SUPERIO_CONFIG_REG_CC 0x02 }}} * Those names are usually file local only, so name clashes wont be a problem * They are the same for most (all?) SuperIOs? Doing so (maybe with function names as well?) would unify the superio interface, or at least make diffing the code of different devices a bit easier.. -- Ticket URL: LinuxBIOS From svn at openbios.org Thu Dec 14 01:31:39 2006 From: svn at openbios.org (svn at openbios.org) Date: Thu, 14 Dec 2006 00:31:39 -0000 Subject: [LinuxBIOS] r2521 - trunk/LinuxBIOSv2/targets/iwill/dk8_htx Message-ID: Author: stepan Date: 2006-12-14 01:31:38 +0100 (Thu, 14 Dec 2006) New Revision: 2521 Modified: trunk/LinuxBIOSv2/targets/iwill/dk8_htx/Config-abuild.lb Log: This is a typo that went into one of the abuild files. it will break abuild on this board for everyone but me. Closes #58 Signed-off-by: Stefan Reinauer Acked-by: Stefan Reinauer (trivial patch) Modified: trunk/LinuxBIOSv2/targets/iwill/dk8_htx/Config-abuild.lb =================================================================== --- trunk/LinuxBIOSv2/targets/iwill/dk8_htx/Config-abuild.lb 2006-12-05 15:27:46 UTC (rev 2520) +++ trunk/LinuxBIOSv2/targets/iwill/dk8_htx/Config-abuild.lb 2006-12-14 00:31:38 UTC (rev 2521) @@ -13,13 +13,13 @@ option USE_FALLBACK_IMAGE=0 option ROM_IMAGE_SIZE=0x17000 option LINUXBIOS_EXTRA_VERSION=".0-normal" - payload /home/stepan/svn/LinuxBIOSv2/util/abuild/LinuxBIOS-payloads/payloads/default/filo-0.5.0.elf + payload PAYLOAD end romimage "fallback" option USE_FALLBACK_IMAGE=1 option ROM_IMAGE_SIZE=0x17000 option LINUXBIOS_EXTRA_VERSION=".0-fallback" - payload /home/stepan/svn/LinuxBIOSv2/util/abuild/LinuxBIOS-payloads/payloads/default/filo-0.5.0.elf + payload PAYLOAD end buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" From svn at openbios.org Thu Dec 14 01:34:14 2006 From: svn at openbios.org (LinuxBIOS) Date: Thu, 14 Dec 2006 00:34:14 -0000 Subject: [LinuxBIOS] #54: flashrom: Add install target to Makefile In-Reply-To: <060.8eb3e6585df9578c7a97e1cc3a979f38@openbios.org> References: <060.8eb3e6585df9578c7a97e1cc3a979f38@openbios.org> Message-ID: <069.18efd84b909012d8528eea06a8ffc68b@openbios.org> #54: flashrom: Add install target to Makefile ----------------------------+----------------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: new Priority: minor | Milestone: Enhance the flashrom utility Component: flashrom | Version: Resolution: | Keywords: Dependencies: | Patchstatus: patch is ready to be committed ----------------------------+----------------------------------------------- Changes (by stepan): * patchstatus: patch needs review => patch is ready to be committed Comment: Acked-by: Stefan Reinauer -- Ticket URL: LinuxBIOS From svn at openbios.org Thu Dec 14 01:35:34 2006 From: svn at openbios.org (LinuxBIOS) Date: Thu, 14 Dec 2006 00:35:34 -0000 Subject: [LinuxBIOS] #61: Add mtrr support for pentium m cpus In-Reply-To: <060.03c40551c978f5758a2002cd5ebd9157@openbios.org> References: <060.03c40551c978f5758a2002cd5ebd9157@openbios.org> Message-ID: <069.fb8bcb53d7335d5e40f8525580d88079@openbios.org> #61: Add mtrr support for pentium m cpus ------------------------------------------------------+--------------------- Reporter: Jon Dufresne | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Resolution: | Keywords: Dependencies: | Patchstatus: patch is ready to be committed ------------------------------------------------------+--------------------- Changes (by stepan): * patchstatus: patch needs review => patch is ready to be committed Comment: Good spot! Acked-by: Stefan Reinauer -- Ticket URL: LinuxBIOS From svn at openbios.org Thu Dec 14 01:40:10 2006 From: svn at openbios.org (svn at openbios.org) Date: Thu, 14 Dec 2006 00:40:10 -0000 Subject: [LinuxBIOS] r2522 - in trunk/LinuxBIOSv2/src/cpu/intel: model_69x model_6dx model_6xx Message-ID: Author: stepan Date: 2006-12-14 01:40:09 +0100 (Thu, 14 Dec 2006) New Revision: 2522 Modified: trunk/LinuxBIOSv2/src/cpu/intel/model_69x/model_69x_init.c trunk/LinuxBIOSv2/src/cpu/intel/model_6dx/model_6dx_init.c trunk/LinuxBIOSv2/src/cpu/intel/model_6xx/model_6xx_init.c Log: Add mtrr support for pentium m cpus For cache to work the x86_setup_mtrrs() must be called. Closes #61 Signed-off-by: Jon Dufresne Acked-by: Stefan Reinauer Modified: trunk/LinuxBIOSv2/src/cpu/intel/model_69x/model_69x_init.c =================================================================== --- trunk/LinuxBIOSv2/src/cpu/intel/model_69x/model_69x_init.c 2006-12-14 00:31:38 UTC (rev 2521) +++ trunk/LinuxBIOSv2/src/cpu/intel/model_69x/model_69x_init.c 2006-12-14 00:40:09 UTC (rev 2522) @@ -24,6 +24,7 @@ { /* Turn on caching if we haven't already */ x86_enable_cache(); + x86_setup_mtrrs(36); x86_mtrr_check(); /* Update the microcode */ Modified: trunk/LinuxBIOSv2/src/cpu/intel/model_6dx/model_6dx_init.c =================================================================== --- trunk/LinuxBIOSv2/src/cpu/intel/model_6dx/model_6dx_init.c 2006-12-14 00:31:38 UTC (rev 2521) +++ trunk/LinuxBIOSv2/src/cpu/intel/model_6dx/model_6dx_init.c 2006-12-14 00:40:09 UTC (rev 2522) @@ -24,6 +24,7 @@ { /* Turn on caching if we haven't already */ x86_enable_cache(); + x86_setup_mtrrs(36); x86_mtrr_check(); /* Update the microcode */ Modified: trunk/LinuxBIOSv2/src/cpu/intel/model_6xx/model_6xx_init.c =================================================================== --- trunk/LinuxBIOSv2/src/cpu/intel/model_6xx/model_6xx_init.c 2006-12-14 00:31:38 UTC (rev 2521) +++ trunk/LinuxBIOSv2/src/cpu/intel/model_6xx/model_6xx_init.c 2006-12-14 00:40:09 UTC (rev 2522) @@ -30,6 +30,7 @@ { /* Turn on caching if we haven't already */ x86_enable_cache(); + x86_setup_mtrrs(36); x86_mtrr_check(); /* Update the microcode */ From svn at openbios.org Thu Dec 14 01:43:50 2006 From: svn at openbios.org (svn at openbios.org) Date: Thu, 14 Dec 2006 00:43:50 -0000 Subject: [LinuxBIOS] r2523 - trunk/LinuxBIOSv2/src/southbridge/intel/i82801ca Message-ID: Author: stepan Date: 2006-12-14 01:43:50 +0100 (Thu, 14 Dec 2006) New Revision: 2523 Modified: trunk/LinuxBIOSv2/src/southbridge/intel/i82801ca/i82801ca_lpc.c Log: In src/southbridge/intel/i82801ca, first the smbus registers are mapped at i/o space offset 0x1000, and later is the acpi registers also mapped at 0x1000. This patch fixes this behavior. Closes #44 Signed-off-by: Acked-by: Stefan Reinauer Modified: trunk/LinuxBIOSv2/src/southbridge/intel/i82801ca/i82801ca_lpc.c =================================================================== --- trunk/LinuxBIOSv2/src/southbridge/intel/i82801ca/i82801ca_lpc.c 2006-12-14 00:40:09 UTC (rev 2522) +++ trunk/LinuxBIOSv2/src/southbridge/intel/i82801ca/i82801ca_lpc.c 2006-12-14 00:43:50 UTC (rev 2523) @@ -121,8 +121,8 @@ // Prevent LPC disabling, enable parity errors, and SERR# (System Error) pci_write_config16(dev, PCI_COMMAND, 0x014f); - // Set ACPI base address to 0x1000 (I/O space) - pci_write_config32(dev, PMBASE, 0x00001001); + // Set ACPI base address to 0x1100 (I/O space) + pci_write_config32(dev, PMBASE, 0x00001101); // Enable ACPI I/O and power management pci_write_config8(dev, ACPI_CNTL, 0x10); From svn at openbios.org Thu Dec 14 01:46:33 2006 From: svn at openbios.org (LinuxBIOS) Date: Thu, 14 Dec 2006 00:46:33 -0000 Subject: [LinuxBIOS] #62: Wrong variable causes a compile error In-Reply-To: <060.059f40c036f2712b5793018f74558faf@openbios.org> References: <060.059f40c036f2712b5793018f74558faf@openbios.org> Message-ID: <069.dbb6ab3974be35349d8f8c0b07c51d74@openbios.org> #62: Wrong variable causes a compile error ------------------------------------------------------+--------------------- Reporter: Jon Dufresne | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Resolution: | Keywords: Dependencies: | Patchstatus: patch needs review ------------------------------------------------------+--------------------- Comment (by stepan): Weird. Any idea why this did not break the build of digitallogic/adl855pc? -- Ticket URL: LinuxBIOS From svn at openbios.org Thu Dec 14 01:50:21 2006 From: svn at openbios.org (LinuxBIOS) Date: Thu, 14 Dec 2006 00:50:21 -0000 Subject: [LinuxBIOS] #63: make flashrom work on Iwill DK8-HTX In-Reply-To: <060.1c7329440e0182d10e759ab8648855af@openbios.org> References: <060.1c7329440e0182d10e759ab8648855af@openbios.org> Message-ID: <069.cc73432ef026854a5885d446bf11f319@openbios.org> #63: make flashrom work on Iwill DK8-HTX -----------------------+---------------------------------------------------- Reporter: stuge | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Resolution: | Keywords: flashrom iwill dk8-htx flash enable Dependencies: | Patchstatus: patch is ready to be committed -----------------------+---------------------------------------------------- Changes (by stepan): * patchstatus: patch needs review => patch is ready to be committed -- Ticket URL: LinuxBIOS From svn at openbios.org Thu Dec 14 01:59:44 2006 From: svn at openbios.org (svn at openbios.org) Date: Thu, 14 Dec 2006 00:59:44 -0000 Subject: [LinuxBIOS] r2524 - trunk/LinuxBIOSv2/util/flashrom Message-ID: Author: uwe Date: 2006-12-14 01:59:41 +0100 (Thu, 14 Dec 2006) New Revision: 2524 Modified: trunk/LinuxBIOSv2/util/flashrom/Makefile Log: Add an install target to the flashrom Makefile which installs flashrom into /usr/local/bin. Closes #54. Signed-off-by: Uwe Hermann Acked-by: Stefan Reinauer Modified: trunk/LinuxBIOSv2/util/flashrom/Makefile =================================================================== --- trunk/LinuxBIOSv2/util/flashrom/Makefile 2006-12-14 00:43:50 UTC (rev 2523) +++ trunk/LinuxBIOSv2/util/flashrom/Makefile 2006-12-14 00:59:41 UTC (rev 2524) @@ -8,6 +8,8 @@ CC = gcc STRIP = strip +INSTALL = /usr/bin/install +PREFIX = /usr/local #CFLAGS = -O2 -g -Wall -Werror CFLAGS = -Os -Wall -Werror -DDISABLE_DOC # -DTS5300 LDFLAGS = -lpci -lz -static @@ -45,6 +47,9 @@ rm -f .test.c .test; exit 1) @rm -f .test.c .test +install: $(PROGRAM) + $(INSTALL) flashrom $(PREFIX)/bin + .PHONY: all clean distclean dep pciutils -include .dependencies From svn at openbios.org Thu Dec 14 02:03:25 2006 From: svn at openbios.org (LinuxBIOS) Date: Thu, 14 Dec 2006 01:03:25 -0000 Subject: [LinuxBIOS] #62: Wrong variable causes a compile error In-Reply-To: <060.059f40c036f2712b5793018f74558faf@openbios.org> References: <060.059f40c036f2712b5793018f74558faf@openbios.org> Message-ID: <069.6eece8c57785e1bb8eaa94e714d14b0d@openbios.org> #62: Wrong variable causes a compile error ------------------------------------------------------+--------------------- Reporter: Jon Dufresne | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Resolution: | Keywords: Dependencies: | Patchstatus: patch needs review ------------------------------------------------------+--------------------- Comment (by anonymous): Replying to [comment:1 stepan]: > Weird. Any idea why this did not break the build of digitallogic/adl855pc? All the pci devices under the southbridge are commented out in the digitallogic/adl855pc/Config.lb if you uncomment them, it will break the build. Since they are commented out, nothing refers to southbridge_intel_i82801dbm_ops. -- Ticket URL: LinuxBIOS From svn at openbios.org Thu Dec 14 02:06:06 2006 From: svn at openbios.org (LinuxBIOS) Date: Thu, 14 Dec 2006 01:06:06 -0000 Subject: [LinuxBIOS] #44: ACPI collides with smbus/ide on i82801ca southbridge In-Reply-To: <060.fc34b4994817bf37b64beee69e99412c@openbios.org> References: <060.fc34b4994817bf37b64beee69e99412c@openbios.org> Message-ID: <069.06986a05786e533b19c5db9b5ad7bf83@openbios.org> #44: ACPI collides with smbus/ide on i82801ca southbridge ---------------------------------+------------------------------------------ Reporter: chn at virtutech.se | Owner: somebody Type: defect | Status: closed Priority: minor | Milestone: Component: code | Version: v2 Resolution: fixed | Keywords: Dependencies: | Patchstatus: patch has been committed ---------------------------------+------------------------------------------ Changes (by uwe): * patchstatus: patch needs review => patch has been committed -- Ticket URL: LinuxBIOS From talbotx at comcast.net Thu Dec 14 02:41:17 2006 From: talbotx at comcast.net (Adam Talbot) Date: Wed, 13 Dec 2006 17:41:17 -0800 Subject: [LinuxBIOS] pc partitoin magic number not found? In-Reply-To: <376ea3380612131546t4b0b1b58m758ae4e48e272dd5@mail.gmail.com> References: <20061213175306.GC19078@greenwood> <376ea3380612131213l13f1008tc4465381094a05cc@mail.gmail.com> <4580803C.6090102@comcast.net> <376ea3380612131546t4b0b1b58m758ae4e48e272dd5@mail.gmail.com> Message-ID: <4580ABBD.4050308@comcast.net> Thats good, its just a simple test to see if memory is set up correctly. -Adam Jon Dufresne wrote: > I did run a memtest and after 1 pass I received 0 errors. Should I run > it longer than one pass? > > Jon > > On 12/13/06, Adam Talbot wrote: >> Point filo to boot off of memtest. I would look at memory. Just an >> idea, and its an easy test. >> -Adam >> >> >> Jon Dufresne wrote: >> > Thanks, Uwe. >> > >> > I used the 82801dbm as a starting ground. I've already had to change a >> > few things such as device IDs. >> > >> > I know something somewhere isn't right because I get a kernel panic >> > anytime I modprobe a kernel module that relates to a device in the >> > southbridge. Since I'm responding I'll post the kernel panic in case >> > someone has an idea. This example is trying to bring up the sound >> > device. If I remove all module loading during init, I can get to a >> > single user prompt. >> > >> > Anyway thanks for the tip. >> > >> > Unable to handle kernel paging request at virtual address 019b2005 >> > printing eip: >> > *pde = 00000000 >> > Oops: 0000 [#1] >> > Modules linked in: snd_intel8x0 snd_ac97_codec snd_pcm_oss >> > snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart >> > snd_rawmidi snd_seq_device snd soundcore floppy ext3 jbd >> > CPU: 0 >> > EIP: 0060:[] Not tainted VLI >> > EFLAGS: 00010202 (2.6.9-42.EL) >> > EIP is at __request_resource+0x24/0x41 >> > eax: 019b2001 ebx: c1ab0460 ecx: c036849c edx: c0004014 >> > esi: f02021ff edi: f0202000 ebp: f0202000 esp: c1a1de80 >> > ds: 007b es: 007b ss: 0068 >> > Process modprobe (pid: 1186, threadinfo=c1a1d000 task=c1a2c170) >> > Stack: c1ab0460 c036849c c1ab047c c012a27c dff4c800 00000200 >> 000001ff 00000002 >> > dff4c800 c1a7dc24 c01f02a0 c1a7dc24 00000002 c1a7dc24 >> dff4c800 f885d270 >> > c01f033c c1a7dc00 dfce2400 dff4c800 f8858c73 00000001 >> c1a7dc00 c1a7dc00 >> > Call Trace: >> > [] __request_region+0x52/0x74 >> > [] pci_request_region+0x82/0xf2 >> > [] pci_request_regions+0x14/0x37 >> > [] snd_intel8x0_create+0x104/0x403 [snd_intel8x0] >> > [] snd_intel8x0_probe+0xca/0x21a [snd_intel8x0] >> > [] pci_device_probe_static+0x2a/0x3d >> > [] __pci_device_probe+0x1b/0x2c >> > [] pci_device_probe+0x1b/0x2d >> > [] bus_match+0x27/0x45 >> > [] driver_attach+0x37/0x66 >> > [] bus_add_driver+0x77/0x97 >> > [] driver_register+0x51/0x58 >> > [] pci_register_driver+0x85/0xa1 >> > [] alsa_card_intel8x0_init+0xa/0x39 [snd_intel8x0] >> > [] sys_init_module+0xe9/0x1d0 >> > [] syscall_call+0x7/0xb >> > Code: 84 36 c0 5b 89 d0 c3 57 89 c1 56 53 8b 7a 04 89 d3 8b 72 08 39 >> > fe 72 2c 3b 79 04 72 27 3b 71 08 77 22 8d 51 18 8b 02 85 c0 74 05 <39> >> > 70 04 76 0c 89 43 14 31 c0 89 1a 89 4b 10 eb 08 39 78 08 >> > <0>Fatal exception: panic in 5 seconds >> > Kernel panic - not syncing: Fatal exception >> > >> > >> > Thanks for the tip. >> > >> > On 12/13/06, Uwe Hermann wrote: >> > >> >> Hi Jon, >> >> >> >> you noted that you work on the Intel 82801DB: >> >> >> http://linuxbios.org/index.php?title=Supported_Chipsets_and_Devices&curid=1002&diff=3747&oldid=3739&rcid=1296 >> >> >> >> >> Please have a look at the 82801DBM code before, that's at the very >> least >> >> very similar, maybe it even already supports the 82801DB, too(?) >> >> >> >> >> >> Uwe. >> >> -- >> >> http://www.hermann-uwe.de | http://www.holsham-traders.de >> >> http://www.crazy-hacks.org | >> http://www.unmaintained-free-software.org >> >> >> >> >> >> -----BEGIN PGP SIGNATURE----- >> >> Version: GnuPG v1.4.6 (GNU/Linux) >> >> >> >> iD8DBQFFgD4CXdVoV3jWIbQRAk0KAJ9J8VboHY4II7umgiNPmS1TIVDynQCfT+sh >> >> IcESivY9FsYMzj1HaUQdhP4= >> >> =JSxz >> >> -----END PGP SIGNATURE----- >> >> >> >> >> >> >> >> >> > >> > >> >> >> -- >> linuxbios mailing list >> linuxbios at linuxbios.org >> http://www.openbios.org/mailman/listinfo/linuxbios >> > From eswierk at arastra.com Thu Dec 14 05:36:56 2006 From: eswierk at arastra.com (Ed Swierk) Date: Wed, 13 Dec 2006 20:36:56 -0800 Subject: [LinuxBIOS] More MCP55 hacking In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA49072D2@ssvlexmb2.amd.com> Message-ID: Thanks for the help so far. After hacking on mptable.c and irq_tables.c, there are definite signs of progress: interrupts are being routed from USB and Ethernet devices. One code change I had to make outside the motherboard tree was to set bit 1 of register 0x74 in the LPC device (in ck804_lpc.c:lpc_common_init()). Without it, the APIC BAR is not exposed in register 0x14, which causes setup_ioapic() to be passed 0x0 instead of 0xfec00000. I hope this isn't the cause of my next issue: Now, after Linux says "Write protecting the kernel read-only data", it just hangs; the next thing it should do is run init. A few clues: - after the hang, I still see messages from the USB driver when I plug or unplug a device, so the serial console is apparently still alive; - if I pass the "noapic" kernel parameter, the kernel doesn't hang (but of course interrupts don't get configured properly); - browsing the kernel source code, the only things that are supposed happen between that last message and running init are (1) calling pageattr.c:global_flush_tlb(), (2) calling mempolicy.c:numa_default_policy(), and (3) opening /dev/console. I've attached a boot log. As always, any help would be appreciated. --Ed -------------- next part -------------- LinuxBIOS-2.0.0-FILO Wed Dec 13 19:23:14 PST 2006 starting... Enabling routing table for node 00 done. Enabling UP settings coherent_ht_finalize done core0 started: started ap apicid: 01 SBLink=00 NC node|link=00 SMBus controller enabled Ram1.00 setting up CPU00 northbridge registers done. Ram2.00 Unbuffered 333Mhz 333Mhz RAM: 0x00080000 KB Ram3 dimm_mask = 00000001 x4_mask = 00000000 x16_mask = 00000000 single_rank_mask = 00000001 ODC = 00111222 Addr Timing= 00202220 Initializing memory: done Setting variable MTRR 02, base: 0000MB, range: 0200MB, type WB DQS Training:RcvrEn:Pass1: 00 CTLRMaxDelay=17 done DQS Training:DQSPos: 00 done DQS Training:RcvrEn:Pass2: 00 CTLRMaxDelay=49 done DQS Training:tsc[00]=000000001126fc46 DQS Training:tsc[01]=00000000123f9ed2 DQS Training:tsc[02]=0000000012447da4 DQS Training:tsc[03]=00000000493b4484 DQS Training:tsc[04]=000000004b86fcdd Ram4 v_esp=000ceecc testx = 5a5a5a5a Copying data from cache to ram -- switching to use ram as stack... Done testx = 5a5a5a5a Disabling cache as ram now Clearing initial memory region: Done Copying LinuxBIOS to ram. src=fffe0000 dst=00004000 linxbios_ram.nrv2b length = 00008a6c linxbios_ram.bin length = 00013ae4 Jumping to LinuxBIOS. LinuxBIOS-2.0.0-FILO Wed Dec 13 19:23:14 PST 2006 booting... Enumerating buses... scan_static_bus for Root Device APIC_CLUSTER: 0 enabled PCI_DOMAIN: 0000 enabled APIC_CLUSTER: 0 scanning... PCI: 00:18.3 siblings=1 CPU: APIC: 00 enabled malloc Enter, size 668, free_mem_ptr 0003a000 malloc 0x0003a000 CPU: APIC: 01 enabled PCI_DOMAIN: 0000 scanning... PCI: pci_scan_bus for bus 00 PCI: 00:18.0 [1022/1100] bus ops PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] ops PCI: 00:18.3 [1022/1103] enabled PCI: devfn 0xc4, bad id 0xffffffff PCI: devfn 0xc5, bad id 0xffffffff PCI: devfn 0xc6, bad id 0xffffffff PCI: devfn 0xc7, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0003a29c malloc 0x0003a29c PCI: 00:19.0 [10de/0372] enabled malloc Enter, size 668, free_mem_ptr 0003a538 malloc 0x0003a538 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 00:1a.0 subbordinate bus PCI Express PCI: 00:1a.0 [10de/0376] enabled malloc Enter, size 668, free_mem_ptr 0003a7d4 malloc 0x0003a7d4 PCI: 00:1b.0 [10de/0374] bus ops PCI: 00:1b.0 [10de/0374] enabled PCI: devfn 0xe0, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0003aa70 malloc 0x0003aa70 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 00:1d.0 subbordinate bus PCI Express PCI: 00:1d.0 [10de/0378] enabled malloc Enter, size 668, free_mem_ptr 0003ad0c malloc 0x0003ad0c Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 00:1e.0 subbordinate bus PCI Express PCI: 00:1e.0 [10de/0375] enabled malloc Enter, size 668, free_mem_ptr 0003afa8 malloc 0x0003afa8 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 00:1f.0 subbordinate bus PCI Express PCI: 00:1f.0 [10de/0377] enabled Capability: 0x08 @ 0x44 flags: 0x01e1 Collapsing PCI: 01:01.0 [10de/02f4] Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 flags: 0xa800 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 flags: 0xa800 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 flags: 0xa800 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x08 @ 0x44 flags: 0x01f0 Collapsing PCI: 01:10.0 [10de/0369] PCI: 01:00.0 [10de/02f4] enabled Capability: 0x08 @ 0x44 flags: 0x01e0 PCI: 01:01.0 count: 000f static_count: 0001 PCI: 01:01.0 [10de/02f4] enabled next_unitid: 0010 malloc Enter, size 668, free_mem_ptr 0003b244 malloc 0x0003b244 PCI: 01:00.0 [10de/0369] ops PCI: 01:00.0 [10de/0369] enabled Capability: 0x08 @ 0x44 flags: 0x01e0 PCI: 01:10.0 count: 000f static_count: 0001 PCI: 01:10.0 [10de/0369] enabled next_unitid: 001f PCI: pci_scan_bus for bus 01 PCI: devfn 0x0, bad id 0xffffffff PCI: 01:01.0 [10de/02f4] enabled malloc Enter, size 668, free_mem_ptr 0003b4e0 malloc 0x0003b4e0 PCI: 01:01.1 [10de/02fa] enabled malloc Enter, size 668, free_mem_ptr 0003b77c malloc 0x0003b77c PCI: 01:01.2 [10de/02fe] enabled malloc Enter, size 668, free_mem_ptr 0003ba18 malloc 0x0003ba18 PCI: 01:01.3 [10de/02f8] enabled malloc Enter, size 668, free_mem_ptr 0003bcb4 malloc 0x0003bcb4 PCI: 01:01.4 [10de/02f9] enabled malloc Enter, size 668, free_mem_ptr 0003bf50 malloc 0x0003bf50 PCI: 01:01.5 [10de/02ff] enabled malloc Enter, size 668, free_mem_ptr 0003c1ec malloc 0x0003c1ec PCI: 01:01.6 [10de/027f] enabled malloc Enter, size 668, free_mem_ptr 0003c488 malloc 0x0003c488 PCI: 01:01.7 [10de/027e] enabled PCI: devfn 0x10, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0003c724 malloc 0x0003c724 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 01:03.0 subbordinate bus PCI Express PCI: 01:03.0 [10de/02fc] enabled malloc Enter, size 668, free_mem_ptr 0003c9c0 malloc 0x0003c9c0 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 01:04.0 subbordinate bus PCI Express PCI: 01:04.0 [10de/02fd] enabled malloc Enter, size 668, free_mem_ptr 0003cc5c malloc 0x0003cc5c Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 01:05.0 subbordinate bus PCI Express PCI: 01:05.0 [10de/02fb] enabled PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: 01:10.0 [10de/0369] enabled malloc Enter, size 668, free_mem_ptr 0003cef8 malloc 0x0003cef8 PCI: 01:11.0 [10de/0360] bus ops PCI: 01:11.0 [10de/0360] enabled malloc Enter, size 668, free_mem_ptr 0003d194 malloc 0x0003d194 PCI: 01:11.1 [10de/0368] bus ops PCI: 01:11.1 [10de/0368] enabled malloc Enter, size 668, free_mem_ptr 0003d430 malloc 0x0003d430 PCI: 01:11.2 [10de/036a] enabled PCI: devfn 0x8b, bad id 0xffffffff PCI: devfn 0x8c, bad id 0xffffffff PCI: devfn 0x8d, bad id 0xffffffff PCI: devfn 0x8e, bad id 0xffffffff PCI: devfn 0x8f, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0003d6cc malloc 0x0003d6cc PCI: 01:12.0 [10de/036c] ops PCI: 01:12.0 [10de/036c] enabled malloc Enter, size 668, free_mem_ptr 0003d968 malloc 0x0003d968 PCI: 01:12.1 [10de/036d] ops PCI: 01:12.1 [10de/036d] enabled PCI: devfn 0x92, bad id 0xffffffff PCI: devfn 0x93, bad id 0xffffffff PCI: devfn 0x94, bad id 0xffffffff PCI: devfn 0x95, bad id 0xffffffff PCI: devfn 0x96, bad id 0xffffffff PCI: devfn 0x97, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0003dc04 malloc 0x0003dc04 PCI: 01:14.0 [10de/036e] ops PCI: 01:14.0 [10de/036e] enabled malloc Enter, size 668, free_mem_ptr 0003dea0 malloc 0x0003dea0 PCI: 01:15.0 [10de/037f] ops PCI: 01:15.0 [10de/037f] enabled malloc Enter, size 668, free_mem_ptr 0003e13c malloc 0x0003e13c PCI: 01:15.1 [10de/037f] ops PCI: 01:15.1 [10de/037f] enabled malloc Enter, size 668, free_mem_ptr 0003e3d8 malloc 0x0003e3d8 PCI: 01:15.2 [10de/037f] ops PCI: 01:15.2 [10de/037f] enabled PCI: devfn 0xab, bad id 0xffffffff PCI: devfn 0xac, bad id 0xffffffff PCI: devfn 0xad, bad id 0xffffffff PCI: devfn 0xae, bad id 0xffffffff PCI: devfn 0xaf, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0003e674 malloc 0x0003e674 PCI: 01:16.0 [10de/0370] bus ops PCI: 01:16.0 [10de/0370] enabled malloc Enter, size 668, free_mem_ptr 0003e910 malloc 0x0003e910 PCI: 01:16.1 [10de/0371] ops PCI: 01:16.1 [10de/0371] enabled PCI: devfn 0xb2, bad id 0xffffffff PCI: devfn 0xb3, bad id 0xffffffff PCI: devfn 0xb4, bad id 0xffffffff PCI: devfn 0xb5, bad id 0xffffffff PCI: devfn 0xb6, bad id 0xffffffff PCI: devfn 0xb7, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0003ebac malloc 0x0003ebac PCI: 01:18.0 [10de/0372] enabled malloc Enter, size 668, free_mem_ptr 0003ee48 malloc 0x0003ee48 PCI: 01:19.0 [10de/0372] enabled malloc Enter, size 668, free_mem_ptr 0003f0e4 malloc 0x0003f0e4 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 01:1a.0 subbordinate bus PCI Express PCI: 01:1a.0 [10de/0376] enabled malloc Enter, size 668, free_mem_ptr 0003f380 malloc 0x0003f380 PCI: 01:1b.0 [10de/0374] bus ops PCI: 01:1b.0 [10de/0374] enabled PCI: devfn 0xe0, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0003f61c malloc 0x0003f61c Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 01:1d.0 subbordinate bus PCI Express PCI: 01:1d.0 [10de/0378] enabled malloc Enter, size 668, free_mem_ptr 0003f8b8 malloc 0x0003f8b8 Capability: 0x07 @ 0x40 Capability: 0x07 @ 0x48 Capability: 0x07 @ 0x50 Capability: 0x07 @ 0x60 Capability: 0x07 @ 0x80 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x40 Capability: 0x08 @ 0x48 Capability: 0x08 @ 0x50 Capability: 0x08 @ 0x60 Capability: 0x08 @ 0x80 Capability: 0x10 @ 0x40 Capability: 0x10 @ 0x48 Capability: 0x10 @ 0x50 Capability: 0x10 @ 0x60 Capability: 0x10 @ 0x80 PCI: 01:1e.0 subbordinate bus PCI Express PCI: 01:1e.0 [10de/0375] enabled do_pci_scan_bridge for PCI: 01:03.0 PCI: pci_scan_bus for bus 02 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=002 do_pci_scan_bridge returns max 2 do_pci_scan_bridge for PCI: 01:04.0 PCI: pci_scan_bus for bus 03 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=003 do_pci_scan_bridge returns max 3 do_pci_scan_bridge for PCI: 01:05.0 PCI: pci_scan_bus for bus 04 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=004 do_pci_scan_bridge returns max 4 scan_static_bus for PCI: 01:11.0 scan_static_bus for PCI: 01:11.0 done scan_static_bus for PCI: 01:11.1 scan_static_bus for PCI: 01:11.1 done do_pci_scan_bridge for PCI: 01:16.0 PCI: pci_scan_bus for bus 05 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0003fb54 malloc 0x0003fb54 PCI: 05:09.0 [1106/3044] enabled PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=005 do_pci_scan_bridge returns max 5 do_pci_scan_bridge for PCI: 01:1a.0 PCI: pci_scan_bus for bus 06 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=006 do_pci_scan_bridge returns max 6 do_pci_scan_bridge for PCI: 01:1b.0 PCI: pci_scan_bus for bus 07 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=007 do_pci_scan_bridge returns max 7 do_pci_scan_bridge for PCI: 01:1d.0 PCI: pci_scan_bus for bus 08 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=008 do_pci_scan_bridge returns max 8 do_pci_scan_bridge for PCI: 01:1e.0 PCI: pci_scan_bus for bus 09 PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=009 do_pci_scan_bridge returns max 9 PCI: pci_scan_bus returning with max=009 do_pci_scan_bridge for PCI: 00:1a.0 PCI: pci_scan_bus for bus 0a PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=00a do_pci_scan_bridge returns max 10 do_pci_scan_bridge for PCI: 00:1b.0 PCI: pci_scan_bus for bus 0b PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=00b do_pci_scan_bridge returns max 11 do_pci_scan_bridge for PCI: 00:1d.0 PCI: pci_scan_bus for bus 0c PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=00c do_pci_scan_bridge returns max 12 do_pci_scan_bridge for PCI: 00:1e.0 PCI: pci_scan_bus for bus 0d PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=00d do_pci_scan_bridge returns max 13 do_pci_scan_bridge for PCI: 00:1f.0 PCI: pci_scan_bus for bus 0e PCI: devfn 0x0, bad id 0xffffffff PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff PCI: devfn 0x60, bad id 0xffffffff PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x78, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: devfn 0x90, bad id 0xffffffff PCI: devfn 0x98, bad id 0xffffffff PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff PCI: pci_scan_bus returning with max=00e do_pci_scan_bridge returns max 14 PCI: pci_scan_bus returning with max=00e PCI_DOMAIN: 0000 passpw: enabled scan_static_bus for Root Device done done Allocating resources... Reading resources... Root Device compute_allocate_io: base: 00000400 size: 00000000 align: 0 gran: 0 Root Device read_resources bus 0 link: 0 PCI_DOMAIN: 0000 read_resources bus 0 link: 0 PCI: 00:18.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:18.0 read_resources bus 1 link: 0 PCI: 01:03.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 01:03.0 read_resources bus 2 link: 0 PCI: 01:03.0 read_resources bus 2 link: 0 done PCI: 01:03.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 01:03.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 01:03.0 read_resources bus 2 link: 0 PCI: 01:03.0 read_resources bus 2 link: 0 done PCI: 01:03.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 01:03.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 02 io PCI: 01:03.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 01:03.0 read_resources bus 2 link: 0 PCI: 01:03.0 read_resources bus 2 link: 0 done PCI: 01:03.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 01:03.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 01:03.0 read_resources bus 2 link: 0 PCI: 01:03.0 read_resources bus 2 link: 0 done PCI: 01:03.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 01:03.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 02 prefmem PCI: 01:03.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 01:03.0 read_resources bus 2 link: 0 PCI: 01:03.0 read_resources bus 2 link: 0 done PCI: 01:03.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 01:03.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 01:03.0 read_resources bus 2 link: 0 PCI: 01:03.0 read_resources bus 2 link: 0 done PCI: 01:03.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 01:03.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 02 mem PCI: 01:04.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 01:04.0 read_resources bus 3 link: 0 PCI: 01:04.0 read_resources bus 3 link: 0 done PCI: 01:04.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 01:04.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 01:04.0 read_resources bus 3 link: 0 PCI: 01:04.0 read_resources bus 3 link: 0 done PCI: 01:04.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 01:04.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 03 io PCI: 01:04.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 01:04.0 read_resources bus 3 link: 0 PCI: 01:04.0 read_resources bus 3 link: 0 done PCI: 01:04.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 01:04.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 01:04.0 read_resources bus 3 link: 0 PCI: 01:04.0 read_resources bus 3 link: 0 done PCI: 01:04.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 01:04.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 03 prefmem PCI: 01:04.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 01:04.0 read_resources bus 3 link: 0 PCI: 01:04.0 read_resources bus 3 link: 0 done PCI: 01:04.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 01:04.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 01:04.0 read_resources bus 3 link: 0 PCI: 01:04.0 read_resources bus 3 link: 0 done PCI: 01:04.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 01:04.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 03 mem PCI: 01:05.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 01:05.0 read_resources bus 4 link: 0 PCI: 01:05.0 read_resources bus 4 link: 0 done PCI: 01:05.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 01:05.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 01:05.0 read_resources bus 4 link: 0 PCI: 01:05.0 read_resources bus 4 link: 0 done PCI: 01:05.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 01:05.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 04 io PCI: 01:05.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 01:05.0 read_resources bus 4 link: 0 PCI: 01:05.0 read_resources bus 4 link: 0 done PCI: 01:05.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 01:05.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 01:05.0 read_resources bus 4 link: 0 PCI: 01:05.0 read_resources bus 4 link: 0 done PCI: 01:05.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 01:05.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 04 prefmem PCI: 01:05.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 01:05.0 read_resources bus 4 link: 0 PCI: 01:05.0 read_resources bus 4 link: 0 done PCI: 01:05.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 01:05.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 01:05.0 read_resources bus 4 link: 0 PCI: 01:05.0 read_resources bus 4 link: 0 done PCI: 01:05.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 01:05.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 04 mem PCI: 01:11.0 read_resources bus 0 link: 0 PCI: 01:11.0 read_resources bus 0 link: 0 done PCI: 01:16.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 01:16.0 read_resources bus 5 link: 0 PCI: 01:16.0 read_resources bus 5 link: 0 done PCI: 05:09.0 14 * [0x00000000 - 0x0000007f] io PCI: 01:16.0 compute_allocate_io: base: 00000080 size: 00001000 align: 12 gran: 12 done PCI: 01:16.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 01:16.0 read_resources bus 5 link: 0 PCI: 01:16.0 read_resources bus 5 link: 0 done PCI: 01:16.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 01:16.0 compute_allocate_prefmem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 01:16.0 read_resources bus 5 link: 0 PCI: 01:16.0 read_resources bus 5 link: 0 done PCI: 01:16.0 compute_allocate_prefmem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 01:16.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 05 prefmem PCI: 01:16.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 01:16.0 read_resources bus 5 link: 0 PCI: 01:16.0 read_resources bus 5 link: 0 done PCI: 05:09.0 10 * [0x00000000 - 0x000007ff] mem PCI: 01:16.0 compute_allocate_mem: base: 00000800 size: 00100000 align: 20 gran: 20 done PCI: 01:1a.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 01:1a.0 read_resources bus 6 link: 0 PCI: 01:1a.0 read_resources bus 6 link: 0 done PCI: 01:1a.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 01:1a.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 01:1a.0 read_resources bus 6 link: 0 PCI: 01:1a.0 read_resources bus 6 link: 0 done PCI: 01:1a.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 01:1a.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 06 io PCI: 01:1a.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 01:1a.0 read_resources bus 6 link: 0 PCI: 01:1a.0 read_resources bus 6 link: 0 done PCI: 01:1a.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 01:1a.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 01:1a.0 read_resources bus 6 link: 0 PCI: 01:1a.0 read_resources bus 6 link: 0 done PCI: 01:1a.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 01:1a.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 06 prefmem PCI: 01:1a.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 01:1a.0 read_resources bus 6 link: 0 PCI: 01:1a.0 read_resources bus 6 link: 0 done PCI: 01:1a.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 01:1a.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 01:1a.0 read_resources bus 6 link: 0 PCI: 01:1a.0 read_resources bus 6 link: 0 done PCI: 01:1a.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 01:1a.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 06 mem PCI: 01:1b.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 01:1b.0 read_resources bus 7 link: 0 PCI: 01:1b.0 read_resources bus 7 link: 0 done PCI: 01:1b.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 01:1b.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 01:1b.0 read_resources bus 7 link: 0 PCI: 01:1b.0 read_resources bus 7 link: 0 done PCI: 01:1b.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 01:1b.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 07 io PCI: 01:1b.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 01:1b.0 read_resources bus 7 link: 0 PCI: 01:1b.0 read_resources bus 7 link: 0 done PCI: 01:1b.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 01:1b.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 01:1b.0 read_resources bus 7 link: 0 PCI: 01:1b.0 read_resources bus 7 link: 0 done PCI: 01:1b.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 01:1b.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 07 prefmem PCI: 01:1b.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 01:1b.0 read_resources bus 7 link: 0 PCI: 01:1b.0 read_resources bus 7 link: 0 done PCI: 01:1b.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 01:1b.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 01:1b.0 read_resources bus 7 link: 0 PCI: 01:1b.0 read_resources bus 7 link: 0 done PCI: 01:1b.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 01:1b.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 07 mem PCI: 01:1d.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 01:1d.0 read_resources bus 8 link: 0 PCI: 01:1d.0 read_resources bus 8 link: 0 done PCI: 01:1d.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 01:1d.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 01:1d.0 read_resources bus 8 link: 0 PCI: 01:1d.0 read_resources bus 8 link: 0 done PCI: 01:1d.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 01:1d.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 08 io PCI: 01:1d.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 01:1d.0 read_resources bus 8 link: 0 PCI: 01:1d.0 read_resources bus 8 link: 0 done PCI: 01:1d.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 01:1d.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 01:1d.0 read_resources bus 8 link: 0 PCI: 01:1d.0 read_resources bus 8 link: 0 done PCI: 01:1d.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 01:1d.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 08 prefmem PCI: 01:1d.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 01:1d.0 read_resources bus 8 link: 0 PCI: 01:1d.0 read_resources bus 8 link: 0 done PCI: 01:1d.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 01:1d.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 01:1d.0 read_resources bus 8 link: 0 PCI: 01:1d.0 read_resources bus 8 link: 0 done PCI: 01:1d.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 01:1d.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 08 mem PCI: 01:1e.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 01:1e.0 read_resources bus 9 link: 0 PCI: 01:1e.0 read_resources bus 9 link: 0 done PCI: 01:1e.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 done PCI: 01:1e.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 PCI: 01:1e.0 read_resources bus 9 link: 0 PCI: 01:1e.0 read_resources bus 9 link: 0 done PCI: 01:1e.0 compute_allocate_io: base: fffff000 size: 00000000 align: 12 gran: 12 done PCI: 01:1e.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 09 io PCI: 01:1e.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 01:1e.0 read_resources bus 9 link: 0 PCI: 01:1e.0 read_resources bus 9 link: 0 done PCI: 01:1e.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 01:1e.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 PCI: 01:1e.0 read_resources bus 9 link: 0 PCI: 01:1e.0 read_resources bus 9 link: 0 done PCI: 01:1e.0 compute_allocate_prefmem: base: fffffffffff00000 size: 00000000 align: 20 gran: 20 done PCI: 01:1e.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 09 prefmem PCI: 01:1e.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 01:1e.0 read_resources bus 9 link: 0 PCI: 01:1e.0 read_resources bus 9 link: 0 done PCI: 01:1e.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 01:1e.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 PCI: 01:1e.0 read_resources bus 9 link: 0 PCI: 01:1e.0 read_resources bus 9 link: 0 done PCI: 01:1e.0 compute_allocate_mem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 01:1e.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 09 mem PCI: 00:18.0 read_resources bus 1 link: 0 done PCI: 01:16.0 1c * [0x00000000 - 0x00000fff] io PCI: 01:11.1 20 * [0x00001000 - 0x0000103f] io PCI: 01:11.1 24 * [0x00001040 - 0x0000107f] io PCI: 01:14.0 20 * [0x00001080 - 0x0000108f] io PCI: 01:15.0 20 * [0x00001090 - 0x0000109f] io PCI: 01:15.1 20 * [0x000010a0 - 0x000010af] io PCI: 01:15.2 20 * [0x000010b0 - 0x000010bf] io PCI: 01:15.0 10 * [0x000010c0 - 0x000010c7] io PCI: 01:15.0 18 * [0x000010d0 - 0x000010d7] io PCI: 01:15.1 10 * [0x000010e0 - 0x000010e7] io PCI: 01:15.1 18 * [0x000010f0 - 0x000010f7] io PCI: 01:15.2 10 * [0x00001100 - 0x00001107] io PCI: 01:15.2 18 * [0x00001400 - 0x00001407] io PCI: 01:18.0 14 * [0x00001410 - 0x00001417] io PCI: 01:19.0 14 * [0x00001420 - 0x00001427] io PCI: 01:15.0 14 * [0x00001430 - 0x00001433] io PCI: 01:15.0 1c * [0x00001440 - 0x00001443] io PCI: 01:15.1 14 * [0x00001450 - 0x00001453] io PCI: 01:15.1 1c * [0x00001460 - 0x00001463] io PCI: 01:15.2 14 * [0x00001470 - 0x00001473] io PCI: 01:15.2 1c * [0x00001480 - 0x00001483] io PCI: 00:18.0 compute_allocate_io: base: 00001484 size: 00002000 align: 12 gran: 12 done PCI: 00:18.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:18.0 read_resources bus 1 link: 0 PCI: 00:18.0 read_resources bus 1 link: 0 done PCI: 00:18.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 done PCI: 00:18.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:18.0 read_resources bus 1 link: 0 PCI: 00:18.0 read_resources bus 1 link: 0 done PCI: 01:16.0 20 * [0x00000000 - 0x000fffff] mem PCI: 01:16.1 10 * [0x00100000 - 0x00103fff] mem PCI: 01:12.0 10 * [0x00104000 - 0x00104fff] mem PCI: 01:15.0 24 * [0x00105000 - 0x00105fff] mem PCI: 01:15.1 24 * [0x00106000 - 0x00106fff] mem PCI: 01:15.2 24 * [0x00107000 - 0x00107fff] mem PCI: 01:18.0 10 * [0x00108000 - 0x00108fff] mem PCI: 01:19.0 10 * [0x00109000 - 0x00109fff] mem PCI: 01:12.1 10 * [0x0010a000 - 0x0010a0ff] mem PCI: 01:18.0 18 * [0x0010b000 - 0x0010b0ff] mem PCI: 01:19.0 18 * [0x0010c000 - 0x0010c0ff] mem PCI: 01:18.0 1c * [0x0010d000 - 0x0010d00f] mem PCI: 01:19.0 1c * [0x0010e000 - 0x0010e00f] mem PCI: 00:18.0 compute_allocate_mem: base: 0010e010 size: 00200000 align: 20 gran: 20 done PCI: 00:19.0 register 10(ffffffff), read-only ignoring it PCI: 00:19.0 register 14(ffffffff), read-only ignoring it PCI: 00:19.0 register 18(ffffffff), read-only ignoring it PCI: 00:19.0 register 1c(ffffffff), read-only ignoring it PCI: 00:19.0 register 20(ffffffff), read-only ignoring it PCI: 00:19.0 register 24(ffffffff), read-only ignoring it PCI: 00:19.0 register 30(ffffffff), read-only ignoring it PCI: 00:1a.0 register 10(ffffffff), read-only ignoring it PCI: 00:1a.0 register 14(ffffffff), read-only ignoring it PCI: 00:1a.0 register 38(ffffffff), read-only ignoring it PCI: 00:1b.0 register 10(ffffffff), read-only ignoring it PCI: 00:1b.0 register 14(ffffffff), read-only ignoring it PCI: 00:1b.0 register 38(ffffffff), read-only ignoring it PCI: 00:1d.0 register 10(ffffffff), read-only ignoring it PCI: 00:1d.0 register 14(ffffffff), read-only ignoring it PCI: 00:1d.0 register 38(ffffffff), read-only ignoring it PCI: 00:1e.0 register 10(ffffffff), read-only ignoring it PCI: 00:1e.0 register 14(ffffffff), read-only ignoring it PCI: 00:1e.0 register 38(ffffffff), read-only ignoring it PCI: 00:1f.0 register 10(ffffffff), read-only ignoring it PCI: 00:1f.0 register 14(ffffffff), read-only ignoring it PCI: 00:1f.0 register 38(ffffffff), read-only ignoring it PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done Root Device read_resources bus 0 link: 0 done PCI: 00:18.0 1c0 * [0x00001000 - 0x00002fff] io Root Device compute_allocate_io: base: 00003000 size: 00002c00 align: 12 gran: 0 done Root Device compute_allocate_mem: base: 00000000 size: 00000000 align: 0 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:18.3 94 * [0x00000000 - 0x03ffffff] mem PCI: 00:18.0 1b0 * [0x04000000 - 0x041fffff] mem PCI: 00:18.0 1b8 * [0x04200000 - 0x041fffff] prefmem Root Device compute_allocate_mem: base: 04200000 size: 04200000 align: 26 gran: 0 done Done reading resources. Setting resources... Root Device compute_allocate_io: base: 00001000 size: 00002c00 align: 12 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:18.0 1c0 * [0x00001000 - 0x00002fff] io Root Device compute_allocate_io: base: 00003000 size: 00002000 align: 12 gran: 0 done Root Device compute_allocate_mem: base: f8000000 size: 04200000 align: 26 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:18.3 94 * [0xf8000000 - 0xfbffffff] mem PCI: 00:18.0 1b0 * [0xfc000000 - 0xfc1fffff] mem PCI: 00:18.0 1b8 * [0xfc200000 - 0xfc1fffff] prefmem Root Device compute_allocate_mem: base: fc200000 size: 04200000 align: 26 gran: 0 done Root Device assign_resources, bus 0 link: 0 PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 PCI: 00:18.0 compute_allocate_io: base: 00001000 size: 00002000 align: 12 gran: 12 PCI: 00:18.0 read_resources bus 1 link: 0 PCI: 00:18.0 read_resources bus 1 link: 0 done PCI: 01:16.0 1c * [0x00001000 - 0x00001fff] io PCI: 01:11.1 20 * [0x00002000 - 0x0000203f] io PCI: 01:11.1 24 * [0x00002040 - 0x0000207f] io PCI: 01:14.0 20 * [0x00002080 - 0x0000208f] io PCI: 01:15.0 20 * [0x00002090 - 0x0000209f] io PCI: 01:15.1 20 * [0x000020a0 - 0x000020af] io PCI: 01:15.2 20 * [0x000020b0 - 0x000020bf] io PCI: 01:15.0 10 * [0x000020c0 - 0x000020c7] io PCI: 01:15.0 18 * [0x000020d0 - 0x000020d7] io PCI: 01:15.1 10 * [0x000020e0 - 0x000020e7] io PCI: 01:15.1 18 * [0x000020f0 - 0x000020f7] io PCI: 01:15.2 10 * [0x00002100 - 0x00002107] io PCI: 01:15.2 18 * [0x00002400 - 0x00002407] io PCI: 01:18.0 14 * [0x00002410 - 0x00002417] io PCI: 01:19.0 14 * [0x00002420 - 0x00002427] io PCI: 01:15.0 14 * [0x00002430 - 0x00002433] io PCI: 01:15.0 1c * [0x00002440 - 0x00002443] io PCI: 01:15.1 14 * [0x00002450 - 0x00002453] io PCI: 01:15.1 1c * [0x00002460 - 0x00002463] io PCI: 01:15.2 14 * [0x00002470 - 0x00002473] io PCI: 01:15.2 1c * [0x00002480 - 0x00002483] io PCI: 00:18.0 compute_allocate_io: base: 00002484 size: 00002000 align: 12 gran: 12 done PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000002fff] io PCI: 00:18.0 compute_allocate_prefmem: base: fc200000 size: 00000000 align: 20 gran: 20 PCI: 00:18.0 read_resources bus 1 link: 0 PCI: 00:18.0 read_resources bus 1 link: 0 done PCI: 00:18.0 compute_allocate_prefmem: base: fc200000 size: 00000000 align: 20 gran: 20 done PCI: 00:18.0 1b8 <- [0x00fc200000 - 0x00fc1fffff] prefmem PCI: 00:18.0 compute_allocate_mem: base: fc000000 size: 00200000 align: 20 gran: 20 PCI: 00:18.0 read_resources bus 1 link: 0 PCI: 00:18.0 read_resources bus 1 link: 0 done PCI: 01:16.0 20 * [0xfc000000 - 0xfc0fffff] mem PCI: 01:16.1 10 * [0xfc100000 - 0xfc103fff] mem PCI: 01:12.0 10 * [0xfc104000 - 0xfc104fff] mem PCI: 01:15.0 24 * [0xfc105000 - 0xfc105fff] mem PCI: 01:15.1 24 * [0xfc106000 - 0xfc106fff] mem PCI: 01:15.2 24 * [0xfc107000 - 0xfc107fff] mem PCI: 01:18.0 10 * [0xfc108000 - 0xfc108fff] mem PCI: 01:19.0 10 * [0xfc109000 - 0xfc109fff] mem PCI: 01:12.1 10 * [0xfc10a000 - 0xfc10a0ff] mem PCI: 01:18.0 18 * [0xfc10b000 - 0xfc10b0ff] mem PCI: 01:19.0 18 * [0xfc10c000 - 0xfc10c0ff] mem PCI: 01:18.0 1c * [0xfc10d000 - 0xfc10d00f] mem PCI: 01:19.0 1c * [0xfc10e000 - 0xfc10e00f] mem PCI: 00:18.0 compute_allocate_mem: base: fc10e010 size: 00200000 align: 20 gran: 20 done PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fc1fffff] mem PCI: 00:18.0 assign_resources, bus 1 link: 0 PCI: 01:11.1 20 <- [0x0000002000 - 0x000000203f] io PCI: 01:11.1 24 <- [0x0000002040 - 0x000000207f] io PCI: 01:12.0 10 <- [0x00fc104000 - 0x00fc104fff] mem PCI: 01:12.1 10 <- [0x00fc10a000 - 0x00fc10a0ff] mem PCI: 01:14.0 20 <- [0x0000002080 - 0x000000208f] io PCI: 01:15.0 10 <- [0x00000020c0 - 0x00000020c7] io PCI: 01:15.0 14 <- [0x0000002430 - 0x0000002433] io PCI: 01:15.0 18 <- [0x00000020d0 - 0x00000020d7] io PCI: 01:15.0 1c <- [0x0000002440 - 0x0000002443] io PCI: 01:15.0 20 <- [0x0000002090 - 0x000000209f] io PCI: 01:15.0 24 <- [0x00fc105000 - 0x00fc105fff] mem PCI: 01:15.1 10 <- [0x00000020e0 - 0x00000020e7] io PCI: 01:15.1 14 <- [0x0000002450 - 0x0000002453] io PCI: 01:15.1 18 <- [0x00000020f0 - 0x00000020f7] io PCI: 01:15.1 1c <- [0x0000002460 - 0x0000002463] io PCI: 01:15.1 20 <- [0x00000020a0 - 0x00000020af] io PCI: 01:15.1 24 <- [0x00fc106000 - 0x00fc106fff] mem PCI: 01:15.2 10 <- [0x0000002100 - 0x0000002107] io PCI: 01:15.2 14 <- [0x0000002470 - 0x0000002473] io PCI: 01:15.2 18 <- [0x0000002400 - 0x0000002407] io PCI: 01:15.2 1c <- [0x0000002480 - 0x0000002483] io PCI: 01:15.2 20 <- [0x00000020b0 - 0x00000020bf] io PCI: 01:15.2 24 <- [0x00fc107000 - 0x00fc107fff] mem PCI: 01:16.0 compute_allocate_io: base: 00001000 size: 00001000 align: 12 gran: 12 PCI: 01:16.0 read_resources bus 5 link: 0 PCI: 01:16.0 read_resources bus 5 link: 0 done PCI: 05:09.0 14 * [0x00001000 - 0x0000107f] io PCI: 01:16.0 compute_allocate_io: base: 00001080 size: 00001000 align: 12 gran: 12 done PCI: 01:16.0 1c <- [0x0000001000 - 0x0000001fff] bus 05 io PCI: 01:16.0 compute_allocate_mem: base: fc000000 size: 00100000 align: 20 gran: 20 PCI: 01:16.0 read_resources bus 5 link: 0 PCI: 01:16.0 read_resources bus 5 link: 0 done PCI: 05:09.0 10 * [0xfc000000 - 0xfc0007ff] mem PCI: 01:16.0 compute_allocate_mem: base: fc000800 size: 00100000 align: 20 gran: 20 done PCI: 01:16.0 20 <- [0x00fc000000 - 0x00fc0fffff] bus 05 mem PCI: 01:16.0 assign_resources, bus 5 link: 0 PCI: 05:09.0 10 <- [0x00fc000000 - 0x00fc0007ff] mem PCI: 05:09.0 14 <- [0x0000001000 - 0x000000107f] io PCI: 01:16.0 assign_resources, bus 5 link: 0 PCI: 01:16.1 10 <- [0x00fc100000 - 0x00fc103fff] mem PCI: 01:18.0 10 <- [0x00fc108000 - 0x00fc108fff] mem PCI: 01:18.0 14 <- [0x0000002410 - 0x0000002417] io PCI: 01:18.0 18 <- [0x00fc10b000 - 0x00fc10b0ff] mem PCI: 01:18.0 1c <- [0x00fc10d000 - 0x00fc10d00f] mem PCI: 01:19.0 10 <- [0x00fc109000 - 0x00fc109fff] mem PCI: 01:19.0 14 <- [0x0000002420 - 0x0000002427] io PCI: 01:19.0 18 <- [0x00fc10c000 - 0x00fc10c0ff] mem PCI: 01:19.0 1c <- [0x00fc10e000 - 0x00fc10e00f] mem PCI: 00:18.0 assign_resources, bus 1 link: 0 PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 Root Device assign_resources, bus 0 link: 0 Done setting resources. Done allocating resources. Enabling resources... PCI: 00:18.0 cmd <- 140 PCI: 01:01.0 subsystem <- 10de/cb84 PCI: 01:01.0 cmd <- 146 PCI: 01:01.1 cmd <- 140 PCI: 01:01.2 cmd <- 140 PCI: 01:01.3 cmd <- 140 PCI: 01:01.4 cmd <- 146 PCI: 01:01.5 cmd <- 146 PCI: 01:01.6 cmd <- 140 PCI: 01:01.7 cmd <- 140 PCI: 01:03.0 bridge ctrl <- 0003 PCI: 01:03.0 cmd <- 140 PCI: 01:04.0 bridge ctrl <- 0003 PCI: 01:04.0 cmd <- 140 PCI: 01:05.0 bridge ctrl <- 0003 PCI: 01:05.0 cmd <- 140 PCI: 01:10.0 cmd <- 146 PCI: 01:11.0 cmd <- 14f PCI: 01:11.1 cmd <- 141 PCI: 01:11.2 cmd <- 540 PCI: 01:12.0 cmd <- 142 PCI: 01:12.1 cmd <- 142 PCI: 01:14.0 cmd <- 141 PCI: 01:15.0 cmd <- 143 PCI: 01:15.1 cmd <- 143 PCI: 01:15.2 cmd <- 143 PCI: 01:16.0 bridge ctrl <- 0003 PCI: 01:16.0 cmd <- 147 PCI: 05:09.0 cmd <- 1c3 PCI: 01:16.1 cmd <- 142 PCI: 01:18.0 cmd <- 143 PCI: 01:19.0 cmd <- 143 PCI: 01:1a.0 bridge ctrl <- 0003 PCI: 01:1a.0 cmd <- 140 PCI: 01:1b.0 bridge ctrl <- 0003 PCI: 01:1b.0 cmd <- 140 PCI: 01:1d.0 bridge ctrl <- 0003 PCI: 01:1d.0 cmd <- 140 PCI: 01:1e.0 bridge ctrl <- 0003 PCI: 01:1e.0 cmd <- 140 PCI: 00:18.1 subsystem <- 10de/cb84 PCI: 00:18.1 cmd <- 140 PCI: 00:18.2 subsystem <- 10de/cb84 PCI: 00:18.2 cmd <- 140 PCI: 00:18.3 cmd <- 140 PCI: 00:19.0 cmd <- ffff PCI: 00:1a.0 bridge ctrl <- ffff PCI: 00:1a.0 cmd <- ffff PCI: 00:1b.0 bridge ctrl <- ffff PCI: 00:1b.0 cmd <- ffff PCI: 00:1d.0 bridge ctrl <- ffff PCI: 00:1d.0 cmd <- ffff PCI: 00:1e.0 bridge ctrl <- ffff PCI: 00:1e.0 cmd <- ffff PCI: 00:1f.0 bridge ctrl <- ffff PCI: 00:1f.0 cmd <- ffff done. Initializing devices... Root Device init APIC_CLUSTER: 0 init Initializing CPU #0 CPU: vendor AMD device 40fb2 CPU: family 0f, model 4b, stepping 02 Enabling cache Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 512MB, type WB ADDRESS_MASK_HIGH=0xff DONE variable MTRRs Clear out the extra MTRR's call enable_var_mtrr() Leave x86_setup_var_mtrrs MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled CPU model AMD Athlon(tm) 64 FX-37 Processor Setting up local apic... apic_id: 0x00 done. ECC Disabled CPU #0 Initialized Asserting INIT. Waiting for send to finish... +Deasserting INIT. Waiting for send to finish... +#startup loops: 2. Sending STARTUP #1 to 1. After apic_write. Startup point 1. Waiting for send to finish... +Sending STARTUP #2 to 1. After apic_write. Startup point 1. Waiting for send to finish... +After Startup. Initializing CPU #1 Waiting for 1 CPUS to stop CPU: vendor AMD device 40fb2 CPU: family 0f, model 4b, stepping 02 Enabling cache Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 512MB, type WB ADDRESS_MASK_HIGH=0xff DONE variable MTRRs Clear out the extra MTRR's call enable_var_mtrr() Leave x86_setup_var_mtrrs MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled CPU model AMD Athlon(tm) 64 FX-37 Processor Setting up local apic... apic_id: 0x01 done. CPU #1 Initialized All AP CPUs stopped PCI: 00:18.0 init PCI: 01:01.0 init PCI: 00:18.1 init PCI: 00:18.2 init PCI: 00:18.3 init NB: Function 3 Misc Control.. done. PCI: 00:19.0 init PCI: 00:1b.0 init PCI: 01:01.1 init PCI: 01:01.2 init PCI: 01:01.3 init PCI: 01:01.4 init PCI: 01:01.5 init PCI: 01:01.6 init PCI: 01:01.7 init PCI: 01:11.0 init setting up IOAPIC at 0xfec00000 for IRQ, reg 0x00000000 value 0x00000700 0x00000000 for IRQ, reg 0x00000001 value 0x00010000 0x00000000 for IRQ, reg 0x00000002 value 0x00010000 0x00000000 for IRQ, reg 0x00000003 value 0x00010000 0x00000000 for IRQ, reg 0x00000004 value 0x00010000 0x00000000 for IRQ, reg 0x00000005 value 0x00010000 0x00000000 for IRQ, reg 0x00000006 value 0x00010000 0x00000000 for IRQ, reg 0x00000007 value 0x00010000 0x00000000 for IRQ, reg 0x00000008 value 0x00010000 0x00000000 for IRQ, reg 0x00000009 value 0x00010000 0x00000000 for IRQ, reg 0x0000000a value 0x00010000 0x00000000 for IRQ, reg 0x0000000b value 0x00010000 0x00000000 for IRQ, reg 0x0000000c value 0x00010000 0x00000000 for IRQ, reg 0x0000000d value 0x00010000 0x00000000 for IRQ, reg 0x0000000e value 0x00010000 0x00000000 for IRQ, reg 0x0000000f value 0x00010000 0x00000000 for IRQ, reg 0x00000010 value 0x00010000 0x00000000 for IRQ, reg 0x00000011 value 0x00010000 0x00000000 for IRQ, reg 0x00000012 value 0x00010000 0x00000000 for IRQ, reg 0x00000013 value 0x00010000 0x00000000 for IRQ, reg 0x00000014 value 0x00010000 0x00000000 for IRQ, reg 0x00000015 value 0x00010000 0x00000000 for IRQ, reg 0x00000016 value 0x00010000 0x00000000 for IRQ, reg 0x00000017 value 0x00010000 0x00000000 set power on after power fail RTC Init PCI: 01:11.2 init PCI: 01:12.1 init PCI: 01:14.0 init PCI: 01:15.0 init PCI: 01:15.1 init PCI: 01:15.2 init PCI: 01:16.0 init dev_root mem base = 0x00f8000000 [0x50] <-- 0xf8000000 PCI: 01:18.0 init PCI: 01:19.0 init PCI: 01:1b.0 init PCI: 05:09.0 init Devices initialized Writing IRQ routing tables to 0xf0000...done. Wrote the mp table end at: 00000020 - 000000ec Moving GDT to 0x500...ok Wrote linuxbios table at: 00000530 - 000006dc checksum c17 Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3 serial_stream: downloading to 0x03000000; start XMODEM transfer now! C. serial_stream: XMODEM transfer complete; 1731968 bytes received serial_stream: copying to 0x02000000 Found ELF candidate at offset 0 header_offset is 0 Try to load at offset 0x0 n_type: 00000001 n_name(8): ELFBoot n_desc(6): Linux n_type: 00000002 n_name(8): ELFBoot n_desc(100): 2.6.17.11-ArosKernel-main-11945 (arastra at bs2.arastra.com) #16 malloc Enter, size 20, free_mem_ptr 0003fdf0 malloc 0x0003fdf0 n_type: 00000003 n_name(8): ELFBoot n_desc(2): C: Dropping non PT_LOAD segment malloc Enter, size 32, free_mem_ptr 0003fe04 malloc 0x0003fe04 New segment addr 0x10000 size 0x12204 offset 0x180 filesize 0x118c (cleaned up) New segment addr 0x10000 size 0x12204 offset 0x180 filesize 0x118c lb: [0x0000000000004000, 0x000000000004a000) segment: [0x0000000000010000, 0x000000000001118c, 0x0000000000022204) bounce: [0x000000001ff80000, 0x000000001ff8118c, 0x000000001ff92204) malloc Enter, size 32, free_mem_ptr 0003fe24 malloc 0x0003fe24 New segment addr 0x20000 size 0x1070 offset 0x130c filesize 0x0 (cleaned up) New segment addr 0x20000 size 0x1070 offset 0x130c filesize 0x0 lb: [0x0000000000004000, 0x000000000004a000) segment: [0x0000000000020000, 0x0000000000020000, 0x0000000000021070) bounce: [0x000000001ff90000, 0x000000001ff90000, 0x000000001ff91070) malloc Enter, size 32, free_mem_ptr 0003fe44 malloc 0x0003fe44 New segment addr 0x100000 size 0x700000 offset 0x130c filesize 0x14a139 (cleaned up) New segment addr 0x100000 size 0x700000 offset 0x130c filesize 0x14a139 lb: [0x0000000000004000, 0x000000000004a000) malloc Enter, size 32, free_mem_ptr 0003fe64 malloc 0x0003fe64 New segment addr 0x800000 size 0x5b915 offset 0x14b445 filesize 0x5b915 (cleaned up) New segment addr 0x800000 size 0x5b915 offset 0x14b445 filesize 0x5b915 lb: [0x0000000000004000, 0x000000000004a000) Loading Segment: addr: 0x000000001ff80000 memsz: 0x0000000000012204 filesz: 0x000000000000118c [ 0x000000001ff80000, 000000001ff8118c, 0x000000001ff92204) <- 0000000000000180 Clearing Segment: addr: 0x000000001ff8118c memsz: 0x0000000000011078 Loading Segment: addr: 0x000000001ff90000 memsz: 0x0000000000001070 filesz: 0x0000000000000000 [ 0x000000001ff90000, 000000001ff90000, 0x000000001ff91070) <- 000000000000130c Clearing Segment: addr: 0x000000001ff90000 memsz: 0x0000000000001070 Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000700000 filesz: 0x000000000014a139 [ 0x0000000000100000, 000000000024a139, 0x0000000000800000) <- 000000000000130c Clearing Segment: addr: 0x000000000024a139 memsz: 0x00000000005b5ec7 Loading Segment: addr: 0x0000000000800000 memsz: 0x000000000005b915 filesz: 0x000000000005b915 [ 0x0000000000800000, 000000000085b915, 0x000000000085b915) <- 000000000014b445 Loaded segments verified segments closed down stream Jumping to boot code at 0x10000 entry = 0x00010000 lb_start = 0x00004000 lb_size = 0x00046000 adjust = 0x1ffb6000 buffer = 0x1ff74000 elf_boot_notes = 0x00017a80 adjusted_boot_notes = 0x1ffcda80 Firmware type: LinuxBIOS Linux version 2.6.17.11-ArosKernel-main-11945 (arastra at bs2.arastra.com) (gcc version 4.0.2 20051125 (Red Hat 46 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000000748 (reserved) BIOS-e820: 0000000000000748 - 00000000000a0000 (usable) BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved) BIOS-e820: 0000000000100000 - 0000000020000000 (usable) 0MB HIGHMEM available. 512MB LOWMEM available. found SMP MP-table at 00000010 DMI not present or invalid. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: DFI Product ID: LP_UT_NF590 APIC at: 0xFEE00000 Processor #0 15:11 APIC version 16 Processor #1 15:11 APIC version 16 I/O APIC #2 Version 17 at 0xFEC00000. Enabling APIC mode: Flat. Using 1 I/O APICs Processors: 2 Allocating PCI resources starting at 30000000 (gap: 20000000:e0000000) Built 1 zonelists Kernel command line: console=ttyS0,115200 apic=debug Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c039d000 soft=c039f000 PID hash table entries: 4096 (order: 12, 16384 bytes) Detected 1000.276 MHz processor. Using tsc for high-res timesource Console: colour dummy device 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 516000k/524288k available (1535k kernel code, 7880k reserved, 953k data, 148k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 2010.04 BogoMIPS (lpj=4020098) Mount-cache hash table entries: 512 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU 0(2) -> Core 0 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Checking 'hlt' instruction... OK. Freeing SMP alternatives: 12k freed CPU0: AMD Athlon(tm) 64 FX-37 Processor stepping 02 Getting VERSION: 80050010 Getting VERSION: 80050010 Getting ID: 0 Getting LVT0: 700 Getting LVT1: 400 enabled ExtINT on CPU#0 Booting processor 1/1 eip 2000 CPU 1 irqstacks, hard=c039e000 soft=c03a0000 Initializing CPU#1 masked ExtINT on CPU#1 Calibrating delay using timer specific routine.. 2000.17 BogoMIPS (lpj=4000354) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU 1(2) -> Core 1 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#1. CPU1: AMD Athlon(tm) 64 FX-37 Processor stepping 02 Total of 2 processors activated (4010.22 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=-1 pin1=-1 apic2=0 pin2=0 ...trying to set up timer (IRQ0) through the 8259A ... ..... (found pin 0) ...works. testing the IO APIC....................... .................................... done. Using local APIC timer interrupts. calibrating APIC timer ... ..... CPU clock speed is 1000.0163 MHz. ..... host bus clock speed is 200.0032 MHz. checking TSC synchronization across 2 CPUs: passed. Brought up 2 CPUs migration_cost=211 Unpacking initramfs... done Freeing initrd memory: 366k freed NET: Registered protocol family 16 PCI: Using configuration type 1 Setting up standard PCI resources SCSI subsystem initialized usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Probing PCI hardware PCI: Unable to handle 64-bit address space for bridge 0000:01:03.0 PCI: Unable to handle 64-bit address space for bridge 0000:01:04.0 PCI: Unable to handle 64-bit address space for bridge 0000:01:05.0 PCI: Unable to handle 64-bit address space for bridge 0000:01:1a.0 PCI: Unable to handle 64-bit address space for bridge 0000:01:1b.0 PCI: Unable to handle 64-bit address space for bridge 0000:01:1d.0 PCI: Unable to handle 64-bit address space for bridge 0000:01:1e.0 PCI: Discovered primary peer bus 01 [IRQ] PCI: Using IRQ router default [10de/0360] at 0000:01:11.0 querying PCI -> IRQ mapping bus:1, slot:17, pin:0. PCI->APIC IRQ transform: 0000:01:11.1[A] -> IRQ 10 querying PCI -> IRQ mapping bus:1, slot:18, pin:0. PCI->APIC IRQ transform: 0000:01:12.0[A] -> IRQ 21 querying PCI -> IRQ mapping bus:1, slot:18, pin:1. PCI->APIC IRQ transform: 0000:01:12.1[B] -> IRQ 20 querying PCI -> IRQ mapping bus:1, slot:21, pin:0. querying PCI -> IRQ mapping bus:1, slot:21, pin:1. querying PCI -> IRQ mapping bus:1, slot:21, pin:2. querying PCI -> IRQ mapping bus:1, slot:22, pin:1. querying PCI -> IRQ mapping bus:1, slot:24, pin:0. PCI->APIC IRQ transform: 0000:01:18.0[A] -> IRQ 5 querying PCI -> IRQ mapping bus:1, slot:25, pin:0. PCI->APIC IRQ transform: 0000:01:19.0[A] -> IRQ 7 querying PCI -> IRQ mapping bus:5, slot:9, pin:0. querying PCI -> IRQ mapping bus:1, slot:22, pin:1. PCI: Cannot allocate resource region 7 of bridge 0000:01:1f.0 TC classifier action (bugs to netdev at vger.kernel.org cc hadi at cyberus.ca) PCI: Bridge: 0000:01:03.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:01:04.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:01:05.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:01:16.0 IO window: 1000-1fff MEM window: fc000000-fc0fffff PREFETCH window: disabled. PCI: Bridge: 0000:01:1a.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:01:1b.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:01:1d.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:01:1e.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:01:1f.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. NET: Registered protocol family 2 IP route cache hash table entries: 16384 (order: 4, 65536 bytes) TCP established hash table entries: 65536 (order: 8, 1572864 bytes) TCP bind hash table entries: 32768 (order: 7, 786432 bytes) TCP: Hash tables configured (established 65536 bind 32768) TCP reno registered Initializing Cryptographic API io scheduler noop registered (default) pcie_portdrv_probe->Dev[02fc:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability pcie_portdrv_probe->Dev[02fd:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability pcie_portdrv_probe->Dev[02fb:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability pcie_portdrv_probe->Dev[0376:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability pcie_portdrv_probe->Dev[0374:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability pcie_portdrv_probe->Dev[0378:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability pcie_portdrv_probe->Dev[0375:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability pcie_portdrv_probe->Dev[0377:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability ipmi message handler version 39.0 ipmi device interface IPMI System Interface driver. ipmi_si: Unable to find any System Interface(s) IPMI Watchdog: driver initialized Copyright (C) 2004 MontaVista Software - IPMI Powerdown via sys_reboot. Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.54. forcedeth: using HIGHDMA eth0: forcedeth.c: subsystem: 00000:0000 bound to 0000:01:18.0 forcedeth: using HIGHDMA eth1: forcedeth.c: subsystem: 00000:0000 bound to 0000:01:19.0 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ehci_hcd 0000:01:12.1: EHCI Host Controller ehci_hcd 0000:01:12.1: new USB bus registered, assigned bus number 1 ehci_hcd 0000:01:12.1: debug port 1 ehci_hcd 0000:01:12.1: irq 20, io mem 0xfc10a000 ehci_hcd 0000:01:12.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 10 ports detected ohci_hcd 0000:01:12.0: OHCI Host Controller ohci_hcd 0000:01:12.0: new USB bus registered, assigned bus number 2 ohci_hcd 0000:01:12.0: irq 21, io mem 0xfc104000 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 10 ports detected USB Universal Host Controller Interface driver v3.0 Initializing USB Mass Storage driver... usbcore: registered new driver usb-storage USB Mass Storage support registered. serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 mice: PS/2 mouse device common for all mice TCP bic registered NET: Registered protocol family 1 Starting balanced_irq Using IPI Shortcut mode Freeing unused kernel memory: 148k freed Write protecting the kernel read-only data: 612k From eswierk at arastra.com Thu Dec 14 08:14:48 2006 From: eswierk at arastra.com (Ed Swierk) Date: Wed, 13 Dec 2006 23:14:48 -0800 Subject: [LinuxBIOS] More MCP55 hacking In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA49072D2@ssvlexmb2.amd.com> Message-ID: On 12/13/06, Ed Swierk wrote: > Now, after Linux says "Write protecting the kernel read-only data", it > just hangs; the next thing it should do is run init. Never mind; turns out my mptable was broken and timers weren't wired up. USB and Ethernet are now working nicely. I'll post the code tomorrow. --Ed From svn at openbios.org Thu Dec 14 15:26:47 2006 From: svn at openbios.org (svn at openbios.org) Date: Thu, 14 Dec 2006 14:26:47 -0000 Subject: [LinuxBIOS] r2525 - in trunk/LinuxBIOSv2/src/superio/smsc: . fdc37m60x Message-ID: Author: uwe Date: 2006-12-14 15:26:46 +0100 (Thu, 14 Dec 2006) New Revision: 2525 Added: trunk/LinuxBIOSv2/src/superio/smsc/fdc37m60x/ trunk/LinuxBIOSv2/src/superio/smsc/fdc37m60x/Config.lb trunk/LinuxBIOSv2/src/superio/smsc/fdc37m60x/chip.h trunk/LinuxBIOSv2/src/superio/smsc/fdc37m60x/fdc37m60x.h trunk/LinuxBIOSv2/src/superio/smsc/fdc37m60x/fdc37m60x_early_serial.c trunk/LinuxBIOSv2/src/superio/smsc/fdc37m60x/superio.c Log: Add support for the SMSC FDC37M60x Super I/O (tested on FDC37M602). Serial output on serial port 1 is tested and works, the rest probably not yet. Closes #59. Signed-off-by: Uwe Hermann Acked-by: Stefan Reinauer Added: trunk/LinuxBIOSv2/src/superio/smsc/fdc37m60x/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/superio/smsc/fdc37m60x/Config.lb (rev 0) +++ trunk/LinuxBIOSv2/src/superio/smsc/fdc37m60x/Config.lb 2006-12-14 14:26:46 UTC (rev 2525) @@ -0,0 +1,23 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2006 Uwe Hermann +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; either version 2 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## + +config chip.h +object superio.o + Added: trunk/LinuxBIOSv2/src/superio/smsc/fdc37m60x/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/smsc/fdc37m60x/chip.h (rev 0) +++ trunk/LinuxBIOSv2/src/superio/smsc/fdc37m60x/chip.h 2006-12-14 14:26:46 UTC (rev 2525) @@ -0,0 +1,36 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#ifndef _SUPERIO_SMSC_FDC37M60X +#define _SUPERIO_SMSC_FDC37M60X + +#include +#include +#include + +extern struct chip_operations superio_smsc_fdc37m60x_ops; + +struct superio_smsc_fdc37m60x_config { + struct uart8250 com1, com2; + struct pc_keyboard keyboard; +}; + +#endif /* _SUPERIO_SMSC_FDC37M60X */ + Added: trunk/LinuxBIOSv2/src/superio/smsc/fdc37m60x/fdc37m60x.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/smsc/fdc37m60x/fdc37m60x.h (rev 0) +++ trunk/LinuxBIOSv2/src/superio/smsc/fdc37m60x/fdc37m60x.h 2006-12-14 14:26:46 UTC (rev 2525) @@ -0,0 +1,39 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/* + * Datasheet: + * - Name: FDC37M60x Enhanced Super I/O Controller with Infrared Support. + * - URL: http://www.smsc.com/main/discfdc.html + * - PDF: http://www.smsc.com/main/tools/discontinued/37m602.pdf + * - Revision: 6/6/97 + */ + +/* Status: Serial port 1 is tested and works (tested on FDC37M602). */ + +/* Note: Logical devices 1, 2, 6, and 9 are reserved. */ + +#define FDC37M60X_FDC 0x00 /* Floppy */ +#define FDC37M60X_PP 0x03 /* Parallel port */ +#define FDC37M60X_SP1 0x04 /* Com1 */ +#define FDC37M60X_SP2 0x05 /* Com2 */ +#define FDC37M60X_KBCK 0x07 /* Keyboard */ +#define FDC37M60X_AUX 0x08 /* Auxiliary I/O */ + Added: trunk/LinuxBIOSv2/src/superio/smsc/fdc37m60x/fdc37m60x_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/smsc/fdc37m60x/fdc37m60x_early_serial.c (rev 0) +++ trunk/LinuxBIOSv2/src/superio/smsc/fdc37m60x/fdc37m60x_early_serial.c 2006-12-14 14:26:46 UTC (rev 2525) @@ -0,0 +1,78 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include "fdc37m60x.h" + +/* The base address is 0x3f0 or 0x370, depending on the SYSOPT pin. */ +#define SIO_BASE 0x3f0 +#define SIO_INDEX SIO_BASE +#define SIO_DATA SIO_BASE+1 + +/* Global configuration registers. */ +#define FDC37M60X_CONFIG_REG_CC 0x02 /* Configure Control. */ +#define FDC37M60X_CONFIG_REG_LDN 0x07 /* Logical Device Number. */ +#define FDC37M60X_CONFIG_POWER_CONTROL 0x22 /* Power Control. */ +#define FDC37M60X_CONFIG_POWER_MGMT 0x23 /* Intelligent Power Mgmt. */ +#define FDC37M60X_CONFIG_OSC 0x24 /* OSC. */ + +#define FDC37M60X_CONFIGURATION_PORT 0x3f0 /* Write-only. */ + +/* The content of FDC37M60X_CONFIG_REG_LDN (index 0x07) must be set to the + LDN the register belongs to, before you can access the register. */ +static void fdc37m60x_sio_write(uint8_t ldn, uint8_t index, uint8_t value) +{ + outb(FDC37M60X_CONFIG_REG_LDN, SIO_BASE); + outb(ldn, SIO_DATA); + outb(index, SIO_BASE); + outb(value, SIO_DATA); +} + +/* Enable the peripheral devices on the FDC37M60X Super I/O chip. */ +static void fdc37m60x_enable_serial(device_t dev, unsigned iobase) +{ + /* (1) Enter the configuration state. */ + outb(0x55, FDC37M60X_CONFIGURATION_PORT); + + /* (2) Modify the data of configuration registers. */ + + /* Power on all devices by setting the respective bit. + Bits: 0 (FDC), 3 (PP), 4 (Com1), 5 (Com2). The rest is reserved. */ + fdc37m60x_sio_write(0x00, FDC37M60X_CONFIG_POWER_CONTROL, 0x39); + + /* Disable intelligent power management. */ + fdc37m60x_sio_write(0x00, FDC37M60X_CONFIG_POWER_MGMT, 0x00); + + /* Turn on OSC, turn on BRG clock. */ + fdc37m60x_sio_write(0x00, FDC37M60X_CONFIG_OSC, 0x04); + + /* Configure serial port 1. */ + fdc37m60x_sio_write(FDC37M60X_SP1, 0x60, 0x03); + fdc37m60x_sio_write(FDC37M60X_SP1, 0x61, 0xf8); /* I/O 0x3f8 */ + fdc37m60x_sio_write(FDC37M60X_SP1, 0x70, 0x04); /* IRQ 4 */ + fdc37m60x_sio_write(FDC37M60X_SP1, 0xf0, 0x00); /* Normal */ + + /* Enable serial port 1. */ + fdc37m60x_sio_write(FDC37M60X_SP1, 0x30, 0x01); + + /* (3) Exit the configuration state. */ + outb(0xaa, FDC37M60X_CONFIGURATION_PORT); +} + Added: trunk/LinuxBIOSv2/src/superio/smsc/fdc37m60x/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/smsc/fdc37m60x/superio.c (rev 0) +++ trunk/LinuxBIOSv2/src/superio/smsc/fdc37m60x/superio.c 2006-12-14 14:26:46 UTC (rev 2525) @@ -0,0 +1,87 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +#include "chip.h" +#include "fdc37m60x.h" + +static void init(device_t dev) +{ + struct superio_smsc_fdc37m60x_config *conf; + struct resource *res0, *res1; + + if (!dev->enabled) { + return; + } + + conf = dev->chip_info; + + switch (dev->path.u.pnp.device) { + case FDC37M60X_FDC: /* TODO. */ + break; + case FDC37M60X_PP: /* TODO. */ + break; + case FDC37M60X_SP1: + res0 = find_resource(dev, PNP_IDX_IO0); + init_uart8250(res0->base, &conf->com1); + break; + case FDC37M60X_SP2: + res0 = find_resource(dev, PNP_IDX_IO0); + init_uart8250(res0->base, &conf->com2); + break; + case FDC37M60X_KBCK: + res0 = find_resource(dev, PNP_IDX_IO0); + res1 = find_resource(dev, PNP_IDX_IO1); + init_pc_keyboard(res0->base, res1->base, &conf->keyboard); + break; + case FDC37M60X_AUX: /* TODO. */ + break; + } +} + +static struct device_operations ops = { + .read_resources = pnp_read_resources, + .set_resources = pnp_set_resources, + .enable_resources = pnp_enable_resources, + .enable = pnp_enable, + .init = init, +}; + +/* TODO: FDC, PP, AUX. */ +static struct pnp_info pnp_dev_info[] = { + { &ops, FDC37M60X_SP1, PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, }, + { &ops, FDC37M60X_SP2, PNP_IO0 | PNP_IRQ0 | PNP_DRQ0 | PNP_DRQ1, { 0x7f8, 0 }, }, + { &ops, FDC37M60X_KBCK, PNP_IO0 | PNP_IO1 | PNP_IRQ0, { 0x7f8, 0 }, { 0x7f8, 0x4}, }, +}; + +static void enable_dev(struct device *dev) +{ + pnp_enable_devices(dev, &pnp_ops, + sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]), pnp_dev_info); +} + +struct chip_operations superio_smsc_fdc37m60x_ops = { + CHIP_NAME("SMSC FDC37M60X Super I/O") + .enable_dev = enable_dev, +}; + From svn at openbios.org Thu Dec 14 15:32:56 2006 From: svn at openbios.org (LinuxBIOS) Date: Thu, 14 Dec 2006 14:32:56 -0000 Subject: [LinuxBIOS] #59: Support for SMSC FDC37M60X Super I/O In-Reply-To: <060.1a58a28db7ce63bcc4fe01aaa59fc30c@openbios.org> References: <060.1a58a28db7ce63bcc4fe01aaa59fc30c@openbios.org> Message-ID: <069.1df371d7a32b48c1b924905972fc6934@openbios.org> #59: Support for SMSC FDC37M60X Super I/O ----------------------------+----------------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: closed Priority: major | Milestone: Component: code | Version: v2 Resolution: fixed | Keywords: superio Dependencies: | Patchstatus: patch has been committed ----------------------------+----------------------------------------------- Changes (by uwe): * patchstatus: patch is ready to be committed => patch has been committed -- Ticket URL: LinuxBIOS From svn at openbios.org Thu Dec 14 15:54:06 2006 From: svn at openbios.org (svn at openbios.org) Date: Thu, 14 Dec 2006 14:54:06 -0000 Subject: [LinuxBIOS] r2526 - trunk/LinuxBIOSv2/src/southbridge/intel/i82801dbm Message-ID: Author: stepan Date: 2006-12-14 15:54:00 +0100 (Thu, 14 Dec 2006) New Revision: 2526 Modified: trunk/LinuxBIOSv2/src/southbridge/intel/i82801dbm/i82801dbm.c Log: In the file mainboard/intel/i82801dbm/i82801dbm.c the variable southbridge_intel_i82801dbm_control should be named southbridge_intel_i82801dbm_ops. Otherwise a compile error occurs if this device is included in Config.lb of the mainboard. Closes #62 Signed-off-by: Jon Dufresne Acked-by: Stefan Reinauer Modified: trunk/LinuxBIOSv2/src/southbridge/intel/i82801dbm/i82801dbm.c =================================================================== --- trunk/LinuxBIOSv2/src/southbridge/intel/i82801dbm/i82801dbm.c 2006-12-14 14:26:46 UTC (rev 2525) +++ trunk/LinuxBIOSv2/src/southbridge/intel/i82801dbm/i82801dbm.c 2006-12-14 14:54:00 UTC (rev 2526) @@ -59,7 +59,7 @@ } } -struct chip_operations southbridge_intel_i82801dbm_control = { +struct chip_operations southbridge_intel_i82801dbm_ops = { CHIP_NAME("Intel 82801DBM Southbridge") .enable_dev = i82801dbm_enable, }; From segher at kernel.crashing.org Thu Dec 14 15:54:07 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Thu, 14 Dec 2006 15:54:07 +0100 Subject: [LinuxBIOS] pc partitoin magic number not found? In-Reply-To: <376ea3380612131213l13f1008tc4465381094a05cc@mail.gmail.com> References: <20061213175306.GC19078@greenwood> <376ea3380612131213l13f1008tc4465381094a05cc@mail.gmail.com> Message-ID: <5F90742C-4A15-4D36-B29D-53CBBAEDBCB2@kernel.crashing.org> > I know something somewhere isn't right because I get a kernel panic > anytime I modprobe a kernel module that relates to a device in the > southbridge. Any device, or just the AC'97? Same backtrace? > Unable to handle kernel paging request at virtual address 019b2005 > [] __request_region+0x52/0x74 > [] pci_request_region+0x82/0xf2 > [] pci_request_regions+0x14/0x37 > [] snd_intel8x0_create+0x104/0x403 [snd_intel8x0] Try to figure out where that bad address came from (add some printk's)? Segher From svn at openbios.org Thu Dec 14 15:55:20 2006 From: svn at openbios.org (LinuxBIOS) Date: Thu, 14 Dec 2006 14:55:20 -0000 Subject: [LinuxBIOS] #62: Wrong variable causes a compile error In-Reply-To: <060.059f40c036f2712b5793018f74558faf@openbios.org> References: <060.059f40c036f2712b5793018f74558faf@openbios.org> Message-ID: <069.c51ae941dd14f9c1d82485d533d2211e@openbios.org> #62: Wrong variable causes a compile error ------------------------------------------------------+--------------------- Reporter: Jon Dufresne | Owner: somebody Type: defect | Status: closed Priority: major | Milestone: Component: code | Version: v2 Resolution: fixed | Keywords: Dependencies: | Patchstatus: patch has been committed ------------------------------------------------------+--------------------- Changes (by stepan): * patchstatus: patch needs review => patch has been committed -- Ticket URL: LinuxBIOS From jon.dufresne at gmail.com Thu Dec 14 16:31:45 2006 From: jon.dufresne at gmail.com (Jon Dufresne) Date: Thu, 14 Dec 2006 10:31:45 -0500 Subject: [LinuxBIOS] pc partitoin magic number not found? In-Reply-To: <5F90742C-4A15-4D36-B29D-53CBBAEDBCB2@kernel.crashing.org> References: <20061213175306.GC19078@greenwood> <376ea3380612131213l13f1008tc4465381094a05cc@mail.gmail.com> <5F90742C-4A15-4D36-B29D-53CBBAEDBCB2@kernel.crashing.org> Message-ID: <376ea3380612140731k7625a1f0l3270f84be6b2340b@mail.gmail.com> Of the southbridge, I can modprobe ehci, uhci and the ide controller (although none of them work fully, they just don't panic), the ac97 audio and the nic panic. I decided to focus on the ac97 first because the nic is behind a PCI bridge and I wasn't sure if the crash was due ot the nic or the bridge. However, it is very likely that these panic for similar reason. At the bottom of my email I'll paste the kernel panic from modprobing and I'll attach the output from linuxbios and the kernel. I haven't tried to modprobe the ac97 modem and in the end I'll probably disable this device. I'll investigate that address range, thanks for the tip. I tried to get information from this output of the panic, but I wasn't sure exactly what it was trying to tell me. This makes a bit more sense now that you point to this section. Are you saying add printk's to the kernel or to linuxbios? I assume you mean lb. Jon # modprobe snd_intel8x0 Unable to handle kernel paging request at virtual address 019b2005 printing eip: *pde = 00000000 Oops: 0000 [#1] Modules linked in: snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd sounddCPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010202 (2.6.9-42.EL) EIP is at __request_resource+0x24/0x41 eax: 019b2001 ebx: f7a608c0 ecx: c036849c edx: c0004014 esi: f02021ff edi: f0202000 ebp: f0202000 esp: c1a11e80 ds: 007b es: 007b ss: 0068 Process modprobe (pid: 2034, threadinfo=c1a11000 task=c1a2c740) Stack: f7a608c0 c036849c f7a608dc c012a27c dff4c800 00000200 000001ff 00000002 dff4c800 f7a53024 c01f02a0 f7a53024 00000002 f7a53024 dff4c800 f89ac270 c01f033c f7a53000 c1a96c00 dff4c800 f89a7c73 00000001 f7a53000 f7a53000 Call Trace: [] __request_region+0x52/0x74 [] pci_request_region+0x82/0xf2 [] pci_request_regions+0x14/0x37 [] snd_intel8x0_create+0x104/0x403 [snd_intel8x0] [] snd_intel8x0_probe+0xca/0x21a [snd_intel8x0] [] pci_device_probe_static+0x2a/0x3d [] __pci_device_probe+0x1b/0x2c [] pci_device_probe+0x1b/0x2d [] bus_match+0x27/0x45 [] driver_attach+0x37/0x66 [] bus_add_driver+0x77/0x97 [] driver_register+0x51/0x58 [] pci_register_driver+0x85/0xa1 [] alsa_card_intel8x0_init+0xa/0x39 [snd_intel8x0] [] sys_init_module+0xe9/0x1d0 [] syscall_call+0x7/0xb [] xfrm_send_policy_notify+0x61/0x6a Code: 84 36 c0 5b 89 d0 c3 57 89 c1 56 53 8b 7a 04 89 d3 8b 72 08 39 fe 72 2c 3b 79 04 72 27 3b 71 08 77 22 8d 51 18 8b 02 85 c0 74 05 <39> 70 04 76 0c 89 43 <0>Fatal exception: panic in 5 seconds Kernel panic - not syncing: Fatal exception # modprobe e100 Unable to handle kernel paging request at virtual address 019b2005 printing eip: *pde = 00000000 Oops: 0000 [#1] Modules linked in: e100 mii dm_mirror dm_mod floppy ext3 jbd CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010202 (2.6.9-42.EL) EIP is at __request_resource+0x24/0x41 eax: 019b2001 ebx: dfce9520 ecx: c036849c edx: c0004014 esi: f0000fff edi: f0000000 ebp: f0000000 esp: f7a4fe8c ds: 007b es: 007b ss: 0068 Process modprobe (pid: 1984, threadinfo=f7a4f000 task=c1a4f320) Stack: dfce9520 c036849c dfce953c c012a27c dff4c000 00001000 00000fff 00000000 dff4c000 f89932d3 c01f02a0 f89932d3 00000000 f89932d3 dff4c000 f7a9e280 c01f033c 00000000 dff4c044 f7a9e00d f8992146 f7a9e000 f8996164 dff4c000 Call Trace: [] __request_region+0x52/0x74 [] pci_request_region+0x82/0xf2 [] pci_request_regions+0x14/0x37 [] e100_probe+0x193/0x61d [e100] [] dput+0x33/0x423 [] pci_device_probe_static+0x2a/0x3d [] __pci_device_probe+0x1b/0x2c [] pci_device_probe+0x1b/0x2d [] bus_match+0x27/0x45 [] driver_attach+0x37/0x66 [] bus_add_driver+0x77/0x97 [] driver_register+0x51/0x58 [] pci_register_driver+0x85/0xa1 [] e100_init_module+0x41/0x4c [e100] [] sys_init_module+0xe9/0x1d0 [] syscall_call+0x7/0xb Code: 84 36 c0 5b 89 d0 c3 57 89 c1 56 53 8b 7a 04 89 d3 8b 72 08 39 fe 72 2c 3b 79 04 72 27 3b 71 08 77 22 8d 51 18 8b 02 85 c0 74 05 <39> 70 04 76 0c 89 43 <0>Fatal exception: panic in 5 seconds Kernel panic - not syncing: Fatal exception -------------- next part -------------- A non-text attachment was scrubbed... Name: kernel.out Type: application/octet-stream Size: 6646 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: linuxbios.out Type: application/octet-stream Size: 18703 bytes Desc: not available URL: From svn at openbios.org Fri Dec 15 02:22:09 2006 From: svn at openbios.org (LinuxBIOS) Date: Fri, 15 Dec 2006 01:22:09 -0000 Subject: [LinuxBIOS] #14: Rename "stream" to "payload" In-Reply-To: <060.7ce253b9ecf6e23e1d409c7624ff96d8@openbios.org> References: <060.7ce253b9ecf6e23e1d409c7624ff96d8@openbios.org> Message-ID: <069.1e6fc98b42371bbfd4403a08de31f29c@openbios.org> #14: Rename "stream" to "payload" ----------------------------+----------------------------------------------- Reporter: uwe | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: | Keywords: Dependencies: #22 | Patchstatus: there is no patch ----------------------------+----------------------------------------------- Comment (by eswierk at arastra.com): Signed-off-by: Ed Swierk -- Ticket URL: LinuxBIOS From eswierk at arastra.com Fri Dec 15 02:41:30 2006 From: eswierk at arastra.com (Ed Swierk) Date: Thu, 14 Dec 2006 17:41:30 -0800 Subject: [LinuxBIOS] More MCP55 hacking In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA49072D2@ssvlexmb2.amd.com> Message-ID: My latest attempt at MCP55 support can be found at http://www-cs-students.stanford.edu/~eswierk/misc/linuxbios-dfi-lp_ut_nf590.patch . So far it's only been tested on the DFI LANParty UT NF590 motherboard, booting Linux 2.6.19. It obviously needs quite a bit of work, including: - generalizing the CK804 southbridge code; I've simply changed the PCI IDs and hacked on a few functions - un-hardcoding various bus and device numbers in irq_tables.c and mptable.c - reinstating the fallback code that I ripped out in an effort to simplify the build process --Ed From eswierk at arastra.com Fri Dec 15 02:53:51 2006 From: eswierk at arastra.com (Ed Swierk) Date: Thu, 14 Dec 2006 17:53:51 -0800 Subject: [LinuxBIOS] Books on PCI and HyperTransport Message-ID: A few weeks ago I came across a set of books from MindShare, Inc. that proved to be absolute lifesavers during my latest round of LinuxBIOS hacking. It takes some careful reading to extract the bits that are relevant to BIOS programming, but they go a long way towards demystifying PCI device configuration, interrupt routing, and HyperTransport configuration. * PCI System Architecture * HyperTransport System Architecture * Opteron Processors: Breaking Tradition (excerpt from upcoming book on AMD K8 Processor Architecture) I didn't see them referenced on the LinuxBIOS web site; would anyone object to adding these to the Documentation page? Also, let me state for the sake of future poor souls: LDT means HyperTransport. LDT means HyperTransport. LDT means HyperTransport. LDT means HyperTransport. That is all. --Ed From yinghai.lu at amd.com Fri Dec 15 06:54:34 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Thu, 14 Dec 2006 21:54:34 -0800 Subject: [LinuxBIOS] Support for recent chipset and powerful desktop CPU Message-ID: <5986589C150B2F49A46483AC44C7BCA49072EA@ssvlexmb2.amd.com> Please check it you are happy with http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?P roductID=2287&ModelName=GA-M57SLI-S4 I got one, and work well with LinuxBIOS. YH From sxpert at sxpert.org Fri Dec 15 10:29:15 2006 From: sxpert at sxpert.org (raphael Jacquot) Date: Fri, 15 Dec 2006 10:29:15 +0100 Subject: [LinuxBIOS] Commell LV-677* Message-ID: <45826AEB.1020501@sxpert.org> I was looking at this http://www.commell.com.tw/Product/SBC/LV-677.HTM and was wondering if there was any chance for linuxbios support ? From stepan at coresystems.de Fri Dec 15 10:39:19 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 15 Dec 2006 10:39:19 +0100 Subject: [LinuxBIOS] Commell LV-677* In-Reply-To: <45826AEB.1020501@sxpert.org> References: <45826AEB.1020501@sxpert.org> Message-ID: <20061215093919.GA1102@coresystems.de> * raphael Jacquot [061215 10:29]: > I was looking at this > > http://www.commell.com.tw/Product/SBC/LV-677.HTM > > and was wondering if there was any chance for linuxbios support ? i945 is currently not supported. You might start with the 855 and some data sheets if you are tough ;-) I'm sure this list would help you as good as possible. The southbridge will be easy to support, its a 82801GHM (ICH7M). There's a couple of 82801 southbridges already supported and they are all reasonably similar. The big task is the 945 north bridge, which supports DDR2 and the Core Duo/Core 2 Duo. DDR2 is basically supported by the AMD side of LinuxBIOS, you might find some valuable hints there, and some of the code like DDR2 training might be reusable to some extent. Better get yourself a null modem cable, a second flash chip, a cheap burner (or bios savior if you can still get one) and roll up your sleeves ;-) Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From svn at openbios.org Fri Dec 15 12:42:17 2006 From: svn at openbios.org (svn at openbios.org) Date: Fri, 15 Dec 2006 11:42:17 -0000 Subject: [LinuxBIOS] r2527 - in trunk/LinuxBIOSv2: src/arch/i386 src/config src/mainboard/agami/aruma src/mainboard/amd/quartet src/mainboard/amd/rumba src/mainboard/amd/serenade src/mainboard/amd/serengeti_cheetah src/mainboard/amd/serengeti_leopard src/mainboard/amd/solo src/mainboard/arima/hdama src/mainboard/artecgroup/dbe61 src/mainboard/asus/p2b src/mainboard/bitworks/ims src/mainboard/broadcom/blast src/mainboard/dell/s1850 src/mainboard/densitron/dpx114 src/mainboard/digitallogic/adl855pc src/mainboard/digitallogic/msm586seg src/mainboard/digitallogic/msm800sev src/mainboard/eaglelion/5bcm src/mainboard/embeddedplanet/ep405pc src/mainboard/emulation/qemu-i386 src/mainboard/ibm/e325 src/mainboard/ibm/e326 src/mainboard/iei/nova4899r src/mainboard/intel/jarrell src/mainboard/intel/xe7501devkit src/mainboard/iwill/dk8_htx src/mainboard/iwill/dk8s2 src/mainboard/iwill/dk8x src/mainboard/lippert/frontrunner src/mainboard/motorola/sandpointx3_altimus_mpc7410 src/mainboard/msi/ms9185 src/mainboard/newisys/khepri src/mainboard/olpc/btest src/mainboard/olpc/rev_a src/mainboard/sunw/ultra40 src/mainboard/supermicro/x6dai_g src/mainboard/supermicro/x6dhe_g src/mainboard/supermicro/x6dhe_g2 src/mainboard/supermicro/x6dhr_ig src/mainboard/supermicro/x6dhr_ig2 src/mainboard/technologic/ts5300 src/mainboard/totalimpact/briq src/mainboard/tyan/s2735 src/mainboard/tyan/s2850 src/mainboard/tyan/s2875 src/mainboard/tyan/s2880 src/mainboard/tyan/s2881 src/mainboard/tyan/s2882 src/mainboard/tyan/s2885 src/mainboard/tyan/s2891 src/mainboard/tyan/s2892 src/mainboard/tyan/s2895 src/mainboard/tyan/s4880 src/mainboard/tyan/s4882 src/mainboard/via/epia src/mainboard/via/epia-m src/stream targets/artecgroup/dbe61 targets/digitallogic/msm800sev targets/emulation/qemu-i386 targets/iei/nova4899r targets/iwill/dk8_htx targets/olpc/btest targets/olpc/rev_a targets/via/epia-m Message-ID: Author: stepan Date: 2006-12-15 12:42:16 +0100 (Fri, 15 Dec 2006) New Revision: 2527 Modified: trunk/LinuxBIOSv2/src/arch/i386/Config.lb trunk/LinuxBIOSv2/src/config/Options.lb trunk/LinuxBIOSv2/src/mainboard/agami/aruma/Options.lb trunk/LinuxBIOSv2/src/mainboard/amd/quartet/Options.lb trunk/LinuxBIOSv2/src/mainboard/amd/rumba/Options.lb trunk/LinuxBIOSv2/src/mainboard/amd/serenade/Options.lb trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/Options.lb trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/Options.lb trunk/LinuxBIOSv2/src/mainboard/amd/solo/Options.lb trunk/LinuxBIOSv2/src/mainboard/arima/hdama/Options.lb trunk/LinuxBIOSv2/src/mainboard/artecgroup/dbe61/Options.lb trunk/LinuxBIOSv2/src/mainboard/asus/p2b/Options.lb trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/Options.lb trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/Options.lb trunk/LinuxBIOSv2/src/mainboard/dell/s1850/Options.lb trunk/LinuxBIOSv2/src/mainboard/densitron/dpx114/Options.lb trunk/LinuxBIOSv2/src/mainboard/digitallogic/adl855pc/Options.lb trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm586seg/Options.lb trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm800sev/Options.lb trunk/LinuxBIOSv2/src/mainboard/eaglelion/5bcm/Options.lb trunk/LinuxBIOSv2/src/mainboard/embeddedplanet/ep405pc/Options.lb trunk/LinuxBIOSv2/src/mainboard/emulation/qemu-i386/Options.lb trunk/LinuxBIOSv2/src/mainboard/ibm/e325/Options.lb trunk/LinuxBIOSv2/src/mainboard/ibm/e326/Options.lb trunk/LinuxBIOSv2/src/mainboard/iei/nova4899r/Options.lb trunk/LinuxBIOSv2/src/mainboard/intel/jarrell/Options.lb trunk/LinuxBIOSv2/src/mainboard/intel/xe7501devkit/Options.lb trunk/LinuxBIOSv2/src/mainboard/iwill/dk8_htx/Options.lb trunk/LinuxBIOSv2/src/mainboard/iwill/dk8s2/Options.lb trunk/LinuxBIOSv2/src/mainboard/iwill/dk8x/Options.lb trunk/LinuxBIOSv2/src/mainboard/lippert/frontrunner/Options.lb trunk/LinuxBIOSv2/src/mainboard/motorola/sandpointx3_altimus_mpc7410/Options.lb trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/Options.lb trunk/LinuxBIOSv2/src/mainboard/newisys/khepri/Options.lb trunk/LinuxBIOSv2/src/mainboard/olpc/btest/Options.lb trunk/LinuxBIOSv2/src/mainboard/olpc/rev_a/Options.lb trunk/LinuxBIOSv2/src/mainboard/sunw/ultra40/Options.lb trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dai_g/Options.lb trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g/Options.lb trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g2/Options.lb trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig/Options.lb trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig2/Options.lb trunk/LinuxBIOSv2/src/mainboard/technologic/ts5300/Options.lb trunk/LinuxBIOSv2/src/mainboard/totalimpact/briq/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2735/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2850/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2875/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2880/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2881/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2882/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2885/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2891/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2892/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2895/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s4880/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s4882/Options.lb trunk/LinuxBIOSv2/src/mainboard/via/epia-m/Options.lb trunk/LinuxBIOSv2/src/mainboard/via/epia/Options.lb trunk/LinuxBIOSv2/src/stream/rom_stream.c trunk/LinuxBIOSv2/src/stream/serial_stream.c trunk/LinuxBIOSv2/targets/artecgroup/dbe61/Config.lb trunk/LinuxBIOSv2/targets/digitallogic/msm800sev/Config.lb trunk/LinuxBIOSv2/targets/emulation/qemu-i386/Config.OLPC.lb trunk/LinuxBIOSv2/targets/iei/nova4899r/Config.lb trunk/LinuxBIOSv2/targets/iwill/dk8_htx/Config-abuild.lb trunk/LinuxBIOSv2/targets/olpc/btest/Config.lb trunk/LinuxBIOSv2/targets/olpc/rev_a/Config.1M.lb trunk/LinuxBIOSv2/targets/olpc/rev_a/Config.SPI.lb trunk/LinuxBIOSv2/targets/olpc/rev_a/Config.lb trunk/LinuxBIOSv2/targets/via/epia-m/Config.lb Log: Apply linuxbios-rename-compressed-payload-options.patch, refs #14 Signed-off-by: Ed Swierk Acked-by: Stefan Reinauer Modified: trunk/LinuxBIOSv2/src/arch/i386/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/arch/i386/Config.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/arch/i386/Config.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -1,5 +1,5 @@ uses CONFIG_SMP -uses CONFIG_PRECOMPRESSED_ROM_STREAM +uses CONFIG_PRECOMPRESSED_PAYLOAD uses CONFIG_USE_INIT uses HAVE_FAILOVER_BOOT uses USE_FAILOVER_IMAGE @@ -61,11 +61,11 @@ makedefine PAYLOAD-1:=payload # match the case where a compression type is specified. -makedefine PAYLOAD-$(CONFIG_COMPRESSED_ROM_STREAM_NRV2B):=payload.nrv2b -makedefine PAYLOAD-$(CONFIG_COMPRESSED_ROM_STREAM_LZMA):=payload.lzma +makedefine PAYLOAD-$(CONFIG_COMPRESSED_PAYLOAD_NRV2B):=payload.nrv2b +makedefine PAYLOAD-$(CONFIG_COMPRESSED_PAYLOAD_LZMA):=payload.lzma # catch the case where there is precompression. Yes, this bites. -if CONFIG_PRECOMPRESSED_ROM_STREAM +if CONFIG_PRECOMPRESSED_PAYLOAD makedefine PAYLOAD-1:=payload end Modified: trunk/LinuxBIOSv2/src/config/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/config/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/config/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -609,22 +609,17 @@ export always comment "ROM stream start location" end -define CONFIG_COMPRESSED_ROM_STREAM +define CONFIG_COMPRESSED_PAYLOAD_NRV2B default 0 export always - comment "compressed boot image is located in ROM and is assumed to be NRV2B (deprecated)" -end -define CONFIG_COMPRESSED_ROM_STREAM_NRV2B - default 0 - export always comment "NRV2B compressed boot image is located in ROM" end -define CONFIG_COMPRESSED_ROM_STREAM_LZMA +define CONFIG_COMPRESSED_PAYLOAD_LZMA default 0 export always comment "LZMA compressed boot image is located in ROM" end -define CONFIG_PRECOMPRESSED_ROM_STREAM +define CONFIG_PRECOMPRESSED_PAYLOAD default 0 export always comment "boot image is already compressed" Modified: trunk/LinuxBIOSv2/src/mainboard/agami/aruma/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/agami/aruma/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/agami/aruma/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -20,7 +20,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/amd/quartet/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/quartet/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/amd/quartet/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -17,7 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/amd/rumba/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/rumba/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/amd/rumba/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -21,7 +21,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/amd/serenade/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/serenade/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/amd/serenade/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -17,7 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -23,7 +23,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -23,7 +23,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/amd/solo/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/solo/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/amd/solo/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -18,7 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/arima/hdama/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/arima/hdama/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/arima/hdama/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -17,7 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/artecgroup/dbe61/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/artecgroup/dbe61/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/artecgroup/dbe61/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -21,7 +21,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/asus/p2b/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/asus/p2b/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/asus/p2b/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -21,7 +21,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -21,7 +21,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -19,7 +19,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/dell/s1850/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/dell/s1850/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/dell/s1850/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -17,7 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/densitron/dpx114/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/densitron/dpx114/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/densitron/dpx114/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -21,7 +21,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/digitallogic/adl855pc/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/digitallogic/adl855pc/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/digitallogic/adl855pc/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -22,7 +22,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm586seg/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm586seg/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm586seg/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -23,7 +23,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm800sev/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm800sev/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm800sev/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -21,7 +21,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/eaglelion/5bcm/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/eaglelion/5bcm/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/eaglelion/5bcm/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -21,7 +21,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/embeddedplanet/ep405pc/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/embeddedplanet/ep405pc/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/embeddedplanet/ep405pc/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -24,7 +24,7 @@ uses CONFIG_FS_EXT2 uses CONFIG_FS_ISO9660 uses CONFIG_FS_FAT -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses AUTOBOOT_CMDLINE uses CONFIG_SYS_CLK_FREQ uses IDE_BOOT_DRIVE Modified: trunk/LinuxBIOSv2/src/mainboard/emulation/qemu-i386/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/emulation/qemu-i386/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/emulation/qemu-i386/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -6,9 +6,9 @@ uses HAVE_OPTION_TABLE uses USE_OPTION_TABLE uses CONFIG_COMPRESS -uses CONFIG_COMPRESSED_ROM_STREAM_NRV2B -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA -uses CONFIG_PRECOMPRESSED_ROM_STREAM +uses CONFIG_COMPRESSED_PAYLOAD_NRV2B +uses CONFIG_COMPRESSED_PAYLOAD_LZMA +uses CONFIG_PRECOMPRESSED_PAYLOAD uses CONFIG_ROM_STREAM uses IRQ_SLOT_COUNT uses MAINBOARD Modified: trunk/LinuxBIOSv2/src/mainboard/ibm/e325/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/ibm/e325/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/ibm/e325/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -17,7 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/ibm/e326/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/ibm/e326/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/ibm/e326/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -17,7 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/iei/nova4899r/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/iei/nova4899r/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/iei/nova4899r/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -41,9 +41,9 @@ uses CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 uses CONFIG_CONSOLE_VGA uses CONFIG_PCI_ROM_RUN -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA -uses CONFIG_COMPRESSED_ROM_STREAM_NRV2B -uses CONFIG_PRECOMPRESSED_ROM_STREAM +uses CONFIG_COMPRESSED_PAYLOAD_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_NRV2B +uses CONFIG_PRECOMPRESSED_PAYLOAD ## ROM_SIZE is the size of boot ROM that this board will use. default ROM_SIZE = 256*1024 Modified: trunk/LinuxBIOSv2/src/mainboard/intel/jarrell/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/intel/jarrell/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/intel/jarrell/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -17,7 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/intel/xe7501devkit/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/intel/xe7501devkit/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/intel/xe7501devkit/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -10,7 +10,7 @@ uses CONFIG_IOAPIC uses CONFIG_SMP uses CONFIG_ROM_STREAM -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses STACK_SIZE uses HEAP_SIZE uses USE_OPTION_TABLE Modified: trunk/LinuxBIOSv2/src/mainboard/iwill/dk8_htx/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/iwill/dk8_htx/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/iwill/dk8_htx/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -23,7 +23,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/iwill/dk8s2/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/iwill/dk8s2/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/iwill/dk8s2/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -17,7 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/iwill/dk8x/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/iwill/dk8x/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/iwill/dk8x/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -17,7 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/lippert/frontrunner/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/lippert/frontrunner/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/lippert/frontrunner/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -21,7 +21,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/motorola/sandpointx3_altimus_mpc7410/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/motorola/sandpointx3_altimus_mpc7410/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/motorola/sandpointx3_altimus_mpc7410/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -21,7 +21,7 @@ uses CONFIG_FS_EXT2 uses CONFIG_FS_ISO9660 uses CONFIG_FS_FAT -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses AUTOBOOT_CMDLINE uses PAYLOAD_SIZE uses ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -44,7 +44,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/newisys/khepri/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/newisys/khepri/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/newisys/khepri/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -17,7 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/olpc/btest/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/olpc/btest/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/olpc/btest/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -21,9 +21,9 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_NRV2B -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA -uses CONFIG_PRECOMPRESSED_ROM_STREAM +uses CONFIG_COMPRESSED_PAYLOAD_NRV2B +uses CONFIG_COMPRESSED_PAYLOAD_LZMA +uses CONFIG_PRECOMPRESSED_PAYLOAD uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/olpc/rev_a/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/olpc/rev_a/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/olpc/rev_a/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -21,9 +21,9 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_NRV2B -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA -uses CONFIG_PRECOMPRESSED_ROM_STREAM +uses CONFIG_COMPRESSED_PAYLOAD_NRV2B +uses CONFIG_COMPRESSED_PAYLOAD_LZMA +uses CONFIG_PRECOMPRESSED_PAYLOAD uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/sunw/ultra40/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/sunw/ultra40/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/sunw/ultra40/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -18,7 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dai_g/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dai_g/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dai_g/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -17,7 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -17,7 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g2/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g2/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g2/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -17,7 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -17,7 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig2/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig2/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig2/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -17,7 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/technologic/ts5300/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/technologic/ts5300/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/technologic/ts5300/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -23,7 +23,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/totalimpact/briq/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/totalimpact/briq/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/totalimpact/briq/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -19,7 +19,7 @@ uses NO_POST uses CONFIG_CONSOLE_SERIAL8250 uses CONFIG_IDE_STREAM -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses IDE_BOOT_DRIVE uses IDE_SWAB IDE_OFFSET uses ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2735/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2735/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2735/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -19,7 +19,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2850/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2850/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2850/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -18,7 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2875/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2875/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2875/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -18,7 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2880/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2880/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2880/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -18,7 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2881/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2881/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2881/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -18,7 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2882/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2882/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2882/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -18,7 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2885/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2885/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2885/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -18,7 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2891/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2891/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2891/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -18,7 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2892/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2892/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2892/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -18,7 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2895/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2895/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2895/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -21,7 +21,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s4880/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s4880/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s4880/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -18,7 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s4882/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s4882/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s4882/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -18,7 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/via/epia/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/via/epia/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/via/epia/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -29,7 +29,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/via/epia-m/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/via/epia-m/Options.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/mainboard/via/epia-m/Options.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -21,7 +21,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_LZMA +uses CONFIG_COMPRESSED_PAYLOAD_NRV2B uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/stream/rom_stream.c =================================================================== --- trunk/LinuxBIOSv2/src/stream/rom_stream.c 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/stream/rom_stream.c 2006-12-15 11:42:16 UTC (rev 2527) @@ -5,23 +5,23 @@ #include /* if they set the precompressed rom stream, they better have set a type */ -#if CONFIG_PRECOMPRESSED_ROM_STREAM && ((!CONFIG_COMPRESSED_ROM_STREAM) && (!CONFIG_COMPRESSED_ROM_STREAM_NRV2B) && (!CONFIG_COMPRESSED_ROM_STREAM_LZMA)) -#error "You set CONFIG_PRECOMPRESSED_ROM_STREAM but need to set CONFIG_COMPRESSED_ROM_STREAM (implies NRV2B, deprecated) or CONFIG_COMPRESSED_ROM_STREAM_NRV2B or CONFIG_COMPRESSED_ROM_STREAM_LZMA" +#if CONFIG_PRECOMPRESSED_PAYLOAD && ((!CONFIG_COMPRESSED_PAYLOAD_NRV2B) && (!CONFIG_COMPRESSED_PAYLOAD_LZMA)) +#error "You set CONFIG_PRECOMPRESSED_PAYLOAD but need to set CONFIG_COMPRESSED_PAYLOAD_NRV2B or CONFIG_COMPRESSED_PAYLOAD_LZMA" #endif /* If they set ANY of these, then we're compressed */ -#if ((CONFIG_COMPRESSED_ROM_STREAM) || (CONFIG_COMPRESSED_ROM_STREAM_NRV2B) || (CONFIG_COMPRESSED_ROM_STREAM_LZMA)) +#if ((CONFIG_COMPRESSED_PAYLOAD_NRV2B) || (CONFIG_COMPRESSED_PAYLOAD_LZMA)) #define UNCOMPRESSER 1 extern unsigned char _heap, _eheap; #endif -#if (CONFIG_COMPRESSED_ROM_STREAM) || (CONFIG_COMPRESSED_ROM_STREAM_NRV2B) +#if (CONFIG_COMPRESSED_PAYLOAD_NRV2B) #define HAVE_UNCOMPRESSER 1 // include generic nrv2b #include "../lib/nrv2b.c" #endif -#if (CONFIG_COMPRESSED_ROM_STREAM_LZMA) +#if (CONFIG_COMPRESSED_PAYLOAD_LZMA) #if HAVE_UNCOMPRESSER #error "You're defining more than one compression type, which is not allowed (of course)" #endif @@ -53,11 +53,11 @@ unsigned long uncompress(uint8_t * rom_start, uint8_t *dest ) { -#if (CONFIG_COMPRESSED_ROM_STREAM) || (CONFIG_COMPRESSED_ROM_STREAM_NRV2B) +#if (CONFIG_COMPRESSED_PAYLOAD_NRV2B) unsigned long ilen; // used compressed stream length return unrv2b(rom_start, dest, &ilen); #endif -#if (CONFIG_COMPRESSED_ROM_STREAM_LZMA) +#if (CONFIG_COMPRESSED_PAYLOAD_LZMA) return ulzma(rom_start, dest); #endif } Modified: trunk/LinuxBIOSv2/src/stream/serial_stream.c =================================================================== --- trunk/LinuxBIOSv2/src/stream/serial_stream.c 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/src/stream/serial_stream.c 2006-12-15 11:42:16 UTC (rev 2527) @@ -5,16 +5,16 @@ #include /* if they set the precompressed rom stream, they better have set a type */ -#if CONFIG_PRECOMPRESSED_ROM_STREAM && ((!CONFIG_COMPRESSED_ROM_STREAM) && (!CONFIG_COMPRESSED_ROM_STREAM_NRV2B) && (!CONFIG_COMPRESSED_ROM_STREAM_LZMA)) -#error "You set CONFIG_PRECOMPRESSED_ROM_STREAM but need to set CONFIG_COMPRESSED_ROM_STREAM (implies NRV2B, deprecated) or CONFIG_COMPRESSED_ROM_STREAM_NRV2B or CONFIG_COMPRESSED_ROM_STREAM_LZMA" +#if CONFIG_PRECOMPRESSED_PAYLOAD && ((!CONFIG_COMPRESSED_PAYLOAD_NRV2B) && (!CONFIG_COMPRESSED_PAYLOAD_LZMA)) +#error "You set CONFIG_PRECOMPRESSED_PAYLOAD but need to set CONFIG_COMPRESSED_PAYLOAD_NRV2B or CONFIG_COMPRESSED_PAYLOAD_LZMA" #endif -#if (CONFIG_COMPRESSED_ROM_STREAM) || (CONFIG_COMPRESSED_ROM_STREAM_NRV2B) +#if (CONFIG_COMPRESSED_PAYLOAD_NRV2B) #define HAVE_UNCOMPRESSER 1 #include "../lib/nrv2b.c" #endif -#if (CONFIG_COMPRESSED_ROM_STREAM_LZMA) +#if (CONFIG_COMPRESSED_PAYLOAD_LZMA) #if HAVE_UNCOMPRESSER #error "You're defining more than one compression type, which is not allowed (of course)" #endif @@ -33,11 +33,11 @@ #if HAVE_UNCOMPRESSER static unsigned long uncompress(uint8_t *src, uint8_t *dest) { -#if (CONFIG_COMPRESSED_ROM_STREAM) || (CONFIG_COMPRESSED_ROM_STREAM_NRV2B) +#if (CONFIG_COMPRESSED_PAYLOAD_NRV2B) unsigned long ilen; return unrv2b(src, dest, &ilen); #endif -#if (CONFIG_COMPRESSED_ROM_STREAM_LZMA) +#if (CONFIG_COMPRESSED_PAYLOAD_LZMA) return ulzma(src, dest); #endif } Modified: trunk/LinuxBIOSv2/targets/artecgroup/dbe61/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/artecgroup/dbe61/Config.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/targets/artecgroup/dbe61/Config.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -3,7 +3,7 @@ target dbe61 mainboard artecgroup/dbe61 -option CONFIG_COMPRESSED_ROM_STREAM_NRV2B=0 +option CONFIG_COMPRESSED_PAYLOAD_NRV2B=0 ## ROM_SIZE is the total number of bytes allocated for LinuxBIOS use ## (normal AND fallback images and payloads). Modified: trunk/LinuxBIOSv2/targets/digitallogic/msm800sev/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/digitallogic/msm800sev/Config.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/targets/digitallogic/msm800sev/Config.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -3,7 +3,7 @@ target msm800sev mainboard digitallogic/msm800sev -option CONFIG_COMPRESSED_ROM_STREAM_NRV2B=0 +option CONFIG_COMPRESSED_PAYLOAD_NRV2B=0 ## ROM_SIZE is the total number of bytes allocated for LinuxBIOS use ## (normal AND fallback images and payloads). Modified: trunk/LinuxBIOSv2/targets/emulation/qemu-i386/Config.OLPC.lb =================================================================== --- trunk/LinuxBIOSv2/targets/emulation/qemu-i386/Config.OLPC.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/targets/emulation/qemu-i386/Config.OLPC.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -4,8 +4,8 @@ mainboard emulation/qemu-i386 option ROM_SIZE=1024*1024 - (128 * 1024) -option CONFIG_COMPRESSED_ROM_STREAM_LZMA=1 -option CONFIG_PRECOMPRESSED_ROM_STREAM=0 +option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 +option CONFIG_PRECOMPRESSED_PAYLOAD=0 option CC="gcc -m32" Modified: trunk/LinuxBIOSv2/targets/iei/nova4899r/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/iei/nova4899r/Config.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/targets/iei/nova4899r/Config.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -7,9 +7,9 @@ #option ROM_SIZE=256*1024 #from OLPC definitions -option CONFIG_COMPRESSED_ROM_STREAM_NRV2B=1 -#option CONFIG_COMPRESSED_ROM_STREAM_LZMA=1 -#option CONFIG_PRECOMPRESSED_ROM_STREAM=0 +option CONFIG_COMPRESSED_PAYLOAD_NRV2B=1 +#option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 +#option CONFIG_PRECOMPRESSED_PAYLOAD=0 # leave 128k for vsa and 32k for VGA code option ROM_SIZE=(256*1024)-(128*1024)-(32*1024) option FALLBACK_SIZE=ROM_SIZE Modified: trunk/LinuxBIOSv2/targets/iwill/dk8_htx/Config-abuild.lb =================================================================== --- trunk/LinuxBIOSv2/targets/iwill/dk8_htx/Config-abuild.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/targets/iwill/dk8_htx/Config-abuild.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -7,7 +7,7 @@ option CROSS_COMPILE="" option HOSTCC="gcc" -option CONFIG_COMPRESSED_ROM_STREAM_LZMA=1 +option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 romimage "normal" option USE_FALLBACK_IMAGE=0 Modified: trunk/LinuxBIOSv2/targets/olpc/btest/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/olpc/btest/Config.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/targets/olpc/btest/Config.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -4,9 +4,9 @@ mainboard olpc/btest # Don't let LinuxBIOS compress the payload -#option CONFIG_COMPRESSED_ROM_STREAM_NRV2B=0 -#option CONFIG_COMPRESSED_ROM_STREAM_LZMA=1 -#option CONFIG_PRECOMPRESSED_ROM_STREAM=0 +#option CONFIG_COMPRESSED_PAYLOAD_NRV2B=0 +#option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 +#option CONFIG_PRECOMPRESSED_PAYLOAD=0 # leave 64k for vsa and 64k for EC code option ROM_SIZE=(1024*1024)-(64*1024)-(64*1024) Modified: trunk/LinuxBIOSv2/targets/olpc/rev_a/Config.1M.lb =================================================================== --- trunk/LinuxBIOSv2/targets/olpc/rev_a/Config.1M.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/targets/olpc/rev_a/Config.1M.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -4,8 +4,8 @@ mainboard olpc/rev_a # Don't let LinuxBIOS compress the payload -# option CONFIG_COMPRESSED_ROM_STREAM_NRV2B=0 -#option CONFIG_PRECOMPRESSED_ROM_STREAM=1 +# option CONFIG_COMPRESSED_PAYLOAD_NRV2B=0 +#option CONFIG_PRECOMPRESSED_PAYLOAD=1 # leave 64k for vsa option ROM_SIZE=(1024*1024)-(64*1024) Modified: trunk/LinuxBIOSv2/targets/olpc/rev_a/Config.SPI.lb =================================================================== --- trunk/LinuxBIOSv2/targets/olpc/rev_a/Config.SPI.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/targets/olpc/rev_a/Config.SPI.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -4,9 +4,9 @@ mainboard olpc/rev_a # Don't let LinuxBIOS compress the payload -#option CONFIG_COMPRESSED_ROM_STREAM_NRV2B=0 -#option CONFIG_COMPRESSED_ROM_STREAM_LZMA=1 -#option CONFIG_PRECOMPRESSED_ROM_STREAM=0 +#option CONFIG_COMPRESSED_PAYLOAD_NRV2B=0 +#option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 +#option CONFIG_PRECOMPRESSED_PAYLOAD=0 # leave 64k for vsa and 64k for EC code option ROM_SIZE=(1024*1024)-(64*1024)-(64*1024) Modified: trunk/LinuxBIOSv2/targets/olpc/rev_a/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/olpc/rev_a/Config.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/targets/olpc/rev_a/Config.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -4,7 +4,7 @@ mainboard olpc/rev_a # leave 64k for vsa -option CONFIG_COMPRESSED_ROM_STREAM_NRV2B=0 +option CONFIG_COMPRESSED_PAYLOAD_NRV2B=0 option ROM_SIZE=512*1024-64*1024 option FALLBACK_SIZE=ROM_SIZE Modified: trunk/LinuxBIOSv2/targets/via/epia-m/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/via/epia-m/Config.lb 2006-12-14 14:54:00 UTC (rev 2526) +++ trunk/LinuxBIOSv2/targets/via/epia-m/Config.lb 2006-12-15 11:42:16 UTC (rev 2527) @@ -13,8 +13,8 @@ option HAVE_OPTION_TABLE=1 option CONFIG_ROM_STREAM=1 option HAVE_FALLBACK_BOOT=1 -#option CONFIG_COMPRESSED_ROM_STREAM=1 -option CONFIG_COMPRESSED_ROM_STREAM=0 +#option CONFIG_COMPRESSED_PAYLOAD_NRV2B=1 +option CONFIG_COMPRESSED_PAYLOAD_NRV2B=0 ### From info at coresystems.de Fri Dec 15 12:44:43 2006 From: info at coresystems.de (LinuxBIOS information) Date: Fri, 15 Dec 2006 12:44:43 +0100 Subject: [LinuxBIOS] r2527 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "stepan" checked in revision 2527 to the LinuxBIOS source repository and caused the following changes: Change Log: Apply linuxbios-rename-compressed-payload-options.patch, refs #14 Signed-off-by: Ed Swierk Acked-by: Stefan Reinauer Build Log: Configuration of agami:aruma has been broken Configuration of amd:quartet has been broken Configuration of amd:rumba has been broken Configuration of amd:serenade has been broken Configuration of amd:serengeti_cheetah has been broken Configuration of amd:serengeti_leopard has been broken Configuration of amd:solo has been broken Configuration of arima:hdama has been broken Configuration of artecgroup:dbe61 has been broken Configuration of asus:p2b has been broken Configuration of bitworks:ims has been broken Configuration of broadcom:blast has been broken Configuration of dell:s1850 has been broken Configuration of densitron:dpx114 has been broken Configuration of digitallogic:adl855pc has been broken Configuration of digitallogic:msm586seg has been broken Configuration of digitallogic:msm800sev has been broken Configuration of eaglelion:5bcm has been broken Configuration of embeddedplanet:ep405pc has been broken Configuration of emulation:qemu-i386 has been broken Configuration of ibm:e325 has been broken Configuration of ibm:e326 has been broken Configuration of iei:nova4899r has been broken Configuration of intel:jarrell has been broken Configuration of intel:xe7501devkit has been broken Configuration of iwill:dk8s2 has been broken Configuration of iwill:dk8x has been broken Configuration of lippert:frontrunner has been broken Configuration of motorola:sandpointx3_altimus_mpc7410 has been broken Configuration of msi:ms9185 has been broken Configuration of newisys:khepri has been broken Configuration of olpc:btest has been broken Configuration of olpc:rev_a has been broken Configuration of sunw:ultra40 has been broken Configuration of supermicro:x6dai_g has been broken Configuration of supermicro:x6dhe_g has been broken Configuration of supermicro:x6dhe_g2 has been broken Configuration of supermicro:x6dhr_ig has been broken Configuration of supermicro:x6dhr_ig2 has been broken Configuration of technologic:ts5300 has been broken Configuration of totalimpact:briq has been broken Configuration of tyan:s2735 has been broken Configuration of tyan:s2850 has been broken Configuration of tyan:s2875 has been broken Configuration of tyan:s2880 has been broken Configuration of tyan:s2881 has been broken Configuration of tyan:s2882 has been broken Configuration of tyan:s2885 has been broken Configuration of tyan:s2891 has been broken Configuration of tyan:s2892 has been broken Configuration of tyan:s2895 has been broken Configuration of tyan:s4880 has been broken Configuration of tyan:s4882 has been broken Configuration of via:epia has been broken Configuration of via:epia-m has been broken If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision will be backed out. Yours truely, LinuxBIOS automatic build system From svn at openbios.org Fri Dec 15 12:55:59 2006 From: svn at openbios.org (svn at openbios.org) Date: Fri, 15 Dec 2006 11:55:59 -0000 Subject: [LinuxBIOS] r2528 - trunk/LinuxBIOSv2/util/abuild Message-ID: Author: stepan Date: 2006-12-15 12:55:58 +0100 (Fri, 15 Dec 2006) New Revision: 2528 Modified: trunk/LinuxBIOSv2/util/abuild/abuild Log: ouch. always abuild with payloads! trivial fix. Signed-off-by: Stefan Reinauer Acked-by: Stefan Reinauer Modified: trunk/LinuxBIOSv2/util/abuild/abuild =================================================================== --- trunk/LinuxBIOSv2/util/abuild/abuild 2006-12-15 11:42:16 UTC (rev 2527) +++ trunk/LinuxBIOSv2/util/abuild/abuild 2006-12-15 11:55:58 UTC (rev 2528) @@ -168,7 +168,7 @@ fi if [ "`which lzma`" != "" -a "$PAYLOAD" != /dev/null ]; then - COMPRESSION="option CONFIG_COMPRESSED_ROM_STREAM_LZMA=1" + COMPRESSION="option CONFIG_COMPRESSED_PAYLOAD_LZMA=1" else COMPRESSION="# no compression" fi From info at coresystems.de Fri Dec 15 13:42:39 2006 From: info at coresystems.de (LinuxBIOS information) Date: Fri, 15 Dec 2006 13:42:39 +0100 Subject: [LinuxBIOS] r2528 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "stepan" checked in revision 2528 to the LinuxBIOS source repository and caused the following changes: Change Log: ouch. always abuild with payloads! trivial fix. Signed-off-by: Stefan Reinauer Acked-by: Stefan Reinauer Build Log: Configuration of agami:aruma has been fixed Configuration of amd:quartet has been fixed Configuration of amd:rumba has been fixed Configuration of amd:serenade has been fixed Configuration of amd:serengeti_cheetah has been fixed Configuration of amd:serengeti_leopard has been fixed Configuration of amd:solo has been fixed Configuration of arima:hdama has been fixed Configuration of artecgroup:dbe61 has been fixed Configuration of asus:p2b has been fixed Configuration of bitworks:ims has been fixed Configuration of broadcom:blast has been fixed Configuration of dell:s1850 has been fixed Configuration of densitron:dpx114 has been fixed Configuration of digitallogic:adl855pc has been fixed Configuration of digitallogic:msm586seg has been fixed Configuration of digitallogic:msm800sev has been fixed Configuration of eaglelion:5bcm has been fixed Configuration of embeddedplanet:ep405pc has been fixed Configuration of emulation:qemu-i386 has been fixed Configuration of ibm:e325 has been fixed Configuration of ibm:e326 has been fixed Configuration of iei:nova4899r has been fixed Configuration of intel:jarrell has been fixed Configuration of intel:xe7501devkit has been fixed Configuration of iwill:dk8s2 has been fixed Configuration of iwill:dk8x has been fixed Configuration of lippert:frontrunner has been fixed Configuration of motorola:sandpointx3_altimus_mpc7410 has been fixed Configuration of msi:ms9185 has been fixed Configuration of newisys:khepri has been fixed Configuration of olpc:btest has been fixed Configuration of olpc:rev_a has been fixed Configuration of sunw:ultra40 has been fixed Configuration of supermicro:x6dai_g has been fixed Configuration of supermicro:x6dhe_g has been fixed Configuration of supermicro:x6dhe_g2 has been fixed Configuration of supermicro:x6dhr_ig has been fixed Configuration of supermicro:x6dhr_ig2 has been fixed Configuration of technologic:ts5300 has been fixed Configuration of totalimpact:briq has been fixed Configuration of tyan:s2735 has been fixed Configuration of tyan:s2850 has been fixed Configuration of tyan:s2875 has been fixed Configuration of tyan:s2880 has been fixed Configuration of tyan:s2881 has been fixed Configuration of tyan:s2882 has been fixed Configuration of tyan:s2885 has been fixed Configuration of tyan:s2891 has been fixed Configuration of tyan:s2892 has been fixed Configuration of tyan:s2895 has been fixed Configuration of tyan:s4880 has been fixed Configuration of tyan:s4882 has been fixed Configuration of via:epia has been fixed Configuration of via:epia-m is still broken If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision will be backed out. Yours truely, LinuxBIOS automatic build system From svn at openbios.org Fri Dec 15 13:56:29 2006 From: svn at openbios.org (svn at openbios.org) Date: Fri, 15 Dec 2006 12:56:29 -0000 Subject: [LinuxBIOS] r2529 - in trunk/LinuxBIOSv2: documentation documentation/RFC src/arch/i386/lib src/boot src/config src/mainboard/agami/aruma src/mainboard/amd/quartet src/mainboard/amd/rumba src/mainboard/amd/serenade src/mainboard/amd/serengeti_cheetah src/mainboard/amd/serengeti_leopard src/mainboard/amd/solo src/mainboard/arima/hdama src/mainboard/artecgroup/dbe61 src/mainboard/asus/p2b src/mainboard/bitworks/ims src/mainboard/broadcom/blast src/mainboard/dell/s1850 src/mainboard/densitron/dpx114 src/mainboard/digitallogic/adl855pc src/mainboard/digitallogic/msm586seg src/mainboard/digitallogic/msm800sev src/mainboard/eaglelion/5bcm src/mainboard/embeddedplanet/ep405pc src/mainboard/emulation/qemu-i386 src/mainboard/ibm/e325 src/mainboard/ibm/e326 src/mainboard/iei/nova4899r src/mainboard/intel/jarrell src/mainboard/intel/xe7501devkit src/mainboard/iwill/dk8_htx src/mainboard/iwill/dk8s2 src/mainboard/iwill/dk8x src/mainboard/lippert/frontrunner src/mainboard/motorola/sandpoint src/mainboard/motorola/sandpointx3_altimus_mpc7410 src/mainboard/msi/ms9185 src/mainboard/newisys/khepri src/mainboard/olpc/btest src/mainboard/olpc/rev_a src/mainboard/sunw/ultra40 src/mainboard/supermicro/x6dai_g src/mainboard/supermicro/x6dhe_g src/mainboard/supermicro/x6dhe_g2 src/mainboard/supermicro/x6dhr_ig src/mainboard/supermicro/x6dhr_ig2 src/mainboard/technologic/ts5300 src/mainboard/totalimpact/briq src/mainboard/tyan/s2735 src/mainboard/tyan/s2850 src/mainboard/tyan/s2875 src/mainboard/tyan/s2880 src/mainboard/tyan/s2881 src/mainboard/tyan/s2882 src/mainboard/tyan/s2885 src/mainboard/tyan/s2891 src/mainboard/tyan/s2892 src/mainboard/tyan/s2895 src/mainboard/tyan/s4880 src/mainboard/tyan/s4882 src/mainboard/via/epia src/mainboard/via/epia-m src/stream targets/arima/hdama targets/embeddedplanet/ep405pc targets/iwill/dk8s2 targets/motorola/sandpoint targets/newisys/khepri targets/totalimpact/briq targets/via/epia-m Message-ID: Author: stepan Date: 2006-12-15 13:56:28 +0100 (Fri, 15 Dec 2006) New Revision: 2529 Modified: trunk/LinuxBIOSv2/documentation/LinuxBIOS-AMD64.tex trunk/LinuxBIOSv2/documentation/RFC/config.tex trunk/LinuxBIOSv2/src/arch/i386/lib/failover.lds trunk/LinuxBIOSv2/src/arch/i386/lib/failover_failover.lds trunk/LinuxBIOSv2/src/boot/Config.lb trunk/LinuxBIOSv2/src/boot/hardwaremain.c trunk/LinuxBIOSv2/src/config/Options.lb trunk/LinuxBIOSv2/src/mainboard/agami/aruma/Config.lb trunk/LinuxBIOSv2/src/mainboard/agami/aruma/Options.lb trunk/LinuxBIOSv2/src/mainboard/amd/quartet/Config.lb trunk/LinuxBIOSv2/src/mainboard/amd/quartet/Options.lb trunk/LinuxBIOSv2/src/mainboard/amd/rumba/Config.lb trunk/LinuxBIOSv2/src/mainboard/amd/rumba/Options.lb trunk/LinuxBIOSv2/src/mainboard/amd/serenade/Config.lb trunk/LinuxBIOSv2/src/mainboard/amd/serenade/Options.lb trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/Config.lb trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/Options.lb trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/Config.lb trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/Options.lb trunk/LinuxBIOSv2/src/mainboard/amd/solo/Config.lb trunk/LinuxBIOSv2/src/mainboard/amd/solo/Options.lb trunk/LinuxBIOSv2/src/mainboard/arima/hdama/Config.lb trunk/LinuxBIOSv2/src/mainboard/arima/hdama/Options.lb trunk/LinuxBIOSv2/src/mainboard/artecgroup/dbe61/Config.lb trunk/LinuxBIOSv2/src/mainboard/artecgroup/dbe61/Options.lb trunk/LinuxBIOSv2/src/mainboard/asus/p2b/Config.lb trunk/LinuxBIOSv2/src/mainboard/asus/p2b/Options.lb trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/Config.lb trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/Options.lb trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/Config.lb trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/Options.lb trunk/LinuxBIOSv2/src/mainboard/dell/s1850/Config.lb trunk/LinuxBIOSv2/src/mainboard/dell/s1850/Options.lb trunk/LinuxBIOSv2/src/mainboard/densitron/dpx114/Config.lb trunk/LinuxBIOSv2/src/mainboard/densitron/dpx114/Options.lb trunk/LinuxBIOSv2/src/mainboard/digitallogic/adl855pc/Config.lb trunk/LinuxBIOSv2/src/mainboard/digitallogic/adl855pc/Options.lb trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm586seg/Config.lb trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm586seg/Options.lb trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm800sev/Config.lb trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm800sev/Options.lb trunk/LinuxBIOSv2/src/mainboard/eaglelion/5bcm/Config.lb trunk/LinuxBIOSv2/src/mainboard/eaglelion/5bcm/Options.lb trunk/LinuxBIOSv2/src/mainboard/embeddedplanet/ep405pc/Options.lb trunk/LinuxBIOSv2/src/mainboard/emulation/qemu-i386/Config.lb trunk/LinuxBIOSv2/src/mainboard/emulation/qemu-i386/Options.lb trunk/LinuxBIOSv2/src/mainboard/ibm/e325/Config.lb trunk/LinuxBIOSv2/src/mainboard/ibm/e325/Options.lb trunk/LinuxBIOSv2/src/mainboard/ibm/e326/Config.lb trunk/LinuxBIOSv2/src/mainboard/ibm/e326/Options.lb trunk/LinuxBIOSv2/src/mainboard/iei/nova4899r/Config.lb trunk/LinuxBIOSv2/src/mainboard/iei/nova4899r/Options.lb trunk/LinuxBIOSv2/src/mainboard/intel/jarrell/Config.lb trunk/LinuxBIOSv2/src/mainboard/intel/jarrell/Options.lb trunk/LinuxBIOSv2/src/mainboard/intel/xe7501devkit/Config.lb trunk/LinuxBIOSv2/src/mainboard/intel/xe7501devkit/Options.lb trunk/LinuxBIOSv2/src/mainboard/iwill/dk8_htx/Config.lb trunk/LinuxBIOSv2/src/mainboard/iwill/dk8_htx/Options.lb trunk/LinuxBIOSv2/src/mainboard/iwill/dk8s2/Config.lb trunk/LinuxBIOSv2/src/mainboard/iwill/dk8s2/Options.lb trunk/LinuxBIOSv2/src/mainboard/iwill/dk8x/Config.lb trunk/LinuxBIOSv2/src/mainboard/iwill/dk8x/Options.lb trunk/LinuxBIOSv2/src/mainboard/lippert/frontrunner/Config.lb trunk/LinuxBIOSv2/src/mainboard/lippert/frontrunner/Options.lb trunk/LinuxBIOSv2/src/mainboard/motorola/sandpoint/Options.lb trunk/LinuxBIOSv2/src/mainboard/motorola/sandpointx3_altimus_mpc7410/Options.lb trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/Config.lb trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/Options.lb trunk/LinuxBIOSv2/src/mainboard/newisys/khepri/Config.lb trunk/LinuxBIOSv2/src/mainboard/newisys/khepri/Options.lb trunk/LinuxBIOSv2/src/mainboard/olpc/btest/Config.lb trunk/LinuxBIOSv2/src/mainboard/olpc/btest/Options.lb trunk/LinuxBIOSv2/src/mainboard/olpc/rev_a/Config.lb trunk/LinuxBIOSv2/src/mainboard/olpc/rev_a/Options.lb trunk/LinuxBIOSv2/src/mainboard/sunw/ultra40/Config.lb trunk/LinuxBIOSv2/src/mainboard/sunw/ultra40/Options.lb trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dai_g/Config.lb trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dai_g/Options.lb trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g/Config.lb trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g/Options.lb trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g2/Config.lb trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g2/Options.lb trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig/Config.lb trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig/Options.lb trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig2/Config.lb trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig2/Options.lb trunk/LinuxBIOSv2/src/mainboard/technologic/ts5300/Config.lb trunk/LinuxBIOSv2/src/mainboard/technologic/ts5300/Options.lb trunk/LinuxBIOSv2/src/mainboard/totalimpact/briq/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2735/Config.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2735/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2850/Config.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2850/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2875/Config.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2875/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2880/Config.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2880/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2881/Config.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2881/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2882/Config.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2882/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2885/Config.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2885/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2891/Config.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2891/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2892/Config.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2892/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2895/Config.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2895/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s4880/Config.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s4880/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s4882/Config.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s4882/Options.lb trunk/LinuxBIOSv2/src/mainboard/via/epia-m/Config.lb trunk/LinuxBIOSv2/src/mainboard/via/epia-m/Options.lb trunk/LinuxBIOSv2/src/mainboard/via/epia/Config.lb trunk/LinuxBIOSv2/src/mainboard/via/epia/Options.lb trunk/LinuxBIOSv2/src/stream/Config.lb trunk/LinuxBIOSv2/src/stream/rom_stream.c trunk/LinuxBIOSv2/targets/arima/hdama/Config.kernelimage.lb trunk/LinuxBIOSv2/targets/embeddedplanet/ep405pc/Config.lb trunk/LinuxBIOSv2/targets/iwill/dk8s2/Config.lb trunk/LinuxBIOSv2/targets/motorola/sandpoint/Config.lb.ide_stream trunk/LinuxBIOSv2/targets/newisys/khepri/Config.lb trunk/LinuxBIOSv2/targets/totalimpact/briq/Config.lb trunk/LinuxBIOSv2/targets/via/epia-m/Config-abuild.lb trunk/LinuxBIOSv2/targets/via/epia-m/Config.512kflash.lb trunk/LinuxBIOSv2/targets/via/epia-m/Config.etherboot.lb trunk/LinuxBIOSv2/targets/via/epia-m/Config.filo.lb trunk/LinuxBIOSv2/targets/via/epia-m/Config.lb trunk/LinuxBIOSv2/targets/via/epia-m/Config.vga.filo Log: Apply linuxbios-rename-other-payload-options.patch (Patch 2, refs #14) Signed-off-by: Ed Swierk Acked-by: Stefan Reinauer Modified: trunk/LinuxBIOSv2/documentation/LinuxBIOS-AMD64.tex =================================================================== --- trunk/LinuxBIOSv2/documentation/LinuxBIOS-AMD64.tex 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/documentation/LinuxBIOS-AMD64.tex 2006-12-15 12:56:28 UTC (rev 2529) @@ -446,9 +446,9 @@ your mainboard has CMOS memory and you want to use it to store LinuxBIOS parameters (Loglevel, serial line speed, ...) -\item \begin{verbatim}CONFIG_ROM_STREAM\end{verbatim} +\item \begin{verbatim}CONFIG_ROM_PAYLOAD\end{verbatim} -Boot image is located in ROM (as opposed to \texttt{CONFIG\_IDE\_STREAM}, which +Boot image is located in ROM (as opposed to \texttt{CONFIG\_IDE\_PAYLOAD}, which will boot from an IDE disk) \item \begin{verbatim}HAVE_FALLBACK_BOOT\end{verbatim} Modified: trunk/LinuxBIOSv2/documentation/RFC/config.tex =================================================================== --- trunk/LinuxBIOSv2/documentation/RFC/config.tex 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/documentation/RFC/config.tex 2006-12-15 12:56:28 UTC (rev 2529) @@ -262,7 +262,7 @@ ### The linuxBIOS bootloader. ### option PAYLOAD_SIZE = (ROM_SECTION_SIZE - ROM_IMAGE_SIZE) -option CONFIG_ROM_STREAM_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) +option CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) # \end{verbatim} Modified: trunk/LinuxBIOSv2/src/arch/i386/lib/failover.lds =================================================================== --- trunk/LinuxBIOSv2/src/arch/i386/lib/failover.lds 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/arch/i386/lib/failover.lds 2006-12-15 12:56:28 UTC (rev 2529) @@ -1 +1 @@ - __normal_image = (CONFIG_ROM_STREAM_START & 0xfffffff0) - 8; + __normal_image = (CONFIG_ROM_PAYLOAD_START & 0xfffffff0) - 8; Modified: trunk/LinuxBIOSv2/src/arch/i386/lib/failover_failover.lds =================================================================== --- trunk/LinuxBIOSv2/src/arch/i386/lib/failover_failover.lds 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/arch/i386/lib/failover_failover.lds 2006-12-15 12:56:28 UTC (rev 2529) @@ -1,2 +1,2 @@ - __fallback_image = (CONFIG_ROM_STREAM_START & 0xfffffff0) - 8; - __normal_image = ((CONFIG_ROM_STREAM_START - FALLBACK_SIZE) & 0xfffffff0) - 8; + __fallback_image = (CONFIG_ROM_PAYLOAD_START & 0xfffffff0) - 8; + __normal_image = ((CONFIG_ROM_PAYLOAD_START - FALLBACK_SIZE) & 0xfffffff0) - 8; Modified: trunk/LinuxBIOSv2/src/boot/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/boot/Config.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/boot/Config.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -1,5 +1,5 @@ object elfboot.o object hardwaremain.o -if CONFIG_FS_STREAM +if CONFIG_FS_PAYLOAD object filo.o end Modified: trunk/LinuxBIOSv2/src/boot/hardwaremain.c =================================================================== --- trunk/LinuxBIOSv2/src/boot/hardwaremain.c 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/boot/hardwaremain.c 2006-12-15 12:56:28 UTC (rev 2529) @@ -88,7 +88,7 @@ */ lb_mem = write_tables(); -#if CONFIG_FS_STREAM == 1 +#if CONFIG_FS_PAYLOAD == 1 filo(lb_mem); #else elfboot(lb_mem); Modified: trunk/LinuxBIOSv2/src/config/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/config/Options.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/config/Options.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -593,17 +593,17 @@ # Boot options ############################################### -define CONFIG_IDE_STREAM +define CONFIG_IDE_PAYLOAD default 0 export always comment "Boot from IDE device" end -define CONFIG_ROM_STREAM +define CONFIG_ROM_PAYLOAD default 0 export always comment "Boot image is located in ROM" end -define CONFIG_ROM_STREAM_START +define CONFIG_ROM_PAYLOAD_START default {0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1} format "0x%x" export always @@ -624,12 +624,12 @@ export always comment "boot image is already compressed" end -define CONFIG_SERIAL_STREAM +define CONFIG_SERIAL_PAYLOAD default 0 export always comment "Download boot image from serial port" end -define CONFIG_FS_STREAM +define CONFIG_FS_PAYLOAD default 0 export always comment "Boot from a filesystem" Modified: trunk/LinuxBIOSv2/src/mainboard/agami/aruma/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/agami/aruma/Config.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/agami/aruma/Config.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -15,12 +15,12 @@ ## The linuxBIOS bootloader. ## default PAYLOAD_SIZE = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE ) -default CONFIG_ROM_STREAM_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) +default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) ## ## Compute where this copy of linuxBIOS will start in the boot rom ## -default _ROMBASE = ( CONFIG_ROM_STREAM_START + PAYLOAD_SIZE ) +default _ROMBASE = ( CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE ) ## ## Compute a range of ROM that can cached to speed up linuxBIOS, Modified: trunk/LinuxBIOSv2/src/mainboard/agami/aruma/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/agami/aruma/Options.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/agami/aruma/Options.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -18,8 +18,8 @@ uses ROM_IMAGE_SIZE uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET -uses CONFIG_ROM_STREAM -uses CONFIG_ROM_STREAM_START +uses CONFIG_ROM_PAYLOAD +uses CONFIG_ROM_PAYLOAD_START uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE @@ -185,7 +185,7 @@ ## ## Load the payload from the ROM ## -default CONFIG_ROM_STREAM = 1 +default CONFIG_ROM_PAYLOAD = 1 ### ### Defaults of options that you may want to override in the target config file Modified: trunk/LinuxBIOSv2/src/mainboard/amd/quartet/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/quartet/Config.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/amd/quartet/Config.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -15,12 +15,12 @@ ## The linuxBIOS bootloader. ## default PAYLOAD_SIZE = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE ) -default CONFIG_ROM_STREAM_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) +default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) ## ## Compute where this copy of linuxBIOS will start in the boot rom ## -default _ROMBASE = ( CONFIG_ROM_STREAM_START + PAYLOAD_SIZE ) +default _ROMBASE = ( CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE ) ## ## Compute a range of ROM that can cached to speed up linuxBIOS, Modified: trunk/LinuxBIOSv2/src/mainboard/amd/quartet/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/quartet/Options.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/amd/quartet/Options.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -15,8 +15,8 @@ uses ROM_IMAGE_SIZE uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET -uses CONFIG_ROM_STREAM -uses CONFIG_ROM_STREAM_START +uses CONFIG_ROM_PAYLOAD +uses CONFIG_ROM_PAYLOAD_START uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE @@ -145,7 +145,7 @@ ## ## Load the payload from the ROM ## -default CONFIG_ROM_STREAM = 1 +default CONFIG_ROM_PAYLOAD = 1 ### ### Defaults of options that you may want to override in the target config file Modified: trunk/LinuxBIOSv2/src/mainboard/amd/rumba/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/rumba/Config.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/amd/rumba/Config.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -14,13 +14,13 @@ ## Compute the start location and size size of ## The linuxBIOS bootloader. ## -default CONFIG_ROM_STREAM_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) +default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) default PAYLOAD_SIZE = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE ) ## ## Compute where this copy of linuxBIOS will start in the boot rom ## -default _ROMBASE = ( CONFIG_ROM_STREAM_START + PAYLOAD_SIZE ) +default _ROMBASE = ( CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE ) ## ## Compute a range of ROM that can cached to speed up linuxBIOS, Modified: trunk/LinuxBIOSv2/src/mainboard/amd/rumba/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/rumba/Options.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/amd/rumba/Options.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -5,7 +5,7 @@ uses HAVE_HARD_RESET uses HAVE_OPTION_TABLE uses USE_OPTION_TABLE -uses CONFIG_ROM_STREAM +uses CONFIG_ROM_PAYLOAD uses IRQ_SLOT_COUNT uses MAINBOARD uses MAINBOARD_VENDOR @@ -20,7 +20,7 @@ uses ROM_IMAGE_SIZE uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET -uses CONFIG_ROM_STREAM_START +uses CONFIG_ROM_PAYLOAD_START uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE @@ -106,7 +106,7 @@ default _RAMBASE = 0x00004000 -default CONFIG_ROM_STREAM = 1 +default CONFIG_ROM_PAYLOAD = 1 ## ## The default compiler Modified: trunk/LinuxBIOSv2/src/mainboard/amd/serenade/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/serenade/Config.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/amd/serenade/Config.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -15,12 +15,12 @@ ## The linuxBIOS bootloader. ## default PAYLOAD_SIZE = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE ) -default CONFIG_ROM_STREAM_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) +default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) ## ## Compute where this copy of linuxBIOS will start in the boot rom ## -default _ROMBASE = ( CONFIG_ROM_STREAM_START + PAYLOAD_SIZE ) +default _ROMBASE = ( CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE ) ## ## Compute a range of ROM that can cached to speed up linuxBIOS, Modified: trunk/LinuxBIOSv2/src/mainboard/amd/serenade/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/serenade/Options.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/amd/serenade/Options.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -15,8 +15,8 @@ uses ROM_IMAGE_SIZE uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET -uses CONFIG_ROM_STREAM -uses CONFIG_ROM_STREAM_START +uses CONFIG_ROM_PAYLOAD +uses CONFIG_ROM_PAYLOAD_START uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE @@ -144,7 +144,7 @@ ## ## Load the payload from the ROM ## -default CONFIG_ROM_STREAM = 1 +default CONFIG_ROM_PAYLOAD = 1 ### ### Defaults of options that you may want to override in the target config file Modified: trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/Config.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/Config.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -20,12 +20,12 @@ ## The linuxBIOS bootloader. ## default PAYLOAD_SIZE = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE ) -default CONFIG_ROM_STREAM_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) +default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) ## ## Compute where this copy of linuxBIOS will start in the boot rom ## -default _ROMBASE = ( CONFIG_ROM_STREAM_START + PAYLOAD_SIZE ) +default _ROMBASE = ( CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE ) ## ## Compute a range of ROM that can cached to speed up linuxBIOS, Modified: trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/Options.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/Options.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -21,8 +21,8 @@ uses ROM_IMAGE_SIZE uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET -uses CONFIG_ROM_STREAM -uses CONFIG_ROM_STREAM_START +uses CONFIG_ROM_PAYLOAD +uses CONFIG_ROM_PAYLOAD_START uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE @@ -265,7 +265,7 @@ ## ## Load the payload from the ROM ## -default CONFIG_ROM_STREAM = 1 +default CONFIG_ROM_PAYLOAD = 1 ### ### Defaults of options that you may want to override in the target config file Modified: trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/Config.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/Config.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -20,12 +20,12 @@ ## The linuxBIOS bootloader. ## default PAYLOAD_SIZE = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE ) -default CONFIG_ROM_STREAM_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) +default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) ## ## Compute where this copy of linuxBIOS will start in the boot rom ## -default _ROMBASE = ( CONFIG_ROM_STREAM_START + PAYLOAD_SIZE ) +default _ROMBASE = ( CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE ) ## ## Compute a range of ROM that can cached to speed up linuxBIOS, Modified: trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/Options.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/Options.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -21,8 +21,8 @@ uses ROM_IMAGE_SIZE uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET -uses CONFIG_ROM_STREAM -uses CONFIG_ROM_STREAM_START +uses CONFIG_ROM_PAYLOAD +uses CONFIG_ROM_PAYLOAD_START uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE @@ -245,7 +245,7 @@ ## ## Load the payload from the ROM ## -default CONFIG_ROM_STREAM = 1 +default CONFIG_ROM_PAYLOAD = 1 ### ### Defaults of options that you may want to override in the target config file Modified: trunk/LinuxBIOSv2/src/mainboard/amd/solo/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/solo/Config.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/amd/solo/Config.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -15,12 +15,12 @@ ## The linuxBIOS bootloader. ## default PAYLOAD_SIZE = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE ) -default CONFIG_ROM_STREAM_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) +default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) ## ## Compute where this copy of linuxBIOS will start in the boot rom ## -default _ROMBASE = ( CONFIG_ROM_STREAM_START + PAYLOAD_SIZE ) +default _ROMBASE = ( CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE ) ## ## Compute a range of ROM that can cached to speed up linuxBIOS, Modified: trunk/LinuxBIOSv2/src/mainboard/amd/solo/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/solo/Options.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/amd/solo/Options.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -16,8 +16,8 @@ uses ROM_IMAGE_SIZE uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET -uses CONFIG_ROM_STREAM -uses CONFIG_ROM_STREAM_START +uses CONFIG_ROM_PAYLOAD +uses CONFIG_ROM_PAYLOAD_START uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE @@ -146,7 +146,7 @@ ## ## Load the payload from the ROM ## -default CONFIG_ROM_STREAM = 1 +default CONFIG_ROM_PAYLOAD = 1 ### ### Defaults of options that you may want to override in the target config file Modified: trunk/LinuxBIOSv2/src/mainboard/arima/hdama/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/arima/hdama/Config.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/arima/hdama/Config.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -15,12 +15,12 @@ ## The linuxBIOS bootloader. ## default PAYLOAD_SIZE = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE ) -default CONFIG_ROM_STREAM_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) +default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) ## ## Compute where this copy of linuxBIOS will start in the boot rom ## -default _ROMBASE = ( CONFIG_ROM_STREAM_START + PAYLOAD_SIZE ) +default _ROMBASE = ( CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE ) ## ## Compute a range of ROM that can cached to speed up linuxBIOS, Modified: trunk/LinuxBIOSv2/src/mainboard/arima/hdama/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/arima/hdama/Options.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/arima/hdama/Options.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -15,8 +15,8 @@ uses ROM_IMAGE_SIZE uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET -uses CONFIG_ROM_STREAM -uses CONFIG_ROM_STREAM_START +uses CONFIG_ROM_PAYLOAD +uses CONFIG_ROM_PAYLOAD_START uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE @@ -163,7 +163,7 @@ ## ## Load the payload from the ROM ## -default CONFIG_ROM_STREAM = 1 +default CONFIG_ROM_PAYLOAD = 1 ### ### Defaults of options that you may want to override in the target config file Modified: trunk/LinuxBIOSv2/src/mainboard/artecgroup/dbe61/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/artecgroup/dbe61/Config.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/artecgroup/dbe61/Config.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -14,13 +14,13 @@ ## Compute the start location and size size of ## The linuxBIOS bootloader. ## -default CONFIG_ROM_STREAM_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) +default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) default PAYLOAD_SIZE = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE ) ## ## Compute where this copy of linuxBIOS will start in the boot rom ## -default _ROMBASE = ( CONFIG_ROM_STREAM_START + PAYLOAD_SIZE ) +default _ROMBASE = ( CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE ) ## ## Compute a range of ROM that can cached to speed up linuxBIOS, Modified: trunk/LinuxBIOSv2/src/mainboard/artecgroup/dbe61/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/artecgroup/dbe61/Options.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/artecgroup/dbe61/Options.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -5,7 +5,7 @@ uses HAVE_HARD_RESET uses HAVE_OPTION_TABLE uses USE_OPTION_TABLE -uses CONFIG_ROM_STREAM +uses CONFIG_ROM_PAYLOAD uses IRQ_SLOT_COUNT uses MAINBOARD uses MAINBOARD_VENDOR @@ -20,7 +20,7 @@ uses ROM_IMAGE_SIZE uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET -uses CONFIG_ROM_STREAM_START +uses CONFIG_ROM_PAYLOAD_START uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE @@ -113,7 +113,7 @@ default _RAMBASE = 0x00004000 -default CONFIG_ROM_STREAM = 1 +default CONFIG_ROM_PAYLOAD = 1 ## ## The default compiler Modified: trunk/LinuxBIOSv2/src/mainboard/asus/p2b/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/asus/p2b/Config.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/asus/p2b/Config.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -14,13 +14,13 @@ ## Compute the start location and size size of ## The linuxBIOS bootloader. ## -default CONFIG_ROM_STREAM_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) +default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) default PAYLOAD_SIZE = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE ) ## ## Compute where this copy of linuxBIOS will start in the boot rom ## -default _ROMBASE = ( CONFIG_ROM_STREAM_START + PAYLOAD_SIZE ) +default _ROMBASE = ( CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE ) ## ## Compute a range of ROM that can cached to speed up linuxBIOS, Modified: trunk/LinuxBIOSv2/src/mainboard/asus/p2b/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/asus/p2b/Options.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/asus/p2b/Options.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -5,7 +5,7 @@ uses HAVE_HARD_RESET uses HAVE_OPTION_TABLE uses USE_OPTION_TABLE -uses CONFIG_ROM_STREAM +uses CONFIG_ROM_PAYLOAD uses IRQ_SLOT_COUNT uses MAINBOARD uses MAINBOARD_VENDOR @@ -20,7 +20,7 @@ uses ROM_IMAGE_SIZE uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET -uses CONFIG_ROM_STREAM_START +uses CONFIG_ROM_PAYLOAD_START uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE @@ -100,7 +100,7 @@ default _RAMBASE = 0x00004000 -default CONFIG_ROM_STREAM = 1 +default CONFIG_ROM_PAYLOAD = 1 ## ## The default compiler Modified: trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/Config.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/Config.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -14,13 +14,13 @@ ## Compute the start location and size size of ## The linuxBIOS bootloader. ## -default CONFIG_ROM_STREAM_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) +default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) default PAYLOAD_SIZE = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE ) ## ## Compute where this copy of linuxBIOS will start in the boot rom ## -default _ROMBASE = ( CONFIG_ROM_STREAM_START + PAYLOAD_SIZE ) +default _ROMBASE = ( CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE ) ## ## Compute a range of ROM that can cached to speed up linuxBIOS, Modified: trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/Options.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/Options.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -5,7 +5,7 @@ uses HAVE_HARD_RESET uses HAVE_OPTION_TABLE uses USE_OPTION_TABLE -uses CONFIG_ROM_STREAM +uses CONFIG_ROM_PAYLOAD uses IRQ_SLOT_COUNT uses MAINBOARD uses MAINBOARD_VENDOR @@ -20,7 +20,7 @@ uses ROM_IMAGE_SIZE uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET -uses CONFIG_ROM_STREAM_START +uses CONFIG_ROM_PAYLOAD_START uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE @@ -100,7 +100,7 @@ default _RAMBASE = 0x00004000 -default CONFIG_ROM_STREAM = 1 +default CONFIG_ROM_PAYLOAD = 1 ## ## The default compiler Modified: trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/Config.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/Config.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -15,12 +15,12 @@ ## The linuxBIOS bootloader. ## default PAYLOAD_SIZE = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE ) -default CONFIG_ROM_STREAM_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) +default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) ## ## Compute where this copy of linuxBIOS will start in the boot rom ## -default _ROMBASE = ( CONFIG_ROM_STREAM_START + PAYLOAD_SIZE ) +default _ROMBASE = ( CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE ) ## ## Compute a range of ROM that can cached to speed up linuxBIOS, Modified: trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/Options.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/Options.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -17,8 +17,8 @@ uses ROM_IMAGE_SIZE uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET -uses CONFIG_ROM_STREAM -uses CONFIG_ROM_STREAM_START +uses CONFIG_ROM_PAYLOAD +uses CONFIG_ROM_PAYLOAD_START uses CONFIG_COMPRESSED_PAYLOAD_LZMA uses PAYLOAD_SIZE uses _ROMBASE @@ -196,7 +196,7 @@ ## ## Load the payload from the ROM ## -default CONFIG_ROM_STREAM = 1 +default CONFIG_ROM_PAYLOAD = 1 ### ### Defaults of options that you may want to override in the target config file Modified: trunk/LinuxBIOSv2/src/mainboard/dell/s1850/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/dell/s1850/Config.lb 2006-12-15 11:55:58 UTC (rev 2528) +++ trunk/LinuxBIOSv2/src/mainboard/dell/s1850/Config.lb 2006-12-15 12:56:28 UTC (rev 2529) @@ -20,12 +20,12 @@ ## The linuxBIOS bootloader. ## default PAYLOAD_SIZE = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE ) -default CONFIG_ROM_STREAM_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) +default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) ## ## Compute where this copy of linuxBIOS will start in the boot rom ## -default _ROMBASE = ( CONFIG_ROM_STREAM_START + PAYLOAD_SIZE ) +default _ROMBASE = ( CONFIG_RO