From joe at smittys.pointclark.net Sat Sep 1 00:37:54 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Fri, 31 Aug 2007 18:37:54 -0400 Subject: [LinuxBIOS] addr_offset help In-Reply-To: <46D87340.7000802@gmail.com> References: <20070831144044.2dn6o3jg0ook80kw@www.smittys.pointclark.net> <46D87340.7000802@gmail.com> Message-ID: <20070831183754.b7c3bytw08cks8oo@www.smittys.pointclark.net> Quoting Corey Osgood : > Joseph Smith wrote: >> Can someone explain the significance of the addr_offset variable in >> raminit.c on the i440bx and i82810? Also why is this set to 0x1d0 for >> the Mode register set (MRS)? >> >> Thanks - Joe >> >> > > MRS is a setting within the ram that's set by reading from a certain > location while the northbridge is in MRS mode. It essentially tells the > ram what timings to run at. For the most part, the only values you'll > ever need for SDRAM are 0x1d0 for CL3 and 0x150 for CL2, but DDR and > DDR2 make more advanced use of MRS and E(xtended)MRS. Read the JEDEC > standard for more info. > > -Corey > Thanks Corey, that makes sense. Not sure how it tells the memory what timings to run at though. Does it tell the northbridge what timings to run at? Thanks - Joe From corey.osgood at gmail.com Sat Sep 1 05:25:35 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Fri, 31 Aug 2007 23:25:35 -0400 Subject: [LinuxBIOS] addr_offset help In-Reply-To: <20070831183754.b7c3bytw08cks8oo@www.smittys.pointclark.net> References: <20070831144044.2dn6o3jg0ook80kw@www.smittys.pointclark.net> <46D87340.7000802@gmail.com> <20070831183754.b7c3bytw08cks8oo@www.smittys.pointclark.net> Message-ID: <46D8DBAF.6060708@gmail.com> Joseph Smith wrote: > Quoting Corey Osgood : > >> Joseph Smith wrote: >>> Can someone explain the significance of the addr_offset variable in >>> raminit.c on the i440bx and i82810? Also why is this set to 0x1d0 for >>> the Mode register set (MRS)? >>> >>> Thanks - Joe >>> >>> >> >> MRS is a setting within the ram that's set by reading from a certain >> location while the northbridge is in MRS mode. It essentially tells the >> ram what timings to run at. For the most part, the only values you'll >> ever need for SDRAM are 0x1d0 for CL3 and 0x150 for CL2, but DDR and >> DDR2 make more advanced use of MRS and E(xtended)MRS. Read the JEDEC >> standard for more info. >> >> -Corey >> > Thanks Corey, that makes sense. Not sure how it tells the memory what > timings to run at though. Does it tell the northbridge what timings to > run at? > > Thanks - Joe > No. The northbridge should have the timing programmed in to some register(s). The ram then needs to be told *the same* timings that the northbridge is told for correct operation, otherwise you end up with them trying to run out of sync. The memory is told what timings to run at by putting the northbridge (which also puts the ram) into MRS mode and reading from an offset, one of the two I've given above. The values are derived from the bits explained here: http://www.jedec.org/download/search/3_11_05_01R12.pdf (page 6). You can see there that those values also correspond with sequential burst and a burst length of 2 (which I didn't know until I looked this up!). In the 440bx and i810 ports we use CL3, so it should be safe for any memory stick, optimizing memory timings should be one of those things to do after everything else works, IMO. -Corey From corey.osgood at gmail.com Sat Sep 1 05:37:44 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Fri, 31 Aug 2007 23:37:44 -0400 Subject: [LinuxBIOS] [PATCH] Initial support for the MSI MS-6178 (i810-based) In-Reply-To: <46D81B7D.2010405@gmx.de> References: <20070830194234.GA7091@greenwood> <46D78E6D.9080201@gmail.com> <20070831091956.GA9039@greenwood> <46D81B7D.2010405@gmx.de> Message-ID: <46D8DE88.5060308@gmail.com> popkonserve wrote: >> 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f >> --------------------------------------------------- >> 00: 86 80 20 71 06 01 80 20 03 00 00 06 00 00 00 00 >> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 50: 60 ff 0a 20 00 00 00 00 00 00 00 00 00 00 00 00 >> 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 90: 00 00 da 77 00 00 00 00 00 00 00 00 00 00 00 00 >> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> f0: 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 >> > > - the refresh (offset 53h) should be 15,6?s instead of 7,8?s which > should only be used for high density rams (>256MB) > No, 0x20 is correct, bit 5 is the only bit flipped. > - CL, SRCD and SRP (offset 53h) are unconfigured. either read them from > the spd or configure them by performing read/write tests > No, they're configured to the slowest and safest possible timings. I haven't gotten to optimizing it yet. > - the onboard vga (offset 70h) is left unconfigured and thus disabling it > But there are some commented lines of code to enable vga. I just never got to messing around with it. > - MISCC2 (offset 80h) is left unconfigured. the datasheet says for some > bits: Do NOT program to 0. > MISCC2 is for VGA. See above. > regarding the L2 cache on the cpu read the following: > > page 7: > http://www.cs.inf.ethz.ch/stricker/lab/doc/intel-part4.pdf > > line 473ff > http://fxr.watson.org/fxr/source/i386/i386/initcpu.c?v=RELENG4 > > Holger I'll look into these later, but I suspect x86_enable_cache() does something similar. -Corey From corey.osgood at gmail.com Sat Sep 1 05:55:48 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Fri, 31 Aug 2007 23:55:48 -0400 Subject: [LinuxBIOS] [PATCH] Initial support for the MSI MS-6178 (i810-based) In-Reply-To: <20070831091956.GA9039@greenwood> References: <20070830194234.GA7091@greenwood> <46D78E6D.9080201@gmail.com> <20070831091956.GA9039@greenwood> Message-ID: <46D8E2C4.8020209@gmail.com> Uwe Hermann wrote: > On Thu, Aug 30, 2007 at 11:43:41PM -0400, Corey Osgood wrote: > >>> I guess (from looking at the boot log diffs) that this may be the reason >>> for the slow boot, but how do I fix it? >>> >>> CPU: L1 I cache: 16K, L1 D cache: 16K >>> -CPU: L2 cache: 128K >>> >>> (i.e., it seems the L2 cache is never enabled when using LinuxBIOS) >>> >>> >> Is your cpu id in model_6xx_init.c? I'm not seeing any attempt even at >> cpu init in the LB boot log, and IIRC there should be something printed. >> And if I'm reading the kernel boot log right, your model ID is 0x06a5, >> which isn't currently in there and not added by your patch. I'll fire up >> the mew-vm tomorrow and see if it has the same problem, the boot on that >> board is slow but not that slow, I figured it was just my old 400MHz >> celeron running over a serial connection. >> > > I checked that, but it looks correct to me. If I'm not mistaken I have > a 0x0665 (Mendocino), but maybe I got the format of those IDs wrong? > > See CPU info below: > > $ proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 6 > model name : Celeron (Mendocino) > stepping : 5 > cpu MHz : 434.356 > cache size : 128 KB > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 2 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr up > bogomips : 869.78 > clflush size : 32 > > > $ cpuid > eax in eax ebx ecx edx > 00000000 00000002 756e6547 6c65746e 49656e69 > 00000001 00000665 00000000 00000000 0183f9ff > 00000002 03020101 00000000 00000000 0c040841 > > Vendor ID: "GenuineIntel"; CPUID level 2 > > Intel-specific functions: > Version 00000665: > Type 0 - Original OEM > Family 6 - Pentium Pro > Model 6 - Celeron > Stepping 5 > Reserved 0 > > > Feature flags 0183f9ff: > FPU Floating Point Unit > VME Virtual 8086 Mode Enhancements > DE Debugging Extensions > PSE Page Size Extensions > TSC Time Stamp Counter > MSR Model Specific Registers > PAE Physical Address Extension > MCE Machine Check Exception > CX8 COMPXCHG8B Instruction > SEP Fast System Call > MTRR Memory Type Range Registers > PGE PTE Global Flag > MCA Machine Check Architecture > CMOV Conditional Move and Compare Instructions > FGPAT Page Attribute Table > PSE-36 36-bit Page Size Extension > MMX MMX instruction set > FXSR Fast FP/MMX Streaming SIMD Extensions save/restore > > TLB and cache info: > 01: Instruction TLB: 4KB pages, 4-way set assoc, 32 entries > 02: Instruction TLB: 4MB pages, 4-way set assoc, 2 entries > 03: Data TLB: 4KB pages, 4-way set assoc, 64 entries > 41: 2nd-level cache: 128KB, 4-way set assoc, 32 byte line size > 08: 1st-level instruction cache: 16KB, 4-way set assoc, 32 byte line size > 04: Data TLB: 4MB pages, 4-way set assoc, 8 entries > 0c: 1st-level data cache: 16KB, 4-way set assoc, 32 byte line size > > > $ x86info -a > x86info v1.20. Dave Jones 2001-2006 > Feedback to . > > Found 1 CPU > -------------------------------------------------------------------------- > eax in: 0x00000000, eax = 00000002 ebx = 756e6547 ecx = 6c65746e edx = 49656e69 > eax in: 0x00000001, eax = 00000665 ebx = 00000000 ecx = 00000000 edx = 0183f9ff > eax in: 0x00000002, eax = 03020101 ebx = 00000000 ecx = 00000000 edx = 0c040841 > > Family: 6 Model: 6 Stepping: 5 Type: 0 Brand: 0 > CPU Model: Celeron (Mendocino) Original OEM > Feature flags: > fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr > > Cache info > L1 Instruction cache: 16KB, 4-way associative. 32 byte line size. > L1 Data cache: 16KB, 4-way associative. 32 byte line size. > L2 unified cache: 128KB, 4-way associative. 32 byte line size. > TLB info > Instruction TLB: 4KB pages, 4-way associative, 32 entries > Instruction TLB: 4MB pages, fully associative, 2 entries > Data TLB: 4KB pages, 4-way associative, 64 entries > Data TLB: 4MB pages, 4-way associative, 8 entries > (null) > Connector type: Socket 370 (370 Pin PGA) > > > MTRR registers: > MTRRcap (0xfe): MTRRphysBase0 (0x200): MTRRphysMask0 (0x201): MTRRphysBase1 (0x202): MTRRphysMask1 (0x203): MTRRphysBase2 (0x204): MTRRphysMask2 (0x205): MTRRphysBase3 (0x206): MTRRphysMask3 (0x207): MTRRphysBase4 (0x208): MTRRphysMask4 (0x209): MTRRphysBase5 (0x20a): MTRRphysMask5 (0x20b): MTRRphysBase6 (0x20c): MTRRphysMask6 (0x20d): MTRRphysBase7 (0x20e): MTRRphysMask7 (0x20f): MTRRfix64K_00000 (0x250): MTRRfix16K_80000 (0x258): MTRRfix16K_A0000 (0x259): MTRRfix4K_C8000 (0x269): MTRRfix4K_D0000 0x26a: MTRRfix4K_D8000 0x26b: MTRRfix4K_E0000 0x26c: MTRRfix4K_E8000 0x26d: MTRRfix4K_F0000 0x26e: MTRRfix4K_F8000 0x26f: MTRRdefType (0x2ff): > > 450MHz processor (estimate). > > > >>> $ lspci -xxx >>> >>> 00:00.0 Host bridge: Intel Corporation 82810 GMCH [Graphics Memory Controller Hub] (rev 03) >>> 00: 86 80 20 71 06 00 80 20 03 00 00 06 00 00 00 00 >>> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 20 71 >>> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 50: 68 51 a0 3c 00 00 00 00 00 00 00 00 00 00 00 00 >>> 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 70: cc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 80: c6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 90: 00 00 9a dd 00 00 00 00 00 00 00 00 00 00 00 00 >>> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> f0: 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 >>> >> Can you send lspci -xxx from linuxbios? I really can't see anything too >> alarming in the boot logs, although I could be overlooking it. >> > > Sure. > > 00: 86 80 20 71 06 01 80 20 03 00 00 06 00 00 00 00 > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 50: 60 ff 0a 20 00 00 00 00 00 00 00 00 00 00 00 00 > 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 90: 00 00 da 77 00 00 00 00 00 00 00 00 00 00 00 00 > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 > > I already tried playing a bit with the northbridge > registers and RAM init (GMCHCFG, DRAMT, BUFF_SC etc.) > but that doesn't seem to have much influence. > I think it's BUFF_SC, can you use the factory value for this? It's 0x92 btw, so you don't have to look it up. I used a single sided 128mb stick to get that value, and then tested it with about 5 other similar sticks, only 1 passed ram_check but hung while copying LB. And just realized something else, directly related to the email I just sent for Joe. Please change the MRS value from 0x1d0 to 0xad0. Heh, that could seriously bork things up, my bad. >> Can you also try memtest86? >> > > I already did, and it works, it's just very slow. > > * Memtest86 with vendor BIOS: > 229 MB/s, L1: 4256 MB/s, L2: 1116 MB/s > > * Memtest with LinuxBIOS: > 16 MB/s, L1: 16 MB/s, L2: off (?) > Eww, you weren't kidding. Hopefully the above will take care of the mem issue, not sure about the L2 cache still. Can you put a printk into model_6xx_init so you can see if it's actually running or not? I'll fire up the mem-vm tomorrow, I've got a new bios savior to try on it anyways. -Corey From popkonserve at gmx.de Sat Sep 1 08:28:54 2007 From: popkonserve at gmx.de (popkonserve) Date: Sat, 01 Sep 2007 08:28:54 +0200 Subject: [LinuxBIOS] [PATCH] Initial support for the MSI MS-6178 (i810-based) In-Reply-To: <46D8DE88.5060308@gmail.com> References: <20070830194234.GA7091@greenwood> <46D78E6D.9080201@gmail.com> <20070831091956.GA9039@greenwood> <46D81B7D.2010405@gmx.de> <46D8DE88.5060308@gmail.com> Message-ID: <46D906A6.40702@gmx.de> >>- the refresh (offset 53h) should be 15,6?s instead of 7,8?s which >>should only be used for high density rams (>256MB) >> > No, 0x20 is correct, bit 5 is the only bit flipped. oops, sorry, you are right... >>- CL, SRCD and SRP (offset 53h) are unconfigured. either read them from >>the spd or configure them by performing read/write tests >> > No, they're configured to the slowest and safest possible timings. I > haven't gotten to optimizing it yet. yeah, that's what i thought, too. but if you're able to read the values from the spd it should be no problem setting them!? >>page 7: >>http://www.cs.inf.ethz.ch/stricker/lab/doc/intel-part4.pdf >> >>line 473ff >>http://fxr.watson.org/fxr/source/i386/i386/initcpu.c?v=RELENG4 >> > I'll look into these later, but I suspect x86_enable_cache() does > something similar. hmm, no. actually x86_enable_cache() just emits a post code, prints some info and calls enable_cache() which is an inline in cache.h which just enables L1 cache by flipping a bit in the processor configuration register 0 (CR0). that's all. it should be renamed to enable_L1_cache() to avoid confusion. the L2 cache can not be enabled in CR0. just take a look at the code and you'll see. Holger From svn at openbios.org Sat Sep 1 13:10:56 2007 From: svn at openbios.org (svn at openbios.org) Date: Sat, 1 Sep 2007 13:10:56 +0200 Subject: [LinuxBIOS] r2756 - in trunk: LinuxBIOSv2/util util Message-ID: Author: uwe Date: 2007-09-01 13:10:56 +0200 (Sat, 01 Sep 2007) New Revision: 2756 Added: trunk/util/getpir/ trunk/util/mptable/ Removed: trunk/LinuxBIOSv2/util/getpir/ trunk/LinuxBIOSv2/util/mptable/ Log: Move getpir and mptable into the global util/ directory. Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Copied: trunk/util/getpir (from rev 2755, trunk/LinuxBIOSv2/util/getpir) Copied: trunk/util/mptable (from rev 2755, trunk/LinuxBIOSv2/util/mptable) From uwe at hermann-uwe.de Sat Sep 1 13:12:00 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 1 Sep 2007 13:12:00 +0200 Subject: [LinuxBIOS] [PATCH] Move common utilities to util/ In-Reply-To: <46D70676.7020903@gmx.net> References: <20070827081648.GB12926@greenwood> <20070827083317.GA31146@coresystems.de> <20070830113735.GV7091@greenwood> <46D70676.7020903@gmx.net> Message-ID: <20070901111200.GA23469@greenwood> On Thu, Aug 30, 2007 at 08:03:34PM +0200, Carl-Daniel Hailfinger wrote: > On 30.08.2007 13:37, Uwe Hermann wrote: > > So here's the updated plan: > > > > - Move probe_superio to util/superio-detect (rename it while we're at it). > > It does much more than detection these days. It also has the ability to > verify and dump SuperI/O configuration. Can we think about the name a > little bit more? 'superiotool'. And then add an interface like this: $ superiotool --detect IT8712F $ superiotool --dump [...] $ superiotool --verify etc... > > - Move getpir to util/. > > - Move mptable to util/. > > > > Everything else stays where it is. Looks good? > > Nice. Done. 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 info at coresystems.de Sat Sep 1 13:56:42 2007 From: info at coresystems.de (LinuxBIOS information) Date: Sat, 01 Sep 2007 13:56:42 +0200 Subject: [LinuxBIOS] r2756 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2756 to the LinuxBIOS source repository and caused the following changes: Change Log: Move getpir and mptable into the global util/ directory. Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2756&device=hdama&vendor=arima Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2756&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2756&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2756&device=juki-511p&vendor=iei Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2756&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2756&device=dk8x&vendor=iwill If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From r.marek at assembler.cz Sat Sep 1 14:09:25 2007 From: r.marek at assembler.cz (Rudolf Marek) Date: Sat, 01 Sep 2007 14:09:25 +0200 Subject: [LinuxBIOS] problems with reboot on K8 In-Reply-To: <46D1B902.6020503@assembler.cz> References: <46D1B902.6020503@assembler.cz> Message-ID: <46D95675.5070009@assembler.cz> Hi all, Just an update to this problem, removing soft_reset in cpu_init module does not help. I added 1s delay before calling the setup_resource map, now it hangs when it writes third "line" of the the resource table. I dont think there is anything significant, yet I dont know what could be wrong that it will just hang up. The PCI writes are to device 18, this is inside a processor, and there is no need to have correctly setup the HT Link correct? Any clue? If someone needs additional info, I will provide that too. Rudolf From philipp.degler at gmx.de Sat Sep 1 15:46:06 2007 From: philipp.degler at gmx.de (Philipp Degler) Date: Sat, 1 Sep 2007 15:46:06 +0200 Subject: [LinuxBIOS] hotplugging flash piece on A8N-E / ROMSIZE In-Reply-To: <20070831164955.GA28487@thorin> References: <705504.68079.qm@web23112.mail.ird.yahoo.com> <200708301857.23546.philipp.degler@gmx.de> <20070831164955.GA28487@thorin> Message-ID: <200709011546.10589.philipp.degler@gmx.de> On Friday 31 August 2007 18:49:55 Robert Millan wrote: > On Thu, Aug 30, 2007 at 06:57:18PM +0200, Philipp Degler wrote: > > On Monday 27 August 2007 00:31:37 Quux wrote: > > > Peter Stuge schrieb: > > > > It may not be best practice to hotplug, but it is rather safe since > > > > the chip is never accessed once the system is running. > > > > > > saves plug cycles and time ... > > > > > > >> Even an 8 Mbit piece 49LF080A works with the Asus a8ne, so > > > >> maybe a kernel may be squeezed in there as well. > > > > > > > > Yup, but only with a minimum of drivers. > > > > > > a 2 MByte piece was used to contain LB + Kernel. I guess a 2 MByte > > > flash would work in A8N-E , too. > > > > > > > > > currently I am trying to manage with the variables ROMSIZE , IMAGE SIZE > > > asf. to build a ROM with correct size 512 KB, which seems tricky for > > > some obscure reason. --Q > > > > Today I checked out the latest svn revision and tested on our ASUS A8N-E > > rev 2.0. > > > > Status of the board is unchanged. It boots with filo 5.0 from IDE. The > > autmatically build images are not working. Reason is the RAM issue with > > Athlon64 CPU in 939 socket. > > > > You need to modify amdk8/raminit.c > > > > Index: src/northbridge/amd/amdk8/raminit.c > > =================================================================== > > --- src/northbridge/amd/amdk8/raminit.c (Revision 2754) > > +++ src/northbridge/amd/amdk8/raminit.c (Arbeitskopie) > > @@ -1201,7 +1201,7 @@ > > if (unbuffered && registered) { > > die("Mixed buffered and registered dimms not supported"); > > } > > -#if 1 > > +#if 0 > > // yhlu debug: Athlon64 939 can do dual channel, but it uses > > unbuffered DIMMs > > if (unbuffered && is_opteron(ctrl)) { > > die("Unbuffered Dimms not supported on Opteron"); > > > > I also need to mention that you have to put the RAM module in a specific > > bank. I used bank 3 (blue). > > Did you try memtest86+ ? Asides from the die() you commented out, there > were spurious memory access problems. Yes I successfully "memtest"ed before commiting a8n-e target. But maybe this was a lucky run. I started memtest from the grub-menu of filo-0.5 payload. Running memtest directly as linuxbios payload in earlier tests returned errors during the random-pattern-test. > In my similar board (A8N5X) those > problems disappeared with a patch provided by Rudolf. I would be happy to test that patch on the A8N-E. > See also: > > http://www.mail-archive.com/linuxbios at linuxbios.org/msg10078.html > > I don't remember if the patch was made public. You'd better ask him about > it :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From joe at smittys.pointclark.net Sat Sep 1 15:56:33 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Sat, 01 Sep 2007 09:56:33 -0400 Subject: [LinuxBIOS] addr_offset help In-Reply-To: <46D8DBAF.6060708@gmail.com> References: <20070831144044.2dn6o3jg0ook80kw@www.smittys.pointclark.net> <46D87340.7000802@gmail.com> <20070831183754.b7c3bytw08cks8oo@www.smittys.pointclark.net> <46D8DBAF.6060708@gmail.com> Message-ID: <20070901095633.vlpi1dx92ckwk080@www.smittys.pointclark.net> >>> MRS is a setting within the ram that's set by reading from a certain >>> location while the northbridge is in MRS mode. It essentially tells the >>> ram what timings to run at. For the most part, the only values you'll >>> ever need for SDRAM are 0x1d0 for CL3 and 0x150 for CL2, but DDR and >>> DDR2 make more advanced use of MRS and E(xtended)MRS. Read the JEDEC >>> standard for more info. >>> What do you mean by this?? > And just realized something else, directly related to the email I just > sent for Joe. Please change the MRS value from 0x1d0 to 0xad0. Heh, that > could seriously bork things up, my bad. > > -Corey > > What am I supposed to use for CL3? Thanks - Joe From peter at stuge.se Sat Sep 1 17:53:20 2007 From: peter at stuge.se (Peter Stuge) Date: Sat, 1 Sep 2007 17:53:20 +0200 Subject: [LinuxBIOS] LinuxBIOS panic room In-Reply-To: <46D6A47C.7060405@gmx.net> References: <20070829051903.21550.qmail@stuge.se> <46D513EB.9080409@gmail.com> <20070829132729.GD7091@greenwood> <20070829135856.GA30258@coresystems.de> <20070829184943.8592.qmail@stuge.se> <20070829212836.3557.qmail@stuge.se> <46D6066E.4090806@gmx.net> <13426df10708292119u409d4164kb3e914f496f27afd@mail.gmail.com> <46D6A47C.7060405@gmx.net> Message-ID: <20070901155320.14353.qmail@stuge.se> On Thu, Aug 30, 2007 at 01:05:32PM +0200, Carl-Daniel Hailfinger wrote: > Can we invert the speaker line each time a byte is written out over > serial? Great idea! May need some more code for polling the UART status register though. //Peter From c-d.hailfinger.devel.2006 at gmx.net Sat Sep 1 18:11:38 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 01 Sep 2007 18:11:38 +0200 Subject: [LinuxBIOS] r2755 - trunk/LinuxBIOSv2/util/probe_superio In-Reply-To: <20070831205127.9107gmx1@mx034.gmx.net> References: <20070831205127.9107gmx1@mx034.gmx.net> Message-ID: <46D98F3A.9030907@gmx.net> Hi Uwe, On 31.08.2007 22:51, svn at openbios.org wrote: > Author: uwe > New Revision: 2755 > > Modified: > trunk/LinuxBIOSv2/util/probe_superio/probe_superio.c > Log: > Fix typo for the ITE IT8712F (trivial). > > The default for LDN 5 (keyboard), index 0xF0 is not 0x00 > but rather 0x08 as per datasheet. My datasheet (IT8712F V0.9.3) says it is 0x00. Look at table 8-7 for reference. Where did you get the value from? Carl-Daniel From uwe at hermann-uwe.de Sat Sep 1 19:19:44 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 1 Sep 2007 19:19:44 +0200 Subject: [LinuxBIOS] r2755 - trunk/LinuxBIOSv2/util/probe_superio In-Reply-To: <46D98F3A.9030907@gmx.net> References: <20070831205127.9107gmx1@mx034.gmx.net> <46D98F3A.9030907@gmx.net> Message-ID: <20070901171944.GA23959@greenwood> On Sat, Sep 01, 2007 at 06:11:38PM +0200, Carl-Daniel Hailfinger wrote: > Hi Uwe, > > On 31.08.2007 22:51, svn at openbios.org wrote: > > Author: uwe > > New Revision: 2755 > > > > Modified: > > trunk/LinuxBIOSv2/util/probe_superio/probe_superio.c > > Log: > > Fix typo for the ITE IT8712F (trivial). > > > > The default for LDN 5 (keyboard), index 0xF0 is not 0x00 > > but rather 0x08 as per datasheet. > > My datasheet (IT8712F V0.9.3) says it is 0x00. Look at table 8-7 for > reference. Where did you get the value from? Oh great, the datasheet contradicts itself. See page 59: 8.9.8 KBC (keyboard) Special Configuration Register (Index=F0h, Default=08h) I guess we'll have to test a bunch of boards to be sure which value is correct. (btw, do you have any pending probe_superio code? I'm about to do some cosmetic cleanups on the code but I don't want to interfere...) 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 peter at stuge.se Sat Sep 1 19:57:18 2007 From: peter at stuge.se (Peter Stuge) Date: Sat, 1 Sep 2007 19:57:18 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <20070830120920.GB10696@localdomain> References: <20070829223334.af415839.rasmus@wiman.org> <20070829213540.4599.qmail@stuge.se> <20070830000830.dc4e4eb6.rasmus@wiman.org> <20070829221844.11522.qmail@stuge.se> <20070830002823.4cc82ee0.rasmus@wiman.org> <20070829223925.15184.qmail@stuge.se> <20070830111446.GA9646@localdomain> <20070830132527.813b7fc0.rasmus@wiman.org> <46D6AB93.9080607@stockwith.co.uk> <20070830120920.GB10696@localdomain> Message-ID: <20070901175718.1761.qmail@stuge.se> On Thu, Aug 30, 2007 at 08:09:20AM -0400, Ward Vandewege wrote: > On Thu, Aug 30, 2007 at 12:35:47PM +0100, Chris Lingard wrote: > > They say the socket that I got is wrong, (PLCC32). > > > > Will the SST 49LF040 be wrong too. > > Most likely if your board is not plcc. Yes - then neither socket nor flash chip can be mounted. > > Is the modification now wrong? > > ST, can you chime in here? Hard to tell without testing. I could give it a go if I had a board. But, someone please send a high-res photo of this part of the board: http://stuge.se/m57sli_spi_mod_area.jpg so that we can have a look at the traces. Please take the photo from straight above the board so that the black PCIe sockets do not obscure any traces or components. There is also the problem of documentation re. SPI flash programming at least on the MCP55; AFAIK there's only documentation for SPI flashing on Intel southbridges. Once we figure out the hardware, it will still be neccessary to reboot into DOS/Windows to flash either chip. :( Re sockets I haven't seen anything that would work well for SOIC. (SOIC and PLCC are packages, SPI and LPC the bus interface.) One easy trick is to attach a clothespin-like clip (Pomona SOIC CLIP 5250) on top of the first flash chip and then connect different flash chips to that clip. This works if the soldered-on flash chip has a HOLD# pin, which seems to be common. A problem with the clip is that it can come off by accident or worse have a glitch in the connection (unlikely, but still) which would cause the soldered-on chip to be overwritten by mistake and bricking the board if the BIOS image was bad. This can be worked around by flashing the factory BIOS onto the clip flash chip and then only working with LB using the soldered-on flash chip. :) Connecting a second flash chip to the clip is very simple electrically, but a bit tricky mechanically since the upper contacts on the clip move when the clip is detached/attached. The most durable method would be AMPMODU contacts for the second row, but just soldering wires should work too. A small adapter board is needed for the SOIC flash chip as well, since the flash chip has .05" pin spacing while the test clip has .1" pin spacing. Either just strip board or a ready made SOIC adapter board such as the Sunhayato Corp PC BOARD ICB-010. (non-RoHS) //Peter From peter at stuge.se Sat Sep 1 20:40:26 2007 From: peter at stuge.se (Peter Stuge) Date: Sat, 1 Sep 2007 20:40:26 +0200 Subject: [LinuxBIOS] [PATCH] Move common utilities to util/ In-Reply-To: <20070901111200.GA23469@greenwood> References: <20070827081648.GB12926@greenwood> <20070827083317.GA31146@coresystems.de> <20070830113735.GV7091@greenwood> <46D70676.7020903@gmx.net> <20070901111200.GA23469@greenwood> Message-ID: <20070901184026.8852.qmail@stuge.se> On Sat, Sep 01, 2007 at 01:12:00PM +0200, Uwe Hermann wrote: > 'superiotool' +1 //Peter From peter at stuge.se Sat Sep 1 20:47:07 2007 From: peter at stuge.se (Peter Stuge) Date: Sat, 1 Sep 2007 20:47:07 +0200 Subject: [LinuxBIOS] hotplugging flash piece on A8N-E / ROMSIZE In-Reply-To: <200708301857.23546.philipp.degler@gmx.de> References: <705504.68079.qm@web23112.mail.ird.yahoo.com> <20070826022936.1798.qmail@stuge.se> <46D1FF49.5090903@yahoo.de> <200708301857.23546.philipp.degler@gmx.de> Message-ID: <20070901184707.10089.qmail@stuge.se> On Thu, Aug 30, 2007 at 06:57:18PM +0200, Philipp Degler wrote: > Status of the board is unchanged. It boots with filo 5.0 from IDE. The > autmatically build images are not working. Reason is the RAM issue with > Athlon64 CPU in 939 socket. > > You need to modify amdk8/raminit.c It would rock if this could be detected at runtime instead of a compile-time #if. Any ideas? > I also need to mention that you have to put the RAM module in a > specific bank. I used bank 3 (blue). Do you know why? //Peter From c-d.hailfinger.devel.2006 at gmx.net Sat Sep 1 21:00:57 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 01 Sep 2007 21:00:57 +0200 Subject: [LinuxBIOS] [PATCH] probe_superio: Cosmetics, cleanup, better structure In-Reply-To: <20070831173825.GA19564@thorin> References: <46D2B882.7000701@gmx.net> <20070827200847.GA16962@thorin> <46D44DEC.3050403@gmx.net> <20070829113056.GA15798@thorin> <46D5A04B.5040902@gmx.net> <20070831173825.GA19564@thorin> Message-ID: <46D9B6E9.8030302@gmx.net> On 31.08.2007 19:38, Robert Millan wrote: > On Wed, Aug 29, 2007 at 06:35:23PM +0200, Carl-Daniel Hailfinger wrote: >>> SuperI/O found at 0x2e: id=0x8712, chipver=0x7 >>> ITE IT8712 >>> switching to LDN 0x4 >>> idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 f6 >>> val 01 02 90 00 00 00 80 00 0a 00 80 00 ff >>> def 00 02 90 02 30 09 00 00 00 00 00 NA NA >> ldn 0x4, idx 0x70: interrupt level of environment controller. >> prop: 0x00, lb 0x09. change? >> >>> switching to LDN 0x5 >>> idx 30 60 61 62 63 70 71 f0 >>> val 01 00 60 00 64 01 02 68 >>> def 01 00 60 00 64 01 02 00 >> ldn 0x5, idx 0xf0: keyboard special config. >> prop: 0x68, lb 0x40. >> prop: no irq sharing, lb: active irq sharing. change? >> prop: kbc clock 8mhz, lb: kbc clock 12mhz. FIX! >> >> IF you fix the stuff mentioned above, PS/2 keyboard should work fine. >> PCI is not affected by SuperIO config. USB keyboard can be investigated >> later if the PS/2 fixes don't help. > > Thanks for the hints. I changed the mentioned registers to the same values > they had with propietary BIOS, but to no avail. Attaching a diff of my > changes. > > Any idea? Should I go after all the other disparities? Only those which I listed in my earlier mail plus the following list: --- propietary 2007-09-01 20:21:24.000000000 +0200 +++ lb 2007-09-01 20:21:24.000000000 +0200 switching to LDN 0x2 (serial port 2) idx 30 60 61 70 -val 00 00 00 00 +val 01 02 f8 03 prop disables com2 an clears baseaddr+irq. FIX. switching to LDN 0x3 idx f0 -val 0b +val 03 fascinating. the board can output post codes via parallel port. maybe? switching to LDN 0x4 idx 62 63 70 -val 00 00 00 +val 02 30 09 pme direct access addr + ec interrupt level FIX. switching to LDN 0x5 idx f0 -val 68 +val 40 keyboard clock etc. FIX. switching to LDN 0x7 idx 25 27 62 b2 ba c0 c2 c8 ca cb -val 00 05 08 01 01 00 05 00 05 00 +val 01 00 00 00 00 01 00 01 00 40 idx 25: pin 84 smart card present? maybe? idx 27: gpio 30+32. FIX. idx 62: simeple i/o base addr. FIX. idx b2: gpio pin set 3: gpio invert polarity. FIX. idx ba: gpio pin set 3: gpio pullup. FIX. idx c0: simple i/o set 1: enable. FIX. idx c2: simple i/o set 3: enable. FIX. idx c8: simple i/o set 1: input mode. FIX. idx ca: simple i/o set 3: input mode. FIX. idx cb: simple i/o set 4: input mode. FIX. switching to LDN 0x8 idx 30 61 -val 01 30 +val 00 00 ok. switching to LDN 0x9 idx 30 -val 01 +val 00 ok. You patch in the other mail looked fine. Fix the issues mentioned above as "FIX" and post another probe_superio from a lb boot after fixes. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Sat Sep 1 21:02:24 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 01 Sep 2007 21:02:24 +0200 Subject: [LinuxBIOS] [PATCH] Move common utilities to util/ In-Reply-To: <20070901184026.8852.qmail@stuge.se> References: <20070827081648.GB12926@greenwood> <20070827083317.GA31146@coresystems.de> <20070830113735.GV7091@greenwood> <46D70676.7020903@gmx.net> <20070901111200.GA23469@greenwood> <20070901184026.8852.qmail@stuge.se> Message-ID: <46D9B740.7010902@gmx.net> On 01.09.2007 20:40, Peter Stuge wrote: > On Sat, Sep 01, 2007 at 01:12:00PM +0200, Uwe Hermann wrote: >> 'superiotool' > > +1 Good name. Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Sat Sep 1 21:04:11 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 01 Sep 2007 21:04:11 +0200 Subject: [LinuxBIOS] r2755 - trunk/LinuxBIOSv2/util/probe_superio In-Reply-To: <20070901171944.GA23959@greenwood> References: <20070831205127.9107gmx1@mx034.gmx.net> <46D98F3A.9030907@gmx.net> <20070901171944.GA23959@greenwood> Message-ID: <46D9B7AB.4000606@gmx.net> On 01.09.2007 19:19, Uwe Hermann wrote: > On Sat, Sep 01, 2007 at 06:11:38PM +0200, Carl-Daniel Hailfinger wrote: >>> The default for LDN 5 (keyboard), index 0xF0 is not 0x00 >>> but rather 0x08 as per datasheet. >> My datasheet (IT8712F V0.9.3) says it is 0x00. Look at table 8-7 for >> reference. Where did you get the value from? > > Oh great, the datasheet contradicts itself. > > See page 59: > 8.9.8 KBC (keyboard) Special Configuration Register (Index=F0h, Default=08h) Where do we write down all the datasheet errors? Wiki or probe_superio? > I guess we'll have to test a bunch of boards to be sure which value > is correct. Yes, unfortunately. > (btw, do you have any pending probe_superio code? I'm about to do some > cosmetic cleanups on the code but I don't want to interfere...) Nothing that wouldn't apply after cosmetics. Carl-Daniel From peter at stuge.se Sat Sep 1 21:18:38 2007 From: peter at stuge.se (Peter Stuge) Date: Sat, 1 Sep 2007 21:18:38 +0200 Subject: [LinuxBIOS] r2755 - trunk/LinuxBIOSv2/util/probe_superio In-Reply-To: <46D9B7AB.4000606@gmx.net> References: <20070831205127.9107gmx1@mx034.gmx.net> <46D98F3A.9030907@gmx.net> <20070901171944.GA23959@greenwood> <46D9B7AB.4000606@gmx.net> Message-ID: <20070901191838.15507.qmail@stuge.se> On Sat, Sep 01, 2007 at 09:04:11PM +0200, Carl-Daniel Hailfinger wrote: > > Oh great, the datasheet contradicts itself. > > > > See page 59: > > 8.9.8 KBC (keyboard) Special Configuration Register (Index=F0h, > > Default=08h) > > Where do we write down all the datasheet errors? Wiki or > probe_superio? Check if the vendor has published some erratas or ECNs. The problem may be known already. //Peter From c-d.hailfinger.devel.2006 at gmx.net Sat Sep 1 21:30:54 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 01 Sep 2007 21:30:54 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <20070901175718.1761.qmail@stuge.se> References: <20070829223334.af415839.rasmus@wiman.org> <20070829213540.4599.qmail@stuge.se> <20070830000830.dc4e4eb6.rasmus@wiman.org> <20070829221844.11522.qmail@stuge.se> <20070830002823.4cc82ee0.rasmus@wiman.org> <20070829223925.15184.qmail@stuge.se> <20070830111446.GA9646@localdomain> <20070830132527.813b7fc0.rasmus@wiman.org> <46D6AB93.9080607@stockwith.co.uk> <20070830120920.GB10696@localdomain> <20070901175718.1761.qmail@stuge.se> Message-ID: <46D9BDEE.9010402@gmx.net> On 01.09.2007 19:57, Peter Stuge wrote: > > Once we figure out the hardware, it will still be neccessary to > reboot into DOS/Windows to flash either chip. :( SPI detection/flashing support is on my list. However, it won't get done in the next 3 weeks because I'm getting married next week and will be offline for a while. Everyone can try the probe_superio patch for IT8716, though, and send dumps for proprietary and LinuxBIOS to the list. It would be nice if I had dumps for both types of M57SLI (SPI and PLCC) to be able to compare. Carl-Daniel From svn at openbios.org Sat Sep 1 21:42:42 2007 From: svn at openbios.org (svn at openbios.org) Date: Sat, 1 Sep 2007 21:42:42 +0200 Subject: [LinuxBIOS] r2757 - trunk/LinuxBIOSv2/util/probe_superio Message-ID: Author: uwe Date: 2007-09-01 21:42:42 +0200 (Sat, 01 Sep 2007) New Revision: 2757 Modified: trunk/LinuxBIOSv2/util/probe_superio/probe_superio.c Log: Add support for the ITE IT8708F. Here's a dump from my test system which has an IT8708F: No SuperI/O chip found at 0x002e probing 0x002e, failed (0x87), data returns 0x87 SuperI/O found at 0x2e: id=0x8708, chipver=0x0 ITE IT8708 idx 07 20 21 22 23 24 25 26 27 28 29 2a 2e 2f val 02 87 08 00 00 00 00 00 03 01 01 00 00 00 def NA 87 08 00 00 NA 3f 00 ff ff ff ff 00 00 switching to LDN 0x0 idx 30 60 61 70 74 f0 f1 val 01 03 f0 06 02 00 80 def 00 03 f0 06 02 00 00 switching to LDN 0x1 idx 30 60 61 70 f0 val 01 03 f8 04 00 def 00 03 f8 04 00 switching to LDN 0x2 idx 30 60 61 70 f0 f1 f2 f3 val 01 02 f8 03 00 50 01 7f def 00 02 f8 03 00 50 00 7f switching to LDN 0x3 idx 30 60 61 62 63 64 65 70 74 f0 val 01 03 78 07 78 00 80 07 03 0b def 00 03 78 07 78 00 80 07 03 03 switching to LDN 0x4 idx e0 e1 e2 e3 e4 e5 e6 e7 f0 f1 f2 f3 f4 f5 f6 val 80 61 00 00 00 00 00 00 80 00 30 00 80 00 de def NA NA 00 00 00 00 00 00 00 00 00 00 00 NA NA switching to LDN 0x5 idx 30 60 61 62 63 70 71 f0 val 01 00 60 00 64 01 02 0c def 01 00 60 00 64 01 02 00 switching to LDN 0x6 idx 30 70 71 f0 val 01 0c 02 00 def 00 0c 02 00 switching to LDN 0x7 idx 70 b0 b1 b2 b3 b4 b5 b8 b9 ba bb bc bd c0 c1 c2 c3 c4 c5 c8 c9 ca cb cc cd d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc val 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 01 01 00 00 00 03 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff 7f 20 51 00 0e 00 00 00 00 00 00 00 def 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 NA NA NA NA NA NA 00 00 00 00 00 00 00 00 00 00 00 NA 00 switching to LDN 0x8 idx 30 60 61 val 00 02 01 def 00 02 01 switching to LDN 0x9 idx 30 60 61 70 f0 val 00 03 10 0b 06 def 00 03 10 0b 00 switching to LDN 0xa idx 30 60 61 70 f0 val 00 03 00 0a 40 def 00 03 00 0a 00 No SuperI/O chip found at 0x004e No SuperIO chip found at 0x004e No SuperIO chip found at 0x004e Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Modified: trunk/LinuxBIOSv2/util/probe_superio/probe_superio.c =================================================================== --- trunk/LinuxBIOSv2/util/probe_superio/probe_superio.c 2007-09-01 11:10:56 UTC (rev 2756) +++ trunk/LinuxBIOSv2/util/probe_superio/probe_superio.c 2007-09-01 19:42:42 UTC (rev 2757) @@ -4,6 +4,7 @@ * Copyright (C) 2006 Ronald Minnich * Copyright (C) 2006 coresystems GmbH * Copyright (C) 2007 Carl-Daniel Hailfinger + * Copyright (C) 2007 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 @@ -159,6 +160,60 @@ {EOT}}}, {0x8705, "IT8705 or IT8700", { {EOT}}}, + {0x8708, "IT8708", { + {NOLDN, + {0x07,0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27,0x28, + 0x29,0x2a,0x2e,0x2f,EOT}, + {NANA,0x87,0x08,0x00,0x00,NANA,0x3f,0x00,0xff,0xff, + 0xff,0xff,0x00,0x00,EOT}}, + {0x0, + {0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT}, + {0x00,0x03,0xf0,0x06,0x02,0x00,0x00,EOT}}, + {0x1, + {0x30,0x60,0x61,0x70,0xf0,EOT}, + {0x00,0x03,0xf8,0x04,0x00,EOT}}, + {0x2, + {0x30,0x60,0x61,0x70,0xf0,0xf1,0xf2,0xf3,EOT}, + {0x00,0x02,0xf8,0x03,0x00,0x50,0x00,0x7f,EOT}}, + {0x3, + {0x30,0x60,0x61,0x62,0x63,0x64,0x65,0x70,0x74, + 0xf0,EOT}, + {0x00,0x03,0x78,0x07,0x78,0x00,0x80,0x07,0x03, + 0x03,EOT}}, + {0x4, + {0xe0,0xe1,0xe2,0xe3,0xe4,0xe5,0xe6,0xe7, + 0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,EOT}, + {NANA,NANA,0x00,0x00,0x00,0x00,0x00,0x00, + 0x00,0x00,0x00,0x00,0x00,NANA,NANA,EOT}}, + {0x5, /* Note: 0x30 can actually be 0x00 _or_ 0x01. */ + {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf0,EOT}, + {0x01,0x00,0x60,0x00,0x64,0x01,0x02,0x00,EOT}}, + {0x6, + {0x30,0x70,0x71,0xf0,EOT}, + {0x00,0x0c,0x02,0x00,EOT}}, + {0x7, + {0x70,0xb0,0xb1,0xb2,0xb3,0xb4,0xb5,0xb8,0xb9,0xba, + 0xbb,0xbc,0xbd,0xc0,0xc1,0xc2,0xc3,0xc4,0xc5,0xc8, + 0xc9,0xca,0xcb,0xcc,0xcd,0xd0,0xd1,0xd2,0xd3,0xd4, + 0xd5,0xd6,0xd7,0xd8,0xd9,0xda,0xdb,0xdc,0xf0,0xf1, + 0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9,0xfa,0xfb, + 0xfc,EOT}, + {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, + 0x00,0x00,NANA,NANA,NANA,NANA,NANA,NANA,0x00,0x00, + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,NANA, + 0x00,EOT}}, + {0x8, + {0x30,0x60,0x61,EOT}, + {0x00,0x02,0x01,EOT}}, + {0x9, + {0x30,0x60,0x61,0x70,0xf0,EOT}, + {0x00,0x03,0x10,0x0b,0x00,EOT}}, + {0xa, + {0x30,0x60,0x61,0x70,0xf0,EOT}, + {0x00,0x03,0x00,0x0a,0x00,EOT}}, + {EOT}}}, {0x8710, "IT8710", { {EOT}}}, {0x8712, "IT8712", { @@ -241,6 +296,7 @@ switch(id) { case 0x8702: case 0x8705: + case 0x8708: case 0x8710: case 0x8712: case 0x8716: @@ -393,6 +449,7 @@ /* Enable configuration sequence (ITE uses this for newer IT87[012]x) IT871[01] uses 0x87, 0x87 -> fintek detection should handle it + IT8708 uses 0x87, 0x87 -> fintek detection should handle it IT8761 uses 0x87, 0x61, 0x55, 0x55/0xaa IT86xx series uses different ports IT8661 uses 0x86, 0x61, 0x55/0xaa, 0x55/0xaa and 32 more writes @@ -429,6 +486,7 @@ unknown -> IT8722 (no datasheet) 0x8702 -> IT8702 0x8705 -> IT8700 or IT8705 + 0x8708 -> IT8708 0x8710 -> IT8710 0x8712 -> IT8712 0x8716 -> IT8716 @@ -441,6 +499,7 @@ switch(id) { case 0x8702: case 0x8705: + case 0x8708: case 0x8712: case 0x8716: case 0x8718: From c-d.hailfinger.devel.2006 at gmx.net Sat Sep 1 21:42:54 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 01 Sep 2007 21:42:54 +0200 Subject: [LinuxBIOS] [PATCH] Add ITE IT8716F support to probe_superio Message-ID: <46D9C0BE.8080708@gmx.net> Add ITE IT8716F support to probe_superio. This helps especially GA-M57SLI board owners who wish to debug remaining problems or handle SPI flash of newer board versions. Signed-off-by: Carl-Daniel Hailfinger Index: LinuxBIOSv2/util/probe_superio/probe_superio.c =================================================================== --- LinuxBIOSv2/util/probe_superio/probe_superio.c (Revision 2754) +++ LinuxBIOSv2/util/probe_superio/probe_superio.c (Arbeitskopie) @@ -212,6 +212,54 @@ {0x00,0x03,0x10,0x0b,0x00,EOT}}, {EOT}}}, {0x8716, "IT8716", { + {NOLDN, + {0x07,0x20,0x21,0x22,0x23,0x24,0x2b,EOT}, + {NANA,0x87,0x16,0x01,0x00,0x00,0x00,EOT}}, + {0x0, + {0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT}, + {0x00,0x03,0xf0,0x06,0x02,0x00,0x00,EOT}}, + {0x1, + {0x30,0x60,0x61,0x70,0xf0,0xf1,0xf2,0xf3,EOT}, + {0x00,0x03,0xf8,0x04,0x00,0x50,0x00,0x7f,EOT}}, + {0x2, + {0x30,0x60,0x61,0x70,0xf0,0xf1,0xf2,0xf3,EOT}, + {0x00,0x02,0xf8,0x03,0x00,0x50,0x00,0x7f,EOT}}, + {0x3, + {0x30,0x60,0x61,0x62,0x63,0x70,0x74,0xf0,EOT}, + {0x00,0x03,0x78,0x07,0x78,0x07,0x03,0x03,EOT}}, + {0x4, + {0x30,0x60,0x61,0x62,0x63,0x70,0xf0,0xf1,0xf2,0xf3, + 0xf4,0xf5,0xf6,EOT}, + {0x00,0x02,0x90,0x02,0x30,0x09,0x00,0x00,0x00,0x00, + 0x00,NANA,NANA,EOT}}, + {0x5, + {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf0,EOT}, + {0x01,0x00,0x60,0x00,0x64,0x01,0x02,0x00,EOT}}, + {0x6, + {0x30,0x70,0x71,0xf0,EOT}, + {0x00,0x0c,0x02,0x00,EOT}}, + {0x7, + {0x25,0x26,0x27,0x28,0x29,0x2a,0x2c,0x60,0x61,0x62, + 0x63,0x64,0x65,0x70,0x71,0x72,0x73,0x74,0xb0,0xb1, + 0xb2,0xb3,0xb4,0xb5,0xb8,0xb9,0xba,0xbb,0xbc,0xbd, + 0xc0,0xc1,0xc2,0xc3,0xc4,0xc8,0xc9,0xca,0xcb,0xcc, + 0xe0,0xe1,0xe2,0xe3,0xe4,0xf0,0xf1,0xf2,0xf3,0xf4, + 0xf5,0xf6,0xf7,0xf8,0xf9,0xfa,0xfb,0xfc,0xfd,EOT}, + {0x01,0x00,0x00,0x40,0x00,0x00,0x00,0x00,0x00,0x00, + 0x00,0x00,0x00,0x00,0x00,0x20,0x38,0x00,0x00,0x00, + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, + 0x01,0x00,0x00,0x40,0x00,0x01,0x00,0x00,0x40,0x00, + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,NANA,0x00,EOT}}, + {0x8, + {0x30,0x60,0x61,0x70,0xf0,EOT}, + {0x00,0x03,0x00,0x0a,0x00,EOT}}, + {0x9, + {0x30,0x60,0x61,EOT}, + {0x00,0x02,0x01,EOT}}, + {0xa, + {0x30,0x60,0x61,0x70,0xf0,EOT}, + {0x00,0x03,0x10,0x0b,0x00,EOT}}, {EOT}}}, {0x8718, "IT8718", { {EOT}}}, From svn at openbios.org Sat Sep 1 21:44:37 2007 From: svn at openbios.org (svn at openbios.org) Date: Sat, 1 Sep 2007 21:44:37 +0200 Subject: [LinuxBIOS] r2758 - in trunk: LinuxBIOSv2/util util Message-ID: Author: uwe Date: 2007-09-01 21:44:36 +0200 (Sat, 01 Sep 2007) New Revision: 2758 Added: trunk/util/superiotool/ Removed: trunk/LinuxBIOSv2/util/probe_superio/ Log: Move probe_superio into the global util/ directory. Rename it to superiotool while we're at it. Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Copied: trunk/util/superiotool (from rev 2757, trunk/LinuxBIOSv2/util/probe_superio) From uwe at hermann-uwe.de Sat Sep 1 21:45:58 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 1 Sep 2007 21:45:58 +0200 Subject: [LinuxBIOS] [PATCH] Move common utilities to util/ In-Reply-To: <46D9B740.7010902@gmx.net> References: <20070827081648.GB12926@greenwood> <20070827083317.GA31146@coresystems.de> <20070830113735.GV7091@greenwood> <46D70676.7020903@gmx.net> <20070901111200.GA23469@greenwood> <20070901184026.8852.qmail@stuge.se> <46D9B740.7010902@gmx.net> Message-ID: <20070901194558.GA29232@greenwood> On Sat, Sep 01, 2007 at 09:02:24PM +0200, Carl-Daniel Hailfinger wrote: > On 01.09.2007 20:40, Peter Stuge wrote: > > On Sat, Sep 01, 2007 at 01:12:00PM +0200, Uwe Hermann wrote: > >> 'superiotool' > > > > +1 > > Good name. OK, moved and renamed. 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 peter at stuge.se Sat Sep 1 21:50:35 2007 From: peter at stuge.se (Peter Stuge) Date: Sat, 1 Sep 2007 21:50:35 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <46D9BDEE.9010402@gmx.net> References: <20070830000830.dc4e4eb6.rasmus@wiman.org> <20070829221844.11522.qmail@stuge.se> <20070830002823.4cc82ee0.rasmus@wiman.org> <20070829223925.15184.qmail@stuge.se> <20070830111446.GA9646@localdomain> <20070830132527.813b7fc0.rasmus@wiman.org> <46D6AB93.9080607@stockwith.co.uk> <20070830120920.GB10696@localdomain> <20070901175718.1761.qmail@stuge.se> <46D9BDEE.9010402@gmx.net> Message-ID: <20070901195035.21050.qmail@stuge.se> On Sat, Sep 01, 2007 at 09:30:54PM +0200, Carl-Daniel Hailfinger wrote: > > Once we figure out the hardware, it will still be neccessary to > > reboot into DOS/Windows to flash either chip. :( > > SPI detection/flashing support is on my list. Is the SPI flash connected to the sio on the m57sli? > However, it won't get done in the next 3 weeks because I'm getting > married next week and will be offline for a while. Congratulations! :) > Everyone can try the probe_superio patch for IT8716, though, and > send dumps for proprietary and LinuxBIOS to the list. It would be > nice if I had dumps for both types of M57SLI (SPI and PLCC) to be > able to compare. I doubt there's much difference. The 8716F datasheet is clear on the SPI stuff - but I didn't think that's where the flash chip was actually connected. Someone mentioned CK804. I guess I'm confusing things. //Peter From c-d.hailfinger.devel.2006 at gmx.net Sat Sep 1 22:13:21 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 01 Sep 2007 22:13:21 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <20070901195035.21050.qmail@stuge.se> References: <20070830000830.dc4e4eb6.rasmus@wiman.org> <20070829221844.11522.qmail@stuge.se> <20070830002823.4cc82ee0.rasmus@wiman.org> <20070829223925.15184.qmail@stuge.se> <20070830111446.GA9646@localdomain> <20070830132527.813b7fc0.rasmus@wiman.org> <46D6AB93.9080607@stockwith.co.uk> <20070830120920.GB10696@localdomain> <20070901175718.1761.qmail@stuge.se> <46D9BDEE.9010402@gmx.net> <20070901195035.21050.qmail@stuge.se> Message-ID: <46D9C7E1.7080801@gmx.net> On 01.09.2007 21:50, Peter Stuge wrote: > On Sat, Sep 01, 2007 at 09:30:54PM +0200, Carl-Daniel Hailfinger wrote: >>> Once we figure out the hardware, it will still be neccessary to >>> reboot into DOS/Windows to flash either chip. :( >> SPI detection/flashing support is on my list. > > Is the SPI flash connected to the sio on the m57sli? No idea. >> However, it won't get done in the next 3 weeks because I'm getting >> married next week and will be offline for a while. > > Congratulations! :) Thanks! >> Everyone can try the probe_superio patch for IT8716, though, and >> send dumps for proprietary and LinuxBIOS to the list. It would be >> nice if I had dumps for both types of M57SLI (SPI and PLCC) to be >> able to compare. > > I doubt there's much difference. The 8716F datasheet is clear on the > SPI stuff - but I didn't think that's where the flash chip was > actually connected. Someone mentioned CK804. I guess I'm confusing > things. AFAIK CK804/MCP55 don't have SPI support. That's why the SuperI/O adds it. Regards, Carl-Daniel From svn at openbios.org Sat Sep 1 22:20:42 2007 From: svn at openbios.org (svn at openbios.org) Date: Sat, 1 Sep 2007 22:20:42 +0200 Subject: [LinuxBIOS] r2759 - trunk/util/superiotool Message-ID: Author: uwe Date: 2007-09-01 22:20:41 +0200 (Sat, 01 Sep 2007) New Revision: 2759 Added: trunk/util/superiotool/superiotool.c Removed: trunk/util/superiotool/probe_superio.c Modified: trunk/util/superiotool/Makefile Log: Rename probe_superio.c to superiotool.c. Flesh out Makefile with all the usual stuff, e.g. install targets etc. Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Modified: trunk/util/superiotool/Makefile =================================================================== --- trunk/util/superiotool/Makefile 2007-09-01 19:44:36 UTC (rev 2758) +++ trunk/util/superiotool/Makefile 2007-09-01 20:20:41 UTC (rev 2759) @@ -1,6 +1,43 @@ -CC:=gcc -CFLAGS:=-O2 -Wall -probe_superio: probe_superio.c +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2007 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 +## + +PROGRAM = superiotool + +CC = gcc +INSTALL = /usr/bin/install +PREFIX = /usr/local + +# TODO: -ansi, -pedantic +CFLAGS = -O2 -Wall -Werror -Wstrict-prototypes -Wundef -Wstrict-aliasing \ + -Werror-implicit-function-declaration + +all: $(PROGRAM) + +$(PROGRAM): $(PROGRAM).c $(CC) $(CFLAGS) -o $@ $< + +install: $(PROGRAM) + $(INSTALL) $(PROGRAM) $(PREFIX)/bin + clean: - rm probe_superio + rm -f $(PROGRAM) + +.PHONY: all install clean + Deleted: trunk/util/superiotool/probe_superio.c =================================================================== --- trunk/util/superiotool/probe_superio.c 2007-09-01 19:44:36 UTC (rev 2758) +++ trunk/util/superiotool/probe_superio.c 2007-09-01 20:20:41 UTC (rev 2759) @@ -1,538 +0,0 @@ -/* - * This file is part of the LinuxBIOS project. - * - * Copyright (C) 2006 Ronald Minnich - * Copyright (C) 2006 coresystems GmbH - * Copyright (C) 2007 Carl-Daniel Hailfinger - * Copyright (C) 2007 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 - -/* well, they really thought this through, eh? Family is 8 bits!!!! */ -char *familyid[] = { - [0xf1] = "pc8374 (winbond, was NS)" -}; - -/* eventually, if you care, break this out into a file. For now, I don't know - * if we need this. - */ - -unsigned char regval(unsigned short port, unsigned char reg) { - outb(reg, port); - return inb(port + 1); -} - -void regwrite(unsigned short port, unsigned char reg, unsigned char val) { - outb(reg, port); - outb(val, port + 1); -} - -void -dump_ns8374(unsigned short port) { - printf("Enables: 21=%02x, 22=%02x, 23=%02x, 24=%02x, 26=%02x\n", - regval(port, 0x21), regval(port, 0x22), regval(port, 0x23), - regval(port, 0x24), regval(port, 0x26)); - printf("SMBUS at %02x\n", regval(port, 0x2a)); - /* check COM1. This is all we care about at present. */ - printf("COM 1 is Globally %s\n", regval(port, 0x26) & 8 ? "disabled" : "enabled"); - /* select com1 */ - regwrite(port, 0x07, 0x03); - printf("COM 1 is locally %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); - printf("COM1 60=%02x, 61=%02x, 70=%02x, 71=%02x, 74=%02x, 75=%02x, f0=%02x\n", - regval(port, 0x60), regval(port, 0x61), regval(port, 0x70), regval(port, 0x71), - regval(port, 0x74), regval(port, 0x75), regval(port, 0xf0)); - /* select gpio */ - regwrite(port, 0x07, 0x07); - printf("GPIO is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); - printf("GPIO 60=%02x, 61=%02x, 70=%02x, 71=%02x, 74=%02x, 75=%02x, f0=%02x\n", - regval(port, 0x60), regval(port, 0x61), regval(port, 0x70), regval(port, 0x71), - regval(port, 0x74), regval(port, 0x75), regval(port, 0xf0)); - -} - -void -dump_fintek(unsigned short port, unsigned int did) -{ - switch(did) { - case 0x0604: - printf ("Fintek F71805\n"); - break; - case 0x4103: - printf ("Fintek F71872\n"); - break; - default: - printf ("Unknown Fintek SuperI/O: did=0x%04x\n", did); - return; - } - - printf("Flash write is %s.\n", regval(port, 0x28) & 0x80 ? "enabled" : "disabled"); - printf("Flash control is 0x%04x.\n", regval(port, 0x28)); - printf("27=%02x\n", regval(port, 0x27)); - printf("29=%02x\n", regval(port, 0x29)); - printf("2a=%02x\n", regval(port, 0x2a)); - printf("2b=%02x\n", regval(port, 0x2b)); - - /* select UART 1 */ - regwrite(port, 0x07, 0x01); - printf("UART1 is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); - printf("UART1 base=%02x%02x, irq=%02x, mode=%s\n", - regval(port, 0x60), regval(port, 0x61), regval(port, 0x70) & 0x0f, - regval(port, 0xf0) & 0x10 ? "RS485":"RS232"); - - /* select UART 2 */ - regwrite(port, 0x07, 0x02); - printf("UART2 is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); - printf("UART2 base=%02x%02x, irq=%02x, mode=%s\n", - regval(port, 0x60), regval(port, 0x61), regval(port, 0x70) & 0x0f, - regval(port, 0xf0) & 0x10 ? "RS485":"RS232"); - - /* select Parport */ - regwrite(port, 0x07, 0x03); - printf("PARPORT is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); - printf("PARPORT base=%02x%02x, irq=%02x\n", - regval(port, 0x60), regval(port, 0x61), regval(port, 0x70) & 0x0f); - - /* select hw monitor */ - regwrite(port, 0x07, 0x04); - printf("HW monitor is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); - printf("HW monitor base=%02x%02x, irq=%02x\n", - regval(port, 0x60), regval(port, 0x61), regval(port, 0x70) & 0x0f); - - /* select gpio */ - regwrite(port, 0x07, 0x05); - printf("GPIO is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); - printf("GPIO 70=%02x, e0=%02x, e1=%02x, e2=%02x, e3=%02x, e4=%02x, e5=%02x\n", - regval(port, 0x70), regval(port, 0xe0), regval(port, 0xe1), regval(port, 0xe2), - regval(port, 0xe3), regval(port, 0xe4), regval(port, 0xe5)); - printf("GPIO e6=%02x, e7=%02x, e8=%02x, e9=%02x, f0=%02x, f1=%02x, f3=%02x, f4=%02x\n", - regval(port, 0xe6), regval(port, 0xe7), regval(port, 0xe8), regval(port, 0xe9), - regval(port, 0xf0), regval(port, 0xf1), regval(port, 0xf3), regval(port, 0xf4)); - printf("GPIO f5=%02x, f6=%02x, f7=%02x, f8=%02x\n", - regval(port, 0xf5), regval(port, 0xf6), regval(port, 0xf7), regval(port, 0xf8)); - - -} - -/* End Of Table */ -#define EOT -1 -/* NO LDN needed */ -#define NOLDN -2 -/* Not Available */ -#define NANA -3 -/* Maximum Name Length */ -#define MAXNAMELEN 20 -/* Biggest LDN */ -#define MAXLDN 0xa -/* biggestLDN + 0 + NOLDN + EOT */ -#define LDNSIZE MAXLDN + 3 -/* MAXimum NUMber of Indexes */ -#define MAXNUMIDX 70 -#define IDXSIZE MAXNUMIDX + 1 - -const static struct ite_registers { - /* yes, superio_id should be unsigned, but EOT has to be negative */ - signed short superio_id; - char name[MAXNAMELEN]; - struct ite_ldnidx { - signed short ldn; - signed short idx[IDXSIZE]; - signed short def[IDXSIZE]; - } ldn[LDNSIZE]; -} ite_reg_table[] = { - {0x8702, "IT8702", { - {EOT}}}, - {0x8705, "IT8705 or IT8700", { - {EOT}}}, - {0x8708, "IT8708", { - {NOLDN, - {0x07,0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27,0x28, - 0x29,0x2a,0x2e,0x2f,EOT}, - {NANA,0x87,0x08,0x00,0x00,NANA,0x3f,0x00,0xff,0xff, - 0xff,0xff,0x00,0x00,EOT}}, - {0x0, - {0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT}, - {0x00,0x03,0xf0,0x06,0x02,0x00,0x00,EOT}}, - {0x1, - {0x30,0x60,0x61,0x70,0xf0,EOT}, - {0x00,0x03,0xf8,0x04,0x00,EOT}}, - {0x2, - {0x30,0x60,0x61,0x70,0xf0,0xf1,0xf2,0xf3,EOT}, - {0x00,0x02,0xf8,0x03,0x00,0x50,0x00,0x7f,EOT}}, - {0x3, - {0x30,0x60,0x61,0x62,0x63,0x64,0x65,0x70,0x74, - 0xf0,EOT}, - {0x00,0x03,0x78,0x07,0x78,0x00,0x80,0x07,0x03, - 0x03,EOT}}, - {0x4, - {0xe0,0xe1,0xe2,0xe3,0xe4,0xe5,0xe6,0xe7, - 0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,EOT}, - {NANA,NANA,0x00,0x00,0x00,0x00,0x00,0x00, - 0x00,0x00,0x00,0x00,0x00,NANA,NANA,EOT}}, - {0x5, /* Note: 0x30 can actually be 0x00 _or_ 0x01. */ - {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf0,EOT}, - {0x01,0x00,0x60,0x00,0x64,0x01,0x02,0x00,EOT}}, - {0x6, - {0x30,0x70,0x71,0xf0,EOT}, - {0x00,0x0c,0x02,0x00,EOT}}, - {0x7, - {0x70,0xb0,0xb1,0xb2,0xb3,0xb4,0xb5,0xb8,0xb9,0xba, - 0xbb,0xbc,0xbd,0xc0,0xc1,0xc2,0xc3,0xc4,0xc5,0xc8, - 0xc9,0xca,0xcb,0xcc,0xcd,0xd0,0xd1,0xd2,0xd3,0xd4, - 0xd5,0xd6,0xd7,0xd8,0xd9,0xda,0xdb,0xdc,0xf0,0xf1, - 0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9,0xfa,0xfb, - 0xfc,EOT}, - {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, - 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, - 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, - 0x00,0x00,NANA,NANA,NANA,NANA,NANA,NANA,0x00,0x00, - 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,NANA, - 0x00,EOT}}, - {0x8, - {0x30,0x60,0x61,EOT}, - {0x00,0x02,0x01,EOT}}, - {0x9, - {0x30,0x60,0x61,0x70,0xf0,EOT}, - {0x00,0x03,0x10,0x0b,0x00,EOT}}, - {0xa, - {0x30,0x60,0x61,0x70,0xf0,EOT}, - {0x00,0x03,0x00,0x0a,0x00,EOT}}, - {EOT}}}, - {0x8710, "IT8710", { - {EOT}}}, - {0x8712, "IT8712", { - {NOLDN, - {0x07,0x20,0x21,0x22,0x23,0x24,0x2b,EOT}, - {NANA,0x87,0x12,0x08,0x00,0x00,0x00,EOT}}, - {0x0, - {0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT}, - {0x00,0x03,0xf0,0x06,0x02,0x00,0x00,EOT}}, - {0x1, - {0x30,0x60,0x61,0x70,0xf0,0xf1,0xf2,0xf3,EOT}, - {0x00,0x03,0xf8,0x04,0x00,0x50,0x00,0x7f,EOT}}, - {0x2, - {0x30,0x60,0x61,0x70,0xf0,0xf1,0xf2,0xf3,EOT}, - {0x00,0x02,0xf8,0x03,0x00,0x50,0x00,0x7f,EOT}}, - {0x3, - {0x30,0x60,0x61,0x62,0x63,0x70,0x74,0xf0,EOT}, - {0x00,0x03,0x78,0x07,0x78,0x07,0x03,0x03,EOT}}, - {0x4, - {0x30,0x60,0x61,0x62,0x63,0x70,0xf0,0xf1,0xf2,0xf3, - 0xf4,0xf5,0xf6,EOT}, - {0x00,0x02,0x90,0x02,0x30,0x09,0x00,0x00,0x00,0x00, - 0x00,NANA,NANA,EOT}}, - {0x5, - {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf0,EOT}, - {0x01,0x00,0x60,0x00,0x64,0x01,0x02,0x08,EOT}}, - {0x6, - {0x30,0x70,0x71,0xf0,EOT}, - {0x00,0x0c,0x02,0x00,EOT}}, - {0x7, - {0x25,0x26,0x27,0x28,0x29,0x2a,0x2c,0x60,0x61,0x62, - 0x63,0x64,0x65,0x70,0x71,0x72,0x73,0x74,0xb0,0xb1, - 0xb2,0xb3,0xb4,0xb5,0xb8,0xb9,0xba,0xbb,0xbc,0xbd, - 0xc0,0xc1,0xc2,0xc3,0xc4,0xc8,0xc9,0xca,0xcb,0xcc, - 0xe0,0xe1,0xe2,0xe3,0xe4,0xf0,0xf1,0xf2,0xf3,0xf4, - 0xf5,0xf6,0xf7,0xf8,0xf9,0xfa,0xfb,0xfc,0xfd,EOT}, - {0x01,0x00,0x00,0x40,0x00,0x00,0x00,0x00,0x00,0x00, - 0x00,0x00,0x00,0x00,0x00,0x30,0x38,0x00,0x00,0x00, - 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, - 0x01,0x00,0x00,0x40,0x00,0x01,0x00,0x00,0x40,0x00, - 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, - 0x00,0x00,0x00,0x00,0x00,0x00,0x00,NANA,0x00,EOT}}, - {0x8, - {0x30,0x60,0x61,0x70,0xf0,EOT}, - {0x00,0x03,0x00,0x0a,0x00,EOT}}, - {0x9, - {0x30,0x60,0x61,EOT}, - {0x00,0x02,0x01,EOT}}, - {0xa, - {0x30,0x60,0x61,0x70,0xf0,EOT}, - {0x00,0x03,0x10,0x0b,0x00,EOT}}, - {EOT}}}, - {0x8716, "IT8716", { - {EOT}}}, - {0x8718, "IT8718", { - {EOT}}}, - {EOT} -}; - -void -dump_ite(unsigned short port, unsigned short id) -{ - int i, j, k; - signed short *idx; - printf ("ITE "); - - - /* ID Mapping Table - unknown -> IT8711 (no datasheet) - unknown -> IT8722 (no datasheet) - 0x8702 -> IT8702 - 0x8705 -> IT8700 or IT8705 - 0x8708 -> IT8708 - 0x8710 -> IT8710 - 0x8712 -> IT8712 - 0x8716 -> IT8716 - 0x8718 -> IT8718 - 0x8726 -> IT8726 (datasheet wrongly says 0x8716) - */ - switch(id) { - case 0x8702: - case 0x8705: - case 0x8708: - case 0x8710: - case 0x8712: - case 0x8716: - case 0x8718: - for (i=0;; i++) { - if (ite_reg_table[i].superio_id == EOT) - break; - if ((unsigned short)ite_reg_table[i].superio_id != id) - continue; - printf ("%s\n", ite_reg_table[i].name); - for (j=0;; j++) { - if (ite_reg_table[i].ldn[j].ldn == EOT) - break; - if (ite_reg_table[i].ldn[j].ldn != NOLDN) { - printf("switching to LDN 0x%01x\n", - ite_reg_table[i].ldn[j].ldn); - regwrite(port, 0x07, - ite_reg_table[i].ldn[j].ldn); - } - idx = ite_reg_table[i].ldn[j].idx; - printf("idx "); - for (k=0;; k++) { - if (idx[k] == EOT) - break; - printf("%02x ", idx[k]); - } - printf("\nval "); - for (k=0;; k++) { - if (idx[k] == EOT) - break; - printf("%02x ", regval(port, idx[k])); - } - printf("\ndef "); - idx = ite_reg_table[i].ldn[j].def; - for (k=0;; k++) { - if (idx[k] == EOT) - break; - if (idx[k] == NANA) - printf("NA "); - else - printf("%02x ", idx[k]); - } - printf("\n"); - } - - } - break; - default: - printf ("unknown ITE chip, id=%04x\n", id); - for (i=0x20; i<=0x24; i++) - printf("index %02x=%02x\n", i, regval(port, i)); - break; - } -} - -void -probe_idregs_simple(unsigned short port){ - unsigned char id; - outb(0x20, port); - if (inb(port) != 0x20) { - if (inb(port) == 0xff ) - printf ("No SuperI/O chip found at 0x%04x\n", port); - else - printf("probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", - port, inb(port), inb(port + 1)); - return; - } - id = inb(port + 1); - - printf("SuperI/O found at 0x%02x: id = 0x%02x\n", port, id); - if (id == 0xff) - return; - - if (familyid[id]) - printf("%s\n", familyid[id]); - else - printf("\n"); - - switch(id) { - case 0xf1: - dump_ns8374(port); - break; - default: - printf("no dump for 0x%02x\n", id); - break; - } -} - - -void -probe_idregs_fintek(unsigned short port){ - unsigned int vid, did, success = 0; - - /* Enable configuration sequence (Fintek uses this for example) - Older ITE chips have the same enable sequence */ - outb(0x87, port); - outb(0x87, port); - - outb(0x20, port); - if (inb(port) != 0x20) { - if (inb(port) == 0xff ) - printf ("No SuperIO chip found at 0x%04x\n", port); - else - printf("probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", - port, inb(port), inb(port + 1)); - return; - } - did = inb(port + 1); - - did |= (regval(port, 0x21)<<8); - - vid = regval(port, 0x23); - vid |= (regval(port, 0x24)<<8); - - printf("SuperIO found at 0x%02x: vid=0x%04x/did=0x%04x\n", port, vid, did); - - if (vid == 0xff || vid == 0xffff) - return; - - /* printf("%s\n", familyid[id]); */ - switch(did) { - case 0x0887: /* pseudoreversed for ITE8708 */ - case 0x1087: /* pseudoreversed for ITE8710 */ - success = 1; - dump_ite(port, ((did & 0xff) << 8) | ((did & 0xff00) >> 8)); - /* disable configuration */ - regwrite(port, 0x02, 0x02); - break; - default: - break; - } - switch(vid) { - case 0x3419: - success = 1; - dump_fintek(port, did); - break; - default: - break; - } - if (!success) - printf("no dump for vid 0x%04x, did 0x%04x\n", vid, did); - - /* disable configuration (for Fintek, doesn't hurt ITE) */ - outb(0xaa, port); -} - -void -probe_idregs_ite(unsigned short port){ - unsigned int id, chipver; - - /* Enable configuration sequence (ITE uses this for newer IT87[012]x) - IT871[01] uses 0x87, 0x87 -> fintek detection should handle it - IT8708 uses 0x87, 0x87 -> fintek detection should handle it - IT8761 uses 0x87, 0x61, 0x55, 0x55/0xaa - IT86xx series uses different ports - IT8661 uses 0x86, 0x61, 0x55/0xaa, 0x55/0xaa and 32 more writes - IT8673 uses 0x86, 0x80, 0x55/0xaa, 0x55/0xaa and 32 more writes */ - outb(0x87, port); - outb(0x01, port); - outb(0x55, port); - if (port == 0x2e) - outb(0x55, port); - else - outb(0xAA, port); - - /* Read Chip ID Byte 1 */ - id = regval(port, 0x20); - if (id != 0x87) { - if (inb(port) == 0xff ) - printf ("No SuperIO chip found at 0x%04x\n", port); - else - printf("probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", - port, inb(port), inb(port + 1)); - return; - } - - id <<= 8; - - /* Read Chip ID Byte 2 */ - id |= regval(port, 0x21); - - /* Read Chip Version, only bit 3..0 for all IT87xx */ - chipver = regval(port, 0x22) & 0x0f; - - /* ID Mapping Table - unknown -> IT8711 (no datasheet) - unknown -> IT8722 (no datasheet) - 0x8702 -> IT8702 - 0x8705 -> IT8700 or IT8705 - 0x8708 -> IT8708 - 0x8710 -> IT8710 - 0x8712 -> IT8712 - 0x8716 -> IT8716 - 0x8718 -> IT8718 - 0x8726 -> IT8726 (datasheet wrongly says 0x8716) - */ - printf("SuperI/O found at 0x%02x: id=0x%04x, chipver=0x%01x\n", - port, id, chipver); - - switch(id) { - case 0x8702: - case 0x8705: - case 0x8708: - case 0x8712: - case 0x8716: - case 0x8718: - case 0x8726: - dump_ite(port, id); - break; - default: - printf("no dump for id 0x%04x\n", id); - break; - } - /* disable configuration */ - regwrite(port, 0x02, 0x02); -} - -void -probe_superio(unsigned short port) { - probe_idregs_simple(port); - probe_idregs_fintek(port); - probe_idregs_ite(port); -} - -int -main(int argc, char *argv[]) -{ - if (iopl(3) < 0) { - perror("iopl"); - exit(1); - } - - /* try the 2e */ - probe_superio(0x2e); - /* now try the 4e */ - probe_superio(0x4e); - - return 0; -} Copied: trunk/util/superiotool/superiotool.c (from rev 2758, trunk/util/superiotool/probe_superio.c) =================================================================== --- trunk/util/superiotool/superiotool.c (rev 0) +++ trunk/util/superiotool/superiotool.c 2007-09-01 20:20:41 UTC (rev 2759) @@ -0,0 +1,538 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 Ronald Minnich + * Copyright (C) 2006 coresystems GmbH + * Copyright (C) 2007 Carl-Daniel Hailfinger + * Copyright (C) 2007 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 + +/* well, they really thought this through, eh? Family is 8 bits!!!! */ +char *familyid[] = { + [0xf1] = "pc8374 (winbond, was NS)" +}; + +/* eventually, if you care, break this out into a file. For now, I don't know + * if we need this. + */ + +unsigned char regval(unsigned short port, unsigned char reg) { + outb(reg, port); + return inb(port + 1); +} + +void regwrite(unsigned short port, unsigned char reg, unsigned char val) { + outb(reg, port); + outb(val, port + 1); +} + +void +dump_ns8374(unsigned short port) { + printf("Enables: 21=%02x, 22=%02x, 23=%02x, 24=%02x, 26=%02x\n", + regval(port, 0x21), regval(port, 0x22), regval(port, 0x23), + regval(port, 0x24), regval(port, 0x26)); + printf("SMBUS at %02x\n", regval(port, 0x2a)); + /* check COM1. This is all we care about at present. */ + printf("COM 1 is Globally %s\n", regval(port, 0x26) & 8 ? "disabled" : "enabled"); + /* select com1 */ + regwrite(port, 0x07, 0x03); + printf("COM 1 is locally %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); + printf("COM1 60=%02x, 61=%02x, 70=%02x, 71=%02x, 74=%02x, 75=%02x, f0=%02x\n", + regval(port, 0x60), regval(port, 0x61), regval(port, 0x70), regval(port, 0x71), + regval(port, 0x74), regval(port, 0x75), regval(port, 0xf0)); + /* select gpio */ + regwrite(port, 0x07, 0x07); + printf("GPIO is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); + printf("GPIO 60=%02x, 61=%02x, 70=%02x, 71=%02x, 74=%02x, 75=%02x, f0=%02x\n", + regval(port, 0x60), regval(port, 0x61), regval(port, 0x70), regval(port, 0x71), + regval(port, 0x74), regval(port, 0x75), regval(port, 0xf0)); + +} + +void +dump_fintek(unsigned short port, unsigned int did) +{ + switch(did) { + case 0x0604: + printf ("Fintek F71805\n"); + break; + case 0x4103: + printf ("Fintek F71872\n"); + break; + default: + printf ("Unknown Fintek SuperI/O: did=0x%04x\n", did); + return; + } + + printf("Flash write is %s.\n", regval(port, 0x28) & 0x80 ? "enabled" : "disabled"); + printf("Flash control is 0x%04x.\n", regval(port, 0x28)); + printf("27=%02x\n", regval(port, 0x27)); + printf("29=%02x\n", regval(port, 0x29)); + printf("2a=%02x\n", regval(port, 0x2a)); + printf("2b=%02x\n", regval(port, 0x2b)); + + /* select UART 1 */ + regwrite(port, 0x07, 0x01); + printf("UART1 is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); + printf("UART1 base=%02x%02x, irq=%02x, mode=%s\n", + regval(port, 0x60), regval(port, 0x61), regval(port, 0x70) & 0x0f, + regval(port, 0xf0) & 0x10 ? "RS485":"RS232"); + + /* select UART 2 */ + regwrite(port, 0x07, 0x02); + printf("UART2 is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); + printf("UART2 base=%02x%02x, irq=%02x, mode=%s\n", + regval(port, 0x60), regval(port, 0x61), regval(port, 0x70) & 0x0f, + regval(port, 0xf0) & 0x10 ? "RS485":"RS232"); + + /* select Parport */ + regwrite(port, 0x07, 0x03); + printf("PARPORT is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); + printf("PARPORT base=%02x%02x, irq=%02x\n", + regval(port, 0x60), regval(port, 0x61), regval(port, 0x70) & 0x0f); + + /* select hw monitor */ + regwrite(port, 0x07, 0x04); + printf("HW monitor is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); + printf("HW monitor base=%02x%02x, irq=%02x\n", + regval(port, 0x60), regval(port, 0x61), regval(port, 0x70) & 0x0f); + + /* select gpio */ + regwrite(port, 0x07, 0x05); + printf("GPIO is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); + printf("GPIO 70=%02x, e0=%02x, e1=%02x, e2=%02x, e3=%02x, e4=%02x, e5=%02x\n", + regval(port, 0x70), regval(port, 0xe0), regval(port, 0xe1), regval(port, 0xe2), + regval(port, 0xe3), regval(port, 0xe4), regval(port, 0xe5)); + printf("GPIO e6=%02x, e7=%02x, e8=%02x, e9=%02x, f0=%02x, f1=%02x, f3=%02x, f4=%02x\n", + regval(port, 0xe6), regval(port, 0xe7), regval(port, 0xe8), regval(port, 0xe9), + regval(port, 0xf0), regval(port, 0xf1), regval(port, 0xf3), regval(port, 0xf4)); + printf("GPIO f5=%02x, f6=%02x, f7=%02x, f8=%02x\n", + regval(port, 0xf5), regval(port, 0xf6), regval(port, 0xf7), regval(port, 0xf8)); + + +} + +/* End Of Table */ +#define EOT -1 +/* NO LDN needed */ +#define NOLDN -2 +/* Not Available */ +#define NANA -3 +/* Maximum Name Length */ +#define MAXNAMELEN 20 +/* Biggest LDN */ +#define MAXLDN 0xa +/* biggestLDN + 0 + NOLDN + EOT */ +#define LDNSIZE MAXLDN + 3 +/* MAXimum NUMber of Indexes */ +#define MAXNUMIDX 70 +#define IDXSIZE MAXNUMIDX + 1 + +const static struct ite_registers { + /* yes, superio_id should be unsigned, but EOT has to be negative */ + signed short superio_id; + char name[MAXNAMELEN]; + struct ite_ldnidx { + signed short ldn; + signed short idx[IDXSIZE]; + signed short def[IDXSIZE]; + } ldn[LDNSIZE]; +} ite_reg_table[] = { + {0x8702, "IT8702", { + {EOT}}}, + {0x8705, "IT8705 or IT8700", { + {EOT}}}, + {0x8708, "IT8708", { + {NOLDN, + {0x07,0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27,0x28, + 0x29,0x2a,0x2e,0x2f,EOT}, + {NANA,0x87,0x08,0x00,0x00,NANA,0x3f,0x00,0xff,0xff, + 0xff,0xff,0x00,0x00,EOT}}, + {0x0, + {0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT}, + {0x00,0x03,0xf0,0x06,0x02,0x00,0x00,EOT}}, + {0x1, + {0x30,0x60,0x61,0x70,0xf0,EOT}, + {0x00,0x03,0xf8,0x04,0x00,EOT}}, + {0x2, + {0x30,0x60,0x61,0x70,0xf0,0xf1,0xf2,0xf3,EOT}, + {0x00,0x02,0xf8,0x03,0x00,0x50,0x00,0x7f,EOT}}, + {0x3, + {0x30,0x60,0x61,0x62,0x63,0x64,0x65,0x70,0x74, + 0xf0,EOT}, + {0x00,0x03,0x78,0x07,0x78,0x00,0x80,0x07,0x03, + 0x03,EOT}}, + {0x4, + {0xe0,0xe1,0xe2,0xe3,0xe4,0xe5,0xe6,0xe7, + 0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,EOT}, + {NANA,NANA,0x00,0x00,0x00,0x00,0x00,0x00, + 0x00,0x00,0x00,0x00,0x00,NANA,NANA,EOT}}, + {0x5, /* Note: 0x30 can actually be 0x00 _or_ 0x01. */ + {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf0,EOT}, + {0x01,0x00,0x60,0x00,0x64,0x01,0x02,0x00,EOT}}, + {0x6, + {0x30,0x70,0x71,0xf0,EOT}, + {0x00,0x0c,0x02,0x00,EOT}}, + {0x7, + {0x70,0xb0,0xb1,0xb2,0xb3,0xb4,0xb5,0xb8,0xb9,0xba, + 0xbb,0xbc,0xbd,0xc0,0xc1,0xc2,0xc3,0xc4,0xc5,0xc8, + 0xc9,0xca,0xcb,0xcc,0xcd,0xd0,0xd1,0xd2,0xd3,0xd4, + 0xd5,0xd6,0xd7,0xd8,0xd9,0xda,0xdb,0xdc,0xf0,0xf1, + 0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9,0xfa,0xfb, + 0xfc,EOT}, + {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, + 0x00,0x00,NANA,NANA,NANA,NANA,NANA,NANA,0x00,0x00, + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,NANA, + 0x00,EOT}}, + {0x8, + {0x30,0x60,0x61,EOT}, + {0x00,0x02,0x01,EOT}}, + {0x9, + {0x30,0x60,0x61,0x70,0xf0,EOT}, + {0x00,0x03,0x10,0x0b,0x00,EOT}}, + {0xa, + {0x30,0x60,0x61,0x70,0xf0,EOT}, + {0x00,0x03,0x00,0x0a,0x00,EOT}}, + {EOT}}}, + {0x8710, "IT8710", { + {EOT}}}, + {0x8712, "IT8712", { + {NOLDN, + {0x07,0x20,0x21,0x22,0x23,0x24,0x2b,EOT}, + {NANA,0x87,0x12,0x08,0x00,0x00,0x00,EOT}}, + {0x0, + {0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT}, + {0x00,0x03,0xf0,0x06,0x02,0x00,0x00,EOT}}, + {0x1, + {0x30,0x60,0x61,0x70,0xf0,0xf1,0xf2,0xf3,EOT}, + {0x00,0x03,0xf8,0x04,0x00,0x50,0x00,0x7f,EOT}}, + {0x2, + {0x30,0x60,0x61,0x70,0xf0,0xf1,0xf2,0xf3,EOT}, + {0x00,0x02,0xf8,0x03,0x00,0x50,0x00,0x7f,EOT}}, + {0x3, + {0x30,0x60,0x61,0x62,0x63,0x70,0x74,0xf0,EOT}, + {0x00,0x03,0x78,0x07,0x78,0x07,0x03,0x03,EOT}}, + {0x4, + {0x30,0x60,0x61,0x62,0x63,0x70,0xf0,0xf1,0xf2,0xf3, + 0xf4,0xf5,0xf6,EOT}, + {0x00,0x02,0x90,0x02,0x30,0x09,0x00,0x00,0x00,0x00, + 0x00,NANA,NANA,EOT}}, + {0x5, + {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf0,EOT}, + {0x01,0x00,0x60,0x00,0x64,0x01,0x02,0x08,EOT}}, + {0x6, + {0x30,0x70,0x71,0xf0,EOT}, + {0x00,0x0c,0x02,0x00,EOT}}, + {0x7, + {0x25,0x26,0x27,0x28,0x29,0x2a,0x2c,0x60,0x61,0x62, + 0x63,0x64,0x65,0x70,0x71,0x72,0x73,0x74,0xb0,0xb1, + 0xb2,0xb3,0xb4,0xb5,0xb8,0xb9,0xba,0xbb,0xbc,0xbd, + 0xc0,0xc1,0xc2,0xc3,0xc4,0xc8,0xc9,0xca,0xcb,0xcc, + 0xe0,0xe1,0xe2,0xe3,0xe4,0xf0,0xf1,0xf2,0xf3,0xf4, + 0xf5,0xf6,0xf7,0xf8,0xf9,0xfa,0xfb,0xfc,0xfd,EOT}, + {0x01,0x00,0x00,0x40,0x00,0x00,0x00,0x00,0x00,0x00, + 0x00,0x00,0x00,0x00,0x00,0x30,0x38,0x00,0x00,0x00, + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, + 0x01,0x00,0x00,0x40,0x00,0x01,0x00,0x00,0x40,0x00, + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,NANA,0x00,EOT}}, + {0x8, + {0x30,0x60,0x61,0x70,0xf0,EOT}, + {0x00,0x03,0x00,0x0a,0x00,EOT}}, + {0x9, + {0x30,0x60,0x61,EOT}, + {0x00,0x02,0x01,EOT}}, + {0xa, + {0x30,0x60,0x61,0x70,0xf0,EOT}, + {0x00,0x03,0x10,0x0b,0x00,EOT}}, + {EOT}}}, + {0x8716, "IT8716", { + {EOT}}}, + {0x8718, "IT8718", { + {EOT}}}, + {EOT} +}; + +void +dump_ite(unsigned short port, unsigned short id) +{ + int i, j, k; + signed short *idx; + printf ("ITE "); + + + /* ID Mapping Table + unknown -> IT8711 (no datasheet) + unknown -> IT8722 (no datasheet) + 0x8702 -> IT8702 + 0x8705 -> IT8700 or IT8705 + 0x8708 -> IT8708 + 0x8710 -> IT8710 + 0x8712 -> IT8712 + 0x8716 -> IT8716 + 0x8718 -> IT8718 + 0x8726 -> IT8726 (datasheet wrongly says 0x8716) + */ + switch(id) { + case 0x8702: + case 0x8705: + case 0x8708: + case 0x8710: + case 0x8712: + case 0x8716: + case 0x8718: + for (i=0;; i++) { + if (ite_reg_table[i].superio_id == EOT) + break; + if ((unsigned short)ite_reg_table[i].superio_id != id) + continue; + printf ("%s\n", ite_reg_table[i].name); + for (j=0;; j++) { + if (ite_reg_table[i].ldn[j].ldn == EOT) + break; + if (ite_reg_table[i].ldn[j].ldn != NOLDN) { + printf("switching to LDN 0x%01x\n", + ite_reg_table[i].ldn[j].ldn); + regwrite(port, 0x07, + ite_reg_table[i].ldn[j].ldn); + } + idx = ite_reg_table[i].ldn[j].idx; + printf("idx "); + for (k=0;; k++) { + if (idx[k] == EOT) + break; + printf("%02x ", idx[k]); + } + printf("\nval "); + for (k=0;; k++) { + if (idx[k] == EOT) + break; + printf("%02x ", regval(port, idx[k])); + } + printf("\ndef "); + idx = ite_reg_table[i].ldn[j].def; + for (k=0;; k++) { + if (idx[k] == EOT) + break; + if (idx[k] == NANA) + printf("NA "); + else + printf("%02x ", idx[k]); + } + printf("\n"); + } + + } + break; + default: + printf ("unknown ITE chip, id=%04x\n", id); + for (i=0x20; i<=0x24; i++) + printf("index %02x=%02x\n", i, regval(port, i)); + break; + } +} + +void +probe_idregs_simple(unsigned short port){ + unsigned char id; + outb(0x20, port); + if (inb(port) != 0x20) { + if (inb(port) == 0xff ) + printf ("No SuperI/O chip found at 0x%04x\n", port); + else + printf("probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", + port, inb(port), inb(port + 1)); + return; + } + id = inb(port + 1); + + printf("SuperI/O found at 0x%02x: id = 0x%02x\n", port, id); + if (id == 0xff) + return; + + if (familyid[id]) + printf("%s\n", familyid[id]); + else + printf("\n"); + + switch(id) { + case 0xf1: + dump_ns8374(port); + break; + default: + printf("no dump for 0x%02x\n", id); + break; + } +} + + +void +probe_idregs_fintek(unsigned short port){ + unsigned int vid, did, success = 0; + + /* Enable configuration sequence (Fintek uses this for example) + Older ITE chips have the same enable sequence */ + outb(0x87, port); + outb(0x87, port); + + outb(0x20, port); + if (inb(port) != 0x20) { + if (inb(port) == 0xff ) + printf ("No SuperIO chip found at 0x%04x\n", port); + else + printf("probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", + port, inb(port), inb(port + 1)); + return; + } + did = inb(port + 1); + + did |= (regval(port, 0x21)<<8); + + vid = regval(port, 0x23); + vid |= (regval(port, 0x24)<<8); + + printf("SuperIO found at 0x%02x: vid=0x%04x/did=0x%04x\n", port, vid, did); + + if (vid == 0xff || vid == 0xffff) + return; + + /* printf("%s\n", familyid[id]); */ + switch(did) { + case 0x0887: /* pseudoreversed for ITE8708 */ + case 0x1087: /* pseudoreversed for ITE8710 */ + success = 1; + dump_ite(port, ((did & 0xff) << 8) | ((did & 0xff00) >> 8)); + /* disable configuration */ + regwrite(port, 0x02, 0x02); + break; + default: + break; + } + switch(vid) { + case 0x3419: + success = 1; + dump_fintek(port, did); + break; + default: + break; + } + if (!success) + printf("no dump for vid 0x%04x, did 0x%04x\n", vid, did); + + /* disable configuration (for Fintek, doesn't hurt ITE) */ + outb(0xaa, port); +} + +void +probe_idregs_ite(unsigned short port){ + unsigned int id, chipver; + + /* Enable configuration sequence (ITE uses this for newer IT87[012]x) + IT871[01] uses 0x87, 0x87 -> fintek detection should handle it + IT8708 uses 0x87, 0x87 -> fintek detection should handle it + IT8761 uses 0x87, 0x61, 0x55, 0x55/0xaa + IT86xx series uses different ports + IT8661 uses 0x86, 0x61, 0x55/0xaa, 0x55/0xaa and 32 more writes + IT8673 uses 0x86, 0x80, 0x55/0xaa, 0x55/0xaa and 32 more writes */ + outb(0x87, port); + outb(0x01, port); + outb(0x55, port); + if (port == 0x2e) + outb(0x55, port); + else + outb(0xAA, port); + + /* Read Chip ID Byte 1 */ + id = regval(port, 0x20); + if (id != 0x87) { + if (inb(port) == 0xff ) + printf ("No SuperIO chip found at 0x%04x\n", port); + else + printf("probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", + port, inb(port), inb(port + 1)); + return; + } + + id <<= 8; + + /* Read Chip ID Byte 2 */ + id |= regval(port, 0x21); + + /* Read Chip Version, only bit 3..0 for all IT87xx */ + chipver = regval(port, 0x22) & 0x0f; + + /* ID Mapping Table + unknown -> IT8711 (no datasheet) + unknown -> IT8722 (no datasheet) + 0x8702 -> IT8702 + 0x8705 -> IT8700 or IT8705 + 0x8708 -> IT8708 + 0x8710 -> IT8710 + 0x8712 -> IT8712 + 0x8716 -> IT8716 + 0x8718 -> IT8718 + 0x8726 -> IT8726 (datasheet wrongly says 0x8716) + */ + printf("SuperI/O found at 0x%02x: id=0x%04x, chipver=0x%01x\n", + port, id, chipver); + + switch(id) { + case 0x8702: + case 0x8705: + case 0x8708: + case 0x8712: + case 0x8716: + case 0x8718: + case 0x8726: + dump_ite(port, id); + break; + default: + printf("no dump for id 0x%04x\n", id); + break; + } + /* disable configuration */ + regwrite(port, 0x02, 0x02); +} + +void +probe_superio(unsigned short port) { + probe_idregs_simple(port); + probe_idregs_fintek(port); + probe_idregs_ite(port); +} + +int +main(int argc, char *argv[]) +{ + if (iopl(3) < 0) { + perror("iopl"); + exit(1); + } + + /* try the 2e */ + probe_superio(0x2e); + /* now try the 4e */ + probe_superio(0x4e); + + return 0; +} From svn at openbios.org Sat Sep 1 22:24:31 2007 From: svn at openbios.org (svn at openbios.org) Date: Sat, 1 Sep 2007 22:24:31 +0200 Subject: [LinuxBIOS] r2760 - trunk/util/superiotool Message-ID: Author: uwe Date: 2007-09-01 22:24:30 +0200 (Sat, 01 Sep 2007) New Revision: 2760 Modified: trunk/util/superiotool/superiotool.c Log: Add ITE IT8716F support to probe_superio. This helps especially GA-M57SLI board owners who wish to debug remaining problems or handle SPI flash of newer board versions. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Uwe Hermann Modified: trunk/util/superiotool/superiotool.c =================================================================== --- trunk/util/superiotool/superiotool.c 2007-09-01 20:20:41 UTC (rev 2759) +++ trunk/util/superiotool/superiotool.c 2007-09-01 20:24:30 UTC (rev 2760) @@ -267,6 +267,54 @@ {0x00,0x03,0x10,0x0b,0x00,EOT}}, {EOT}}}, {0x8716, "IT8716", { + {NOLDN, + {0x07,0x20,0x21,0x22,0x23,0x24,0x2b,EOT}, + {NANA,0x87,0x16,0x01,0x00,0x00,0x00,EOT}}, + {0x0, + {0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT}, + {0x00,0x03,0xf0,0x06,0x02,0x00,0x00,EOT}}, + {0x1, + {0x30,0x60,0x61,0x70,0xf0,0xf1,0xf2,0xf3,EOT}, + {0x00,0x03,0xf8,0x04,0x00,0x50,0x00,0x7f,EOT}}, + {0x2, + {0x30,0x60,0x61,0x70,0xf0,0xf1,0xf2,0xf3,EOT}, + {0x00,0x02,0xf8,0x03,0x00,0x50,0x00,0x7f,EOT}}, + {0x3, + {0x30,0x60,0x61,0x62,0x63,0x70,0x74,0xf0,EOT}, + {0x00,0x03,0x78,0x07,0x78,0x07,0x03,0x03,EOT}}, + {0x4, + {0x30,0x60,0x61,0x62,0x63,0x70,0xf0,0xf1,0xf2,0xf3, + 0xf4,0xf5,0xf6,EOT}, + {0x00,0x02,0x90,0x02,0x30,0x09,0x00,0x00,0x00,0x00, + 0x00,NANA,NANA,EOT}}, + {0x5, + {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf0,EOT}, + {0x01,0x00,0x60,0x00,0x64,0x01,0x02,0x00,EOT}}, + {0x6, + {0x30,0x70,0x71,0xf0,EOT}, + {0x00,0x0c,0x02,0x00,EOT}}, + {0x7, + {0x25,0x26,0x27,0x28,0x29,0x2a,0x2c,0x60,0x61,0x62, + 0x63,0x64,0x65,0x70,0x71,0x72,0x73,0x74,0xb0,0xb1, + 0xb2,0xb3,0xb4,0xb5,0xb8,0xb9,0xba,0xbb,0xbc,0xbd, + 0xc0,0xc1,0xc2,0xc3,0xc4,0xc8,0xc9,0xca,0xcb,0xcc, + 0xe0,0xe1,0xe2,0xe3,0xe4,0xf0,0xf1,0xf2,0xf3,0xf4, + 0xf5,0xf6,0xf7,0xf8,0xf9,0xfa,0xfb,0xfc,0xfd,EOT}, + {0x01,0x00,0x00,0x40,0x00,0x00,0x00,0x00,0x00,0x00, + 0x00,0x00,0x00,0x00,0x00,0x20,0x38,0x00,0x00,0x00, + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, + 0x01,0x00,0x00,0x40,0x00,0x01,0x00,0x00,0x40,0x00, + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,NANA,0x00,EOT}}, + {0x8, + {0x30,0x60,0x61,0x70,0xf0,EOT}, + {0x00,0x03,0x00,0x0a,0x00,EOT}}, + {0x9, + {0x30,0x60,0x61,EOT}, + {0x00,0x02,0x01,EOT}}, + {0xa, + {0x30,0x60,0x61,0x70,0xf0,EOT}, + {0x00,0x03,0x10,0x0b,0x00,EOT}}, {EOT}}}, {0x8718, "IT8718", { {EOT}}}, From info at coresystems.de Sat Sep 1 22:29:26 2007 From: info at coresystems.de (LinuxBIOS information) Date: Sat, 01 Sep 2007 22:29:26 +0200 Subject: [LinuxBIOS] r2757 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2757 to the LinuxBIOS source repository and caused the following changes: Change Log: Add support for the ITE IT8708F. Here's a dump from my test system which has an IT8708F: No SuperI/O chip found at 0x002e probing 0x002e, failed (0x87), data returns 0x87 SuperI/O found at 0x2e: id=0x8708, chipver=0x0 ITE IT8708 idx 07 20 21 22 23 24 25 26 27 28 29 2a 2e 2f val 02 87 08 00 00 00 00 00 03 01 01 00 00 00 def NA 87 08 00 00 NA 3f 00 ff ff ff ff 00 00 switching to LDN 0x0 idx 30 60 61 70 74 f0 f1 val 01 03 f0 06 02 00 80 def 00 03 f0 06 02 00 00 switching to LDN 0x1 idx 30 60 61 70 f0 val 01 03 f8 04 00 def 00 03 f8 04 00 switching to LDN 0x2 idx 30 60 61 70 f0 f1 f2 f3 val 01 02 f8 03 00 50 01 7f def 00 02 f8 03 00 50 00 7f switching to LDN 0x3 idx 30 60 61 62 63 64 65 70 74 f0 val 01 03 78 07 78 00 80 07 03 0b def 00 03 78 07 78 00 80 07 03 03 switching to LDN 0x4 idx e0 e1 e2 e3 e4 e5 e6 e7 f0 f1 f2 f3 f4 f5 f6 val 80 61 00 00 00 00 00 00 80 00 30 00 80 00 de def NA NA 00 00 00 00 00 00 00 00 00 00 00 NA NA switching to LDN 0x5 idx 30 60 61 62 63 70 71 f0 val 01 00 60 00 64 01 02 0c def 01 00 60 00 64 01 02 00 switching to LDN 0x6 idx 30 70 71 f0 val 01 0c 02 00 def 00 0c 02 00 switching to LDN 0x7 idx 70 b0 b1 b2 b3 b4 b5 b8 b9 ba bb bc bd c0 c1 c2 c3 c4 c5 c8 c9 ca cb cc cd d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc val 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 01 01 00 00 00 03 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff 7f 20 51 00 0e 00 00 00 00 00 00 00 def 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 NA NA NA NA NA NA 00 00 00 00 00 00 00 00 00 00 00 NA 00 switching to LDN 0x8 idx 30 60 61 val 00 02 01 def 00 02 01 switching to LDN 0x9 idx 30 60 61 70 f0 val 00 03 10 0b 06 def 00 03 10 0b 00 switching to LDN 0xa idx 30 60 61 70 f0 val 00 03 00 0a 40 def 00 03 00 0a 00 No SuperI/O chip found at 0x004e No SuperIO chip found at 0x004e No SuperIO chip found at 0x004e Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2757&device=hdama&vendor=arima Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2757&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2757&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2757&device=juki-511p&vendor=iei Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2757&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2757&device=dk8x&vendor=iwill If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From uwe at hermann-uwe.de Sat Sep 1 22:29:35 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 1 Sep 2007 22:29:35 +0200 Subject: [LinuxBIOS] [PATCH] Add ITE IT8716F support to probe_superio In-Reply-To: <46D9C0BE.8080708@gmx.net> References: <46D9C0BE.8080708@gmx.net> Message-ID: <20070901202935.GC29232@greenwood> On Sat, Sep 01, 2007 at 09:42:54PM +0200, Carl-Daniel Hailfinger wrote: > Add ITE IT8716F support to probe_superio. This helps especially > GA-M57SLI board owners who wish to debug remaining problems or handle > SPI flash of newer board versions. > > Signed-off-by: Carl-Daniel Hailfinger r2760, thanks. 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 yinghailu at gmail.com Sat Sep 1 22:33:00 2007 From: yinghailu at gmail.com (yhlu) Date: Sat, 1 Sep 2007 13:33:00 -0700 Subject: [LinuxBIOS] problems with reboot on K8 In-Reply-To: <46D95675.5070009@assembler.cz> References: <46D1B902.6020503@assembler.cz> <46D95675.5070009@assembler.cz> Message-ID: <2ea3fae10709011333i44bb38dbo606cd58fb8eb621c@mail.gmail.com> boot log? YH From svn at openbios.org Sat Sep 1 23:02:44 2007 From: svn at openbios.org (svn at openbios.org) Date: Sat, 1 Sep 2007 23:02:44 +0200 Subject: [LinuxBIOS] r2761 - trunk/util/superiotool Message-ID: Author: uwe Date: 2007-09-01 23:02:44 +0200 (Sat, 01 Sep 2007) New Revision: 2761 Modified: trunk/util/superiotool/superiotool.c Log: Various coding style and whitespace fixes (trivial). Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Modified: trunk/util/superiotool/superiotool.c =================================================================== --- trunk/util/superiotool/superiotool.c 2007-09-01 20:24:30 UTC (rev 2760) +++ trunk/util/superiotool/superiotool.c 2007-09-01 21:02:44 UTC (rev 2761) @@ -25,131 +25,136 @@ #include #include -/* well, they really thought this through, eh? Family is 8 bits!!!! */ -char *familyid[] = { - [0xf1] = "pc8374 (winbond, was NS)" +/* Well, they really thought this through, eh? Family is 8 bits! */ +static const char *familyid[] = { + [0xf1] = "PC8374 (Winbond/NatSemi)" }; -/* eventually, if you care, break this out into a file. For now, I don't know - * if we need this. - */ - -unsigned char regval(unsigned short port, unsigned char reg) { +unsigned char regval(unsigned short port, unsigned char reg) +{ outb(reg, port); return inb(port + 1); } -void regwrite(unsigned short port, unsigned char reg, unsigned char val) { +void regwrite(unsigned short port, unsigned char reg, unsigned char val) +{ outb(reg, port); outb(val, port + 1); } -void -dump_ns8374(unsigned short port) { +void dump_ns8374(unsigned short port) +{ printf("Enables: 21=%02x, 22=%02x, 23=%02x, 24=%02x, 26=%02x\n", - regval(port, 0x21), regval(port, 0x22), regval(port, 0x23), - regval(port, 0x24), regval(port, 0x26)); + regval(port, 0x21), regval(port, 0x22), regval(port, 0x23), + regval(port, 0x24), regval(port, 0x26)); printf("SMBUS at %02x\n", regval(port, 0x2a)); - /* check COM1. This is all we care about at present. */ - printf("COM 1 is Globally %s\n", regval(port, 0x26) & 8 ? "disabled" : "enabled"); - /* select com1 */ + + /* Check COM1. This is all we care about at present. */ + printf("COM 1 is globally %s\n", + regval(port, 0x26) & 8 ? "disabled" : "enabled"); + + /* Select COM1. */ regwrite(port, 0x07, 0x03); - printf("COM 1 is locally %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); - printf("COM1 60=%02x, 61=%02x, 70=%02x, 71=%02x, 74=%02x, 75=%02x, f0=%02x\n", - regval(port, 0x60), regval(port, 0x61), regval(port, 0x70), regval(port, 0x71), - regval(port, 0x74), regval(port, 0x75), regval(port, 0xf0)); - /* select gpio */ + printf("COM 1 is locally %s\n", + regval(port, 0x30) & 1 ? "enabled" : "disabled"); + printf + ("COM1 60=%02x, 61=%02x, 70=%02x, 71=%02x, 74=%02x, 75=%02x, f0=%02x\n", + regval(port, 0x60), regval(port, 0x61), regval(port, 0x70), + regval(port, 0x71), regval(port, 0x74), regval(port, 0x75), + regval(port, 0xf0)); + + /* Select GPIO. */ regwrite(port, 0x07, 0x07); printf("GPIO is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); - printf("GPIO 60=%02x, 61=%02x, 70=%02x, 71=%02x, 74=%02x, 75=%02x, f0=%02x\n", - regval(port, 0x60), regval(port, 0x61), regval(port, 0x70), regval(port, 0x71), - regval(port, 0x74), regval(port, 0x75), regval(port, 0xf0)); - + printf + ("GPIO 60=%02x, 61=%02x, 70=%02x, 71=%02x, 74=%02x, 75=%02x, f0=%02x\n", + regval(port, 0x60), regval(port, 0x61), regval(port, 0x70), + regval(port, 0x71), regval(port, 0x74), regval(port, 0x75), + regval(port, 0xf0)); } -void -dump_fintek(unsigned short port, unsigned int did) +void dump_fintek(unsigned short port, unsigned int did) { - switch(did) { + switch (did) { case 0x0604: - printf ("Fintek F71805\n"); + printf("Fintek F71805\n"); break; case 0x4103: - printf ("Fintek F71872\n"); + printf("Fintek F71872\n"); break; default: - printf ("Unknown Fintek SuperI/O: did=0x%04x\n", did); + printf("Unknown Fintek Super I/O: did=0x%04x\n", did); return; } - printf("Flash write is %s.\n", regval(port, 0x28) & 0x80 ? "enabled" : "disabled"); + printf("Flash write is %s.\n", + regval(port, 0x28) & 0x80 ? "enabled" : "disabled"); printf("Flash control is 0x%04x.\n", regval(port, 0x28)); printf("27=%02x\n", regval(port, 0x27)); printf("29=%02x\n", regval(port, 0x29)); printf("2a=%02x\n", regval(port, 0x2a)); printf("2b=%02x\n", regval(port, 0x2b)); - /* select UART 1 */ + /* Select UART 1. */ regwrite(port, 0x07, 0x01); - printf("UART1 is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); - printf("UART1 base=%02x%02x, irq=%02x, mode=%s\n", - regval(port, 0x60), regval(port, 0x61), regval(port, 0x70) & 0x0f, - regval(port, 0xf0) & 0x10 ? "RS485":"RS232"); + printf("UART1 is %s\n", + regval(port, 0x30) & 1 ? "enabled" : "disabled"); + printf("UART1 base=%02x%02x, irq=%02x, mode=%s\n", regval(port, 0x60), + regval(port, 0x61), regval(port, 0x70) & 0x0f, + regval(port, 0xf0) & 0x10 ? "RS485" : "RS232"); - /* select UART 2 */ + /* Select UART 2. */ regwrite(port, 0x07, 0x02); - printf("UART2 is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); - printf("UART2 base=%02x%02x, irq=%02x, mode=%s\n", - regval(port, 0x60), regval(port, 0x61), regval(port, 0x70) & 0x0f, - regval(port, 0xf0) & 0x10 ? "RS485":"RS232"); + printf("UART2 is %s\n", + regval(port, 0x30) & 1 ? "enabled" : "disabled"); + printf("UART2 base=%02x%02x, irq=%02x, mode=%s\n", regval(port, 0x60), + regval(port, 0x61), regval(port, 0x70) & 0x0f, + regval(port, 0xf0) & 0x10 ? "RS485" : "RS232"); - /* select Parport */ + /* Select parallel port. */ regwrite(port, 0x07, 0x03); - printf("PARPORT is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); - printf("PARPORT base=%02x%02x, irq=%02x\n", - regval(port, 0x60), regval(port, 0x61), regval(port, 0x70) & 0x0f); + printf("PARPORT is %s\n", + regval(port, 0x30) & 1 ? "enabled" : "disabled"); + printf("PARPORT base=%02x%02x, irq=%02x\n", regval(port, 0x60), + regval(port, 0x61), regval(port, 0x70) & 0x0f); - /* select hw monitor */ + /* Select HW monitor. */ regwrite(port, 0x07, 0x04); - printf("HW monitor is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); - printf("HW monitor base=%02x%02x, irq=%02x\n", - regval(port, 0x60), regval(port, 0x61), regval(port, 0x70) & 0x0f); + printf("HW monitor is %s\n", + regval(port, 0x30) & 1 ? "enabled" : "disabled"); + printf("HW monitor base=%02x%02x, irq=%02x\n", regval(port, 0x60), + regval(port, 0x61), regval(port, 0x70) & 0x0f); - /* select gpio */ + /* Select GPIO. */ regwrite(port, 0x07, 0x05); printf("GPIO is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); - printf("GPIO 70=%02x, e0=%02x, e1=%02x, e2=%02x, e3=%02x, e4=%02x, e5=%02x\n", - regval(port, 0x70), regval(port, 0xe0), regval(port, 0xe1), regval(port, 0xe2), - regval(port, 0xe3), regval(port, 0xe4), regval(port, 0xe5)); - printf("GPIO e6=%02x, e7=%02x, e8=%02x, e9=%02x, f0=%02x, f1=%02x, f3=%02x, f4=%02x\n", - regval(port, 0xe6), regval(port, 0xe7), regval(port, 0xe8), regval(port, 0xe9), - regval(port, 0xf0), regval(port, 0xf1), regval(port, 0xf3), regval(port, 0xf4)); - printf("GPIO f5=%02x, f6=%02x, f7=%02x, f8=%02x\n", - regval(port, 0xf5), regval(port, 0xf6), regval(port, 0xf7), regval(port, 0xf8)); - - + printf + ("GPIO 70=%02x, e0=%02x, e1=%02x, e2=%02x, e3=%02x, e4=%02x, e5=%02x\n", + regval(port, 0x70), regval(port, 0xe0), regval(port, 0xe1), + regval(port, 0xe2), regval(port, 0xe3), regval(port, 0xe4), + regval(port, 0xe5)); + printf + ("GPIO e6=%02x, e7=%02x, e8=%02x, e9=%02x, f0=%02x, f1=%02x, f3=%02x, f4=%02x\n", + regval(port, 0xe6), regval(port, 0xe7), regval(port, 0xe8), + regval(port, 0xe9), regval(port, 0xf0), regval(port, 0xf1), + regval(port, 0xf3), regval(port, 0xf4)); + printf("GPIO f5=%02x, f6=%02x, f7=%02x, f8=%02x\n", regval(port, 0xf5), + regval(port, 0xf6), regval(port, 0xf7), regval(port, 0xf8)); } -/* End Of Table */ -#define EOT -1 -/* NO LDN needed */ -#define NOLDN -2 -/* Not Available */ -#define NANA -3 -/* Maximum Name Length */ -#define MAXNAMELEN 20 -/* Biggest LDN */ -#define MAXLDN 0xa -/* biggestLDN + 0 + NOLDN + EOT */ -#define LDNSIZE MAXLDN + 3 -/* MAXimum NUMber of Indexes */ -#define MAXNUMIDX 70 -#define IDXSIZE MAXNUMIDX + 1 +#define EOT -1 /* End Of Table */ +#define NOLDN -2 /* NO LDN needed */ +#define NANA -3 /* Not Available */ +#define MAXNAMELEN 20 /* Maximum Name Length */ +#define MAXLDN 0xa /* Biggest LDN */ +#define LDNSIZE (MAXLDN + 3) /* Biggest LDN + 0 + NOLDN + EOT */ +#define MAXNUMIDX 70 /* Maximum number of indexes */ +#define IDXSIZE (MAXNUMIDX + 1) const static struct ite_registers { - /* yes, superio_id should be unsigned, but EOT has to be negative */ + /* Yes, superio_id should be unsigned, but EOT has to be negative. */ signed short superio_id; - char name[MAXNAMELEN]; + const char name[MAXNAMELEN]; struct ite_ldnidx { signed short ldn; signed short idx[IDXSIZE]; @@ -321,14 +326,12 @@ {EOT} }; -void -dump_ite(unsigned short port, unsigned short id) +void dump_ite(unsigned short port, unsigned short id) { int i, j, k; signed short *idx; printf ("ITE "); - /* ID Mapping Table unknown -> IT8711 (no datasheet) unknown -> IT8722 (no datasheet) @@ -340,8 +343,8 @@ 0x8716 -> IT8716 0x8718 -> IT8718 0x8726 -> IT8726 (datasheet wrongly says 0x8716) - */ - switch(id) { + */ + switch (id) { case 0x8702: case 0x8705: case 0x8708: @@ -349,37 +352,37 @@ case 0x8712: case 0x8716: case 0x8718: - for (i=0;; i++) { + for (i = 0;; i++) { if (ite_reg_table[i].superio_id == EOT) break; if ((unsigned short)ite_reg_table[i].superio_id != id) continue; - printf ("%s\n", ite_reg_table[i].name); - for (j=0;; j++) { + printf("%s\n", ite_reg_table[i].name); + for (j = 0;; j++) { if (ite_reg_table[i].ldn[j].ldn == EOT) break; if (ite_reg_table[i].ldn[j].ldn != NOLDN) { - printf("switching to LDN 0x%01x\n", + printf("Switching to LDN 0x%01x\n", ite_reg_table[i].ldn[j].ldn); regwrite(port, 0x07, - ite_reg_table[i].ldn[j].ldn); + ite_reg_table[i].ldn[j].ldn); } idx = ite_reg_table[i].ldn[j].idx; printf("idx "); - for (k=0;; k++) { + for (k = 0;; k++) { if (idx[k] == EOT) break; printf("%02x ", idx[k]); } printf("\nval "); - for (k=0;; k++) { + for (k = 0;; k++) { if (idx[k] == EOT) break; printf("%02x ", regval(port, idx[k])); } printf("\ndef "); idx = ite_reg_table[i].ldn[j].def; - for (k=0;; k++) { + for (k = 0;; k++) { if (idx[k] == EOT) break; if (idx[k] == NANA) @@ -389,27 +392,25 @@ } printf("\n"); } - } break; default: - printf ("unknown ITE chip, id=%04x\n", id); - for (i=0x20; i<=0x24; i++) + printf("Unknown ITE chip, id=%04x\n", id); + for (i = 0x20; i <= 0x24; i++) printf("index %02x=%02x\n", i, regval(port, i)); break; } } -void -probe_idregs_simple(unsigned short port){ +void probe_idregs_simple(unsigned short port) +{ unsigned char id; outb(0x20, port); - if (inb(port) != 0x20) { - if (inb(port) == 0xff ) - printf ("No SuperI/O chip found at 0x%04x\n", port); + if (inb(port) != 0x20) { + if (inb(port) == 0xff) + printf("No SuperI/O chip found at 0x%04x\n", port); else - printf("probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", - port, inb(port), inb(port + 1)); + printf("probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", port, inb(port), inb(port + 1)); return; } id = inb(port + 1); @@ -418,90 +419,91 @@ if (id == 0xff) return; - if (familyid[id]) + if (familyid[id]) printf("%s\n", familyid[id]); else printf("\n"); - switch(id) { - case 0xf1: - dump_ns8374(port); - break; - default: - printf("no dump for 0x%02x\n", id); - break; + switch (id) { + case 0xf1: + dump_ns8374(port); + break; + default: + printf("no dump for 0x%02x\n", id); + break; } } - -void -probe_idregs_fintek(unsigned short port){ +void probe_idregs_fintek(unsigned short port) +{ unsigned int vid, did, success = 0; /* Enable configuration sequence (Fintek uses this for example) - Older ITE chips have the same enable sequence */ + * Older ITE chips have the same enable sequence. + */ outb(0x87, port); outb(0x87, port); outb(0x20, port); - if (inb(port) != 0x20) { - if (inb(port) == 0xff ) - printf ("No SuperIO chip found at 0x%04x\n", port); + if (inb(port) != 0x20) { + if (inb(port) == 0xff) + printf("No SuperIO chip found at 0x%04x\n", port); else - printf("probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", - port, inb(port), inb(port + 1)); + printf("probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", port, inb(port), inb(port + 1)); return; } did = inb(port + 1); + did |= (regval(port, 0x21) << 8); - did |= (regval(port, 0x21)<<8); - vid = regval(port, 0x23); - vid |= (regval(port, 0x24)<<8); + vid |= (regval(port, 0x24) << 8); - printf("SuperIO found at 0x%02x: vid=0x%04x/did=0x%04x\n", port, vid, did); + printf("Super I/O found at 0x%02x: vid=0x%04x/did=0x%04x\n", + port, vid, did); if (vid == 0xff || vid == 0xffff) return; /* printf("%s\n", familyid[id]); */ - switch(did) { - case 0x0887: /* pseudoreversed for ITE8708 */ - case 0x1087: /* pseudoreversed for ITE8710 */ - success = 1; - dump_ite(port, ((did & 0xff) << 8) | ((did & 0xff00) >> 8)); - /* disable configuration */ - regwrite(port, 0x02, 0x02); - break; - default: - break; + switch (did) { + case 0x0887: /* Pseudoreversed for ITE8708 */ + case 0x1087: /* Pseudoreversed for ITE8710 */ + success = 1; + dump_ite(port, ((did & 0xff) << 8) | ((did & 0xff00) >> 8)); + regwrite(port, 0x02, 0x02); /* Exit MB PnP mode. */ + break; + default: + break; } - switch(vid) { - case 0x3419: - success = 1; - dump_fintek(port, did); - break; - default: - break; + + switch (vid) { + case 0x3419: + success = 1; + dump_fintek(port, did); + break; + default: + break; } + if (!success) - printf("no dump for vid 0x%04x, did 0x%04x\n", vid, did); + printf("No dump for vid 0x%04x, did 0x%04x\n", vid, did); - /* disable configuration (for Fintek, doesn't hurt ITE) */ + /* Exit MB PnP mode (for Fintek, doesn't hurt ITE). */ outb(0xaa, port); } -void -probe_idregs_ite(unsigned short port){ +void probe_idregs_ite(unsigned short port) +{ unsigned int id, chipver; /* Enable configuration sequence (ITE uses this for newer IT87[012]x) - IT871[01] uses 0x87, 0x87 -> fintek detection should handle it - IT8708 uses 0x87, 0x87 -> fintek detection should handle it - IT8761 uses 0x87, 0x61, 0x55, 0x55/0xaa - IT86xx series uses different ports - IT8661 uses 0x86, 0x61, 0x55/0xaa, 0x55/0xaa and 32 more writes - IT8673 uses 0x86, 0x80, 0x55/0xaa, 0x55/0xaa and 32 more writes */ + * IT871[01] uses 0x87, 0x87 -> fintek detection should handle it + * IT8708 uses 0x87, 0x87 -> fintek detection should handle it + * IT8761 uses 0x87, 0x61, 0x55, 0x55/0xaa + * IT86xx series uses different ports + * IT8661 uses 0x86, 0x61, 0x55/0xaa, 0x55/0xaa and 32 more writes + * IT8673 uses 0x86, 0x80, 0x55/0xaa, 0x55/0xaa and 32 more writes + */ outb(0x87, port); outb(0x01, port); outb(0x55, port); @@ -510,77 +512,72 @@ else outb(0xAA, port); - /* Read Chip ID Byte 1 */ + /* Read Chip ID Byte 1. */ id = regval(port, 0x20); - if (id != 0x87) { - if (inb(port) == 0xff ) - printf ("No SuperIO chip found at 0x%04x\n", port); + if (id != 0x87) { + if (inb(port) == 0xff) + printf("No Super-I/O chip found at 0x%04x\n", port); else - printf("probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", - port, inb(port), inb(port + 1)); + printf("probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", port, inb(port), inb(port + 1)); return; } id <<= 8; - /* Read Chip ID Byte 2 */ + /* Read Chip ID Byte 2. */ id |= regval(port, 0x21); - /* Read Chip Version, only bit 3..0 for all IT87xx */ + /* Read chip version, only bits 3..0 for all IT87xx. */ chipver = regval(port, 0x22) & 0x0f; /* ID Mapping Table - unknown -> IT8711 (no datasheet) - unknown -> IT8722 (no datasheet) - 0x8702 -> IT8702 - 0x8705 -> IT8700 or IT8705 - 0x8708 -> IT8708 - 0x8710 -> IT8710 - 0x8712 -> IT8712 - 0x8716 -> IT8716 - 0x8718 -> IT8718 - 0x8726 -> IT8726 (datasheet wrongly says 0x8716) - */ - printf("SuperI/O found at 0x%02x: id=0x%04x, chipver=0x%01x\n", + * unknown -> IT8711 (no datasheet) + * unknown -> IT8722 (no datasheet) + * 0x8702 -> IT8702 + * 0x8705 -> IT8700 or IT8705 + * 0x8708 -> IT8708 + * 0x8710 -> IT8710 + * 0x8712 -> IT8712 + * 0x8716 -> IT8716 + * 0x8718 -> IT8718 + * 0x8726 -> IT8726 (datasheet wrongly says 0x8716) + */ + printf("Super I/O found at 0x%02x: id=0x%04x, chipver=0x%01x\n", port, id, chipver); - switch(id) { - case 0x8702: - case 0x8705: - case 0x8708: - case 0x8712: - case 0x8716: - case 0x8718: - case 0x8726: - dump_ite(port, id); - break; - default: - printf("no dump for id 0x%04x\n", id); - break; + switch (id) { + case 0x8702: + case 0x8705: + case 0x8708: + case 0x8712: + case 0x8716: + case 0x8718: + case 0x8726: + dump_ite(port, id); + break; + default: + printf("No dump for id 0x%04x\n", id); + break; } - /* disable configuration */ - regwrite(port, 0x02, 0x02); + regwrite(port, 0x02, 0x02); /* Exit MB PnP mode. */ } -void -probe_superio(unsigned short port) { +void probe_superio(unsigned short port) +{ probe_idregs_simple(port); probe_idregs_fintek(port); probe_idregs_ite(port); } -int -main(int argc, char *argv[]) +int main(int argc, char *argv[]) { if (iopl(3) < 0) { perror("iopl"); exit(1); } - /* try the 2e */ - probe_superio(0x2e); - /* now try the 4e */ - probe_superio(0x4e); + probe_superio(0x2e); /* Try 0x2e. */ + probe_superio(0x4e); /* Try 0x4e. */ return 0; } From peter at stuge.se Sat Sep 1 23:08:16 2007 From: peter at stuge.se (Peter Stuge) Date: Sat, 1 Sep 2007 23:08:16 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <46D9C7E1.7080801@gmx.net> References: <20070830002823.4cc82ee0.rasmus@wiman.org> <20070829223925.15184.qmail@stuge.se> <20070830111446.GA9646@localdomain> <20070830132527.813b7fc0.rasmus@wiman.org> <46D6AB93.9080607@stockwith.co.uk> <20070830120920.GB10696@localdomain> <20070901175718.1761.qmail@stuge.se> <46D9BDEE.9010402@gmx.net> <20070901195035.21050.qmail@stuge.se> <46D9C7E1.7080801@gmx.net> Message-ID: <20070901210818.1799.qmail@stuge.se> On Sat, Sep 01, 2007 at 10:13:21PM +0200, Carl-Daniel Hailfinger wrote: > >> SPI detection/flashing support is on my list. > > > > Is the SPI flash connected to the sio on the m57sli? > > No idea. So we should find out. Ward - do you have a continuity tester? Could you see if the SPI flash chip is connected to the Super IO? If I get a high-res photo of the Super IO and the flash chip area I can mark the pins that should be connected on both to get a yes/no indication. > > I didn't think that's where the flash chip was actually > > connected. > > AFAIK CK804/MCP55 don't have SPI support. That's why the SuperI/O > adds it. Intel ICH has SPI, but maybe different for NVIDIA chipsets. The logic design controlled by the boot-from-PCI jumper on the m57sli is less obvious with external SPI, but it's still entirely possible. I hope it is this simple! :) //Peter From info at coresystems.de Sat Sep 1 23:20:13 2007 From: info at coresystems.de (LinuxBIOS information) Date: Sat, 01 Sep 2007 23:20:13 +0200 Subject: [LinuxBIOS] r2758 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2758 to the LinuxBIOS source repository and caused the following changes: Change Log: Move probe_superio into the global util/ directory. Rename it to superiotool while we're at it. Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2758&device=hdama&vendor=arima Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2758&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2758&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2758&device=juki-511p&vendor=iei Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2758&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2758&device=dk8x&vendor=iwill If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From svn at openbios.org Sat Sep 1 23:20:29 2007 From: svn at openbios.org (svn at openbios.org) Date: Sat, 1 Sep 2007 23:20:29 +0200 Subject: [LinuxBIOS] r2762 - trunk/util/superiotool Message-ID: Author: uwe Date: 2007-09-01 23:20:29 +0200 (Sat, 01 Sep 2007) New Revision: 2762 Modified: trunk/util/superiotool/superiotool.c Log: Small consistency fixes (trivial). Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Modified: trunk/util/superiotool/superiotool.c =================================================================== --- trunk/util/superiotool/superiotool.c 2007-09-01 21:02:44 UTC (rev 2761) +++ trunk/util/superiotool/superiotool.c 2007-09-01 21:20:29 UTC (rev 2762) @@ -330,27 +330,18 @@ { int i, j, k; signed short *idx; - printf ("ITE "); - /* ID Mapping Table - unknown -> IT8711 (no datasheet) - unknown -> IT8722 (no datasheet) - 0x8702 -> IT8702 - 0x8705 -> IT8700 or IT8705 - 0x8708 -> IT8708 - 0x8710 -> IT8710 - 0x8712 -> IT8712 - 0x8716 -> IT8716 - 0x8718 -> IT8718 - 0x8726 -> IT8726 (datasheet wrongly says 0x8716) - */ + printf("ITE "); + + /* TODO: Get datasheets for IT8711 and IT8712. */ switch (id) { case 0x8702: - case 0x8705: + case 0x8705: /* IT8700F or IT8705F */ case 0x8708: case 0x8710: case 0x8712: case 0x8716: + /* Note: IT8726F has ID 0x8726 (datasheet wrongly says 0x8716). */ case 0x8718: for (i = 0;; i++) { if (ite_reg_table[i].superio_id == EOT) @@ -405,17 +396,18 @@ void probe_idregs_simple(unsigned short port) { unsigned char id; + outb(0x20, port); if (inb(port) != 0x20) { if (inb(port) == 0xff) - printf("No SuperI/O chip found at 0x%04x\n", port); + printf("No Super I/O chip found at 0x%04x\n", port); else - printf("probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", port, inb(port), inb(port + 1)); + printf("Probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", port, inb(port), inb(port + 1)); return; } id = inb(port + 1); - printf("SuperI/O found at 0x%02x: id = 0x%02x\n", port, id); + printf("Super I/O found at 0x%02x: id = 0x%02x\n", port, id); if (id == 0xff) return; @@ -429,7 +421,7 @@ dump_ns8374(port); break; default: - printf("no dump for 0x%02x\n", id); + printf("No dump for 0x%02x\n", id); break; } } @@ -447,9 +439,9 @@ outb(0x20, port); if (inb(port) != 0x20) { if (inb(port) == 0xff) - printf("No SuperIO chip found at 0x%04x\n", port); + printf("No Super I/O chip found at 0x%04x\n", port); else - printf("probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", port, inb(port), inb(port + 1)); + printf("Probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", port, inb(port), inb(port + 1)); return; } did = inb(port + 1); @@ -516,9 +508,9 @@ id = regval(port, 0x20); if (id != 0x87) { if (inb(port) == 0xff) - printf("No Super-I/O chip found at 0x%04x\n", port); + printf("No Super I/O chip found at 0x%04x\n", port); else - printf("probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", port, inb(port), inb(port + 1)); + printf("Probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", port, inb(port), inb(port + 1)); return; } @@ -530,18 +522,6 @@ /* Read chip version, only bits 3..0 for all IT87xx. */ chipver = regval(port, 0x22) & 0x0f; - /* ID Mapping Table - * unknown -> IT8711 (no datasheet) - * unknown -> IT8722 (no datasheet) - * 0x8702 -> IT8702 - * 0x8705 -> IT8700 or IT8705 - * 0x8708 -> IT8708 - * 0x8710 -> IT8710 - * 0x8712 -> IT8712 - * 0x8716 -> IT8716 - * 0x8718 -> IT8718 - * 0x8726 -> IT8726 (datasheet wrongly says 0x8716) - */ printf("Super I/O found at 0x%02x: id=0x%04x, chipver=0x%01x\n", port, id, chipver); @@ -556,7 +536,7 @@ dump_ite(port, id); break; default: - printf("No dump for id 0x%04x\n", id); + printf("No dump for ID 0x%04x\n", id); break; } regwrite(port, 0x02, 0x02); /* Exit MB PnP mode. */ From info at coresystems.de Sun Sep 2 00:05:51 2007 From: info at coresystems.de (LinuxBIOS information) Date: Sun, 02 Sep 2007 00:05:51 +0200 Subject: [LinuxBIOS] r2759 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2759 to the LinuxBIOS source repository and caused the following changes: Change Log: Rename probe_superio.c to superiotool.c. Flesh out Makefile with all the usual stuff, e.g. install targets etc. Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2759&device=hdama&vendor=arima Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2759&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2759&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2759&device=juki-511p&vendor=iei Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2759&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2759&device=dk8x&vendor=iwill If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From info at coresystems.de Sun Sep 2 00:59:48 2007 From: info at coresystems.de (LinuxBIOS information) Date: Sun, 02 Sep 2007 00:59:48 +0200 Subject: [LinuxBIOS] r2760 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2760 to the LinuxBIOS source repository and caused the following changes: Change Log: Add ITE IT8716F support to probe_superio. This helps especially GA-M57SLI board owners who wish to debug remaining problems or handle SPI flash of newer board versions. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Uwe Hermann Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2760&device=hdama&vendor=arima Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2760&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2760&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2760&device=juki-511p&vendor=iei Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2760&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2760&device=dk8x&vendor=iwill If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From info at coresystems.de Sun Sep 2 02:08:48 2007 From: info at coresystems.de (LinuxBIOS information) Date: Sun, 02 Sep 2007 02:08:48 +0200 Subject: [LinuxBIOS] r2761 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2761 to the LinuxBIOS source repository and caused the following changes: Change Log: Various coding style and whitespace fixes (trivial). Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2761&device=hdama&vendor=arima Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2761&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2761&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2761&device=juki-511p&vendor=iei Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2761&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2761&device=dk8x&vendor=iwill If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From info at coresystems.de Sun Sep 2 02:56:20 2007 From: info at coresystems.de (LinuxBIOS information) Date: Sun, 02 Sep 2007 02:56:20 +0200 Subject: [LinuxBIOS] r2762 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2762 to the LinuxBIOS source repository and caused the following changes: Change Log: Small consistency fixes (trivial). Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2762&device=hdama&vendor=arima Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2762&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2762&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2762&device=juki-511p&vendor=iei Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2762&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2762&device=dk8x&vendor=iwill If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From corey.osgood at gmail.com Sun Sep 2 03:52:57 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Sat, 01 Sep 2007 21:52:57 -0400 Subject: [LinuxBIOS] addr_offset help In-Reply-To: <20070901095633.vlpi1dx92ckwk080@www.smittys.pointclark.net> References: <20070831144044.2dn6o3jg0ook80kw@www.smittys.pointclark.net> <46D87340.7000802@gmail.com> <20070831183754.b7c3bytw08cks8oo@www.smittys.pointclark.net> <46D8DBAF.6060708@gmail.com> <20070901095633.vlpi1dx92ckwk080@www.smittys.pointclark.net> Message-ID: <46DA1779.3070607@gmail.com> Joseph Smith wrote: > >>>> MRS is a setting within the ram that's set by reading from a certain >>>> location while the northbridge is in MRS mode. It essentially tells >>>> the >>>> ram what timings to run at. For the most part, the only values you'll >>>> ever need for SDRAM are 0x1d0 for CL3 and 0x150 for CL2, but DDR and >>>> DDR2 make more advanced use of MRS and E(xtended)MRS. Read the JEDEC >>>> standard for more info. >>>> > What do you mean by this?? Think of it as setting a register in the ram. To have access to it, you first have to send the northbridge the MRS command. While the northbridge is in MRS mode is the only time you have access to that register. Then the register is set by reading from the ram...except that it doesn't really read. The northbridge, in MRS mode, interprets the read as setting the value of the register. The value of the register is the location that you tell it to read from. The northbridge takes care of the process of setting the value, so that's all you need to do. > >> And just realized something else, directly related to the email I just >> sent for Joe. Please change the MRS value from 0x1d0 to 0xad0. Heh, that >> could seriously bork things up, my bad. >> >> -Corey >> >> > What am I supposed to use for CL3? > > > Thanks - Joe > That value (0xad0) is wrong. Anyways, the i810 datasheet says to use Burst length 4 and interleaved burst. I'm not sure what the heck 0x1d0 is for, I thought I knew but I'm wrong. Anyways, 0x1d0 should at least get the system running, just use it. -Corey From ward at gnu.org Sun Sep 2 15:27:03 2007 From: ward at gnu.org (Ward Vandewege) Date: Sun, 2 Sep 2007 09:27:03 -0400 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <20070901175718.1761.qmail@stuge.se> References: <20070829213540.4599.qmail@stuge.se> <20070830000830.dc4e4eb6.rasmus@wiman.org> <20070829221844.11522.qmail@stuge.se> <20070830002823.4cc82ee0.rasmus@wiman.org> <20070829223925.15184.qmail@stuge.se> <20070830111446.GA9646@localdomain> <20070830132527.813b7fc0.rasmus@wiman.org> <46D6AB93.9080607@stockwith.co.uk> <20070830120920.GB10696@localdomain> <20070901175718.1761.qmail@stuge.se> Message-ID: <20070902132703.GA8877@localdomain> On Sat, Sep 01, 2007 at 07:57:18PM +0200, Peter Stuge wrote: > > > Is the modification now wrong? > > > > ST, can you chime in here? > > Hard to tell without testing. I could give it a go if I had a board. > But, someone please send a high-res photo of this part of the board: > http://stuge.se/m57sli_spi_mod_area.jpg so that we can have a look at > the traces. Please take the photo from straight above the board so > that the black PCIe sockets do not obscure any traces or components. Something like this? http://ward.vandewege.net/m57sli_soic_detail.jpg Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From echelon at free.fr Sun Sep 2 15:35:25 2007 From: echelon at free.fr (echelon at free.fr) Date: Sun, 02 Sep 2007 15:35:25 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <20070901210818.1799.qmail@stuge.se> References: <20070830002823.4cc82ee0.rasmus@wiman.org> <20070829223925.15184.qmail@stuge.se> <20070830111446.GA9646@localdomain> <20070830132527.813b7fc0.rasmus@wiman.org> <46D6AB93.9080607@stockwith.co.uk> <20070830120920.GB10696@localdomain> <20070901175718.1761.qmail@stuge.se> <46D9BDEE.9010402@gmx.net> <20070901195035.21050.qmail@stuge.se> <46D9C7E1.7080801@gmx.net> <20070901210818.1799.qmail@stuge.se> Message-ID: <1188740125.46dabc1db865d@imp.free.fr> Quoting Peter Stuge : > On Sat, Sep 01, 2007 at 10:13:21PM +0200, Carl-Daniel Hailfinger wrote: > > >> SPI detection/flashing support is on my list. > > > > > > Is the SPI flash connected to the sio on the m57sli? > > > > No idea. > > So we should find out. > > Ward - do you have a continuity tester? Could you see if the SPI > flash chip is connected to the Super IO? > > If I get a high-res photo of the Super IO and the flash chip area I > can mark the pins that should be connected on both to get a yes/no > indication. > Hi Peter, The spi clock signal (SCK - pad 25 of the SIO) doesn't seem to be directly connected to the pad 6 of the bios spi chip.. One could think that there is a serial resistor between them (for signal integrity) but when I measure the resistance value between the 2 nodes I find values greater than 1 kohm.. I think that for the operating frequency (I measured 25 MHz for this signal with the scope on the bios chip pad), if there was a serial resistor it should had much a much lower value (maybe something like 50 ohm f.ex..) Please, someone with better electronics background can correct me if Im wrong on this topic? Also when studying the board with a powerfull magnifying glass around the sio chip, one can see that the trace starting on the pad 25 apparently ends with a unpopulated smt resistor (?) footprint. In fact, there is also a via connected to this signal, but here I have no way figuring where this signal go trough this via. (btw, as a joke, has someone here a good friend which is tooth physician or radiologist to do a X-ray radiography of this board? ;-) ) Now, back to my investigations.. Florentin From ward at gnu.org Sun Sep 2 16:11:08 2007 From: ward at gnu.org (Ward Vandewege) Date: Sun, 2 Sep 2007 10:11:08 -0400 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <20070901210818.1799.qmail@stuge.se> References: <20070829223925.15184.qmail@stuge.se> <20070830111446.GA9646@localdomain> <20070830132527.813b7fc0.rasmus@wiman.org> <46D6AB93.9080607@stockwith.co.uk> <20070830120920.GB10696@localdomain> <20070901175718.1761.qmail@stuge.se> <46D9BDEE.9010402@gmx.net> <20070901195035.21050.qmail@stuge.se> <46D9C7E1.7080801@gmx.net> <20070901210818.1799.qmail@stuge.se> Message-ID: <20070902141108.GA9106@localdomain> On Sat, Sep 01, 2007 at 11:08:16PM +0200, Peter Stuge wrote: > On Sat, Sep 01, 2007 at 10:13:21PM +0200, Carl-Daniel Hailfinger wrote: > > >> SPI detection/flashing support is on my list. > > > > > > Is the SPI flash connected to the sio on the m57sli? > > > > No idea. > > So we should find out. > > Ward - do you have a continuity tester? I have a multimeter. > Could you see if the SPI > flash chip is connected to the Super IO? They are about 5 or 6 cm apart. I took some additional pictures of the area between the superio and the soic chips. There's an unpopulated patch that is marked as 'SPI_EN' near the superio chip - not sure if that is related. Looks like it would fit a jumper or a 2 pin connector of some sort. http://ward.vandewege.net/m57sli_soic_detail.jpg http://ward.vandewege.net/dscn1656.jpg http://ward.vandewege.net/dscn1657.jpg http://ward.vandewege.net/dscn1658.jpg > If I get a high-res photo of the Super IO and the flash chip area I > can mark the pins that should be connected on both to get a yes/no > indication. Yes please :) Let me know if the pictures suffice. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From todthgie at hotmail.com Sun Sep 2 16:25:41 2007 From: todthgie at hotmail.com (todthgie) Date: Sun, 2 Sep 2007 16:25:41 +0200 Subject: [LinuxBIOS] LinuxBIOS panic room References: <46D584F7.8070008@gmx.net><13426df10708281151i690c6a7fp7622b7bfe933ff35@mail.gmail.com><20070829051903.21550.qmail@stuge.se> <46D513EB.9080409@gmail.com><20070829132729.GD7091@greenwood><20070829135856.GA30258@coresystems.de><20070829184943.8592.qmail@stuge.se><20070829212836.3557.qmail@stuge.se> <46D6066E.4090806@gmx.net> <13426df10708292119u409d4164kb3e914f496f27afd@mail.gmail.com> <46D88E38.90008@gmx.net> Message-ID: ----- Original Message ----- From: "Carl-Daniel Hailfinger" To: "todthgie" Cc: "LinuxBIOS Mailing List" Sent: Friday, August 31, 2007 23:55 Subject: Re: [LinuxBIOS] LinuxBIOS panic room > Hi, > > On 30.08.2007 21:59, todthgie wrote: >> for some time now i have a bootloader in my howbrew rom emulator that can >> read / write to memory in on a byte basis and on a block basis using iHex >> for the block ones >> i have adapted it it to run on the pc in porting LB to right now. it can >> erase flash sectors or the whole chip. > > Nice. Can you send a patch/tarball? i will make a website for the romemulator. the lb version is to big a hacke to pubish atm and im having stabilty problems with it... if you are realy interested panic.c is attached if i figure out how to make a V3 target for my board and how to enable CAR on a IBM/Cyrix 6X86MX i will port it to V3. > >> im thinking about extending it with IO read/write and pci read/write for >> the >> larger version ( i only have 8Kbyte atm and that is thight for romcc >> compiled code:-( ) > > So you use romcc? yes and im having LOADS of trouble > >> i use single letters in the range G-Z for commands and ignore 0-9 and A-F >> that way if a hex download is aborted it just ignores the rest of the >> input >> >> a nice addition would be to emit the welcome message over and over again >> with some delay in between (so the reciever is not stressed to much) >> until >> the first command > > Yeah, a delay between messages in wait mode would be nice. > > Regards, > Carl-Daniel > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: panic.c URL: From ward at gnu.org Sun Sep 2 16:25:11 2007 From: ward at gnu.org (Ward Vandewege) Date: Sun, 2 Sep 2007 10:25:11 -0400 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <46D9BDEE.9010402@gmx.net> References: <20070830000830.dc4e4eb6.rasmus@wiman.org> <20070829221844.11522.qmail@stuge.se> <20070830002823.4cc82ee0.rasmus@wiman.org> <20070829223925.15184.qmail@stuge.se> <20070830111446.GA9646@localdomain> <20070830132527.813b7fc0.rasmus@wiman.org> <46D6AB93.9080607@stockwith.co.uk> <20070830120920.GB10696@localdomain> <20070901175718.1761.qmail@stuge.se> <46D9BDEE.9010402@gmx.net> Message-ID: <20070902142511.GB9354@localdomain> On Sat, Sep 01, 2007 at 09:30:54PM +0200, Carl-Daniel Hailfinger wrote: > On 01.09.2007 19:57, Peter Stuge wrote: > > > > Once we figure out the hardware, it will still be neccessary to > > reboot into DOS/Windows to flash either chip. :( > > SPI detection/flashing support is on my list. However, it won't get done > in the next 3 weeks because I'm getting married next week and will be > offline for a while. > > Everyone can try the probe_superio patch for IT8716, though, and send > dumps for proprietary and LinuxBIOS to the list. It would be nice if I > had dumps for both types of M57SLI (SPI and PLCC) to be able to compare. This is the PLCC version of the M57SLI, booted into the proprietary bios. I'll get you a LinuxBIOS boot dump later in the week. Thanks, Ward. -------------------------------------------------- No Super I/O chip found at 0x002e No Super I/O chip found at 0x002e Super I/O found at 0x2e: id=0x8716, chipver=0x0 ITE IT8716 idx 07 20 21 22 23 24 2b val 0a 87 16 00 11 00 00 def NA 87 16 01 00 00 00 Switching to LDN 0x0 idx 30 60 61 70 74 f0 f1 val 01 03 f0 06 02 00 80 def 00 03 f0 06 02 00 00 Switching to LDN 0x1 idx 30 60 61 70 f0 f1 f2 f3 val 01 03 f8 04 00 50 00 7f def 00 03 f8 04 00 50 00 7f Switching to LDN 0x2 idx 30 60 61 70 f0 f1 f2 f3 val 00 00 00 00 00 50 00 7f def 00 02 f8 03 00 50 00 7f Switching to LDN 0x3 idx 30 60 61 62 63 70 74 f0 val 01 03 78 00 00 07 04 08 def 00 03 78 07 78 07 03 03 Switching to LDN 0x4 idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 f6 val 01 02 90 00 00 00 80 00 0a 00 80 00 e7 def 00 02 90 02 30 09 00 00 00 00 00 NA NA Switching to LDN 0x5 idx 30 60 61 62 63 70 71 f0 val 01 00 60 00 64 01 02 68 def 01 00 60 00 64 01 02 00 Switching to LDN 0x6 idx 30 70 71 f0 val 01 0c 02 00 def 00 0c 02 00 Switching to LDN 0x7 idx 25 26 27 28 29 2a 2c 60 61 62 63 64 65 70 71 72 73 74 b0 b1 b2 b3 b4 b5 b8 b9 ba bb bc bd c0 c1 c2 c3 c4 c8 c9 ca cb cc e0 e1 e2 e3 e4 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd val 00 43 20 00 81 00 1f 00 00 08 00 00 00 00 01 00 38 00 00 00 00 00 00 00 00 00 00 00 01 00 00 43 20 00 00 00 40 00 00 00 00 00 00 00 00 10 40 00 00 00 00 28 00 00 00 00 00 32 00 def 01 00 00 40 00 00 00 00 00 00 00 00 00 00 00 20 38 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 40 00 01 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 NA 00 Switching to LDN 0x8 idx 30 60 61 70 f0 val 00 03 00 0a 00 def 00 03 00 0a 00 Switching to LDN 0x9 idx 30 60 61 val 00 02 01 def 00 02 01 Switching to LDN 0xa idx 30 60 61 70 f0 val 00 03 10 0b 06 def 00 03 10 0b 00 No Super I/O chip found at 0x004e No Super I/O chip found at 0x004e No Super I/O chip found at 0x004e -- Ward Vandewege Free Software Foundation - Senior System Administrator From ward at gnu.org Sun Sep 2 16:39:43 2007 From: ward at gnu.org (Ward Vandewege) Date: Sun, 2 Sep 2007 10:39:43 -0400 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <46D9BDEE.9010402@gmx.net> References: <20070830000830.dc4e4eb6.rasmus@wiman.org> <20070829221844.11522.qmail@stuge.se> <20070830002823.4cc82ee0.rasmus@wiman.org> <20070829223925.15184.qmail@stuge.se> <20070830111446.GA9646@localdomain> <20070830132527.813b7fc0.rasmus@wiman.org> <46D6AB93.9080607@stockwith.co.uk> <20070830120920.GB10696@localdomain> <20070901175718.1761.qmail@stuge.se> <46D9BDEE.9010402@gmx.net> Message-ID: <20070902143943.GA9437@localdomain> On Sat, Sep 01, 2007 at 09:30:54PM +0200, Carl-Daniel Hailfinger wrote: > On 01.09.2007 19:57, Peter Stuge wrote: > > > > Once we figure out the hardware, it will still be neccessary to > > reboot into DOS/Windows to flash either chip. :( > > SPI detection/flashing support is on my list. However, it won't get done > in the next 3 weeks because I'm getting married next week and will be > offline for a while. > > Everyone can try the probe_superio patch for IT8716, though, and send > dumps for proprietary and LinuxBIOS to the list. It would be nice if I > had dumps for both types of M57SLI (SPI and PLCC) to be able to compare. And here's a dump from a soic/spi version of the m57sli, again with the proprietary BIOS. Thanks, Ward. -------------------------------------------------------------------------- No Super I/O chip found at 0x002e No Super I/O chip found at 0x002e Super I/O found at 0x2e: id=0x8716, chipver=0x0 ITE IT8716 idx 07 20 21 22 23 24 2b val 0a 87 16 00 11 1a 00 def NA 87 16 01 00 00 00 Switching to LDN 0x0 idx 30 60 61 70 74 f0 f1 val 00 00 00 00 04 00 80 def 00 03 f0 06 02 00 00 Switching to LDN 0x1 idx 30 60 61 70 f0 f1 f2 f3 val 01 03 f8 04 00 50 00 7f def 00 03 f8 04 00 50 00 7f Switching to LDN 0x2 idx 30 60 61 70 f0 f1 f2 f3 val 00 00 00 00 00 50 00 7f def 00 02 f8 03 00 50 00 7f Switching to LDN 0x3 idx 30 60 61 62 63 70 74 f0 val 00 00 00 00 00 00 04 08 def 00 03 78 07 78 07 03 03 Switching to LDN 0x4 idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 f6 val 01 02 90 00 00 00 80 00 0a 00 80 00 ff def 00 02 90 02 30 09 00 00 00 00 00 NA NA Switching to LDN 0x5 idx 30 60 61 62 63 70 71 f0 val 01 00 60 00 64 01 02 68 def 01 00 60 00 64 01 02 00 Switching to LDN 0x6 idx 30 70 71 f0 val 01 0c 02 00 def 00 0c 02 00 Switching to LDN 0x7 idx 25 26 27 28 29 2a 2c 60 61 62 63 64 65 70 71 72 73 74 b0 b1 b2 b3 b4 b5 b8 b9 ba bb bc bd c0 c1 c2 c3 c4 c8 c9 ca cb cc e0 e1 e2 e3 e4 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd val 00 43 20 00 81 00 1f 00 00 08 00 08 20 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00 01 00 00 43 20 00 00 00 40 00 00 00 00 00 00 00 00 10 40 00 00 00 00 28 00 00 00 00 00 32 00 def 01 00 00 40 00 00 00 00 00 00 00 00 00 00 00 20 38 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 40 00 01 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 NA 00 Switching to LDN 0x8 idx 30 60 61 70 f0 val 00 03 00 0a 00 def 00 03 00 0a 00 Switching to LDN 0x9 idx 30 60 61 val 00 02 01 def 00 02 01 Switching to LDN 0xa idx 30 60 61 70 f0 val 00 03 10 0b 06 def 00 03 10 0b 00 No Super I/O chip found at 0x004e No Super I/O chip found at 0x004e No Super I/O chip found at 0x004e -- Ward Vandewege Free Software Foundation - Senior System Administrator From peter at stuge.se Sun Sep 2 16:43:44 2007 From: peter at stuge.se (Peter Stuge) Date: Sun, 2 Sep 2007 16:43:44 +0200 Subject: [LinuxBIOS] LinuxBIOS panic room In-Reply-To: References: <46D6066E.4090806@gmx.net> <13426df10708292119u409d4164kb3e914f496f27afd@mail.gmail.com> <46D88E38.90008@gmx.net> Message-ID: <20070902144344.14825.qmail@stuge.se> On Sun, Sep 02, 2007 at 04:25:41PM +0200, todthgie wrote: > >So you use romcc? > yes and im having LOADS of trouble romcc is not actively maintained, so it's not in great shape. Besides, most of the code was assembly anyway.. :) //Peter From todthgie at hotmail.com Sun Sep 2 17:02:51 2007 From: todthgie at hotmail.com (todthgie) Date: Sun, 2 Sep 2007 17:02:51 +0200 Subject: [LinuxBIOS] [RFC] Call for Action: LinuxBIOS foundations References: <46D523BC.90403@gmail.com> <20070830120608.GA10696@localdomain> <20070902132822.GB8877@localdomain> Message-ID: > http://ward.vandewege.net/m57sli_soic_detail.jpg > > Thanks, > Ward. thanks. whats writen on top of U20 ? can you make a photo of the same area but the other side of the board ? do you have a multi meter ? can you find out if HOLD# of U5 and U9 are connected to Q4 and Q5 ? are you in the irc channel ? if nout could you join ? greetings Todthgie From echelon at free.fr Sun Sep 2 17:10:51 2007 From: echelon at free.fr (echelon at free.fr) Date: Sun, 02 Sep 2007 17:10:51 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <20070901210818.1799.qmail@stuge.se> References: <20070830002823.4cc82ee0.rasmus@wiman.org> <20070829223925.15184.qmail@stuge.se> <20070830111446.GA9646@localdomain> <20070830132527.813b7fc0.rasmus@wiman.org> <46D6AB93.9080607@stockwith.co.uk> <20070830120920.GB10696@localdomain> <20070901175718.1761.qmail@stuge.se> <46D9BDEE.9010402@gmx.net> <20070901195035.21050.qmail@stuge.se> <46D9C7E1.7080801@gmx.net> <20070901210818.1799.qmail@stuge.se> Message-ID: <1188745851.46dad27bc711a@imp.free.fr> again me ;) also when probing the 25 pad (SCK) of SIO with the scope, there doesn't seem to be electrical activity on this node (it stays tied @ 5V all the time..) also I have given an erroneous measure in my previous mail: the frequency of the spi clock is 16 MHz and not 25.. Florentin Quoting Peter Stuge : > On Sat, Sep 01, 2007 at 10:13:21PM +0200, Carl-Daniel Hailfinger wrote: > > >> SPI detection/flashing support is on my list. > > > > > > Is the SPI flash connected to the sio on the m57sli? > > > > No idea. > > So we should find out. > > Ward - do you have a continuity tester? Could you see if the SPI > flash chip is connected to the Super IO? > > If I get a high-res photo of the Super IO and the flash chip area I > can mark the pins that should be connected on both to get a yes/no > indication. > > > > > I didn't think that's where the flash chip was actually > > > connected. > > > > AFAIK CK804/MCP55 don't have SPI support. That's why the SuperI/O > > adds it. > > Intel ICH has SPI, but maybe different for NVIDIA chipsets. > > The logic design controlled by the boot-from-PCI jumper on the m57sli > is less obvious with external SPI, but it's still entirely possible. > I hope it is this simple! :) > > > //Peter > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > From stepan at coresystems.de Sun Sep 2 18:43:05 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 2 Sep 2007 18:43:05 +0200 Subject: [LinuxBIOS] [PATCH] v3: code documentation fixes In-Reply-To: <46D609C9.80609@gmx.net> References: <46D609C9.80609@gmx.net> Message-ID: <20070902164305.GA7823@coresystems.de> * Carl-Daniel Hailfinger [070830 02:05]: > - printk(BIOS_SPEW, "%s: %s(%s) have_resources %d enabled %d\n", > + printk(BIOS_SPEW, > + "%s: %s(%s) dtsname %s have_resources %d enabled %d\n", > __func__, bus->dev->dtsname, dev_path(bus->dev), These kind of indent changes look rather ugly in my opinion. > + /* TODO: Explain why we use printk here although it is impossible */ What? Impossible? Why? That commend looks pretty bogus. > printk(BIOS_NOTICE, console_test); > > dev_init(); > > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > -- 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/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From peter at stuge.se Sun Sep 2 19:35:22 2007 From: peter at stuge.se (Peter Stuge) Date: Sun, 2 Sep 2007 19:35:22 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <20070902141108.GA9106@localdomain> References: <20070830111446.GA9646@localdomain> <20070830132527.813b7fc0.rasmus@wiman.org> <46D6AB93.9080607@stockwith.co.uk> <20070830120920.GB10696@localdomain> <20070901175718.1761.qmail@stuge.se> <46D9BDEE.9010402@gmx.net> <20070901195035.21050.qmail@stuge.se> <46D9C7E1.7080801@gmx.net> <20070901210818.1799.qmail@stuge.se> <20070902141108.GA9106@localdomain> Message-ID: <20070902173522.27942.qmail@stuge.se> Hey! On Sun, Sep 02, 2007 at 10:11:08AM -0400, Ward Vandewege wrote: > > Ward - do you have a continuity tester? > > I have a multimeter. Great! > > Could you see if the SPI > > flash chip is connected to the Super IO? > > They are about 5 or 6 cm apart. It's not really possible to tell from visual inspection. Maybe with some measurements. > I took some additional pictures of the area between the superio and > the soic chips. There's an unpopulated patch that is marked as > 'SPI_EN' near the superio chip - not sure if that is related. Looks > like it would fit a jumper or a 2 pin connector of some sort. Yep, that's a jumper all right. I wonder what it does. Maybe we'll find out. > http://ward.vandewege.net/m57sli_soic_detail.jpg > > http://ward.vandewege.net/dscn1656.jpg > http://ward.vandewege.net/dscn1657.jpg > http://ward.vandewege.net/dscn1658.jpg > > > > If I get a high-res photo of the Super IO and the flash chip area I > > can mark the pins that should be connected on both to get a yes/no > > indication. > > Yes please :) Let me know if the pictures suffice. Good photos! I put some labels on interesting pads on the soic detail photo; available at: http://stuge.se/m57sli_soic_detail_labels.jpg We want to investigate two things: 1. Dual flash chip mod on this board 2. What is driving the flash chip - super io or southbridge? For 2 I need to put some labels on a super io photo, so let's start with 1. For the first iteration, please check: * which signals are connected straight across between U5 and U9. (I suspect SI, SCLK, HOLD#, VCC, GND, WP# and maybe also SO are all connected across.) * what Q4-1, Q5-1, R99-1 and R102-2 connects to on U5, if anything. //Peter From echelon at free.fr Sun Sep 2 20:13:24 2007 From: echelon at free.fr (echelon at free.fr) Date: Sun, 02 Sep 2007 20:13:24 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <20070902173522.27942.qmail@stuge.se> References: <20070830111446.GA9646@localdomain> <20070830132527.813b7fc0.rasmus@wiman.org> <46D6AB93.9080607@stockwith.co.uk> <20070830120920.GB10696@localdomain> <20070901175718.1761.qmail@stuge.se> <46D9BDEE.9010402@gmx.net> <20070901195035.21050.qmail@stuge.se> <46D9C7E1.7080801@gmx.net> <20070901210818.1799.qmail@stuge.se> <20070902141108.GA9106@localdomain> <20070902173522.27942.qmail@stuge.se> Message-ID: <1188756804.46dafd4437693@imp.free.fr> Quoting Peter Stuge : > For 2 I need to put some labels on a super io photo, so let's start > with 1. For the first iteration, please check: > > * which signals are connected straight across between U5 and U9. (I > suspect SI, SCLK, HOLD#, VCC, GND, WP# and maybe also SO are all > connected across.) Agree! All of them are inter-connected btw the 2 locations. (only CS is not) > > * what Q4-1, Q5-1, R99-1 and R102-2 connects to on U5, if anything. Q4-1 -> U9-CS# Q5-1 -> U5-CS# R99-1 -> VCC R99-2 -> BIOS_WP-1 R102-2 -> ? (why does it matter?) thus spoke my multimeter.. Florentin From ward at gnu.org Sun Sep 2 21:39:55 2007 From: ward at gnu.org (Ward Vandewege) Date: Sun, 2 Sep 2007 15:39:55 -0400 Subject: [LinuxBIOS] buildrom Message-ID: <20070902193955.GA12149@localdomain> I've been working on adding support for the m57sli to buildrom. I'm almost there - particularly I've got filo and linux-as-a-bootloader (lab) going. Lab has a stripped down 2.6.22.2 kernel and a tiny initrd in a 1MB rom chip (25K to spare :), configured to kexec another kernel from disk. I need to do a bit more testing but I intend to have filo and lab fully functional, and hopefully I'll also have time to look at other payloads. Now; before I post my patches to the list for review, I'd like to know what the current thinking is on the future of buildrom. There are a couple of issues with buildrom as it stands today: a) it's v2 only b) there is no standardized way to use a different initrd 'skeleton' for a specific board c) there is no standardized way to have different LinuxBIOS Config.lb files for a particular board, based on the payload It looks like the kconfig setup for v3 will take over much (everything?) of what buildrom does now. If that is true, I think I might just add a few patches to fix b) and c) before I submit the m57sli patches. Thoughts? Does that sound reasonable? Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From c-d.hailfinger.devel.2006 at gmx.net Sun Sep 2 22:05:18 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 02 Sep 2007 22:05:18 +0200 Subject: [LinuxBIOS] [PATCH] v3: code documentation fixes In-Reply-To: <20070902164305.GA7823@coresystems.de> References: <46D609C9.80609@gmx.net> <20070902164305.GA7823@coresystems.de> Message-ID: <46DB177E.9000303@gmx.net> On 02.09.2007 18:43, Stefan Reinauer wrote: > * Carl-Daniel Hailfinger [070830 02:05]: >> - printk(BIOS_SPEW, "%s: %s(%s) have_resources %d enabled %d\n", >> + printk(BIOS_SPEW, >> + "%s: %s(%s) dtsname %s have_resources %d enabled %d\n", >> __func__, bus->dev->dtsname, dev_path(bus->dev), > > These kind of indent changes look rather ugly in my opinion. This is not really an indent change, the message became 18 chars longer so I had to either violate the 80 column limit or move the message to a new line. I chose the second option. >> + /* TODO: Explain why we use printk here although it is impossible */ > > What? Impossible? Why? That commend looks pretty bogus. newboot.lyx chapter 5.3 says stage 2 phase 1 makes printk work. That implies printk will not work before that. >> printk(BIOS_NOTICE, console_test); Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Sun Sep 2 22:09:07 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 02 Sep 2007 22:09:07 +0200 Subject: [LinuxBIOS] r2762 - trunk/util/superiotool In-Reply-To: <20070901212043.26527gmx1@mx021.gmx.net> References: <20070901212043.26527gmx1@mx021.gmx.net> Message-ID: <46DB1863.3050400@gmx.net> Hi Uwe, please stop these "trivial" self-acked fixes to flashrom. They are either wrong, remove documentation or change capitalization or punctuation in comments. Neither of these actions is beneficial. I'll send patches to undo the wrong parts. Thanks. Carl-Daniel On 01.09.2007 23:20, svn at openbios.org wrote: > Author: uwe > Date: 2007-09-01 23:20:29 +0200 (Sat, 01 Sep 2007) > New Revision: 2762 > > Modified: > trunk/util/superiotool/superiotool.c > Log: > Small consistency fixes (trivial). From peter at stuge.se Sun Sep 2 22:16:14 2007 From: peter at stuge.se (Peter Stuge) Date: Sun, 2 Sep 2007 22:16:14 +0200 Subject: [LinuxBIOS] r2762 - trunk/util/superiotool In-Reply-To: <46DB1863.3050400@gmx.net> References: <20070901212043.26527gmx1@mx021.gmx.net> <46DB1863.3050400@gmx.net> Message-ID: <20070902201614.22935.qmail@stuge.se> On Sun, Sep 02, 2007 at 10:09:07PM +0200, Carl-Daniel Hailfinger wrote: > please stop these "trivial" self-acked fixes to flashrom. They are > either wrong, remove documentation or change capitalization or > punctuation in comments. Neither of these actions is beneficial. Dunno, I kind of like it? Makes everything nice and neat. //Peter From todthgie at hotmail.com Sun Sep 2 22:40:39 2007 From: todthgie at hotmail.com (todthgie) Date: Sun, 2 Sep 2007 22:40:39 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) References: <20070830111446.GA9646@localdomain><20070830132527.813b7fc0.rasmus@wiman.org><46D6AB93.9080607@stockwith.co.uk><20070830120920.GB10696@localdomain><20070901175718.1761.qmail@stuge.se> <46D9BDEE.9010402@gmx.net><20070901195035.21050.qmail@stuge.se><46D9C7E1.7080801@gmx.net> <20070901210818.1799.qmail@stuge.se><20070902141108.GA9106@localdomain><20070902173522.27942.qmail@stuge.se> <1188756804.46dafd4437693@imp.free.fr> Message-ID: ----- Original Message ----- From: To: Sent: Sunday, September 02, 2007 20:13 Subject: Re: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) > Quoting Peter Stuge : > > > For 2 I need to put some labels on a super io photo, so let's start > > with 1. For the first iteration, please check: > > > > * which signals are connected straight across between U5 and U9. (I > > suspect SI, SCLK, HOLD#, VCC, GND, WP# and maybe also SO are all > > connected across.) > > Agree! All of them are inter-connected btw the 2 locations. (only CS is > not) are you sure the HOLD pins are connected eg 0 Ohm ? > > > > * what Q4-1, Q5-1, R99-1 and R102-2 connects to on U5, if anything. > > Q4-1 -> U9-CS# this seems to be conected to the unpopulated resistor R89 right? to what is the other pin of this resistor connected ? i would expect ground.. > Q5-1 -> U5-CS# can you find out to which (i think populated) resistor this also connects ? what is the value of this resistor (if you measure measure both 1->2 and 2->1) ? and to what is the other pin of this resistor connected i expect ground ..? > R99-1 -> VCC > R99-2 -> BIOS_WP-1 > R102-2 -> ? (why does it matter?) it might be the write protect option on this board... can you find out if WP# of both chips is connected to some pin of (or around) BIOS_WP ? > > thus spoke my multimeter.. > Florentin > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > From echelon at free.fr Mon Sep 3 01:43:27 2007 From: echelon at free.fr (echelon at free.fr) Date: Mon, 03 Sep 2007 01:43:27 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <20070902173522.27942.qmail@stuge.se> References: <20070830111446.GA9646@localdomain> <20070830132527.813b7fc0.rasmus@wiman.org> <46D6AB93.9080607@stockwith.co.uk> <20070830120920.GB10696@localdomain> <20070901175718.1761.qmail@stuge.se> <46D9BDEE.9010402@gmx.net> <20070901195035.21050.qmail@stuge.se> <46D9C7E1.7080801@gmx.net> <20070901210818.1799.qmail@stuge.se> <20070902141108.GA9106@localdomain> <20070902173522.27942.qmail@stuge.se> Message-ID: <1188776607.46db4a9fdab03@imp.free.fr> Hmmm.. interesting findings I made!.. First of all I have to apologize because I have given some erroneous information in my previous posts.. Here we go: Quoting Peter Stuge : > > > Could you see if the SPI > > > flash chip is connected to the Super IO? > > > > They are about 5 or 6 cm apart. > > It's not really possible to tell from visual inspection. Maybe with > some measurements. Indeed it is!!! But NOT in the way this datasheet (http://www.ite.com.tw/product_info/file/pc/IT8716F_V0.3.zip) says! Here are the real connections I found on my board: super_io-pad55 -> spi_chip-pad5 (SI) super_io-pad56 -> spi_chip-pad6 (SCK) super_io-pad60 -> spi_chip-pad2 (SO) super_io-pad61 -> spi_chip-pad1 (nCS) nHOLD (pad 7 of spi chip) and nWP (pad 3 of spi chip) are not controlled at all by the super io chip! I have a little question : does someone have a more up-to-date version of the DS of the it8716 chip? It seems to me that the version that can be currently downloaded on the ite website doesn't match at all the chip revision used on gigabyte mobo.. (regarding the electrical interface at least..) Florentin From peter at stuge.se Mon Sep 3 02:43:16 2007 From: peter at stuge.se (Peter Stuge) Date: Mon, 3 Sep 2007 02:43:16 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <1188776607.46db4a9fdab03@imp.free.fr> References: <46D6AB93.9080607@stockwith.co.uk> <20070830120920.GB10696@localdomain> <20070901175718.1761.qmail@stuge.se> <46D9BDEE.9010402@gmx.net> <20070901195035.21050.qmail@stuge.se> <46D9C7E1.7080801@gmx.net> <20070901210818.1799.qmail@stuge.se> <20070902141108.GA9106@localdomain> <20070902173522.27942.qmail@stuge.se> <1188776607.46db4a9fdab03@imp.free.fr> Message-ID: <20070903004317.2682.qmail@stuge.se> On Mon, Sep 03, 2007 at 01:43:27AM +0200, echelon at free.fr wrote: > Quoting Peter Stuge : > > > > Could you see if the SPI > > > > flash chip is connected to the Super IO? > > > > > > They are about 5 or 6 cm apart. > > > > It's not really possible to tell from visual inspection. Maybe > > with some measurements. > > Indeed it is!!! But NOT in the way this datasheet > (http://www.ite.com.tw/product_info/file/pc/IT8716F_V0.3.zip) > says! Here are the real connections I found on my board: > > super_io-pad55 -> spi_chip-pad5 (SI) > super_io-pad56 -> spi_chip-pad6 (SCK) > super_io-pad60 -> spi_chip-pad2 (SO) Good news. Then we can make flashrom work. > super_io-pad61 -> spi_chip-pad1 (nCS) Is this a 0 ohm connection? > nHOLD (pad 7 of spi chip) and nWP (pad 3 of spi chip) are not > controlled at all by the super io chip! Correct. U5-HOLD# and U9-HOLD# are pulled high by R84. U5-WP# and U9-WP# are pulled high by R128. WP# can be pulled low using the BIOS_WP jumper, through R127 which I believe connects to R102-2. So, about the CS# signals then. If CS# is a direct connection I think U5-CS# and U9-CS# should be lifted from the board and pulled high independently, then a switch added which connects one chip's CS# pin back to the U5-CS# pad. > I have a little question : does someone have a more up-to-date > version of the DS of the it8716 chip? It seems to me that the > version that can be currently downloaded on the ite website doesn't > match at all the chip revision used on gigabyte mobo.. (regarding > the electrical interface at least..) I can't find any other documentation than that either. The M57SLI board with SOIC flash has a version C 8716, I guess they've changed the pinout. --8<-- 0.3 data sheet cover page Please note that the IT8716F V0.3 is applicable to D version and future versions. -->8-- //Peter From rminnich at gmail.com Mon Sep 3 03:51:14 2007 From: rminnich at gmail.com (ron minnich) Date: Sun, 2 Sep 2007 18:51:14 -0700 Subject: [LinuxBIOS] buildrom In-Reply-To: <20070902193955.GA12149@localdomain> References: <20070902193955.GA12149@localdomain> Message-ID: <13426df10709021851j742190a2ye98ec96a48c2ace2@mail.gmail.com> On 9/2/07, Ward Vandewege wrote: > Now; before I post my patches to the list for review, I'd like to know what > the current thinking is on the future of buildrom. > it's pretty key to our future as far as I am concerned! > There are a couple of issues with buildrom as it stands today: > > a) it's v2 only we can fix that. > b) there is no standardized way to use a different initrd 'skeleton' for a specific board Shouldn't we be moving to initramfs? If we do, will that make life easier? > c) there is no standardized way to have different LinuxBIOS Config.lb files for a > particular board, based on the payload that we will need to fix, again, this will be easier in V3, I hope ... so is the answer to get v3 working on hardware and let it solve this problem? > > It looks like the kconfig setup for v3 will take over much (everything?) of > what buildrom does now. If that is true, I think I might just add a few > patches to fix b) and c) before I submit the m57sli patches. I don't think the v3 kconfig is going to take over completely; we don't want to put busybox and kernel builds into v3. So, let's try to keep buildrom working. This is great stuff, thanks for your work! ron From echelon at free.fr Mon Sep 3 11:04:59 2007 From: echelon at free.fr (echelon at free.fr) Date: Mon, 03 Sep 2007 11:04:59 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <20070903004317.2682.qmail@stuge.se> References: <46D6AB93.9080607@stockwith.co.uk> <20070830120920.GB10696@localdomain> <20070901175718.1761.qmail@stuge.se> <46D9BDEE.9010402@gmx.net> <20070901195035.21050.qmail@stuge.se> <46D9C7E1.7080801@gmx.net> <20070901210818.1799.qmail@stuge.se> <20070902141108.GA9106@localdomain> <20070902173522.27942.qmail@stuge.se> <1188776607.46db4a9fdab03@imp.free.fr> <20070903004317.2682.qmail@stuge.se> Message-ID: <1188810299.46dbce3b1a227@imp.free.fr> Quoting Peter Stuge : > > super_io-pad61 -> spi_chip-pad1 (nCS) > Is this a 0 ohm connection? I think so.. (at least my multimeter in bip-bip mode shouts loud when I connect the 2 pads ;-) => that means <5ohms in general..) > > I have a little question : does someone have a more up-to-date > > version of the DS of the it8716 chip? It seems to me that the > > version that can be currently downloaded on the ite website doesn't > > match at all the chip revision used on gigabyte mobo.. (regarding > > the electrical interface at least..) > > I can't find any other documentation than that either. > > The M57SLI board with SOIC flash has a version C 8716, I guess > they've changed the pinout. > > --8<-- 0.3 data sheet cover page > Please note that the IT8716F V0.3 is applicable to D version and > future versions. > -->8-- This seems a little bit strange for me : the pinout of the C version seems to replace a floppy disk interface with the spi interface.. When one think that FD is considered "antiquated peripheral" and spi a "new paradigm" for bios storage, that would mean that ver. C is "more modern" that ver. D in its design?!.. Just my 2 (euro)cents Florentin From ml at saxnet.de Mon Sep 3 14:35:52 2007 From: ml at saxnet.de (Steffen D.) Date: Mon, 03 Sep 2007 14:35:52 +0200 Subject: [LinuxBIOS] Ethernet problem with GeodeLX (db800) with running lxbios Message-ID: <46DBFFA8.3080600@saxnet.de> Hello again, i finally got my linuxbios running under my db800 development board. I now have a problem with ethernet. When there is traffic over the ethernet device there come a lot of "r8169: eth0: link up" messages again and again. Also the datarate is very very slow (~100kbyte). I tryed it with the normal bios and there it works perfectly. I also have checked the cable and such simple things, im really sure that it is a bios problem. Here are all details: Ethernet: RTL8110SB SuperIO - Winbond83627hG AMD Geode LX 700 / CS5536AD ROM - SST49LF004B (4mbit) Devel-env: debian gcc-4.1 (3.4 wont work at all with lxbios for me!) Linubios 2750 (made with buildrom). Any tipps are very welcome :) Cheers, steffen From ml at saxnet.de Mon Sep 3 15:34:00 2007 From: ml at saxnet.de (Steffen D.) Date: Mon, 03 Sep 2007 15:34:00 +0200 Subject: [LinuxBIOS] Ethernet problem with GeodeLX (db800) with running lxbios In-Reply-To: <46DBFFA8.3080600@saxnet.de> References: <46DBFFA8.3080600@saxnet.de> Message-ID: <46DC0D48.9050100@saxnet.de> By the way: dmesg: PCI: Guessed IRQ 11 for device 0000:00:0d.0 PCI: Sharing IRQ 11 with 0000:00:0f.3 eth0: RTL8169sb/8110sb at 0xd0000000, 00:08:ee:00:ee:1c, IRQ 11 lspci -v ........... 00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11 I/O ports at 1000 [size=256] Memory at fe019000 (32-bit, non-prefetchable) [size=256] Expansion ROM at ffec0000 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 ........... From juergen127 at kreuzholzen.de Mon Sep 3 16:58:33 2007 From: juergen127 at kreuzholzen.de (Juergen Beisert) Date: Mon, 3 Sep 2007 16:58:33 +0200 Subject: [LinuxBIOS] Ethernet problem with GeodeLX (db800) with running lxbios In-Reply-To: <46DC0D48.9050100@saxnet.de> References: <46DBFFA8.3080600@saxnet.de> <46DC0D48.9050100@saxnet.de> Message-ID: <200709031658.34797.juergen127@kreuzholzen.de> On Monday 03 September 2007 15:34, Steffen D. wrote: > By the way: > > dmesg: > PCI: Guessed IRQ 11 for device 0000:00:0d.0 > PCI: Sharing IRQ 11 with 0000:00:0f.3 > eth0: RTL8169sb/8110sb at 0xd0000000, 00:08:ee:00:ee:1c, IRQ 11 > > lspci -v > ........... > 00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 > Gigabit Ethernet (rev 10) > Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit > Ethernet Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11 I/O > ports at 1000 [size=256] > Memory at fe019000 (32-bit, non-prefetchable) [size=256] > Expansion ROM at ffec0000 [disabled] [size=128K] > Capabilities: [dc] Power Management version 2 Can you also create such a text when you start your system with the regular BIOS? And an "lspci -vvv" also. Might help to see the difference. Does the system behavior changes when you start your linux with the "irqpoll" kernel parameter? Juergen From ml at saxnet.de Mon Sep 3 19:31:46 2007 From: ml at saxnet.de (Steffen D.) Date: Mon, 03 Sep 2007 19:31:46 +0200 Subject: [LinuxBIOS] Ethernet problem with GeodeLX (db800) with running lxbios In-Reply-To: <200709031658.34797.juergen127@kreuzholzen.de> References: <46DBFFA8.3080600@saxnet.de> <46DC0D48.9050100@saxnet.de> <200709031658.34797.juergen127@kreuzholzen.de> Message-ID: <46DC4502.90504@saxnet.de> I compared the outputs from dmesg and lspci (-vvv) with linuxbios and normal bios - no difference! Also the option irqpoll doesn't changed anyhing (i added it to the grub line of the linux which boots the final system..) Steffen From c-d.hailfinger.devel.2006 at gmx.net Mon Sep 3 20:36:59 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 03 Sep 2007 20:36:59 +0200 Subject: [LinuxBIOS] r2758 - in trunk: LinuxBIOSv2/util util In-Reply-To: <20070901194454.26802gmx1@mx084.gmx.net> References: <20070901194454.26802gmx1@mx084.gmx.net> Message-ID: <46DC544B.8030305@gmx.net> This commit removed probe_superio from v2. It has not been referenced as svn:externals, so none of the v2 and v3 trees have probe_superio or superiotool. As of revision 2762, the v2 repository is still BROKEN and superiotool doesn't appear in v3 either (checked revision 486). Such commits are one reason why I think self-acked commits should not be allowed. Carl-Daniel On 01.09.2007 21:44, svn at openbios.org wrote: > Author: uwe > Date: 2007-09-01 21:44:36 +0200 (Sat, 01 Sep 2007) > New Revision: 2758 > > Added: > trunk/util/superiotool/ > Removed: > trunk/LinuxBIOSv2/util/probe_superio/ > Log: > Move probe_superio into the global util/ directory. > Rename it to superiotool while we're at it. > > Signed-off-by: Uwe Hermann > Acked-by: Uwe Hermann > > > > Copied: trunk/util/superiotool (from rev 2757, trunk/LinuxBIOSv2/util/probe_superio) From news at jackwasey.com Mon Sep 3 21:57:43 2007 From: news at jackwasey.com (Jack Wasey) Date: Mon, 03 Sep 2007 20:57:43 +0100 Subject: [LinuxBIOS] Gigabyte GA-K8NF-9 Message-ID: Hi, I have a spare motherboard to experiment with linuxbios. I see that each individual component of my mobo seems to be on your supported list. http://www.giga-byte.co.uk/Support/Motherboard/BIOS_Model.aspx?ProductID=1860 Should this be straightforward? Thanks, Jack From peter at stuge.se Mon Sep 3 22:11:37 2007 From: peter at stuge.se (Peter Stuge) Date: Mon, 3 Sep 2007 22:11:37 +0200 Subject: [LinuxBIOS] Gigabyte GA-K8NF-9 In-Reply-To: References: Message-ID: <20070903201137.26920.qmail@stuge.se> On Mon, Sep 03, 2007 at 08:57:43PM +0100, Jack Wasey wrote: > I have a spare motherboard to experiment with linuxbios. I see that > each individual component of my mobo seems to be on your supported > list. > > Should this be straightforward? Mh, I wouldn't go that far. But it may be easy enough. :) Depends on your skill level really. But is the nForce4 really supported? Is it just another name for MCP55? //Peter From news at jackwasey.com Mon Sep 3 22:24:42 2007 From: news at jackwasey.com (Jack Wasey) Date: Mon, 03 Sep 2007 21:24:42 +0100 Subject: [LinuxBIOS] Gigabyte GA-K8NF-9 In-Reply-To: <20070903201137.26920.qmail@stuge.se> References: <20070903201137.26920.qmail@stuge.se> Message-ID: <46DC6D8A.2070500@jackwasey.com> Peter Stuge a ?crit : > On Mon, Sep 03, 2007 at 08:57:43PM +0100, Jack Wasey wrote: >> I have a spare motherboard to experiment with linuxbios. I see that >> each individual component of my mobo seems to be on your supported >> list. >> >> Should this be straightforward? > > Mh, I wouldn't go that far. But it may be easy enough. :) Depends on > your skill level really. > > But is the nForce4 really supported? Is it just another name for > MCP55? > Maybe... but it says "OK" on the status page. I did read that the DualBIOS won't get me out of trouble if I flash with linuxbios. This would seem like a useful thing to be able to use, if possible. From pawn2be.wild at yahoo.de Mon Sep 3 22:44:35 2007 From: pawn2be.wild at yahoo.de (Quux) Date: Mon, 03 Sep 2007 22:44:35 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI/SOIC) In-Reply-To: <1188740125.46dabc1db865d@imp.free.fr> References: <20070830002823.4cc82ee0.rasmus@wiman.org> <20070829223925.15184.qmail@stuge.se> <20070830111446.GA9646@localdomain> <20070830132527.813b7fc0.rasmus@wiman.org> <46D6AB93.9080607@stockwith.co.uk> <20070830120920.GB10696@localdomain> <20070901175718.1761.qmail@stuge.se> <46D9BDEE.9010402@gmx.net> <20070901195035.21050.qmail@stuge.se> <46D9C7E1.7080801@gmx.net> <20070901210818.1799.qmail@stuge.se> <1188740125.46dabc1db865d@imp.free.fr> Message-ID: <46DC7233.5090107@yahoo.de> echelon at free.fr schrieb: > via. (btw, as a joke, has someone here a good friend which is tooth physician or > radiologist to do a X-ray radiography of this board? ;-) ) OT : reverse engineering a 4+ layer pcb with a 2D X-ray may still be tricky. I wonder how it is being done professionally ? 8 pin SOIC socket ar ~ ?30 compared with 2,5? for a plcc32 socket, see http://www.rsonline.de/cgi-bin/bv/rswww/searchBrowseAction.do?N=0&Ntk=I18NRSStockNumber&Ntt=766-980&Nty=1&D=766-980 From peter at stuge.se Mon Sep 3 23:34:48 2007 From: peter at stuge.se (Peter Stuge) Date: Mon, 3 Sep 2007 23:34:48 +0200 Subject: [LinuxBIOS] Gigabyte GA-K8NF-9 In-Reply-To: <46DC6D8A.2070500@jackwasey.com> References: <20070903201137.26920.qmail@stuge.se> <46DC6D8A.2070500@jackwasey.com> Message-ID: <20070903213448.8901.qmail@stuge.se> On Mon, Sep 03, 2007 at 09:24:42PM +0100, Jack Wasey wrote: > > But is the nForce4 really supported? Is it just another name for > > MCP55? > > Maybe... but it says "OK" on the status page. Cool. Can you send lspci from a running system? > I did read that the DualBIOS won't get me out of trouble if I flash > with linuxbios. This would seem like a useful thing to be able to > use, if possible. Not possible. DualBIOS is a software thingy that Gigabyte seem to market rather loudly. There are pads for a second flash chip on the rev 1 board though, so maybe you can reverse engineer the schematics for the board enough to make a dual flash chip mod similar to the on for M57SLI. Then you have a physical switch, anything else is just not very useful. The other option is to swap pushpinflash (chips with glued on plastic knob) back and forth - works fine too. :) //Peter From peter at stuge.se Mon Sep 3 23:38:53 2007 From: peter at stuge.se (Peter Stuge) Date: Mon, 3 Sep 2007 23:38:53 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI/SOIC) In-Reply-To: <46DC7233.5090107@yahoo.de> References: <20070830132527.813b7fc0.rasmus@wiman.org> <46D6AB93.9080607@stockwith.co.uk> <20070830120920.GB10696@localdomain> <20070901175718.1761.qmail@stuge.se> <46D9BDEE.9010402@gmx.net> <20070901195035.21050.qmail@stuge.se> <46D9C7E1.7080801@gmx.net> <20070901210818.1799.qmail@stuge.se> <1188740125.46dabc1db865d@imp.free.fr> <46DC7233.5090107@yahoo.de> Message-ID: <20070903213853.9520.qmail@stuge.se> On Mon, Sep 03, 2007 at 10:44:35PM +0200, Quux wrote: > OT : reverse engineering a 4+ layer pcb with a 2D X-ray may still > be tricky. I wonder how it is being done professionally ? Probably not at all. For testing the board is just put on a bed of nails.. > 8 pin SOIC socket ar ~ ?30 compared with 2,5? for a plcc32 socket The problem is that no SOIC sockets have SOIC footprints. I've only found that for TSOP. (From Emulation Technology) //Peter From jordan.crouse at amd.com Tue Sep 4 00:22:24 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Mon, 3 Sep 2007 16:22:24 -0600 Subject: [LinuxBIOS] buildrom In-Reply-To: <20070902193955.GA12149@localdomain> References: <20070902193955.GA12149@localdomain> Message-ID: <20070903222224.GA6148@cosmic.amd.com> On 02/09/07 15:39 -0400, Ward Vandewege wrote: > I've been working on adding support for the m57sli to buildrom. I'm almost > there - particularly I've got filo and linux-as-a-bootloader (lab) going. Lab > has a stripped down 2.6.22.2 kernel and a tiny initrd in a 1MB rom chip (25K > to spare :), configured to kexec another kernel from disk. I need to do a bit > more testing but I intend to have filo and lab fully functional, and > hopefully I'll also have time to look at other payloads. > > Now; before I post my patches to the list for review, I'd like to know what > the current thinking is on the future of buildrom. > > There are a couple of issues with buildrom as it stands today: > > a) it's v2 only We are working on this - by the time something real boots with V3, so will buildrom.. :) > b) there is no standardized way to use a different initrd 'skeleton' for a specific board No, there really isn't. The LAB stuff has really fallen into disrepair since the fork from OLPC. If you are interested in beating it into shape, then please, by all means. > c) there is no standardized way to have different LinuxBIOS Config.lb files for a > particular board, based on the payload Not sure what you mean by this. Do you have an example? Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From stepan at coresystems.de Tue Sep 4 00:44:26 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 4 Sep 2007 00:44:26 +0200 Subject: [LinuxBIOS] [PATCH] Move common utilities to util/ In-Reply-To: <20070830113735.GV7091@greenwood> References: <20070827081648.GB12926@greenwood> <20070827083317.GA31146@coresystems.de> <20070830113735.GV7091@greenwood> Message-ID: <20070903224426.GB7138@coresystems.de> * Uwe Hermann [070830 13:37]: > On Mon, Aug 27, 2007 at 10:33:18AM +0200, Stefan Reinauer wrote: > > > Todo > > > ---- > > > abuild -- needs discussion; will it work for v3 eventually? > > > > No, I think we want to migrate this to use Jordan's buildrom instead and > > thus lower the complexity and number of tools that can be used to build > > LinuxBIOS images. Less tools, better tools. > > Good idea, I like it. So abuild stays in v2 for now? yepp. > > > analysis > > > > Not sure if this is needed anymore. I think it has to do with used files > > and dependencies. > > Drop it? Leave it in v2? Leave it. > > > dump_mmcr > > > > sc520 specific. I doubt we will ever need this outside of v2. AMD > > replaced the SC520 series with Geode. So since I doubt v3 will ever have > > sc520 support, this should stay and die with v2. > > Well, I wouldn't rule out SC520 support in v3. But will this tool be > needed in v3 (if it ever has SC520 support)? No, it wouldn't. SC520 is basically dead, and never was really wide spread I think. Of course we don't want to rule out any ports. If someone finds out he needs the tool while doing the port to v3, it can still be moved. > > I added this when lxbios was not part of the tree. We can let this > > bit rot in the v2 tree, but lets not move it on. > > OK. Does lxbios support everything lbtdump does? If so I'd even say we > remove it. Not sure if it does. I agree 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 unmanaged at gmail.com Tue Sep 4 04:19:19 2007 From: unmanaged at gmail.com (Gavin Groce) Date: Mon, 3 Sep 2007 21:19:19 -0500 Subject: [LinuxBIOS] A question of support... (GX1/CS5530/PC97317) Message-ID: <59d1d9570709031919l4eb3c725l6b548ad8fdfd4bdb@mail.gmail.com> I have a general question of compatibility for the list. I have a system that was developed by antex electronics. It is currently booting windows ce and has General Software's Embedded BIOS 4.3. I have tried different linux flavors and get a kernel panic (EIP?) at boot .... General Software pointed me to the mailing list due to the fact that I am a end user that they will not provide support to and Antex will not contact me. The information on the board is as follows: Geode GX1 300b-85-2.0 CS5530A-UCE (VS121AB / VSC) 2000 3.0 Super I/O PC97317 IBW/VUL (VS0030AP) The BIOS says it is a 'Unicorn Evaluation Board' ... The only motherboard markings are : F2443-4-1 Rev F Antex Electronics 2001 NSC DS14185 EIA/TIA-232 3 Driver x 5 Receiver (Serial) ... 2-megabit (256K x 8) OTP EPROM AT27C020 with the label AXBIOS_E on it (was)... 74ABT16244 16-Bit Buffer/Line Driver with 3-STATE Outputs Conexant CX88168-11 Smartscm/56 (modem?) Altera epm70325 with a sticker that says AX ISA_C on it. (another OTP EPROM??) I tried to put a windows OS on it but it is painfully (useless) slow and this would make a great server as it is in a desktop component style case (think home stereo) ... Some of this info might help and some of it might be TMI but Any help would be great other wise it is going to get stuck into the closet with the rest of the projects that died... Gavin From unmanaged at gmail.com Tue Sep 4 04:37:50 2007 From: unmanaged at gmail.com (Gavin Groce) Date: Mon, 3 Sep 2007 21:37:50 -0500 Subject: [LinuxBIOS] A question of support... (GX1/CS5530/PC97317) In-Reply-To: <59d1d9570709031919l4eb3c725l6b548ad8fdfd4bdb@mail.gmail.com> References: <59d1d9570709031919l4eb3c725l6b548ad8fdfd4bdb@mail.gmail.com> Message-ID: <59d1d9570709031937p43bfef7qebcfd9b23e128c0f@mail.gmail.com> I think I just answered my own question... The box has a AT27C020... http://www.atmel.com/dyn/resources/prod_documents/doc0570.pdf Which is OTP (one time programmable) :( And it does not look to me pin compatable with the other AMTEL supported chips in a PLCC (i think that is the correct acro.) package... Any input? Gavin On 9/3/07, Gavin Groce wrote: > I have a general question of compatibility for the list. > > I have a system that was developed by antex electronics. > It is currently booting windows ce and has General Software's Embedded BIOS 4.3. > > I have tried different linux flavors and get a kernel panic (EIP?) at boot .... > > General Software pointed me to the mailing list due to the fact that I > am a end user that they will not provide support to and Antex will not > contact me. > > The information on the board is as follows: > > Geode GX1 300b-85-2.0 > CS5530A-UCE (VS121AB / VSC) 2000 3.0 > Super I/O PC97317 IBW/VUL (VS0030AP) > > The BIOS says it is a 'Unicorn Evaluation Board' ... > > The only motherboard markings are : F2443-4-1 Rev F Antex Electronics 2001 > > NSC DS14185 EIA/TIA-232 3 Driver x 5 Receiver (Serial) ... > > 2-megabit (256K x 8) OTP EPROM AT27C020 with the label AXBIOS_E on it (was)... > > 74ABT16244 16-Bit Buffer/Line Driver with 3-STATE Outputs > > Conexant CX88168-11 Smartscm/56 (modem?) > > Altera epm70325 with a sticker that says AX ISA_C on it. (another OTP EPROM??) > > > I tried to put a windows OS on it but it is painfully (useless) slow > and this would make a great server as it is in a desktop component > style case (think home stereo) ... > > Some of this info might help and some of it might be TMI but > > Any help would be great other wise it is going to get stuck into the > closet with the rest of the projects that died... > > > Gavin > From joe at smittys.pointclark.net Tue Sep 4 06:33:00 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Tue, 04 Sep 2007 00:33:00 -0400 Subject: [LinuxBIOS] RCA RM4100 almost running - help Message-ID: <20070904003300.jtpivs51c0www4g8@www.smittys.pointclark.net> Hello, I almost have the system I have been woring on for so long now running on the console (vga is next). Here is a recap of my hardware: i82830 Northbridge i82801db Southbridge (using i82801XX) SMSC lpc47m192 Superio (using smscsuperio) For some reason it keeps restarting over and over again right after the "SMBus controller enabled" message (see below). Any ideas what could be causing this? Also, since I have something happening (console output) and I am diffinatly going to see this through can I submit the RCA RM4100 and i82830 code as a "WIP". Thanks - Joe ------------------------------------------------------------------ LinuxBIOS-2.0.0.0Fallback Mon Sep 3 21:23:01 EDT 2007 starting... Setting initial registers.... Initial registers have been set. No DIMM found in slot 00 DRB 0x60 has been set to 0x00 DRB1 0x61 has been set to 0x00 Found DIMM in slot 01 DIMM is 0x0080 on side 1 DIMM is 0x0000 on side 2 DRB2 0x62 has been set to 0x04 DRB3 0x63 has been set to 0x04 No DIMM found in slot 00, setting DRA to 0xFF DRA 0x70 has been set to 0xff Found DIMM in slot 01, setting DRA... DRA 0x71 has been set to 0xf1 RAM Enable 1: Apply NOP Sending RAM command 0x00000010 to 0x00000000 RAM Enable 2: Precharge all Sending RAM command 0x00000020 to 0x00000000 RAM Enable 3: CBR Sending RAM command 0x00000060 to 0x00000000 RAM Enable 4: Mode register set Sending RAM command 0x00000030 to 0x000001d0 RAM Enable 5: Normal operation Sending RAM command 0x20000170 to 0x00000000 Northbridge following SDRAM init: PCI: 00:00.00 00: 86 80 75 35 06 00 10 00 04 00 00 06 00 00 00 00 10: 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 40: 09 00 05 01 00 00 00 00 00 00 00 00 02 28 00 0e 50: 72 a0 0a 00 00 00 00 00 00 30 33 33 33 33 33 33 60: 00 00 04 04 00 00 00 00 00 00 00 00 00 00 00 00 70: ff f1 ff ff 00 00 00 00 10 00 00 00 70 01 00 20 80: 00 00 00 00 00 00 00 00 00 d0 00 40 00 00 00 00 90: 02 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 02 00 20 00 17 02 00 1f 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 54 0e 41 a2 99 01 00 c0 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 fc 14 00 00 f0: 11 11 01 00 00 00 0b 05 37 d6 30 cf 22 cf 23 cf Copying LinuxBIOS to RAM. Jumping to LinuxBIOS. SMBus controller enabled LinuxBIOS-2.0.0.0Fallback Mon Sep 3 21:23:01 EDT 2007 starting... Setting initial registers.... Initial registers have been set. No DIMM found in slot 00 DRB 0x60 has been set to 0x00 DRB1 0x61 has been set to 0x00 Found DIMM in slot 01 DIMM is 0x0080 on side 1 DIMM is 0x0000 on side 2 DRB2 0x62 has been set to 0x04 DRB3 0x63 has been set to 0x04 No DIMM found in slot 00, setting DRA to 0xFF DRA 0x70 has been set to 0xff Found DIMM in slot 01, setting DRA... DRA 0x71 has been set to 0xf1 RAM Enable 1: Apply NOP Sending RAM command 0x00000010 to 0x00000000 RAM Enable 2: Precharge all Sending RAM command 0x00000020 to 0x00000000 RAM Enable 3: CBR Sending RAM command 0x00000060 to 0x00000000 RAM Enable 4: Mode register set Sending RAM command 0x00000030 to 0x000001d0 RAM Enable 5: Normal operation Sending RAM command 0x20000170 to 0x00000000 Northbridge following SDRAM init: PCI: 00:00.00 00: 86 80 75 35 06 00 10 00 04 00 00 06 00 00 00 00 10: 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 40: 09 00 05 01 00 00 00 00 00 00 00 00 02 28 00 0e 50: 72 a0 0a 00 00 00 00 00 00 30 33 33 33 33 33 33 60: 00 00 04 04 00 00 00 00 00 00 00 00 00 00 00 00 70: ff f1 ff ff 00 00 00 00 10 00 00 00 70 01 00 20 80: 00 00 00 00 00 00 00 00 00 d0 00 40 00 00 00 00 90: 02 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 02 00 20 00 17 02 00 1f 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 54 0e 41 a2 99 01 00 c0 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 fc 14 00 00 f0: 11 11 01 00 00 00 0b 05 34 d6 30 cf 22 cf 23 cf Copying LinuxBIOS to RAM. Jumping to LinuxBIOS. SMBus controller enabled From corey.osgood at gmail.com Tue Sep 4 06:54:47 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Tue, 04 Sep 2007 00:54:47 -0400 Subject: [LinuxBIOS] RCA RM4100 almost running - help In-Reply-To: <20070904003300.jtpivs51c0www4g8@www.smittys.pointclark.net> References: <20070904003300.jtpivs51c0www4g8@www.smittys.pointclark.net> Message-ID: <46DCE517.4010806@gmail.com> Joseph Smith wrote: > Hello, > I almost have the system I have been woring on for so long now running > on the console (vga is next). Here is a recap of my hardware: > > i82830 Northbridge > i82801db Southbridge (using i82801XX) > SMSC lpc47m192 Superio (using smscsuperio) > > Great news! > For some reason it keeps restarting over and over again right after > the "SMBus controller enabled" message (see below). Any ideas what > could be causing this? > Check that there isn't a GPIO (usually GP3) that's set to reboot the system automatically when the timer runs up. If there is, it needs to be disabled prior to ram init. Also, have you run ram_check to make sure that your ram is initializing correctly? -Corey From joe at smittys.pointclark.net Tue Sep 4 07:40:27 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Tue, 04 Sep 2007 01:40:27 -0400 Subject: [LinuxBIOS] RCA RM4100 almost running - help In-Reply-To: <46DCE517.4010806@gmail.com> References: <20070904003300.jtpivs51c0www4g8@www.smittys.pointclark.net> <46DCE517.4010806@gmail.com> Message-ID: <20070904014027.mumag6jjvowos88c@www.smittys.pointclark.net> Quoting Corey Osgood : > Joseph Smith wrote: >> Hello, >> I almost have the system I have been woring on for so long now running >> on the console (vga is next). Here is a recap of my hardware: >> >> i82830 Northbridge >> i82801db Southbridge (using i82801XX) >> SMSC lpc47m192 Superio (using smscsuperio) >> >> > > Great news! > >> For some reason it keeps restarting over and over again right after >> the "SMBus controller enabled" message (see below). Any ideas what >> could be causing this? >> > > Check that there isn't a GPIO (usually GP3) that's set to reboot the > system automatically when the timer runs up. If there is, it needs to be > disabled prior to ram init. Also, have you run ram_check to make sure > that your ram is initializing correctly? > > -Corey > In my Config.lb I have: device pnp 2e.7 off end # GAME_MIDI_GIPO1 device pnp 2e.8 off end # GPIO2 device pnp 2e.9 off end # GPIO3 device pnp 2e.a off end # ACPI They seem to be off is that what you mean? Ok, I ran it with: /* Check RAM. */ ram_check(0, 640 * 1024); What does this "Fail" mean? How do I fix this? Does this have anything to do with the fact that the memory (128MB) is embedded into the board (shows on original bios in slot 01) and does not have SPD? Thanks - Joe ----------------------------------------------------------- LinuxBIOS-2.0.0.0Fallback Mon Sep 3 19:38:42 EDT 2007 starting... Setting initial registers.... Initial registers have been set. No DIMM found in slot 00 DRB 0x60 has been set to 0x00 DRB1 0x61 has been set to 0x00 Found DIMM in slot 01 DIMM is 0x0080 on side 1 DIMM is 0x0000 on side 2 DRB2 0x62 has been set to 0x04 DRB3 0x63 has been set to 0x04 No DIMM found in slot 00, setting DRA to 0xFF DRA 0x70 has been set to 0xff Found DIMM in slot 01, setting DRA... DRA 0x71 has been set to 0xf1 RAM Enable 1: Apply NOP Sending RAM command 0x00000010 to 0x00000000 RAM Enable 2: Precharge all Sending RAM command 0x00000020 to 0x00000000 RAM Enable 3: CBR Sending RAM command 0x00000060 to 0x00000000 RAM Enable 4: Mode register set Sending RAM command 0x00000030 to 0x000001d0 RAM Enable 5: Normal operation Sending RAM command 0x20000170 to 0x00000000 Northbridge following SDRAM init: PCI: 00:00.00 00: 86 80 75 35 06 00 10 00 04 00 00 06 00 00 00 00 10: 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 40: 09 00 05 01 00 00 00 00 00 00 00 00 02 28 00 0e 50: 72 a0 0a 00 00 00 00 00 00 30 33 33 33 33 33 33 60: 00 00 04 04 00 00 00 00 00 00 00 00 00 00 00 00 70: ff f1 ff ff 00 00 00 00 10 00 00 00 70 01 00 20 80: 00 00 00 00 00 00 00 00 00 50 00 40 00 00 00 00 90: 02 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 02 00 20 00 17 02 00 1f 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 54 0e 41 a2 99 01 00 c0 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 fc 14 00 00 f0: 11 11 01 00 00 00 0b 05 37 d6 30 cf 22 cf 23 cf Testing DRAM : 00000000-000a0000 DRAM fill: 00000000-000a0000 00000000 00010000 00020000 00030000 00040000 00050000 00060000 00070000 00080000 00090000 000a0000 DRAM filled DRAM verify: 00000000-000a0000 00000000 Fail: @0x00000000 Read value=0xffffffff Fail: @0x00000004 Read value=0xffffffff Fail: @0x00000008 Read value=0xffffffff Fail: @0x0000000c Read value=0xffffffff Fail: @0x00000010 Read value=0xffffffff Fail: @0x00000014 Read value=0xffffffff Fail: @0x00000018 Read value=0xffffffff Fail: @0x0000001c Read value=0xffffffff Fail: @0x00000020 Read value=0xffffffff Fail: @0x00000024 Read value=0xffffffff Fail: @0x00000028 Read value=0xffffffff Fail: @0x0000002c Read value=0xffffffff Fail: @0x00000030 Read value=0xffffffff Fail: @0x00000034 Read value=0xffffffff Fail: @0x00000038 Read value=0xffffffff Fail: @0x0000003c Read value=0xffffffff Fail: @0x00000040 Read value=0xffffffff Fail: @0x00000044 Read value=0xffffffff Fail: @0x00000048 Read value=0xffffffff Fail: @0x0000004c Read value=0xffffffff Fail: @0x00000050 Read value=0xffffffff Fail: @0x00000054 Read value=0xffffffff Fail: @0x00000058 Read value=0xffffffff Fail: @0x0000005c Read value=0xffffffff Fail: @0x00000060 Read value=0xffffffff Fail: @0x00000064 Read value=0xffffffff Fail: @0x00000068 Read value=0xffffffff Fail: @0x0000006c Read value=0xffffffff Fail: @0x00000070 Read value=0xffffffff Fail: @0x00000074 Read value=0xffffffff Fail: @0x00000078 Read value=0xffffffff Fail: @0x0000007c Read value=0xffffffff Fail: @0x00000080 Read value=0xffffffff Fail: @0x00000084 Read value=0xffffffff Fail: @0x00000088 Read value=0xffffffff Fail: @0x0000008c Read value=0xffffffff Fail: @0x00000090 Read value=0xffffffff Fail: @0x00000094 Read value=0xffffffff Fail: @0x00000098 Read value=0xffffffff Fail: @0x0000009c Read value=0xffffffff Fail: @0x000000a0 Read value=0xffffffff Fail: @0x000000a4 Read value=0xffffffff Fail: @0x000000a8 Read value=0xffffffff Fail: @0x000000ac Read value=0xffffffff Fail: @0x000000b0 Read value=0xffffffff Fail: @0x000000b4 Read value=0xffffffff Fail: @0x000000b8 Read value=0xffffffff Fail: @0x000000bc Read value=0xffffffff Fail: @0x000000c0 Read value=0xffffffff Fail: @0x000000c4 Read value=0xffffffff Fail: @0x000000c8 Read value=0xffffffff Fail: @0x000000cc Read value=0xffffffff Fail: @0x000000d0 Read value=0xffffffff Fail: @0x000000d4 Read value=0xffffffff Fail: @0x000000d8 Read value=0xffffffff Fail: @0x000000dc Read value=0xffffffff Fail: @0x000000e0 Read value=0xffffffff Fail: @0x000000e4 Read value=0xffffffff Fail: @0x000000e8 Read value=0xffffffff Fail: @0x000000ec Read value=0xffffffff Fail: @0x000000f0 Read value=0xffffffff Fail: @0x000000f4 Read value=0xffffffff Fail: @0x000000f8 Read value=0xffffffff Fail: @0x000000fc Read value=0xffffffff Fail: @0x00000100 Read value=0xffffffff Fail: @0x00000104 Read value=0xffffffff Fail: @0x00000108 Read value=0xffffffff Fail: @0x0000010c Read value=0xffffffff Fail: @0x00000110 Read value=0xffffffff Fail: @0x00000114 Read value=0xffffffff Fail: @0x00000118 Read value=0xffffffff Fail: @0x0000011c Read value=0xffffffff Fail: @0x00000120 Read value=0xffffffff Fail: @0x00000124 Read value=0xffffffff Fail: @0x00000128 Read value=0xffffffff Fail: @0x0000012c Read value=0xffffffff Fail: @0x00000130 Read value=0xffffffff Fail: @0x00000134 Read value=0xffffffff Fail: @0x00000138 Read value=0xffffffff Fail: @0x0000013c Read value=0xffffffff Fail: @0x00000140 Read value=0xffffffff Fail: @0x00000144 Read value=0xffffffff Fail: @0x00000148 Read value=0xffffffff Fail: @0x0000014c Read value=0xffffffff Fail: @0x00000150 Read value=0xffffffff Fail: @0x00000154 Read value=0xffffffff Fail: @0x00000158 Read value=0xffffffff Fail: @0x0000015c Read value=0xffffffff Fail: @0x00000160 Read value=0xffffffff Fail: @0x00000164 Read value=0xffffffff Fail: @0x00000168 Read value=0xffffffff Fail: @0x0000016c Read value=0xffffffff Fail: @0x00000170 Read value=0xffffffff Fail: @0x00000174 Read value=0xffffffff Fail: @0x00000178 Read value=0xffffffff Fail: @0x0000017c Read value=0xffffffff Fail: @0x00000180 Read value=0xffffffff Fail: @0x00000184 Read value=0xffffffff Fail: @0x00000188 Read value=0xffffffff Fail: @0x0000018c Read value=0xffffffff Fail: @0x00000190 Read value=0xffffffff Fail: @0x00000194 Read value=0xffffffff Fail: @0x00000198 Read value=0xffffffff Fail: @0x0000019c Read value=0xffffffff Fail: @0x000001a0 Read value=0xffffffff Fail: @0x000001a4 Read value=0xffffffff Fail: @0x000001a8 Read value=0xffffffff Fail: @0x000001ac Read value=0xffffffff Fail: @0x000001b0 Read value=0xffffffff Fail: @0x000001b4 Read value=0xffffffff Fail: @0x000001b8 Read value=0xffffffff Fail: @0x000001bc Read value=0xffffffff Fail: @0x000001c0 Read value=0xffffffff Fail: @0x000001c4 Read value=0xffffffff Fail: @0x000001c8 Read value=0xffffffff Fail: @0x000001cc Read value=0xffffffff Fail: @0x000001d0 Read value=0xffffffff Fail: @0x000001d4 Read value=0xffffffff Fail: @0x000001d8 Read value=0xffffffff Fail: @0x000001dc Read value=0xffffffff Fail: @0x000001e0 Read value=0xffffffff Fail: @0x000001e4 Read value=0xffffffff Fail: @0x000001e8 Read value=0xffffffff Fail: @0x000001ec Read value=0xffffffff Fail: @0x000001f0 Read value=0xffffffff Fail: @0x000001f4 Read value=0xffffffff Fail: @0x000001f8 Read value=0xffffffff Fail: @0x000001fc Read value=0xffffffff Fail: @0x00000200 Read value=0xffffffff Fail: @0x00000204 Read value=0xffffffff Fail: @0x00000208 Read value=0xffffffff Fail: @0x0000020c Read value=0xffffffff Fail: @0x00000210 Read value=0xffffffff Fail: @0x00000214 Read value=0xffffffff Fail: @0x00000218 Read value=0xffffffff Fail: @0x0000021c Read value=0xffffffff Fail: @0x00000220 Read value=0xffffffff Fail: @0x00000224 Read value=0xffffffff Fail: @0x00000228 Read value=0xffffffff Fail: @0x0000022c Read value=0xffffffff Fail: @0x00000230 Read value=0xffffffff Fail: @0x00000234 Read value=0xffffffff Fail: @0x00000238 Read value=0xffffffff Fail: @0x0000023c Read value=0xffffffff Fail: @0x00000240 Read value=0xffffffff Fail: @0x00000244 Read value=0xffffffff Fail: @0x00000248 Read value=0xffffffff Fail: @0x0000024c Read value=0xffffffff Fail: @0x00000250 Read value=0xffffffff Fail: @0x00000254 Read value=0xffffffff Fail: @0x00000258 Read value=0xffffffff Fail: @0x0000025c Read value=0xffffffff Fail: @0x00000260 Read value=0xffffffff Fail: @0x00000264 Read value=0xffffffff Fail: @0x00000268 Read value=0xffffffff Fail: @0x0000026c Read value=0xffffffff Fail: @0x00000270 Read value=0xffffffff Fail: @0x00000274 Read value=0xffffffff Fail: @0x00000278 Read value=0xffffffff Fail: @0x0000027c Read value=0xffffffff Fail: @0x00000280 Read value=0xffffffff Fail: @0x00000284 Read value=0xffffffff Fail: @0x00000288 Read value=0xffffffff Fail: @0x0000028c Read value=0xffffffff Fail: @0x00000290 Read value=0xffffffff Fail: @0x00000294 Read value=0xffffffff Fail: @0x00000298 Read value=0xffffffff Fail: @0x0000029c Read value=0xffffffff Fail: @0x000002a0 Read value=0xffffffff Fail: @0x000002a4 Read value=0xffffffff Fail: @0x000002a8 Read value=0xffffffff Fail: @0x000002ac Read value=0xffffffff Fail: @0x000002b0 Read value=0xffffffff Fail: @0x000002b4 Read value=0xffffffff Fail: @0x000002b8 Read value=0xffffffff Fail: @0x000002bc Read value=0xffffffff Fail: @0x000002c0 Read value=0xffffffff Fail: @0x000002c4 Read value=0xffffffff Fail: @0x000002c8 Read value=0xffffffff Fail: @0x000002cc Read value=0xffffffff Fail: @0x000002d0 Read value=0xffffffff Fail: @0x000002d4 Read value=0xffffffff Fail: @0x000002d8 Read value=0xffffffff Fail: @0x000002dc Read value=0xffffffff Fail: @0x000002e0 Read value=0xffffffff Fail: @0x000002e4 Read value=0xffffffff Fail: @0x000002e8 Read value=0xffffffff Fail: @0x000002ec Read value=0xffffffff Fail: @0x000002f0 Read value=0xffffffff Fail: @0x000002f4 Read value=0xffffffff Fail: @0x000002f8 Read value=0xffffffff Fail: @0x000002fc Read value=0xffffffff Fail: @0x00000300 Read value=0xffffffff Fail: @0x00000304 Read value=0xffffffff Fail: @0x00000308 Read value=0xffffffff Fail: @0x0000030c Read value=0xffffffff Fail: @0x00000310 Read value=0xffffffff Fail: @0x00000314 Read value=0xffffffff Fail: @0x00000318 Read value=0xffffffff Fail: @0x0000031c Read value=0xffffffff Fail: @0x00000320 Read value=0xffffffff Fail: @0x00000324 Read value=0xffffffff Fail: @0x00000328 Read value=0xffffffff Fail: @0x0000032c Read value=0xffffffff Fail: @0x00000330 Read value=0xffffffff Fail: @0x00000334 Read value=0xffffffff Fail: @0x00000338 Read value=0xffffffff Fail: @0x0000033c Read value=0xffffffff Fail: @0x00000340 Read value=0xffffffff Fail: @0x00000344 Read value=0xffffffff Fail: @0x00000348 Read value=0xffffffff Fail: @0x0000034c Read value=0xffffffff Fail: @0x00000350 Read value=0xffffffff Fail: @0x00000354 Read value=0xffffffff Fail: @0x00000358 Read value=0xffffffff Fail: @0x0000035c Read value=0xffffffff Fail: @0x00000360 Read value=0xffffffff Fail: @0x00000364 Read value=0xffffffff Fail: @0x00000368 Read value=0xffffffff Fail: @0x0000036c Read value=0xffffffff Fail: @0x00000370 Read value=0xffffffff Fail: @0x00000374 Read value=0xffffffff Fail: @0x00000378 Read value=0xffffffff Fail: @0x0000037c Read value=0xffffffff Fail: @0x00000380 Read value=0xffffffff Fail: @0x00000384 Read value=0xffffffff Fail: @0x00000388 Read value=0xffffffff Fail: @0x0000038c Read value=0xffffffff Fail: @0x00000390 Read value=0xffffffff Fail: @0x00000394 Read value=0xffffffff Fail: @0x00000398 Read value=0xffffffff Fail: @0x0000039c Read value=0xffffffff Fail: @0x000003a0 Read value=0xffffffff Fail: @0x000003a4 Read value=0xffffffff Fail: @0x000003a8 Read value=0xffffffff Fail: @0x000003ac Read value=0xffffffff Fail: @0x000003b0 Read value=0xffffffff Fail: @0x000003b4 Read value=0xffffffff Fail: @0x000003b8 Read value=0xffffffff Fail: @0x000003bc Read value=0xffffffff Fail: @0x000003c0 Read value=0xffffffff Fail: @0x000003c4 Read value=0xffffffff Fail: @0x000003c8 Read value=0xffffffff Fail: @0x000003cc Read value=0xffffffff Fail: @0x000003d0 Read value=0xffffffff Fail: @0x000003d4 Read value=0xffffffff Fail: @0x000003d8 Read value=0xffffffff Fail: @0x000003dc Read value=0xffffffff Fail: @0x000003e0 Read value=0xffffffff Fail: @0x000003e4 Read value=0xffffffff Fail: @0x000003e8 Read value=0xffffffff Fail: @0x000003ec Read value=0xffffffff Fail: @0x000003f0 Read value=0xffffffff Fail: @0x000003f4 Read value=0xffffffff Fail: @0x000003f8 Read value=0xffffffff Fail: @0x000003fc Read value=0xffffffff Fail: @0x00000400 Read value=0xffffffff Aborting. 00000400 DRAM did _NOT_ verify! Done. Copying LinuxBIOS to RAM. Jumping to LinuxBIOS. SMBus controller enabled From ml at saxnet.de Tue Sep 4 08:26:10 2007 From: ml at saxnet.de (Steffen D.) Date: Tue, 04 Sep 2007 08:26:10 +0200 Subject: [LinuxBIOS] Ethernet problem with GeodeLX (db800) with running lxbios In-Reply-To: <46DC4502.90504@saxnet.de> References: <46DBFFA8.3080600@saxnet.de> <46DC0D48.9050100@saxnet.de> <200709031658.34797.juergen127@kreuzholzen.de> <46DC4502.90504@saxnet.de> Message-ID: <46DCFA82.5090904@saxnet.de> Anybody a idea what to test? From corey.osgood at gmail.com Tue Sep 4 09:47:51 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Tue, 04 Sep 2007 03:47:51 -0400 Subject: [LinuxBIOS] RCA RM4100 almost running - help In-Reply-To: <20070904014027.mumag6jjvowos88c@www.smittys.pointclark.net> References: <20070904003300.jtpivs51c0www4g8@www.smittys.pointclark.net> <46DCE517.4010806@gmail.com> <20070904014027.mumag6jjvowos88c@www.smittys.pointclark.net> Message-ID: <46DD0DA7.7020706@gmail.com> Joseph Smith wrote: > Quoting Corey Osgood : > >> Joseph Smith wrote: >>> Hello, >>> I almost have the system I have been woring on for so long now running >>> on the console (vga is next). Here is a recap of my hardware: >>> >>> i82830 Northbridge >>> i82801db Southbridge (using i82801XX) >>> SMSC lpc47m192 Superio (using smscsuperio) >>> >>> >> >> Great news! >> >>> For some reason it keeps restarting over and over again right after >>> the "SMBus controller enabled" message (see below). Any ideas what >>> could be causing this? >>> >> >> Check that there isn't a GPIO (usually GP3) that's set to reboot the >> system automatically when the timer runs up. If there is, it needs to be >> disabled prior to ram init. Also, have you run ram_check to make sure >> that your ram is initializing correctly? >> >> -Corey >> > In my Config.lb I have: > device pnp 2e.7 off end # GAME_MIDI_GIPO1 > device pnp 2e.8 off end # GPIO2 > device pnp 2e.9 off end # GPIO3 > device pnp 2e.a off end # ACPI > > They seem to be off is that what you mean? Those only affect LB after the ram has been initialized. You'd have to manually disable it in pre-ram if that were the problem, but I think it's much more likely the below. I've only seen GPIO resets on Via hardware, so you're probably safe. > > Ok, I ran it with: > /* Check RAM. */ > ram_check(0, 640 * 1024); > > What does this "Fail" mean? How do I fix this? Does this have anything > to do with the fact that the memory (128MB) is embedded into the board > (shows on original bios in slot 01) and does not have SPD? No, this means that your ram isn't being initialized correctly somewhere. Start by checking that your northbridge timing registers are set correctly, drbs set correctly, etc. As long as the init itself follows the same procedure as the 440bx and 810, that should be correct. Comparing lspci -xxx -s 0:0.0 and dump_dev(0) (from debug.c) might also provide some help. -Corey From joe at smittys.pointclark.net Tue Sep 4 11:21:40 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Tue, 04 Sep 2007 05:21:40 -0400 Subject: [LinuxBIOS] RCA RM4100 almost running - help In-Reply-To: <46DD0DA7.7020706@gmail.com> References: <20070904003300.jtpivs51c0www4g8@www.smittys.pointclark.net> <46DCE517.4010806@gmail.com> <20070904014027.mumag6jjvowos88c@www.smittys.pointclark.net> <46DD0DA7.7020706@gmail.com> Message-ID: <20070904052140.1kiwmfm0co40wkc4@www.smittys.pointclark.net> Quoting Corey Osgood : > Joseph Smith wrote: >> Quoting Corey Osgood : >> >>> Joseph Smith wrote: >>>> Hello, >>>> I almost have the system I have been woring on for so long now running >>>> on the console (vga is next). Here is a recap of my hardware: >>>> >>>> i82830 Northbridge >>>> i82801db Southbridge (using i82801XX) >>>> SMSC lpc47m192 Superio (using smscsuperio) >>>> >>>> >>> >>> Great news! >>> >>>> For some reason it keeps restarting over and over again right after >>>> the "SMBus controller enabled" message (see below). Any ideas what >>>> could be causing this? >>>> >>> >>> Check that there isn't a GPIO (usually GP3) that's set to reboot the >>> system automatically when the timer runs up. If there is, it needs to be >>> disabled prior to ram init. Also, have you run ram_check to make sure >>> that your ram is initializing correctly? >>> >>> -Corey >>> >> In my Config.lb I have: >> device pnp 2e.7 off end # GAME_MIDI_GIPO1 >> device pnp 2e.8 off end # GPIO2 >> device pnp 2e.9 off end # GPIO3 >> device pnp 2e.a off end # ACPI >> >> They seem to be off is that what you mean? > > Those only affect LB after the ram has been initialized. You'd have to > manually disable it in pre-ram if that were the problem, but I think > it's much more likely the below. I've only seen GPIO resets on Via > hardware, so you're probably safe. > >> >> Ok, I ran it with: >> /* Check RAM. */ >> ram_check(0, 640 * 1024); >> >> What does this "Fail" mean? How do I fix this? Does this have anything >> to do with the fact that the memory (128MB) is embedded into the board >> (shows on original bios in slot 01) and does not have SPD? > > No, this means that your ram isn't being initialized correctly > somewhere. Start by checking that your northbridge timing registers are > set correctly, drbs set correctly, etc. As long as the init itself > follows the same procedure as the 440bx and 810, that should be correct. > Comparing lspci -xxx -s 0:0.0 and dump_dev(0) (from debug.c) might also > provide some help. > > -Corey > > The only thing about lspci -xxx -s 0:0.0 is you can't see all of the 16bit and 32bit registers. Is there another way in linux to dump 0:0.0 so you can see all of the values? Thanks - Joe From stepan at coresystems.de Tue Sep 4 11:23:46 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 4 Sep 2007 11:23:46 +0200 Subject: [LinuxBIOS] [RFC] Call for Action: LinuxBIOS foundations In-Reply-To: <46D60C18.2040607@gmail.com> References: <46D2EE93.9080105@gmx.net> <46D2F7E3.2070509@coresystems.de> <46D34E54.2090702@gmail.com> <20070828173050.GG20189@greenwood> <46D470A9.6020804@gmx.de> <46D523BC.90403@gmail.com> <20070829075057.GD7562@coresystems.de> <46D5BA47.8030200@gmail.com> <20070829223428.GA2730@coresystems.de> <46D60C18.2040607@gmail.com> Message-ID: <20070904092346.GA21962@coresystems.de> * Corey Osgood [070830 02:15]: > Okay, but how/where should documentation be placed? I can place comments in > the code that I write, but there's no guarantee that a new dev will find > them. Generally, code comments should be doxygen style. This will make them appear in the code documentation on the web page. Also, the Wiki is a good place for documentation. > digging around for them. doxygen is good in some ways, I've found but it > only really helps if you can pinpoint a board that uses the function you > want, and there's a comment to explain it. The generated html documentation also has a search function. What information are you missing from the doxygen docs? Maybe we can add them? > Perhaps some pages in the wiki > documenting commonly used functions, or perhaps even on a per-file basis? > For instance, something like this: Hm... what about a "LinuxBIOSv2 internals" page with sub categories for each stage (preram init, linuxbios_ram.rom etc) and have other pages link to them. > Title: Commonly used functions in LinuxBIOSv2 pre-ram init (auto.c, > raminit.c, *early*.c) > > Menu: lists/links function names > > Functions: (example) > pci_write_configX(a, b, c): brief description of what pci_write_configX() > does, what parameters need to be passed and what format they're in, perhaps > link to another explanation of "device_t dev" > > Does this sound like what people want? So far the call for documentation > has been clear, just it's unclear what is wanted and where. > > -Corey > -- 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 Sep 4 11:27:40 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 4 Sep 2007 11:27:40 +0200 Subject: [LinuxBIOS] RCA RM4100 almost running - help In-Reply-To: <20070904052140.1kiwmfm0co40wkc4@www.smittys.pointclark.net> References: <20070904003300.jtpivs51c0www4g8@www.smittys.pointclark.net> <46DCE517.4010806@gmail.com> <20070904014027.mumag6jjvowos88c@www.smittys.pointclark.net> <46DD0DA7.7020706@gmail.com> <20070904052140.1kiwmfm0co40wkc4@www.smittys.pointclark.net> Message-ID: <20070904092739.GA25393@coresystems.de> * Joseph Smith [070904 11:21]: > The only thing about lspci -xxx -s 0:0.0 is you can't see all of the > 16bit and 32bit registers. Is there another way in linux to dump 0:0.0 > so you can see all of the values? You need to be root and try again. -- 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 Sep 4 11:38:05 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 4 Sep 2007 11:38:05 +0200 Subject: [LinuxBIOS] LinuxBIOS panic room In-Reply-To: <46D6066E.4090806@gmx.net> References: <20070819181455.GA19802@greenwood> <13426df10708281151i690c6a7fp7622b7bfe933ff35@mail.gmail.com> <20070829051903.21550.qmail@stuge.se> <46D513EB.9080409@gmail.com> <20070829132729.GD7091@greenwood> <20070829135856.GA30258@coresystems.de> <20070829184943.8592.qmail@stuge.se> <20070829212836.3557.qmail@stuge.se> <46D6066E.4090806@gmx.net> Message-ID: <20070904093805.GB25667@coresystems.de> * Carl-Daniel Hailfinger [070830 01:51]: > I'd say it should accept a lar archive via serial console, perhaps using > ymodem, and start executing the first member of the lar. I really like the idea. BUT: The one thing that seems unclear is where would we store that lar archive? On the BIOS chip? RAM seems no option as it is not initialized yet. 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 Sep 4 11:43:53 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 4 Sep 2007 11:43:53 +0200 Subject: [LinuxBIOS] [PATCH][v3] Support for multiple LinuxBIOS payloads In-Reply-To: <46D58478.5010104@gmx.net> References: <20070819181455.GA19802@greenwood> <46D357C7.7040503@gmx.net> <20070829072152.GA5132@coresystems.de> <46D58478.5010104@gmx.net> Message-ID: <20070904094353.GC25667@coresystems.de> * Carl-Daniel Hailfinger [070829 16:36]: > >>> Actually, you can specify the prefix (e.g. 'payload') via Kconfig. > >> Can we tell the implementation in some way that we'd like it to ignore > >> payloads with numbers before x? > > > > Seems simple, but why? > > Ability to modify boot order without reflashing. But this could be > accomplished with the "next payload" selection via CMOS. But if we want the boot order, lets store the indices of all payloads rather than adding lots of implicit assumptions and options like "ignore all payloads up to index". We can easily spare 16 or 32 bytes of CMOS. And that is quite a number of possible payloads to exceed. I bet we run out of flash easier (and out of payloads ;) 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 alex at rtfs.hu Tue Sep 4 13:17:55 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Tue, 04 Sep 2007 13:17:55 +0200 Subject: [LinuxBIOS] [PATCH] pci_rom.c checksum extension rom Message-ID: <1188904675.17055.2.camel@localhost> Hi, the attached patch adds code to checksum the pci extension rom and stop if the stored and calculated checksum differ. -- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: checksum.diff Type: text/x-patch Size: 983 bytes Desc: not available URL: From alex at rtfs.hu Tue Sep 4 13:19:53 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Tue, 04 Sep 2007 13:19:53 +0200 Subject: [LinuxBIOS] [PATCH] LAR compression in xip not supported Message-ID: <1188904793.17055.5.camel@localhost> Hi, attached patch returns if someone tries to execute in place a compressed entry. -- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: lar-xip.diff Type: text/x-patch Size: 484 bytes Desc: not available URL: From alex at rtfs.hu Tue Sep 4 14:17:00 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Tue, 04 Sep 2007 14:17:00 +0200 Subject: [LinuxBIOS] [PATCH] elfboot minor changes Message-ID: <1188908220.17055.9.camel@localhost> Hi, cleanupmsg.diff changes the "(cleaned up) New segment.." message to be displayed only when the condition happens. properzero.diff changes the memset to only clean up the area which is not memcopied to. -- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: elfboot.cleanupmsg.diff Type: text/x-patch Size: 788 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: elfboot.properzero2.diff Type: text/x-patch Size: 1157 bytes Desc: not available URL: From alex at rtfs.hu Tue Sep 4 14:30:38 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Tue, 04 Sep 2007 14:30:38 +0200 Subject: [LinuxBIOS] [PATCH] vgabios: use same interface for biosemu.c and vm86.c Message-ID: <1188909038.17055.14.camel@localhost> Hi, this patch changes vm86.c:do_bios to run_bios(dev, addr). While doing this, we can remove lot of code duplication about searching the device, which is already done in the parent pci_device.c. -- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: vgabios-same.diff Type: text/x-patch Size: 2641 bytes Desc: not available URL: From pawn2be.wild at yahoo.de Tue Sep 4 17:14:10 2007 From: pawn2be.wild at yahoo.de (Quux) Date: Tue, 04 Sep 2007 17:14:10 +0200 Subject: [LinuxBIOS] buildrom strategy In-Reply-To: <20070902193955.GA12149@localdomain> References: <20070902193955.GA12149@localdomain> Message-ID: <46DD7642.3030308@yahoo.de> Ward Vandewege schrieb: > Now; before I post my patches to the list for review, I'd like to know what > the current thinking is on the future of buildrom. > > There are a couple of issues with buildrom as it stands today: > > a) it's v2 only > b) there is no standardized way to use a different initrd 'skeleton' for a specific board > c) there is no standardized way to have different LinuxBIOS Config.lb files for a > particular board, based on the payload > > Thoughts? Does that sound reasonable? > my view: whatever gets us closer to a feasible live-Linux-CDROM that is bootable on GA M57-SLI as well as ASUS A8N-E (the desktop flagships 30 - 80? in cost) and has binaries to flash on those targets is well supportable. we need binaries for early adopters to download and flash into their mobos and save that in wiki. --Q -- New Mexico: it's not new, and it isn't it Mexico. The Fed: "There is nothing federal about the federal reserve system, and there are no reserves." (Prof. Bill Still) From liransgarage at gmail.com Tue Sep 4 17:50:39 2007 From: liransgarage at gmail.com (liran tal) Date: Tue, 4 Sep 2007 17:50:39 +0200 Subject: [LinuxBIOS] LZMA compression of kernel image and p7zip (Carl-Daniel Hailfinger / Stefan Reinauer) In-Reply-To: <46D88DA4.4070108@gmx.net> References: <3ed55890708300806ib8b65bfi9935c8aa53b5ced9@mail.gmail.com> <46D88DA4.4070108@gmx.net> Message-ID: <3ed55890709040850r72a5298uacf1e2eaaa1f38d8@mail.gmail.com> Hey Carl, Sorry about the late reply, I've been on and off during flights out of the country and haven't got around to check this issue. I have done some more investigating on this issue but no luck (yet). It made some sense to me as well that the problem might be with the use of 7ZIP-specific compression/decompression but I'm not sure of that anymore. I have attempted to use the LZMA SDK library to compress the image using that instead of the 7z application (p7zip) but actually the booloader/kernel denied me from that image, possibly because it was written specifically to 7z so I am sure that encoding the image must be done using 7z. That's about how to encode the image. Regarding the decompression which happens in the kernel/bootloader stage - well the print out is: Launching kernel decompressor. Starting LZMA Uncompression Algorithm. Compressed file is LZMA format. Kernel decompressor was successful ... launching kernel. So I am relying on the fact that it decompressed fine and that there is no bug in the decompression code (I've been provided with an SDK so this is not some home-brew code that might contain more errors than usual). So going over the code more thouroughly - the part that handles the decompression calls the kernel_entry function which in turn calls the start_kernel and that to _text (if I remember the ordering right) and I am assuming that the problem is there somewhere. A good thing to remember is that the only difference from this problem to a working kernel image is the CONFIG_KERNEL_COMPRESS_7ZIP option which I use. If I use the default GZIP compression then the kernel image loads just fine. I guess this could also be some sort of alignment problems, but memory alignments specific to the 7z compression is somewhat doubtful, isn't it? Any insight is welcome, Regards, Liran. On 8/31/07, Carl-Daniel Hailfinger wrote: > > Hello Liran, > > On 30.08.2007 17:06, liran tal wrote: > > I have stumbled upon posts by Carl-Daniel and Stefan while trying to get > > some information why when I compile a kernel image with 7zip (LZMA) > > the kernel image doesn't load up. > > [...] > > I have been given an SDK based on Linux 2.6.10 for an embedded mips 4Kec > (TI > > Avalanche series) cpu to build an image from. When I build the image > > using GZIP (standard) the kernel boots fine but when I > > choose 7ZIP support for better compression, the 'make ram_zimage' > procedure > > is working successfully > > but when the image attempts to run off the device (via nfs) it writes: > > > > Launching kernel decompressor. > > Starting LZMA Uncompression Algorithm. > > Compressed file is LZMA format. > > Kernel decompressor was successful ... launching kernel. > > > > and nothing happens after that. > > Ah, the classic "no logs available" problem because the kernel hangs > during early boot. Since it works with gzip I have to assume there is a > bug either in the decompression routine or some #define has not been > adjusted to the architecture. Less likely, but still possible would be > that the decompression routine is touching memory which is special on > your machine. > > > I've been attempting to figure out what is causing the kernel not to > load > > and after reading the post by Carl-Daniel and Stefan about 7zip > > using different headers than "normal" LZMA sdk > > I thought that this could be the problem. > > Possible, but rather unlikely. What do the docs for the lzma kernel > patch say? Is it supposed to be used with p7zip or the original SDK? > > Carl-Daniel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at rtfs.hu Tue Sep 4 18:57:20 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Tue, 04 Sep 2007 18:57:20 +0200 Subject: [LinuxBIOS] [PATCH] Support other than 0xC000 ROMs in VM86 Message-ID: <1188925040.17055.40.camel@localhost> Hi, this patch changes the real_mode_switch_call_vga() function to jump to the addr given as an argument instead the hardcoded 0xc000. Also it changes the function to inline assembly and passes the arguments through that. This patch includes the changes from my previous patch "[PATCH] vgabios: use same interface for biosemu.c and vm86.c", but should be committed incrementally. Btw, I think it would be a good idea to export the interrupt handlers to a common file (biosints.c?) and let it be hooked up by both vm86 and x86emu implementations. -- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: vm86-extra.diff Type: text/x-patch Size: 6222 bytes Desc: not available URL: From rminnich at gmail.com Tue Sep 4 19:16:17 2007 From: rminnich at gmail.com (ron minnich) Date: Tue, 4 Sep 2007 10:16:17 -0700 Subject: [LinuxBIOS] buildrom strategy In-Reply-To: <46DD7642.3030308@yahoo.de> References: <20070902193955.GA12149@localdomain> <46DD7642.3030308@yahoo.de> Message-ID: <13426df10709041016g35ebf9fdtb5deb272e057ab04@mail.gmail.com> Also, can someone put instructions on where-to-buy on the wiki for these boards and systems? thanks ron From r.marek at assembler.cz Tue Sep 4 21:47:30 2007 From: r.marek at assembler.cz (Rudolf Marek) Date: Tue, 04 Sep 2007 21:47:30 +0200 Subject: [LinuxBIOS] problems with reboot on K8 In-Reply-To: <2ea3fae10709011333i44bb38dbo606cd58fb8eb621c@mail.gmail.com> References: <46D1B902.6020503@assembler.cz> <46D95675.5070009@assembler.cz> <2ea3fae10709011333i44bb38dbo606cd58fb8eb621c@mail.gmail.com> Message-ID: <46DDB652.60600@assembler.cz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Sorry for the delay, I moved to flat and got no internet for a while. LinuxBIOS-2.0.0_Fallback Po z?? 3 22:17:08 CEST 2007 starting... now booting... fallback LinuxBIOS-2.0.0_Normal Po z?? 3 22:16:19 CEST 2007 starting... now booting... real_main INIT detected from ---- {APICID = 00 NODEID = 00 COREID = 00} --- Issuing SOFT_RESET... soft reset soft reset done now booting... after init_cpus now booting... after udelay now booting... bist 000c1044 <-00000000 000c104c <-00000001 000c1054 <- This is my boot log when I type "reboot" from Linux. It seems chipset just sends INIT# to CPU. I could not force it to generate proper CPURST#. It seems there is some bit for that in SB but documentation is unclear (VT8237) I asked VIA recently, but still no answer. To catch the log with my code: w83627ehg_enable_serial(SERIAL_DEV, TTYS0_BASE); uart_init(); console_init(); print_info("now booting... real_main\r\n"); if (bist == 0) { //init_cpus(cpu_init_detectedx); bsp_apicid = init_cpus(cpu_init_detectedx, sysinfo); } // enable_lapic(); init_timer(); print_info("now booting... after init_cpus\r\n"); mdelay(1000); print_info("now booting... after udelay\r\n"); /* Halt if there was a built in self test failure */ report_bist_failure(bist); print_info("now booting... bist\r\n"); // setup_a8v_resource_map(); setup_default_resource_map(); print_info("now booting... resource map\r\n"); setup_coherent_ht_domain(); print_info("now booting... HT domain\r\n"); wait_all_core0_started(); print_info("now booting... Core0 started\r\n"); So the problem is with setup_default resource map... With the delay(1000) it will hang on the third write, without the delay it will hang in random place in the very same routine. What is interesting if I reboot through undocumented 0xcf9 (already send some questions about this to VIA) I can go on at least to setup_coherent_ht_domain(); I dont know what might be wrong :/ My ROM strap for VIA chipset is not working (all registers gets filled with FF) correctly right now, but I dont think this should be a problem while rebooting??? I think HT Link is set up bit later.... My soft_reset routine just triggers PCI_RESET signal from SB. I put online some log file of full boot and reboot tries at http://assembler.cz/lb there is also my mainboard specific code. Thanks, Rudolf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG3bZS3J9wPJqZRNURAgg3AKCGzybE9IxEDt1bBLLp5QqUQPQU/QCgmUML lQQX8wblhLJGZsU+BxyXM4Y= =O5GO -----END PGP SIGNATURE----- From alex at rtfs.hu Wed Sep 5 00:19:00 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Wed, 05 Sep 2007 00:19:00 +0200 Subject: [LinuxBIOS] [PATCH] stage1 multi-segment lar bug Message-ID: <1188944340.17055.47.camel@localhost> Hi, the new multi-segment lar handling has an off-by-one error in the printk. -- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: stage1-bug.diff Type: text/x-patch Size: 438 bytes Desc: not available URL: From c-d.hailfinger.devel.2006 at gmx.net Tue Sep 4 20:11:16 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue, 04 Sep 2007 20:11:16 +0200 Subject: [LinuxBIOS] UBoot Message-ID: <46DD9FC4.4080506@gmx.net> Hi, while looking at the OpenMoko codebase, I noticed they are using UBoot as their hardware init software. UBoot seems to be similar to LinuxBIOS from a conceptual point of view, although it seems they target mostly embedded and non-x86 systems, while we mostly target x86/x86_64 systems where hardware configuration can be changed easily by the user. Did anyone publish a comparison between LinuxBIOS and UBoot or is there some mail exchange which I could read to learn about the relationship between the two projects? Carl-Daniel From alex at rtfs.hu Wed Sep 5 01:06:35 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Wed, 05 Sep 2007 01:06:35 +0200 Subject: [LinuxBIOS] [RFC] ADLO2 Message-ID: <1188947195.17055.59.camel@localhost> Hi, attached is my work on ADLO. Changes: 1, use macros for frequently used functions (LOAD_SEG, CMOS_OUT, PCI_OUT) 2, store loader size at end (no 1kb limit) 3, change the copy routine to support 128kb images 4, createpayload utility, which concatenates the ELF header, the loader and BIOS Together with bochsbios.diff, this made it possible to use the latest 128kb big bios images from Bochs. After talking with Stefan, it turned out that the enable/disable shadowing inside ADLO are really machine specific, thus this method is not really welcomed. The new segment support in LAR made the following changes possible: 1, store ADLO in segment0 ("current ADLO" without the copy routine) 2, store the bios in segment1 Thus LinuxBIOS will copy the BIOS to the desired location and the 300byte ADLO will just set up the following: 1, clean up the interrupt vectors 2, set some CMOS variables 3, switch back to 16bit real mode 4, jump to the bios This works fine now. Inside QEMU. A nice shadow disable/enable should be implemented inside LinuxBIOS, and the lar segment loader should disable it when infering with a region which is shadowed. The linuxbios.diff is needed to turn on LAR segment support. What is needed to be done: 1, shadowing in linuxbios 2, reading linuxbios tables for memory size in adlo 3, implementing a better logic in bochsbios regarding the boot devices (currently it can only try one device, hardcoded in cmos) Regarding 2, is there a simpler way than reading all the MEM entries in the linuxbios tables? -- Alex Beregszaszi -------------- next part -------------- A non-text attachment was scrubbed... Name: adlo2.tar.gz Type: application/x-compressed-tar Size: 69914 bytes Desc: not available URL: From alex at rtfs.hu Wed Sep 5 01:12:18 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Wed, 05 Sep 2007 01:12:18 +0200 Subject: [LinuxBIOS] [RFC] ADLO2 In-Reply-To: <1188947195.17055.59.camel@localhost> References: <1188947195.17055.59.camel@localhost> Message-ID: <1188947538.17055.64.camel@localhost> On Wed, 2007-09-05 at 01:06 +0200, Alex Beregszaszi wrote: > Hi, > > attached is my work on ADLO. One more note: normal/payload/segment0 (290 bytes, lzma compressed to 185 bytes @0x50) normal/payload/segment1 (131072 bytes, lzma compressed to 25353 bytes @0x160) 25kb is not bad, leaves plenty of space for lbmenu, efi, grub. Also the BIOS* images in adlo2.tar.gz are compiled from the latest Bochs CVS but with some patches applied. They have lot of debug turned on, which will be written on serial. Of course the stock CVS with the bochsbios.diff will work. -- Alex Beregszaszi From peter at stuge.se Wed Sep 5 01:12:23 2007 From: peter at stuge.se (Peter Stuge) Date: Wed, 5 Sep 2007 01:12:23 +0200 Subject: [LinuxBIOS] A question of support... (GX1/CS5530/PC97317) In-Reply-To: <59d1d9570709031937p43bfef7qebcfd9b23e128c0f@mail.gmail.com> References: <59d1d9570709031919l4eb3c725l6b548ad8fdfd4bdb@mail.gmail.com> <59d1d9570709031937p43bfef7qebcfd9b23e128c0f@mail.gmail.com> Message-ID: <20070904231223.16854.qmail@stuge.se> On Mon, Sep 03, 2007 at 09:37:50PM -0500, Gavin Groce wrote: > The box has a AT27C020... > > Which is OTP (one time programmable) :( Yes - you'll need to get a flash chip to replace it. > And it does not look to me pin compatable with the other AMTEL > supported chips in a PLCC (i think that is the correct acro.) > package... Please check out http://linuxbios.org/FAQ under 3.7 how to identify the flash chip package, and if the chip is socketed or not. Worst case it's not socketed and then you would have to desolder the current chip from the board and instead solder on a socket for a flash chip. Flash chips are easy enough to get hold of. It doesn't have to be the same make - there are lots of compatible chips from different vendors. If the soldering is needed and you're up for it there's a fair chance you can get LB working on the board - but it does need some research and experimentation to find some specific settings for this particular board design that are usually different between any GX1 board - code supporting the hardware chips is already done though. //Peter From peter at stuge.se Wed Sep 5 01:24:14 2007 From: peter at stuge.se (Peter Stuge) Date: Wed, 5 Sep 2007 01:24:14 +0200 Subject: [LinuxBIOS] Ethernet problem with GeodeLX (db800) with running lxbios In-Reply-To: <46DCFA82.5090904@saxnet.de> References: <46DBFFA8.3080600@saxnet.de> <46DC0D48.9050100@saxnet.de> <200709031658.34797.juergen127@kreuzholzen.de> <46DC4502.90504@saxnet.de> <46DCFA82.5090904@saxnet.de> Message-ID: <20070904232414.18742.qmail@stuge.se> On Tue, Sep 04, 2007 at 08:26:10AM +0200, Steffen D. wrote: > Anybody a idea what to test? What's the problem? Do you get interrupts? cat /proc/interrupts //Peter From peter at stuge.se Wed Sep 5 01:29:41 2007 From: peter at stuge.se (Peter Stuge) Date: Wed, 5 Sep 2007 01:29:41 +0200 Subject: [LinuxBIOS] LinuxBIOS panic room In-Reply-To: <20070904093805.GB25667@coresystems.de> References: <13426df10708281151i690c6a7fp7622b7bfe933ff35@mail.gmail.com> <20070829051903.21550.qmail@stuge.se> <46D513EB.9080409@gmail.com> <20070829132729.GD7091@greenwood> <20070829135856.GA30258@coresystems.de> <20070829184943.8592.qmail@stuge.se> <20070829212836.3557.qmail@stuge.se> <46D6066E.4090806@gmx.net> <20070904093805.GB25667@coresystems.de> Message-ID: <20070904232941.19492.qmail@stuge.se> On Tue, Sep 04, 2007 at 11:38:05AM +0200, Stefan Reinauer wrote: > I really like the idea. BUT: The one thing that seems unclear is > where would we store that lar archive? On the BIOS chip? RAM seems > no option as it is not initialized yet. Good point. How usable is the CAR? I guess either the download will in fact write to flash immediately (bad idea!) or only initram would be downloaded first, and then the full lar. //Peter From c-d.hailfinger.devel.2006 at gmx.net Wed Sep 5 01:31:14 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 05 Sep 2007 01:31:14 +0200 Subject: [LinuxBIOS] LinuxBIOS panic room In-Reply-To: <20070904093805.GB25667@coresystems.de> References: <20070819181455.GA19802@greenwood> <13426df10708281151i690c6a7fp7622b7bfe933ff35@mail.gmail.com> <20070829051903.21550.qmail@stuge.se> <46D513EB.9080409@gmail.com> <20070829132729.GD7091@greenwood> <20070829135856.GA30258@coresystems.de> <20070829184943.8592.qmail@stuge.se> <20070829212836.3557.qmail@stuge.se> <46D6066E.4090806@gmx.net> <20070904093805.GB25667@coresystems.de> Message-ID: <46DDEAC2.8040406@gmx.net> On 04.09.2007 11:38, Stefan Reinauer wrote: > * Carl-Daniel Hailfinger [070830 01:51]: >> I'd say it should accept a lar archive via serial console, perhaps using >> ymodem, and start executing the first member of the lar. > > I really like the idea. BUT: The one thing that seems unclear is where > would we store that lar archive? On the BIOS chip? RAM seems no option > as it is not initialized yet. What about outputting the size of CAR and how much we have left of it over serial and then allowing to use up to 70% (arbitrary) for code download? That should be enough room to download and execute RAM init code, unless the CPU has really tiny amounts of cache. Even then we could try to split the code and use RAM-over-serial (ok, that's a real hack, but it would work). Once RAM is running, we could use a different panic room mode as we have megabytes of main RAM for payload download. Carl-Daniel From stepan at coresystems.de Wed Sep 5 01:40:59 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 5 Sep 2007 01:40:59 +0200 Subject: [LinuxBIOS] LinuxBIOS panic room In-Reply-To: <20070904232941.19492.qmail@stuge.se> References: <20070829051903.21550.qmail@stuge.se> <46D513EB.9080409@gmail.com> <20070829132729.GD7091@greenwood> <20070829135856.GA30258@coresystems.de> <20070829184943.8592.qmail@stuge.se> <20070829212836.3557.qmail@stuge.se> <46D6066E.4090806@gmx.net> <20070904093805.GB25667@coresystems.de> <20070904232941.19492.qmail@stuge.se> Message-ID: <20070904234059.GA16565@coresystems.de> * Peter Stuge [070905 01:29]: > How usable is the CAR? I guess either the download will in fact write > to flash immediately (bad idea!) or only initram would be downloaded > first, and then the full lar. Why would that be a bad idea? I think writing the flash directly (except bootblock) is an excellent idea, since this is the code that is executed when a) the flash file is corrupt b) a new lar is sent -- 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 Wed Sep 5 01:50:42 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 05 Sep 2007 01:50:42 +0200 Subject: [LinuxBIOS] LinuxBIOS panic room In-Reply-To: <20070904234059.GA16565@coresystems.de> References: <20070829051903.21550.qmail@stuge.se> <46D513EB.9080409@gmail.com> <20070829132729.GD7091@greenwood> <20070829135856.GA30258@coresystems.de> <20070829184943.8592.qmail@stuge.se> <20070829212836.3557.qmail@stuge.se> <46D6066E.4090806@gmx.net> <20070904093805.GB25667@coresystems.de> <20070904232941.19492.qmail@stuge.se> <20070904234059.GA16565@coresystems.de> Message-ID: <46DDEF52.1060908@gmx.net> On 05.09.2007 01:40, Stefan Reinauer wrote: > * Peter Stuge [070905 01:29]: >> How usable is the CAR? I guess either the download will in fact write >> to flash immediately (bad idea!) or only initram would be downloaded >> first, and then the full lar. > > Why would that be a bad idea? I think writing the flash directly (except > bootblock) is an excellent idea, since this is the code that is executed > when > > a) the flash file is corrupt > b) a new lar is sent I still would like to try to enable RAM first. That will allow us to verify an image after flashing instead of having to redownload it over serial. Besides that, if there is some timing critical component in the flashing process, we don't want to wait for serial input. Carl-Daniel From alex at rtfs.hu Wed Sep 5 01:51:37 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Wed, 05 Sep 2007 01:51:37 +0200 Subject: [LinuxBIOS] [PATCH] lar use run_address Message-ID: <1188949897.17055.70.camel@localhost> Hi, minor patch: use run_address() instead duplicating in lib/lar.c -- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: lar-minor.diff Type: text/x-patch Size: 525 bytes Desc: not available URL: From stepan at coresystems.de Wed Sep 5 01:52:57 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 5 Sep 2007 01:52:57 +0200 Subject: [LinuxBIOS] r2758 - in trunk: LinuxBIOSv2/util util In-Reply-To: <46DC544B.8030305@gmx.net> References: <20070901194454.26802gmx1@mx084.gmx.net> <46DC544B.8030305@gmx.net> Message-ID: <20070904235256.GA19641@coresystems.de> * Carl-Daniel Hailfinger [070903 20:36]: > This commit removed probe_superio from v2. It has not been referenced as > svn:externals, so none of the v2 and v3 trees have probe_superio or > superiotool. > As of revision 2762, the v2 repository is still BROKEN and superiotool > doesn't appear in v3 either (checked revision 486). > > Such commits are one reason why I think self-acked commits should not be > allowed. Well. Half-hearted code reviews are an illusion of safety, too. The current code's lar handling is pretty much broken even though that code was reviewed, but obviously nobody even tested it: Wrote LinuxBIOS table at: 0x00000500 - 0x00000a54 checksum 401f Show all devs... cpus: Unknown device path type: 0 Stage2 code done. LAR: Attempting to open 'normal/payload'. LAR: Attempting to open 'normal/payload/segment0'. LAR: load_file: No such file 'normal/payload/segment0' It just hangs somewhere bogus and never gets to the defined error in arch/x86/stage1.c:194: die("FATAL: No usable payload found.\n"); also the current code contains quite some warnings again regarding int-to-pointer casts in lar.c and pointer-to-int cast and uninitialized variable use in stage1.c 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 alex at rtfs.hu Wed Sep 5 02:09:13 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Wed, 05 Sep 2007 02:09:13 +0200 Subject: [LinuxBIOS] [PATCH] LAR no-segment crash (was: Re: r2758 - in trunk: LinuxBIOSv2/util util) In-Reply-To: <20070904235256.GA19641@coresystems.de> References: <20070901194454.26802gmx1@mx084.gmx.net> <46DC544B.8030305@gmx.net> <20070904235256.GA19641@coresystems.de> Message-ID: <1188950953.17055.75.camel@localhost> Hi, > > As of revision 2762, the v2 repository is still BROKEN and superiotool > > doesn't appear in v3 either (checked revision 486). > > > > Such commits are one reason why I think self-acked commits should not be > > allowed. > > Well. Half-hearted code reviews are an illusion of safety, too. > > The current code's lar handling is pretty much broken even though that > code was reviewed, but obviously nobody even tested it: > > Wrote LinuxBIOS table at: 0x00000500 - 0x00000a54 checksum 401f > Show all devs... > cpus: Unknown device path type: 0 > Stage2 code done. > LAR: Attempting to open 'normal/payload'. > LAR: Attempting to open 'normal/payload/segment0'. > LAR: load_file: No such file 'normal/payload/segment0' > > It just hangs somewhere bogus and never gets to the defined error in > > arch/x86/stage1.c:194: die("FATAL: No usable payload found.\n"); > > also the current code contains quite some warnings again regarding > int-to-pointer casts in lar.c and pointer-to-int cast and uninitialized > variable use in stage1.c run_address gets called with entry=0. Attached patch fixes it. (If thread hi-jacking is forbidden, sorry) -- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: lar-segment-nullpointer.diff Type: text/x-patch Size: 373 bytes Desc: not available URL: From alex at rtfs.hu Wed Sep 5 02:20:32 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Wed, 05 Sep 2007 02:20:32 +0200 Subject: [LinuxBIOS] Patch signed-off-by Message-ID: <1188951632.17055.78.camel@localhost> Hi, I apologize I forgot to apply "Signed-off-by: Alex Beregszaszi " to my patches. From hereby, my earlier patches shall be taken as signed off by me. Will not forget for further patches. Thank you, -- Alex Beregszaszi From c-d.hailfinger.devel.2006 at gmx.net Wed Sep 5 02:37:56 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 05 Sep 2007 02:37:56 +0200 Subject: [LinuxBIOS] r2758 - in trunk: LinuxBIOSv2/util util In-Reply-To: <20070904235256.GA19641@coresystems.de> References: <20070901194454.26802gmx1@mx084.gmx.net> <46DC544B.8030305@gmx.net> <20070904235256.GA19641@coresystems.de> Message-ID: <46DDFA64.5040805@gmx.net> On 05.09.2007 01:52, Stefan Reinauer wrote: > * Carl-Daniel Hailfinger [070903 20:36]: >> This commit removed probe_superio from v2. It has not been referenced as >> svn:externals, so none of the v2 and v3 trees have probe_superio or >> superiotool. >> As of revision 2762, the v2 repository is still BROKEN and superiotool >> doesn't appear in v3 either (checked revision 486). >> >> Such commits are one reason why I think self-acked commits should not be >> allowed. > > Well. Half-hearted code reviews are an illusion of safety, too. Yes. > The current code's lar handling is pretty much broken even though that > code was reviewed, but obviously nobody even tested it: It seems I tested without a payload. Apologies. > Wrote LinuxBIOS table at: 0x00000500 - 0x00000a54 checksum 401f > Show all devs... > cpus: Unknown device path type: 0 > Stage2 code done. > LAR: Attempting to open 'normal/payload'. > LAR: Attempting to open 'normal/payload/segment0'. > LAR: load_file: No such file 'normal/payload/segment0' > > It just hangs somewhere bogus and never gets to the defined error in > > arch/x86/stage1.c:194: die("FATAL: No usable payload found.\n"); > > also the current code contains quite some warnings again regarding > int-to-pointer casts in lar.c and pointer-to-int cast and uninitialized > variable use in stage1.c Which gcc? I seem to have trouble getting my gcc to warn about anything on i386. "gcc (GCC) 4.1.0 (SUSE Linux)". On my other machine, I get a few warnings: > /sources/LinuxBIOSv3/lib/lar.c: In function ?find_file?: > /sources/LinuxBIOSv3/lib/lar.c:110: warning: cast to pointer from integer of different size > /sources/LinuxBIOSv3/lib/lar.c:111: warning: cast to pointer from integer of different size resulting from this code: > result->entry = (void *)ntohl(header->entry); > result->loadaddress = (void *)ntohl(header->loadaddress); Because we switched these lar header entries to u64 and struct mem_file uses void * for the related entries, we are stuck. There are two ways out of this problem: struct mem_file { void *start; int len; u32 reallen; u32 compression; u64 entry; u64 loadaddress; }; But that means we can't use ->entry and ->loadaddress as pointers anymore. Sucks. Or explicitly check if any of the upper 32 bits are set and if not, convert to void *. That "solution" breaks as soon as we want to make use of 64 bits. Sucks even more. So I fear we have to go for the first route and work with PAE once we have an entry above 32 bits. > /sources/LinuxBIOSv3/arch/x86/stage1.c: In function ?legacy?: > /sources/LinuxBIOSv3/arch/x86/stage1.c:66: warning: ?result.reallen? is used uninitialized in this function resulting from this code: > ret = elfboot_mem(mem, where, result.reallen); Not a problem right now because elfboot_mem doesn't use its third parameter. But Ron might want to fix this in a future commit. > /sources/LinuxBIOSv3/arch/x86/stage1.c: In function ?stage1_main?: > /sources/LinuxBIOSv3/arch/x86/stage1.c:185: warning: passing argument 1 of ?printk? makes integer from pointer without a cast printk prefix was forgotten. Alex Beregszaszi has already sent a patch for that: "[PATCH] stage1 multi-segment lar bug" Carl-Daniel From pyro at linuxlabs.com Wed Sep 5 03:41:09 2007 From: pyro at linuxlabs.com (pyro) Date: Tue, 4 Sep 2007 21:41:09 -0400 (EDT) Subject: [LinuxBIOS] LinuxBIOS panic room In-Reply-To: <46DDEF52.1060908@gmx.net> References: <20070829051903.21550.qmail@stuge.se> <46D513EB.9080409@gmail.com> <20070829132729.GD7091@greenwood> <20070829135856.GA30258@coresystems.de> <20070829184943.8592.qmail@stuge.se> <20070829212836.3557.qmail@stuge.se> <46D6066E.4090806@gmx.net> <20070904093805.GB25667@coresystems.de> <20070904232941.19492.qmail@stuge.se> <20070904234059.GA16565@coresystems.de> <46DDEF52.1060908@gmx.net> Message-ID: Greetings, On Wed, 5 Sep 2007, Carl-Daniel Hailfinger wrote: > On 05.09.2007 01:40, Stefan Reinauer wrote: > > * Peter Stuge [070905 01:29]: > >> How usable is the CAR? I guess either the download will in fact write > >> to flash immediately (bad idea!) or only initram would be downloaded > >> first, and then the full lar. > > > > Why would that be a bad idea? I think writing the flash directly (except > > bootblock) is an excellent idea, since this is the code that is executed > > when > > > > a) the flash file is corrupt > > b) a new lar is sent > > I still would like to try to enable RAM first. That will allow us to > verify an image after flashing instead of having to redownload it over > serial. Besides that, if there is some timing critical component in the > flashing process, we don't want to wait for serial input. > Why not just load and run whatever is downloaded? If the flash is corrupt, send a flash program followed by the image. If under development, perhaps a ram init test or just something to dump registers. During production, it might be memtest or other diagnostic. The one behavior that seems to support every option (and options I haven't considered) is load and run. That also lets you send raminit code, then a flash image and a flash program that does the verify. The less it actually does before handing control to the serial line, the less likely it is to do the wrong thing. I envision something like the Dragonball's bootstrap mode but not with "b-records". A b-record is just a string of hex containing an absolute address, a count and count bytes of data. When it gets a brec with a count of 0, it jumps to the address. G'day, sjames > Carl-Daniel > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > ||||| |||| ||||||||||||| ||| by Linux Labs International, Inc. Steven James, CTO 55 Marietta Street Suite 1830 Atlanta, Ga 30303 866 824 9737 support From svn at openbios.org Wed Sep 5 03:41:52 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 5 Sep 2007 03:41:52 +0200 Subject: [LinuxBIOS] r487 - in LinuxBIOSv3: device util/x86emu Message-ID: Author: stepan Date: 2007-09-05 03:41:52 +0200 (Wed, 05 Sep 2007) New Revision: 487 Modified: LinuxBIOSv3/device/pci_device.c LinuxBIOSv3/util/x86emu/vm86.c Log: this patch changes vm86.c:do_bios to run_bios(dev, addr). While doing this, we can remove lot of code duplication about searching the device, which is already done in the parent pci_device.c. Signed-off-by: Alex Beregszaszi Acked-by: Stefan Reinauer Modified: LinuxBIOSv3/device/pci_device.c =================================================================== --- LinuxBIOSv3/device/pci_device.c 2007-08-30 10:25:43 UTC (rev 486) +++ LinuxBIOSv3/device/pci_device.c 2007-09-05 01:41:52 UTC (rev 487) @@ -649,9 +649,9 @@ void pci_dev_init(struct device *dev) { + printk(BIOS_SPEW, "PCI: pci_dev_init\n"); #if defined(CONFIG_PCI_OPTION_ROM_RUN) && CONFIG_PCI_OPTION_ROM_RUN == 1 void run_bios(struct device *dev, unsigned long addr); - void do_vgabios(void); struct rom_header *rom, *ram; printk(BIOS_INFO, "Probing for option ROM\n"); @@ -661,15 +661,8 @@ ram = pci_rom_load(dev, rom); if (ram == NULL) return; -#if defined(CONFIG_PCI_OPTION_ROM_RUN_X86EMU) && \ - CONFIG_PCI_OPTION_ROM_RUN_X86EMU == 1 run_bios(dev, ram); #endif -#if defined(CONFIG_PCI_OPTION_ROM_RUN_VM86) && \ - CONFIG_PCI_OPTION_ROM_RUN_VM86 == 1 - do_vgabios(); -#endif -#endif } /** Default device operation for PCI devices. */ Modified: LinuxBIOSv3/util/x86emu/vm86.c =================================================================== --- LinuxBIOSv3/util/x86emu/vm86.c 2007-08-30 10:25:43 UTC (rev 486) +++ LinuxBIOSv3/util/x86emu/vm86.c 2007-09-05 01:41:52 UTC (rev 487) @@ -307,13 +307,8 @@ ); } -void do_vgabios(void) +void run_bios(struct device *dev, unsigned long addr) { - struct device *dev; - unsigned int busdevfn; - unsigned long rom = 0; - unsigned char *buf; - unsigned int size = 64*1024; int i; /* clear vga bios data area */ @@ -321,41 +316,7 @@ *(unsigned char *) i = 0; } - dev = dev_find_class(PCI_CLASS_DISPLAY_VGA<<8 , 0); - - if (!dev) { - printk(BIOS_DEBUG, "NO VGA FOUND\n"); - return; - } - printk(BIOS_DEBUG,"found VGA: vid=%x, did=%x\n", dev->vendor, dev->device); - - /* declare rom address here - keep any config data out of the way - * of core LXB stuff */ -#warning fix rom address - rom = 0xc0000; - pci_write_config32(dev, PCI_ROM_ADDRESS, rom|1); - printk(BIOS_DEBUG, "rom base, size: %p\n", (void *)rom); - - buf = (unsigned char *) rom; - if ((buf[0] == 0x55) && (buf[1] == 0xaa)) { - memcpy((void *) 0xc0000, buf, size); - -#warning Implement write_protect_vgabios() - //write_protect_vgabios(); // in northbridge - - // check signature again - buf = (unsigned char *) 0xc0000; - if (buf[0]==0x55 && buf[1]==0xAA) { - busdevfn = (dev->bus->secondary << 8) | dev->path.u.pci.devfn; - printk(BIOS_DEBUG, "bus/devfn = %#x\n", busdevfn); - - real_mode_switch_call_vga(busdevfn); - } else - printk(BIOS_DEBUG, "Failed to copy VGA BIOS to 0xc0000\n"); - } else - printk(BIOS_DEBUG, "BAD SIGNATURE 0x%x 0x%x\n", buf[0], buf[1]); - - pci_write_config32(dev, PCI_ROM_ADDRESS, 0); + real_mode_switch_call_vga((dev->bus->secondary << 8) | dev->path.u.pci.devfn); } From stepan at coresystems.de Wed Sep 5 03:42:27 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 5 Sep 2007 03:42:27 +0200 Subject: [LinuxBIOS] [PATCH] vgabios: use same interface for biosemu.c and vm86.c In-Reply-To: <1188909038.17055.14.camel@localhost> References: <1188909038.17055.14.camel@localhost> Message-ID: <20070905014227.GA10233@coresystems.de> * Alex Beregszaszi [070904 14:30]: > Hi, > > this patch changes vm86.c:do_bios to run_bios(dev, addr). > > While doing this, we can remove lot of code duplication about searching > the device, which is already done in the parent pci_device.c. r487 -- 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 Wed Sep 5 03:45:27 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 5 Sep 2007 03:45:27 +0200 Subject: [LinuxBIOS] [PATCH] Support other than 0xC000 ROMs in VM86 In-Reply-To: <1188925040.17055.40.camel@localhost> References: <1188925040.17055.40.camel@localhost> Message-ID: <20070905014527.GB10233@coresystems.de> * Alex Beregszaszi [070904 18:57]: > Hi, > > this patch changes the real_mode_switch_call_vga() function to jump to > the addr given as an argument instead the hardcoded 0xc000. This is good stuff. > Also it changes the function to inline assembly and passes the arguments > through that. > > This patch includes the changes from my previous patch "[PATCH] vgabios: > use same interface for biosemu.c and vm86.c", but should be committed > incrementally. Can you please rediff against the current svn and send this patch again? > Btw, I think it would be a good idea to export the interrupt handlers to > a common file (biosints.c?) and let it be hooked up by both vm86 and > x86emu implementations. Yes, definitely! > -- > Alex 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 Wed Sep 5 03:47:21 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 5 Sep 2007 03:47:21 +0200 Subject: [LinuxBIOS] r488 - LinuxBIOSv3/arch/x86 Message-ID: Author: stepan Date: 2007-09-05 03:47:21 +0200 (Wed, 05 Sep 2007) New Revision: 488 Modified: LinuxBIOSv3/arch/x86/stage1.c Log: the new multi-segment lar handling has an off-by-one error in the printk. Signed-off-by: Alex Beregszaszi Acked-by: Stefan Reinauer Modified: LinuxBIOSv3/arch/x86/stage1.c =================================================================== --- LinuxBIOSv3/arch/x86/stage1.c 2007-09-05 01:41:52 UTC (rev 487) +++ LinuxBIOSv3/arch/x86/stage1.c 2007-09-05 01:47:21 UTC (rev 488) @@ -182,7 +182,7 @@ archive.len = *(u32 *)0xfffffff4; archive.start =(void *)(0UL-archive.len); newentry = load_file(&archive, filename); - printk("newentry is %p\n", newentry); + printk(BIOS_SPEW, "newentry is %p\n", newentry); if (newentry == (void *)-1) break; if (! entry) From stepan at coresystems.de Wed Sep 5 03:47:45 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 5 Sep 2007 03:47:45 +0200 Subject: [LinuxBIOS] [PATCH] stage1 multi-segment lar bug In-Reply-To: <1188944340.17055.47.camel@localhost> References: <1188944340.17055.47.camel@localhost> Message-ID: <20070905014744.GC10233@coresystems.de> * Alex Beregszaszi [070905 00:19]: > Hi, > > the new multi-segment lar handling has an off-by-one error in the > printk. > > -- > Alex r488 -- 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 Wed Sep 5 03:53:37 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 5 Sep 2007 03:53:37 +0200 Subject: [LinuxBIOS] r489 - LinuxBIOSv3/lib Message-ID: Author: stepan Date: 2007-09-05 03:53:37 +0200 (Wed, 05 Sep 2007) New Revision: 489 Modified: LinuxBIOSv3/lib/elfboot.c Log: cleanupmsg.diff changes the "(cleaned up) New segment.." message to be displayed only when the condition happens. Signed-off-by: Alex Beregszaszi Acked-by: Stefan Reinauer Modified: LinuxBIOSv3/lib/elfboot.c =================================================================== --- LinuxBIOSv3/lib/elfboot.c 2007-09-05 01:47:21 UTC (rev 488) +++ LinuxBIOSv3/lib/elfboot.c 2007-09-05 01:53:37 UTC (rev 489) @@ -103,11 +103,11 @@ phdr[i].p_paddr, phdr[i].p_memsz, phdr[i].p_offset, phdr[i].p_filesz); /* Clean up the values */ size = phdr[i].p_filesz; - if (phdr[i].p_filesz > phdr[i].p_memsz) { + if (size > phdr[i].p_memsz) { size = phdr[i].p_memsz; + printk(BIOS_DEBUG, "(cleaned up) New segment addr 0x%x size 0x%x offset 0x%x\n", + phdr[i].p_paddr, size, phdr[i].p_offset); } - printk(BIOS_DEBUG, "(cleaned up) New segment addr 0x%x size 0x%x offset 0x%x\n", - phdr[i].p_paddr, size, phdr[i].p_offset); /* Verify the memory addresses in the segment are valid */ if (!valid_area(mem, phdr[i].p_paddr, size)) From svn at openbios.org Wed Sep 5 03:54:28 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 5 Sep 2007 03:54:28 +0200 Subject: [LinuxBIOS] r490 - LinuxBIOSv3/lib Message-ID: Author: stepan Date: 2007-09-05 03:54:28 +0200 (Wed, 05 Sep 2007) New Revision: 490 Modified: LinuxBIOSv3/lib/elfboot.c Log: properzero.diff changes the memset to only clean up the area which is not memcopied to. Signed-off-by: Alex Beregszaszi Acked-by: Stefan Reinauer Modified: LinuxBIOSv3/lib/elfboot.c =================================================================== --- LinuxBIOSv3/lib/elfboot.c 2007-09-05 01:53:37 UTC (rev 489) +++ LinuxBIOSv3/lib/elfboot.c 2007-09-05 01:54:28 UTC (rev 490) @@ -112,16 +112,13 @@ /* Verify the memory addresses in the segment are valid */ if (!valid_area(mem, phdr[i].p_paddr, size)) goto out; - /* let's just be stupid about this. Bzero the whole area we are copying to, - * then copy out the data, which may be a subset of the total area. - * the cache, after all, is your friend. - */ - printk(BIOS_INFO, "Set %p to 0 for %d bytes\n", (unsigned char *)phdr[i].p_paddr, phdr[i].p_memsz); - memset((unsigned char *)phdr[i].p_paddr, 0, phdr[i].p_memsz); /* ok, copy it out */ printk(BIOS_INFO, "Copy to %p from %p for %d bytes\n", (unsigned char *)phdr[i].p_paddr, &header[phdr[i].p_offset], size); memcpy((unsigned char *)phdr[i].p_paddr, &header[phdr[i].p_offset], size); - + if (size < phdr[i].p_memsz) { + printk(BIOS_INFO, "Set %p to 0 for %d bytes\n", (unsigned char *)phdr[i].p_paddr, phdr[i].p_memsz-size); + memset((unsigned char *)phdr[i].p_paddr+size, 0, phdr[i].p_memsz-size); + } } return 1; out: From stepan at coresystems.de Wed Sep 5 03:55:06 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 5 Sep 2007 03:55:06 +0200 Subject: [LinuxBIOS] [PATCH] elfboot minor changes In-Reply-To: <1188908220.17055.9.camel@localhost> References: <1188908220.17055.9.camel@localhost> Message-ID: <20070905015506.GA18667@coresystems.de> * Alex Beregszaszi [070904 14:17]: > Hi, > > cleanupmsg.diff changes the "(cleaned up) New segment.." message to be > displayed only when the condition happens. r489 > properzero.diff changes the memset to only clean up the area which is > not memcopied to. r490 -- 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 Wed Sep 5 03:59:27 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 5 Sep 2007 03:59:27 +0200 Subject: [LinuxBIOS] r491 - LinuxBIOSv3/arch/x86 Message-ID: Author: stepan Date: 2007-09-05 03:59:27 +0200 (Wed, 05 Sep 2007) New Revision: 491 Modified: LinuxBIOSv3/arch/x86/stage1.c Log: run_address gets called with entry=0. This patch fixes it. Signed-off-by: Alex Beregszaszi Acked-by: Stefan Reinauer Modified: LinuxBIOSv3/arch/x86/stage1.c =================================================================== --- LinuxBIOSv3/arch/x86/stage1.c 2007-09-05 01:54:28 UTC (rev 490) +++ LinuxBIOSv3/arch/x86/stage1.c 2007-09-05 01:59:27 UTC (rev 491) @@ -189,7 +189,8 @@ entry = newentry; } printk(BIOS_SPEW, "all loaded, entry %p\n", entry); - run_address(entry); + if (entry) + run_address(entry); die("FATAL: No usable payload found.\n"); From stepan at coresystems.de Wed Sep 5 04:01:02 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 5 Sep 2007 04:01:02 +0200 Subject: [LinuxBIOS] [PATCH] LAR no-segment crash (was: Re: r2758 - in trunk: LinuxBIOSv2/util util) In-Reply-To: <1188950953.17055.75.camel@localhost> References: <20070901194454.26802gmx1@mx084.gmx.net> <46DC544B.8030305@gmx.net> <20070904235256.GA19641@coresystems.de> <1188950953.17055.75.camel@localhost> Message-ID: <20070905020102.GC21947@coresystems.de> * Alex Beregszaszi [070905 02:09]: > > LAR: Attempting to open 'normal/payload'. > > LAR: Attempting to open 'normal/payload/segment0'. > > LAR: load_file: No such file 'normal/payload/segment0' > > > run_address gets called with entry=0. > > Attached patch fixes it. r491. -- 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 Wed Sep 5 04:05:55 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 5 Sep 2007 04:05:55 +0200 Subject: [LinuxBIOS] r492 - LinuxBIOSv3/lib Message-ID: Author: stepan Date: 2007-09-05 04:05:55 +0200 (Wed, 05 Sep 2007) New Revision: 492 Modified: LinuxBIOSv3/lib/lar.c Log: this patch returns if someone tries to execute in place a compressed entry. Signed-off-by: Alex Beregszaszi Acked-by: Stefan Reinauer Modified: LinuxBIOSv3/lib/lar.c =================================================================== --- LinuxBIOSv3/lib/lar.c 2007-09-05 01:59:27 UTC (rev 491) +++ LinuxBIOSv3/lib/lar.c 2007-09-05 02:05:55 UTC (rev 492) @@ -251,6 +251,13 @@ filename); return 1; } + if (result.compression != 0) { + printk(BIOS_INFO, + "LAR: Run file %s failed: Compressed file" + " not supported for in-place execution\n", + filename); + return 1; + } where = result.start; } printk(BIOS_SPEW, "where is %p\n", where); From stepan at coresystems.de Wed Sep 5 04:06:23 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 5 Sep 2007 04:06:23 +0200 Subject: [LinuxBIOS] [PATCH] LAR compression in xip not supported In-Reply-To: <1188904793.17055.5.camel@localhost> References: <1188904793.17055.5.camel@localhost> Message-ID: <20070905020623.GA25140@coresystems.de> * Alex Beregszaszi [070904 13:19]: > Hi, > > attached patch returns if someone tries to execute in place a compressed > entry. > > -- > Alex r492 -- 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 Wed Sep 5 04:10:46 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 5 Sep 2007 04:10:46 +0200 Subject: [LinuxBIOS] r493 - LinuxBIOSv3/lib Message-ID: Author: stepan Date: 2007-09-05 04:10:45 +0200 (Wed, 05 Sep 2007) New Revision: 493 Modified: LinuxBIOSv3/lib/lar.c Log: minor patch: use run_address() instead duplicating in lib/lar.c Signed-off-by: Alex Beregszaszi Acked-by: Stefan Reinauer Modified: LinuxBIOSv3/lib/lar.c =================================================================== --- LinuxBIOSv3/lib/lar.c 2007-09-05 02:05:55 UTC (rev 492) +++ LinuxBIOSv3/lib/lar.c 2007-09-05 02:10:45 UTC (rev 493) @@ -233,7 +233,6 @@ */ int run_file(struct mem_file *archive, const char *filename, void *where) { - int (*v) (void); struct mem_file result; int ret; @@ -261,8 +260,7 @@ where = result.start; } printk(BIOS_SPEW, "where is %p\n", where); - v = where; - ret = v(); + ret = run_address(where); printk(BIOS_SPEW, "run_file returns with %d\n", ret); return ret; } From stepan at coresystems.de Wed Sep 5 04:11:21 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 5 Sep 2007 04:11:21 +0200 Subject: [LinuxBIOS] [PATCH] lar use run_address In-Reply-To: <1188949897.17055.70.camel@localhost> References: <1188949897.17055.70.camel@localhost> Message-ID: <20070905021121.GA25602@coresystems.de> * Alex Beregszaszi [070905 01:51]: > Hi, > > minor patch: use run_address() instead duplicating in lib/lar.c > > -- > Alex r493 -- 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 Wed Sep 5 04:29:11 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 5 Sep 2007 04:29:11 +0200 Subject: [LinuxBIOS] [PATCH] pci_rom.c checksum extension rom In-Reply-To: <1188904675.17055.2.camel@localhost> References: <1188904675.17055.2.camel@localhost> Message-ID: <20070905022911.GA31013@coresystems.de> * Alex Beregszaszi [070904 13:17]: > Hi, > > the attached patch adds code to checksum the pci extension rom and stop > if the stored and calculated checksum differ. Is this checksum reliably correct? I am hesitating to add new restrictions that might break otherwise working cards. -- 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 yinghailu at gmail.com Wed Sep 5 05:07:18 2007 From: yinghailu at gmail.com (yhlu) Date: Tue, 4 Sep 2007 20:07:18 -0700 Subject: [LinuxBIOS] problems with reboot on K8 In-Reply-To: <46DDB652.60600@assembler.cz> References: <46D1B902.6020503@assembler.cz> <46D95675.5070009@assembler.cz> <2ea3fae10709011333i44bb38dbo606cd58fb8eb621c@mail.gmail.com> <46DDB652.60600@assembler.cz> Message-ID: <2ea3fae10709042007p55c153l4eb526178aad54df@mail.gmail.com> it seems your soft-reset never work... YH From rminnich at gmail.com Wed Sep 5 05:19:02 2007 From: rminnich at gmail.com (ron minnich) Date: Tue, 4 Sep 2007 20:19:02 -0700 Subject: [LinuxBIOS] [PATCH] LAR compression in xip not supported In-Reply-To: <1188904793.17055.5.camel@localhost> References: <1188904793.17055.5.camel@localhost> Message-ID: <13426df10709042019g60216b55r5f103ca348663cdb@mail.gmail.com> On 9/4/07, Alex Beregszaszi wrote: > Hi, > > attached patch returns if someone tries to execute in place a compressed > entry. > This is a must never happen. If the lar tool ever creates this, it has seriously screwed up. We need to make sure the lar tool can not set both compression and XIP. thanks ron From rminnich at gmail.com Wed Sep 5 05:21:28 2007 From: rminnich at gmail.com (ron minnich) Date: Tue, 4 Sep 2007 20:21:28 -0700 Subject: [LinuxBIOS] [PATCH] LAR no-segment crash (was: Re: r2758 - in trunk: LinuxBIOSv2/util util) In-Reply-To: <1188950953.17055.75.camel@localhost> References: <20070901194454.26802gmx1@mx084.gmx.net> <46DC544B.8030305@gmx.net> <20070904235256.GA19641@coresystems.de> <1188950953.17055.75.camel@localhost> Message-ID: <13426df10709042021q1330509fl199bb64e776f80f@mail.gmail.com> On 9/4/07, Alex Beregszaszi wrote: > > The current code's lar handling is pretty much broken even though that > > code was reviewed, but obviously nobody even tested it: I did test it before each commit, with a full rebuild. This is a case where testing can miss a bug. (Alex, I know you did not write that, I lost track who wrote it). > > also the current code contains quite some warnings again regarding > > int-to-pointer casts in lar.c and pointer-to-int cast and uninitialized > > variable use in stage1.c let's fix it. ron From rminnich at gmail.com Wed Sep 5 06:23:10 2007 From: rminnich at gmail.com (ron minnich) Date: Tue, 4 Sep 2007 21:23:10 -0700 Subject: [LinuxBIOS] [RFC] ADLO2 In-Reply-To: <1188947538.17055.64.camel@localhost> References: <1188947195.17055.59.camel@localhost> <1188947538.17055.64.camel@localhost> Message-ID: <13426df10709042123h60e235d6sf47855ef4774a26f@mail.gmail.com> can someone with an XP license try to recreate Alex's fine work? The more people we get to try this, the better! thanks ron From rminnich at gmail.com Wed Sep 5 07:41:11 2007 From: rminnich at gmail.com (ron minnich) Date: Tue, 4 Sep 2007 22:41:11 -0700 Subject: [LinuxBIOS] run_bios Message-ID: <13426df10709042241p66e8956ev12478e43e461a82d@mail.gmail.com> void run_bios(struct device * dev, unsigned long addr) unsigned long or u32? Or, really, void * and cast it in the function? ron From r.marek at assembler.cz Wed Sep 5 08:40:24 2007 From: r.marek at assembler.cz (Rudolf Marek) Date: Wed, 05 Sep 2007 08:40:24 +0200 Subject: [LinuxBIOS] problems with reboot on K8 In-Reply-To: <2ea3fae10709042007p55c153l4eb526178aad54df@mail.gmail.com> References: <46D1B902.6020503@assembler.cz> <46D95675.5070009@assembler.cz> <2ea3fae10709011333i44bb38dbo606cd58fb8eb621c@mail.gmail.com> <46DDB652.60600@assembler.cz> <2ea3fae10709042007p55c153l4eb526178aad54df@mail.gmail.com> Message-ID: <46DE4F58.90800@assembler.cz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 yhlu wrote: > it seems your soft-reset never work... You mean, the soft_reset should reset the CPU too? So never return? Rudolf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG3k9Y3J9wPJqZRNURAqrGAJwONKI0DALXvHgE7Rm+10Smhg+8TQCfWMAF AIvmwNQNtMDv729JmYSaXzU= =s+SS -----END PGP SIGNATURE----- From ml at saxnet.de Wed Sep 5 09:57:20 2007 From: ml at saxnet.de (Steffen D.) Date: Wed, 05 Sep 2007 09:57:20 +0200 Subject: [LinuxBIOS] Ethernet problem with GeodeLX (db800) with running lxbios In-Reply-To: <20070904232414.18742.qmail@stuge.se> References: <46DBFFA8.3080600@saxnet.de> <46DC0D48.9050100@saxnet.de> <200709031658.34797.juergen127@kreuzholzen.de> <46DC4502.90504@saxnet.de> <46DCFA82.5090904@saxnet.de> <20070904232414.18742.qmail@stuge.se> Message-ID: <46DE6160.3050804@saxnet.de> > Do you get interrupts? > > cat /proc/interrupts I show you whats happening :) Lxbios-device: meshnode:~# iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ [ 6] local 192.168.2.52 port 5001 connected with 192.168.2.2 port 55300 r8169: eth0: link up r8169: eth0: link up r8169: eth0: link up ... and again... and again this message comes two times a second. The other side of iperf: # iperf -c 192.168.2.52 -t 100 -i 1 ------------------------------------------------------------ Client connecting to 192.168.2.52, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.2.2 port 55300 connected with 192.168.2.52 port 5001 [ 3] 0.0- 1.0 sec 24.0 KBytes 197 Kbits/sec [ 3] 1.0- 2.0 sec 16.0 KBytes 131 Kbits/sec [ 3] 2.0- 3.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 0.0- 7.4 sec 64.0 KBytes 71.3 Kbits/sec ..... -------------- # cat /proc/interrupts CPU0 0: 1009599 XT-PIC-XT timer 2: 0 XT-PIC-XT cascade 4: 845 XT-PIC-XT serial 11: 354 XT-PIC-XT ohci_hcd:usb1, ehci_hcd:usb2, eth0 14: 336 XT-PIC-XT ide0 NMI: 0 LOC: 0 ERR: 6 MIS: 0 I dont know how to read this interrups or what they say to me, sorry. Any idea? Steffen From juergen127 at kreuzholzen.de Wed Sep 5 10:07:15 2007 From: juergen127 at kreuzholzen.de (Juergen Beisert) Date: Wed, 5 Sep 2007 10:07:15 +0200 Subject: [LinuxBIOS] A question of support... (GX1/CS5530/PC97317) In-Reply-To: <59d1d9570709031919l4eb3c725l6b548ad8fdfd4bdb@mail.gmail.com> References: <59d1d9570709031919l4eb3c725l6b548ad8fdfd4bdb@mail.gmail.com> Message-ID: <200709051007.15739.juergen127@kreuzholzen.de> Hi, On Tuesday 04 September 2007 04:19, Gavin Groce wrote: > [...] > > Geode GX1 300b-85-2.0 > CS5530A-UCE (VS121AB / VSC) 2000 3.0 > Super I/O PC97317 IBW/VUL (VS0030AP) > > [...] > > I tried to put a windows OS on it but it is painfully (useless) slow > and this would make a great server as it is in a desktop component > style case (think home stereo) ... Note: The GX1 CPU only supports audio with the help of SMM (system management mode). Without it (and AFAIK LB does not support SMM code) you can't use audio reliably. Juergen From juergen127 at kreuzholzen.de Wed Sep 5 10:15:52 2007 From: juergen127 at kreuzholzen.de (Juergen Beisert) Date: Wed, 5 Sep 2007 10:15:52 +0200 Subject: [LinuxBIOS] A question of support... (GX1/CS5530/PC97317) In-Reply-To: <59d1d9570709031937p43bfef7qebcfd9b23e128c0f@mail.gmail.com> References: <59d1d9570709031919l4eb3c725l6b548ad8fdfd4bdb@mail.gmail.com> <59d1d9570709031937p43bfef7qebcfd9b23e128c0f@mail.gmail.com> Message-ID: <200709051015.52951.juergen127@kreuzholzen.de> On Tuesday 04 September 2007 04:37, Gavin Groce wrote: > I think I just answered my own question... > > The box has a AT27C020... > http://www.atmel.com/dyn/resources/prod_documents/doc0570.pdf > > Which is OTP (one time programmable) :( > > And it does not look to me pin compatable with the other AMTEL > supported chips in a PLCC (i think that is the correct acro.) > package... Your device is pin compatible to all other 256kiB flash chips with PLCC32 housing. For example SST93SF020A or AM29F002 and many other can replace it. The only thing to check is, if your board can program this device in place (means if the developer routed the WE# signal to the device). Otherwise you need an external flash programmer. Juergen From st at iss.tu-darmstadt.de Wed Sep 5 15:20:08 2007 From: st at iss.tu-darmstadt.de (ST) Date: Wed, 5 Sep 2007 15:20:08 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <20070830120920.GB10696@localdomain> References: <20070829202148.24398.qmail@stuge.se> <46D6AB93.9080607@stockwith.co.uk> <20070830120920.GB10696@localdomain> Message-ID: <200709051520.08757.st@iss.tu-darmstadt.de> Hi > > Is the modification now wrong? > ST, can you chime in here? Mh, i don't know anything about SPI, but i think if they also have #init pins it should work. Just my 2ct ST From rminnich at gmail.com Wed Sep 5 16:31:45 2007 From: rminnich at gmail.com (ron minnich) Date: Wed, 5 Sep 2007 07:31:45 -0700 Subject: [LinuxBIOS] PATCH: clean up some type errors and a real bug fix Message-ID: <13426df10709050731t7b717bf6te52fc0fd7c38f259@mail.gmail.com> attached. ron -------------- next part -------------- A non-text attachment was scrubbed... Name: typecleanup.diff Type: text/x-patch Size: 2448 bytes Desc: not available URL: From stepan at coresystems.de Wed Sep 5 17:11:57 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 5 Sep 2007 17:11:57 +0200 Subject: [LinuxBIOS] PATCH: clean up some type errors and a real bug fix In-Reply-To: <13426df10709050731t7b717bf6te52fc0fd7c38f259@mail.gmail.com> References: <13426df10709050731t7b717bf6te52fc0fd7c38f259@mail.gmail.com> Message-ID: <20070905151157.GC31827@coresystems.de> * ron minnich [070905 16:31]: > attached. > > ron > These are type cleanups and a genuine bug fix. > Signed-off-by: Ronald G. Minnich Acked-by: Stefan Reinauer -- 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 tsylla at gmail.com Wed Sep 5 17:16:27 2007 From: tsylla at gmail.com (Tom Sylla) Date: Wed, 5 Sep 2007 11:16:27 -0400 Subject: [LinuxBIOS] PCIe switch Message-ID: <57947bf80709050816k5beb77fal2b3c215bdcd0ab54@mail.gmail.com> I have a platform with a PCIe switch (turns one x8 into four x1s) connected to an HT2100. Do I need to add the description of the four resulting PCI busses to Config.lb for my platform? Is that true for PCI bridges in general? Tom From svn at openbios.org Wed Sep 5 17:17:20 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 5 Sep 2007 17:17:20 +0200 Subject: [LinuxBIOS] r494 - in LinuxBIOSv3: arch/x86 device lib util/lar Message-ID: Author: rminnich Date: 2007-09-05 17:17:20 +0200 (Wed, 05 Sep 2007) New Revision: 494 Modified: LinuxBIOSv3/arch/x86/stage1.c LinuxBIOSv3/device/pci_device.c LinuxBIOSv3/lib/lar.c LinuxBIOSv3/util/lar/stream.c Log: These are type cleanups and a genuine bug fix. Signed-off-by: Ronald G. Minnich Acked-by: Stefan Reinauer Modified: LinuxBIOSv3/arch/x86/stage1.c =================================================================== --- LinuxBIOSv3/arch/x86/stage1.c 2007-09-05 02:10:45 UTC (rev 493) +++ LinuxBIOSv3/arch/x86/stage1.c 2007-09-05 15:17:20 UTC (rev 494) @@ -56,14 +56,13 @@ int legacy(struct mem_file *archive, char *name, void *where, struct lb_memory *mem) { int ret; - struct mem_file result; int elfboot_mem(struct lb_memory *mem, void *where, int size); ret = copy_file(archive, name, where); if (ret) { printk(BIOS_ERR, "'%s' found, but could not load it.\n", name); } - ret = elfboot_mem(mem, where, result.reallen); + ret = elfboot_mem(mem, where, archive->reallen); printk(BIOS_ERR, "elfboot_mem returns %d\n", ret); return -1; Modified: LinuxBIOSv3/device/pci_device.c =================================================================== --- LinuxBIOSv3/device/pci_device.c 2007-09-05 02:10:45 UTC (rev 493) +++ LinuxBIOSv3/device/pci_device.c 2007-09-05 15:17:20 UTC (rev 494) @@ -661,7 +661,7 @@ ram = pci_rom_load(dev, rom); if (ram == NULL) return; - run_bios(dev, ram); + run_bios(dev, (unsigned long)ram); #endif } Modified: LinuxBIOSv3/lib/lar.c =================================================================== --- LinuxBIOSv3/lib/lar.c 2007-09-05 02:10:45 UTC (rev 493) +++ LinuxBIOSv3/lib/lar.c 2007-09-05 15:17:20 UTC (rev 494) @@ -107,8 +107,8 @@ result->len = ntohl(header->len); result->reallen = ntohl(header->reallen); result->compression = ntohl(header->compression); - result->entry = (void *)ntohl(header->entry); - result->loadaddress = (void *)ntohl(header->loadaddress); + result->entry = (void *)ntohl((u32)header->entry); + result->loadaddress = (void *)ntohl((u32)header->loadaddress); printk(BIOS_SPEW, "start %p len %d reallen %d compression %x entry %p loadaddress %p\n", result->start, result->len, result->reallen, Modified: LinuxBIOSv3/util/lar/stream.c =================================================================== --- LinuxBIOSv3/util/lar/stream.c 2007-09-05 02:10:45 UTC (rev 493) +++ LinuxBIOSv3/util/lar/stream.c 2007-09-05 15:17:20 UTC (rev 494) @@ -79,7 +79,7 @@ u32 entry; int i; int size; - unsigned char *header; + char *header; char ename[64]; int headers; char *temp; @@ -101,7 +101,7 @@ /* validate elf header */ ehdr = (Elf32_Ehdr *)filebuf; headers = ehdr->e_phnum; - header = (unsigned char *)ehdr; + header = (char *)ehdr; if (verbose()) fprintf(stderr, "Type %d machine %d version %d entry %p phoff %d shoff %d flags %#x hsize %d phentsize %d phnum %d s_hentsize %d s_shnum %d \n", ehdr->e_type, From rminnich at gmail.com Wed Sep 5 17:20:08 2007 From: rminnich at gmail.com (ron minnich) Date: Wed, 5 Sep 2007 08:20:08 -0700 Subject: [LinuxBIOS] PCIe switch In-Reply-To: <57947bf80709050816k5beb77fal2b3c215bdcd0ab54@mail.gmail.com> References: <57947bf80709050816k5beb77fal2b3c215bdcd0ab54@mail.gmail.com> Message-ID: <13426df10709050820r140cd1fbic6687443153e2c1f@mail.gmail.com> On 9/5/07, Tom Sylla wrote: > I have a platform with a PCIe switch (turns one x8 into four x1s) > connected to an HT2100. Do I need to add the description of the four > resulting PCI busses to Config.lb for my platform? Is that true for > PCI bridges in general? Well, if you don't get an answer I will take a look. this is a first for me too. ron From rminnich at gmail.com Wed Sep 5 17:43:08 2007 From: rminnich at gmail.com (ron minnich) Date: Wed, 5 Sep 2007 08:43:08 -0700 Subject: [LinuxBIOS] interesting article Message-ID: <13426df10709050843v58607f57l96eb9e30946074dc@mail.gmail.com> I wonder if this would help us figure out how to do XIP in the LAR? http://www.johanforrer.net/BLACKFIN/index.html ron From alex at rtfs.hu Wed Sep 5 18:07:54 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Wed, 05 Sep 2007 18:07:54 +0200 Subject: [LinuxBIOS] [PATCH] LAR compression in xip not supported In-Reply-To: <13426df10709042019g60216b55r5f103ca348663cdb@mail.gmail.com> References: <1188904793.17055.5.camel@localhost> <13426df10709042019g60216b55r5f103ca348663cdb@mail.gmail.com> Message-ID: <1189008475.17055.96.camel@localhost> Hi, On Tue, 2007-09-04 at 20:19 -0700, ron minnich wrote: > On 9/4/07, Alex Beregszaszi wrote: > > Hi, > > > > attached patch returns if someone tries to execute in place a compressed > > entry. > > > > This is a must never happen. If the lar tool ever creates this, it has > seriously screwed up. We need to make sure the lar tool can not set > both compression and XIP. LAR doesn't has a field for telling that an entry will be XIP or not. Whether we run it in place or move it is only our _runtime_ decision, thus this check is needed. If you mean that the LAR tool should check for mandatory names (like initram) which can't be compressed, well, that is handled in the makefiles (see nocompress:normal/initram). I think such an extra check wouldn't hurt (maybe if you care about space, you could merge some checks to print only one message). -- Alex From alex at rtfs.hu Wed Sep 5 18:09:40 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Wed, 05 Sep 2007 18:09:40 +0200 Subject: [LinuxBIOS] [RFC] ADLO2 In-Reply-To: <13426df10709042123h60e235d6sf47855ef4774a26f@mail.gmail.com> References: <1188947195.17055.59.camel@localhost> <1188947538.17055.64.camel@localhost> <13426df10709042123h60e235d6sf47855ef4774a26f@mail.gmail.com> Message-ID: <1189008580.17055.99.camel@localhost> Hi, On Tue, 2007-09-04 at 21:23 -0700, ron minnich wrote: > can someone with an XP license try to recreate Alex's fine work? The > more people we get to try this, the better! You can try this with a standard GRUB, any Linux / BSD installation, or the better: with FreeDOS. -- Alex From alex at rtfs.hu Wed Sep 5 18:12:17 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Wed, 05 Sep 2007 18:12:17 +0200 Subject: [LinuxBIOS] [PATCH] pci_rom.c checksum extension rom In-Reply-To: <20070905022911.GA31013@coresystems.de> References: <1188904675.17055.2.camel@localhost> <20070905022911.GA31013@coresystems.de> Message-ID: <1189008737.17055.103.camel@localhost> Hi, On Wed, 2007-09-05 at 04:29 +0200, Stefan Reinauer wrote: > * Alex Beregszaszi [070904 13:17]: > > Hi, > > > > the attached patch adds code to checksum the pci extension rom and stop > > if the stored and calculated checksum differ. > > Is this checksum reliably correct? I am hesitating to add new > restrictions that might break otherwise working cards. This algorithm is used in vgabios to set the checksum, and bochsbios to check the option roms. If you think this makes too much restrictions, you might make this only a warning and not a fail condition. Or defined under a PARANOID_SECURITY option :) -- Alex Beregszaszi From alex at rtfs.hu Wed Sep 5 18:16:50 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Wed, 05 Sep 2007 18:16:50 +0200 Subject: [LinuxBIOS] [PATCH] Support other than 0xC000 ROMs in VM86 In-Reply-To: <20070905014527.GB10233@coresystems.de> References: <1188925040.17055.40.camel@localhost> <20070905014527.GB10233@coresystems.de> Message-ID: <1189009010.17055.107.camel@localhost> On Wed, 2007-09-05 at 03:45 +0200, Stefan Reinauer wrote: > > Also it changes the function to inline assembly and passes the arguments > > through that. > > > > This patch includes the changes from my previous patch "[PATCH] vgabios: > > use same interface for biosemu.c and vm86.c", but should be committed > > incrementally. > > Can you please rediff against the current svn and send this patch again? Sure, attached. -- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: vm86-varaddr.diff Type: text/x-patch Size: 4979 bytes Desc: not available URL: From stepan at coresystems.de Wed Sep 5 19:11:04 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 5 Sep 2007 19:11:04 +0200 Subject: [LinuxBIOS] PCIe switch In-Reply-To: <57947bf80709050816k5beb77fal2b3c215bdcd0ab54@mail.gmail.com> References: <57947bf80709050816k5beb77fal2b3c215bdcd0ab54@mail.gmail.com> Message-ID: <20070905171104.GB2096@coresystems.de> * Tom Sylla [070905 17:16]: > I have a platform with a PCIe switch (turns one x8 into four x1s) > connected to an HT2100. Do I need to add the description of the four > resulting PCI busses to Config.lb for my platform? Is that true for > PCI bridges in general? If the PCIe bridge is a PCI device itself, it should be sufficient to mention the PCIe "driver" using the "driver" keyword in Config.lb to get the device specific code executed for each device found in the system. You _might_ have to mention the bridge in some cases, like when there are undetectable devices behind the bridge. Most Config.lb files in LinuxBIOSv2 are quite over specified in this matter. 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 rminnich at gmail.com Wed Sep 5 19:21:53 2007 From: rminnich at gmail.com (ron minnich) Date: Wed, 5 Sep 2007 10:21:53 -0700 Subject: [LinuxBIOS] [PATCH] LAR compression in xip not supported In-Reply-To: <1189008475.17055.96.camel@localhost> References: <1188904793.17055.5.camel@localhost> <13426df10709042019g60216b55r5f103ca348663cdb@mail.gmail.com> <1189008475.17055.96.camel@localhost> Message-ID: <13426df10709051021n38b50c68wfaf471b31531cbaf@mail.gmail.com> On 9/5/07, Alex Beregszaszi wrote: > LAR doesn't has a field for telling that an entry will be XIP or not. > Whether we run it in place or move it is only our _runtime_ decision, > thus this check is needed. > So here is a good point. Why not adopt the existing convention that a load address of 0xffffffff means "XIP"? > I think such an extra check wouldn't hurt (maybe if you care about > space, you could merge some checks to print only one message). We should do all possible checks at LAR time. Any runtime check that fails means we had a failure in how we built the lar. ron From marc.jones at amd.com Wed Sep 5 19:26:19 2007 From: marc.jones at amd.com (Marc Jones) Date: Wed, 05 Sep 2007 11:26:19 -0600 Subject: [LinuxBIOS] [PATCH] LAR compression in xip not supported In-Reply-To: <13426df10709051021n38b50c68wfaf471b31531cbaf@mail.gmail.com> References: <1188904793.17055.5.camel@localhost> <13426df10709042019g60216b55r5f103ca348663cdb@mail.gmail.com> <1189008475.17055.96.camel@localhost> <13426df10709051021n38b50c68wfaf471b31531cbaf@mail.gmail.com> Message-ID: <46DEE6BB.9050306@amd.com> ron minnich wrote: > So here is a good point. Why not adopt the existing convention that a > load address of 0xffffffff means "XIP"? > Yes agreed, That is how I did it in my testing. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From peter at stuge.se Wed Sep 5 19:53:35 2007 From: peter at stuge.se (Peter Stuge) Date: Wed, 5 Sep 2007 19:53:35 +0200 Subject: [LinuxBIOS] A question of support... (GX1/CS5530/PC97317) In-Reply-To: <200709051007.15739.juergen127@kreuzholzen.de> References: <59d1d9570709031919l4eb3c725l6b548ad8fdfd4bdb@mail.gmail.com> <200709051007.15739.juergen127@kreuzholzen.de> Message-ID: <20070905175335.11097.qmail@stuge.se> On Wed, Sep 05, 2007 at 10:07:15AM +0200, Juergen Beisert wrote: > Note: The GX1 CPU only supports audio with the help of SMM (system > management mode). Without it (and AFAIK LB does not support SMM > code) you can't use audio reliably. The CS5530 companion which has the audio function is supported by at least one driver (for FreeBSD) which drives the audio hardware completely natively. No VSM needed. There was an effort to port it to Linux IIRC but I don't recall the outcome. //Peter From peter at stuge.se Wed Sep 5 19:55:59 2007 From: peter at stuge.se (Peter Stuge) Date: Wed, 5 Sep 2007 19:55:59 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <200709051520.08757.st@iss.tu-darmstadt.de> References: <20070829202148.24398.qmail@stuge.se> <46D6AB93.9080607@stockwith.co.uk> <20070830120920.GB10696@localdomain> <200709051520.08757.st@iss.tu-darmstadt.de> Message-ID: <20070905175559.11458.qmail@stuge.se> On Wed, Sep 05, 2007 at 03:20:08PM +0200, ST wrote: > > > Is the modification now wrong? > > ST, can you chime in here? > Mh, i don't know anything about SPI, but i think if they also have > #init pins it should work. They don't. The only signal we can work with is CS# which is connected directly to the super io, which means we want to be a bit careful about driving it, to be on the safe side. I'd lift the pin. At least it's in a corner. //Peter From peter at stuge.se Wed Sep 5 20:13:07 2007 From: peter at stuge.se (Peter Stuge) Date: Wed, 5 Sep 2007 20:13:07 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <20070905175559.11458.qmail@stuge.se> References: <20070829202148.24398.qmail@stuge.se> <46D6AB93.9080607@stockwith.co.uk> <20070830120920.GB10696@localdomain> <200709051520.08757.st@iss.tu-darmstadt.de> <20070905175559.11458.qmail@stuge.se> Message-ID: <20070905181307.14028.qmail@stuge.se> On Wed, Sep 05, 2007 at 07:55:59PM +0200, Peter Stuge wrote: > I'd lift the pin. What resistance is there between U5-CS# and U5-VCC ? What resistance is there between U9-CS# and U9-VCC ? Thanks. //Peter From stepan at coresystems.de Wed Sep 5 20:19:06 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 5 Sep 2007 20:19:06 +0200 Subject: [LinuxBIOS] run_bios In-Reply-To: <13426df10709042241p66e8956ev12478e43e461a82d@mail.gmail.com> References: <13426df10709042241p66e8956ev12478e43e461a82d@mail.gmail.com> Message-ID: <20070905181906.GA20170@coresystems.de> * ron minnich [070905 07:41]: > void run_bios(struct device * dev, unsigned long addr) > > unsigned long or u32? Or, really, void * and cast it in the function? void * sounds good. 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 Wed Sep 5 21:22:13 2007 From: svn at openbios.org (LinuxBIOS) Date: Wed, 05 Sep 2007 19:22:13 -0000 Subject: [LinuxBIOS] #86: filo sata boot delay patch In-Reply-To: <041.7350c29c43b0c1714ac99d5554d073a9@openbios.org> References: <041.7350c29c43b0c1714ac99d5554d073a9@openbios.org> Message-ID: <050.a0f35c115e78f3cc10ecafdb9116b266@openbios.org> #86: filo sata boot delay patch -----------------------+---------------------------------------------------- Reporter: ward | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Resolution: | Keywords: Dependencies: | Patchstatus: patch needs work -----------------------+---------------------------------------------------- Comment (by ward): A further update. Five seconds turns out not to be enough for the new 1TB hitachi drives... I hope to be able to test a longer delay, and will report back. -- Ticket URL: LinuxBIOS From linuxbios at asyring.homeip.net Wed Sep 5 23:20:05 2007 From: linuxbios at asyring.homeip.net (Alexander Syring) Date: Wed, 5 Sep 2007 23:20:05 +0200 Subject: [LinuxBIOS] [OT] Support for Dual-Core on Tyan Tomcat K8S (s2850) Message-ID: <200709052320.05829.linuxbios@asyring.homeip.net> Hi @all my question is if this mainboard supports dual-core CPUs with original or LinuxBIOS thanks Alex From echelon at free.fr Thu Sep 6 00:25:42 2007 From: echelon at free.fr (echelon at free.fr) Date: Thu, 06 Sep 2007 00:25:42 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <20070905181307.14028.qmail@stuge.se> References: <20070829202148.24398.qmail@stuge.se> <46D6AB93.9080607@stockwith.co.uk> <20070830120920.GB10696@localdomain> <200709051520.08757.st@iss.tu-darmstadt.de> <20070905175559.11458.qmail@stuge.se> <20070905181307.14028.qmail@stuge.se> Message-ID: <1189031142.46df2ce67ff34@imp.free.fr> Quoting Peter Stuge : > On Wed, Sep 05, 2007 at 07:55:59PM +0200, Peter Stuge wrote: > > I'd lift the pin. > > What resistance is there between U5-CS# and U5-VCC ? > 8 kohm > What resistance is there between U9-CS# and U9-VCC ? > infinity From myles at pel.cs.byu.edu Wed Sep 5 23:42:06 2007 From: myles at pel.cs.byu.edu (Myles Watson) Date: Wed, 5 Sep 2007 15:42:06 -0600 Subject: [LinuxBIOS] [OT] Support for Dual-Core on Tyan Tomcat K8S (s2850) Message-ID: <016801c7f005$9b09ec50$4d22040a@chimp> > Hi @all > my question is if this mainboard supports dual-core CPUs with original or > LinuxBIOS http://www.tyan.com/archive/support/html/cpu_athlon_duron_opteron.html Looks like no. Myles > thanks > Alex From ward at gnu.org Thu Sep 6 00:08:39 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 5 Sep 2007 18:08:39 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: doquilt.sh Message-ID: <20070905220839.GA23344@localdomain> Hi there, This is the first in a series of patches for buildrom to add support for the Gigabyte m57sli board. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: doquilt.sh.patch Type: text/x-diff Size: 665 bytes Desc: not available URL: From ward at gnu.org Thu Sep 6 00:12:38 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 5 Sep 2007 18:12:38 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: config/payloads/lab.conf Message-ID: <20070905221238.GA23411@localdomain> -- Ward Vandewege Free Software Foundation - Senior System Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: lab.conf.patch Type: text/x-diff Size: 610 bytes Desc: not available URL: From ward at gnu.org Thu Sep 6 00:15:32 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 5 Sep 2007 18:15:32 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: README Message-ID: <20070905221531.GA23467@localdomain> -- Ward Vandewege Free Software Foundation - Senior System Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: README.patch Type: text/x-diff Size: 565 bytes Desc: not available URL: From ward at gnu.org Thu Sep 6 00:22:24 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 5 Sep 2007 18:22:24 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: bin/mklibs.py Message-ID: <20070905222224.GB23467@localdomain> OK, so this one is a workaround. I'm not sure what the proper fix would be. I'd be grateful for comments on how to solve this in a better way. The mklibs.py script is stripping one symbol too much (__ctype_toupper) from the uclibc libc, which breaks busybox. This might be toolchain dependent - I've done my testing on Gnewsense Deltad (aka Ubuntu Dapper Drake) with GCC 4.1.0. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: mklibs.py.patch Type: text/x-diff Size: 688 bytes Desc: not available URL: From ward at gnu.org Thu Sep 6 00:33:08 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 5 Sep 2007 18:33:08 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: filo patches for m57sli Message-ID: <20070905223308.GC23467@localdomain> This adds buildrom m57sli support for the filo bootloader. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: filo-sata-spinup.patch Type: text/x-diff Size: 629 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: filo-m57sli-Config.patch Type: text/x-diff Size: 1525 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: filo.mk.patch Type: text/x-diff Size: 552 bytes Desc: not available URL: From ward at gnu.org Thu Sep 6 00:39:21 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 5 Sep 2007 18:39:21 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: LinuxBIOS payload Config.lb files Message-ID: <20070905223921.GD23467@localdomain> Two new patch files for LAB/kernel and FILO payload respectively. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: linuxbios-m57sli-filo-Config.lb.patch Type: text/x-diff Size: 4590 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: linuxbios-m57sli-kernel-and-lab-Config.lb.patch Type: text/x-diff Size: 4668 bytes Desc: not available URL: From ward at gnu.org Thu Sep 6 00:41:16 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 5 Sep 2007 18:41:16 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: no-stack-protector for building LinuxBIOS (m57sli target) Message-ID: <20070905224116.GE23467@localdomain> Add -fno-stack-protector to the GCC options. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: no-stack-protector.patch Type: text/x-diff Size: 830 bytes Desc: not available URL: From ward at gnu.org Thu Sep 6 00:44:04 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 5 Sep 2007 18:44:04 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: packages/linuxbios/m57sli-linuxbios.mk Message-ID: <20070905224404.GF23467@localdomain> -- Ward Vandewege Free Software Foundation - Senior System Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: m57sli-linuxbios.mk.patch Type: text/x-diff Size: 1811 bytes Desc: not available URL: From alex at rtfs.hu Thu Sep 6 02:50:55 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Thu, 06 Sep 2007 02:50:55 +0200 Subject: [LinuxBIOS] [PATCH] use strncmp in lar Message-ID: <1189039855.26302.2.camel@localhost> Hi, attached patch adds: 1, simple strncmp implementation in include/string.h 2, changes lib/lar.c to use strncmp for magic check. Current code depends on that the len field will never hold a value bigger than 0xffffff, which is a working assumption given current flash sizes, but my next patch might affect this. -- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: lar-strncmp.diff Type: text/x-patch Size: 504 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: strncmp.diff Type: text/x-patch Size: 765 bytes Desc: not available URL: From alex at rtfs.hu Thu Sep 6 02:59:19 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Thu, 06 Sep 2007 02:59:19 +0200 Subject: [LinuxBIOS] [PATCH] LAR verison field Message-ID: <1189040359.26302.7.camel@localhost> Hi, this adds a 32bit version field after the magic. I choose 200709061 as a starting version, where the last 1 is a counter ranging to 9, thus there can be 9 different version per day (lol). It is not going to try any backward compatibility or workaround based on version, just bail out or skip when a different version than we are running is encountered. It might be a better idea grouping len and offset fields after or before version field, and make then fixed by design, so we can do correct skipping instead the 16-byte aligned walking. Note: the "/* NOTE -- This and the user-mode lar.h are NOT IN SYNC. Be careful. */" message (which is present both in include/lar.h and utils/lar/lar.h) is not valid anymore. -- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: lar-version.diff Type: text/x-patch Size: 3267 bytes Desc: not available URL: From alex at rtfs.hu Thu Sep 6 03:23:41 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Thu, 06 Sep 2007 03:23:41 +0200 Subject: [LinuxBIOS] [PATCH] LAR checksums Message-ID: <1189041821.26302.13.camel@localhost> Hi, checksum-fix.diff fixes a checksum calculation bug in the lar utility, where it would checksum less bytes then desired. lar-check-sum.diff implements checksum checking in the runtime lar code. I implemented the check inside the filename check, thus it wont be executed on unneeded entries. As my assumption was that I cant modify the memory, the code is skipping bytes between 20-24 of the header (checksum field) to generate a correct sum. This is bad, as the numbers shall be updated at every lar structure change. This is good, as we are not writing to memory. -- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: checksum-fix.diff Type: text/x-patch Size: 449 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lar-check-sum.diff Type: text/x-patch Size: 1007 bytes Desc: not available URL: From alex at rtfs.hu Thu Sep 6 04:30:28 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Thu, 06 Sep 2007 04:30:28 +0200 Subject: [LinuxBIOS] [PATCH] LAR: linearly count segment numbers Message-ID: <1189045829.26302.20.camel@localhost> Hi, when outputting ELF segments in LAR, the utility will use the segment number from ELF as segment number in the file. This works nicely when there are no skips (e.g. not PT_LOAD segments, which are discarded). If one segment is skipped, we get a bump: normal/payload0/segment0 (27288 bytes, lzma compressed to 14506 bytes @0x64c0) normal/payload0/segment2 (211136 bytes, lzma compressed to 70905 bytes @0x9dc0) The LAR loader wont load segment2, and in this particular case, grub2-lb will only boot into rescue mode (segment0 contains it). Attached patch adds a counter for segment number in the LAR utility to solve this bug: normal/payload0/segment0 (27288 bytes, lzma compressed to 14506 bytes @0x64c0) normal/payload0/segment1 (211136 bytes, lzma compressed to 70905 bytes @0x9dc0) Also the eagle eyed can see that I merged in Uwe's multiple-payload patch into current stage1, which includes the segment support. And this means that grub2-lb without any hacks works when loaded from LAR segments. -- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: lar-linear-segments.diff Type: text/x-patch Size: 691 bytes Desc: not available URL: From jordan.crouse at amd.com Thu Sep 6 04:34:35 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 5 Sep 2007 20:34:35 -0600 Subject: [LinuxBIOS] buildrom: doquilt.sh In-Reply-To: <20070905220839.GA23344@localdomain> References: <20070905220839.GA23344@localdomain> Message-ID: <20070906023435.GA23823@cosmic.amd.com> Acked-by: Jordan Crouse On 05/09/07 18:08 -0400, Ward Vandewege wrote: > Hi there, > > This is the first in a series of patches for buildrom to add support for the > Gigabyte m57sli board. > > Thanks, > Ward. > > -- > Ward Vandewege > Free Software Foundation - Senior System Administrator > Make doquilt.sh a bit smarter about dealing with quilt patch trees. > > Signed-off-by: Ward Vandewege > Index: bin/doquilt.sh > =================================================================== > --- bin/doquilt.sh (revision 17) > +++ bin/doquilt.sh (working copy) > @@ -22,6 +22,13 @@ > exit 0 > fi > > +# Sometimes the patch order matches. In that case, we can pass the entire patch subdirectory > +# to this script as the second argument, and we'll copy it into $DIR/patches/ > +if [ -d $1 ]; then > + cp -pr $1/* $DIR/patches/ > + shift > +fi > + > while [ $# -gt 0 ]; do > echo `basename $1` >> $DIR/patches/series > cp $1 $DIR/patches > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From jordan.crouse at amd.com Thu Sep 6 04:35:46 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 5 Sep 2007 20:35:46 -0600 Subject: [LinuxBIOS] buildrom: README In-Reply-To: <20070905221531.GA23467@localdomain> References: <20070905221531.GA23467@localdomain> Message-ID: <20070906023546.GC23823@cosmic.amd.com> On 05/09/07 18:15 -0400, Ward Vandewege wrote: > -- > Ward Vandewege > Free Software Foundation - Senior System Administrator > > Fixed typo. > > Signed-off-by: Ward Vandewege Acked by: Jordan Crouse > Index: README > =================================================================== > --- README (revision 17) > +++ README (working copy) > @@ -9,7 +9,7 @@ > LinuxBIOS based systems. This system allows one to choose one of several > different payloads for a variety of platforms. The intention of buildROM > is to build everythign together with one step, rather then the 6 or 8 > -individual steps that it would hae taken previously. > +individual steps that it would have taken previously. > > Payloads > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From jordan.crouse at amd.com Thu Sep 6 04:35:24 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 5 Sep 2007 20:35:24 -0600 Subject: [LinuxBIOS] buildrom: config/payloads/lab.conf In-Reply-To: <20070905221238.GA23411@localdomain> References: <20070905221238.GA23411@localdomain> Message-ID: <20070906023524.GB23823@cosmic.amd.com> On 05/09/07 18:12 -0400, Ward Vandewege wrote: > -- > Ward Vandewege > Free Software Foundation - Senior System Administrator > > > Don't limit RAM to 119MB for LAB. Not sure why this was necessary in the first place. Ahhh - the good ol' days of OLPC - when just booting the kernel was new and magical. > Signed-off-by: Ward Vandewege Acked-by: Jordan Crouse > Index: config/payloads/lab.conf > =================================================================== > --- config/payloads/lab.conf (revision 17) > +++ config/payloads/lab.conf (working copy) > @@ -7,7 +7,7 @@ > ### Payload specific configuration > > # Specify the default command line for the image > -COMMAND_LINE=console=ttyS0,115200 mem=119m rdinit=/linuxrc > +COMMAND_LINE=console=tty0 console=ttyS0,115200 rdinit=/linuxrc > > # This is the version string printed during boot. > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From alex at rtfs.hu Thu Sep 6 04:36:55 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Thu, 06 Sep 2007 04:36:55 +0200 Subject: [LinuxBIOS] [RFC] Multiple payload support in v3 Message-ID: <1189046215.26302.26.camel@localhost> Hi, attached is the multiple payload support originally by Uwe Hermann. I am lazy to attach Uwe's Kconfig and Makefile changes, get them at: http://www.linuxbios.org/pipermail/linuxbios/2007-August/023728.html To be less obtrusive, created a run_payload function which does the logic already present. This function will be called in every iteration (normal/payload0..9 and as a last resolt normal/payload). Added pusha/popa around payload entry points. Not a big safety otoh. In no means is this mature enough for a commit. -- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: multiple-payloads.diff Type: text/x-patch Size: 3137 bytes Desc: not available URL: From jordan.crouse at amd.com Thu Sep 6 04:45:01 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 5 Sep 2007 20:45:01 -0600 Subject: [LinuxBIOS] buildrom: bin/mklibs.py In-Reply-To: <20070905222224.GB23467@localdomain> References: <20070905222224.GB23467@localdomain> Message-ID: <20070906024501.GD23823@cosmic.amd.com> On 05/09/07 18:22 -0400, Ward Vandewege wrote: > OK, so this one is a workaround. I'm not sure what the proper fix would be. > > I'd be grateful for comments on how to solve this in a better way. The > mklibs.py script is stripping one symbol too much (__ctype_toupper) from the > uclibc libc, which breaks busybox. This might be toolchain dependent - I've > done my testing on Gnewsense Deltad (aka Ubuntu Dapper Drake) with GCC 4.1.0. sigh - we've seen issues with ctype functions before, and I'm just not really clear on the best way to handle them. It seems that there is some sort of obfustication going on in the ctype.h header file that somehow filters down to pain in uclibc/busybox. This work around is as good as any - if anything, it costs us a few bytes in an extra possibly not needed function, but thats not so bad. Acked-by: Jordan Crouse > Thanks, > Ward. > > -- > Ward Vandewege > Free Software Foundation - Senior System Administrator > > This is a workaround for a bug in the mklibs.py script. > > Signed-off-by: Ward Vandewege > > Index: bin/mklibs.py > =================================================================== > --- bin/mklibs.py (revision 17) > +++ bin/mklibs.py (working copy) > @@ -472,6 +472,10 @@ > # to be the only one and including it on alpha as well > # doesn't hurt. I guess all archs can live with this. > needed_symbols.add(("sys_siglist", 1)) > +# For some reason this symbol is needed by busybox but not included in the > +# stripped libc... > +# Ward Vandewege, 2007-08-30 > +needed_symbols.add(("__ctype_toupper", 1)) > > while True: > debug(DEBUG_NORMAL, "library reduction pass", `passnr`) > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From jordan.crouse at amd.com Thu Sep 6 04:45:54 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 5 Sep 2007 20:45:54 -0600 Subject: [LinuxBIOS] buildrom: filo patches for m57sli In-Reply-To: <20070905223308.GC23467@localdomain> References: <20070905223308.GC23467@localdomain> Message-ID: <20070906024554.GE23823@cosmic.amd.com> On 05/09/07 18:33 -0400, Ward Vandewege wrote: > This adds buildrom m57sli support for the filo bootloader. > > Thanks, > Ward. > > -- > Ward Vandewege > Free Software Foundation - Senior System Administrator > > The sata spinup patch. > > Signed-off-by: Ward Vandewege Acked-by: Jordan CRouse > Index: packages/filo/patches/sata-spinup-delay.patch > =================================================================== > --- packages/filo/patches/sata-spinup-delay.patch (revision 0) > +++ packages/filo/patches/sata-spinup-delay.patch (revision 0) > @@ -0,0 +1,12 @@ > +Index: main/filo.c > +=================================================================== > +--- svn/main/filo.c (revision 34) > ++++ svn/main/filo.c (working copy) > +@@ -60,6 +60,7 @@ > + > + /* Initialize */ > + init(); > ++ delay (5); > + grub_main(); > + return 0; > + } > > The filo config file for the m57sli. > > Signed-off-by: Ward Vandewege > > Index: packages/filo/conf/m57sli-Config > =================================================================== > --- packages/filo/conf/m57sli-Config (revision 0) > +++ packages/filo/conf/m57sli-Config (revision 0) > @@ -0,0 +1,50 @@ > +# Use grub instead of autoboot? > +USE_GRUB = 1 > +# Grub menu.lst path > +MENULST_FILE = "hde1:/boot/grub/menu.lst" > +# Driver for hard disk, CompactFlash, and CD-ROM on IDE bus > +IDE_DISK = 1 > +# Add a short delay when polling status registers > +# (required on some broken SATA controllers) > +IDE_DISK_POLL_DELAY = 1 > +# Driver for USB Storage > +USB_DISK = 1 > +# VGA text console > +VGA_CONSOLE = 1 > +PC_KEYBOARD = 1 > +# Enable the serial console > +SERIAL_CONSOLE = 1 > +# Serial console; real external serial port > +SERIAL_IOBASE = 0x3f8 > +SERIAL_SPEED = 115200 > +# Filesystems > +FSYS_EXT2FS = 1 > +FSYS_ISO9660 = 1 > +# Support for boot disk image in bootable CD-ROM (El Torito) > +ELTORITO = 1 > +# PCI support > +SUPPORT_PCI = 1 > +# Enable this to scan PCI busses above bus 0 > +# AMD64 based boards do need this. > +PCI_BRUTE_SCAN = 1 > +# Loader for standard Linux kernel image, a.k.a. /vmlinuz > +LINUX_LOADER = 1 > + > +# Debugging > +#DEBUG_ALL = 1 > +#DEBUG_ELFBOOT = 1 > +#DEBUG_ELFNOTE = 1 > +#DEBUG_LINUXBIOS = 1 > +#DEBUG_MALLOC = 1 > +#DEBUG_MULTIBOOT = 1 > +#DEBUG_SEGMENT = 1 > +#DEBUG_SYS_INFO = 1 > +#DEBUG_TIMER = 1 > +#DEBUG_BLOCKDEV = 1 > +#DEBUG_PCI = 1 > +#DEBUG_VIA_SOUND = 1 > +#DEBUG_LINUXLOAD = 1 > +#DEBUG_IDE = 1 > +#DEBUG_USB = 1 > +#DEBUG_ELTORITO = 1 > + > > Add the sata spinup delay patch. > > Signed-off-by: Ward Vandewege > > Index: packages/filo/filo.mk > =================================================================== > --- packages/filo/filo.mk (revision 17) > +++ packages/filo/filo.mk (working copy) > @@ -8,6 +8,11 @@ > > FILO_PATCHES=$(PACKAGE_DIR)/filo/patches/make.patch > > +ifeq ($(CONFIG_PLATFORM_M57SLI),y) > + FILO_PATCHES += $(PACKAGE_DIR)/filo/patches/sata-spinup-delay.patch > +endif > + > + > ifeq ($(CONFIG_VERBOSE),y) > FILO_FETCH_LOG=/dev/stdout > FILO_BUILD_LOG=/dev/stdout > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From jordan.crouse at amd.com Thu Sep 6 04:46:25 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 5 Sep 2007 20:46:25 -0600 Subject: [LinuxBIOS] buildrom: LinuxBIOS payload Config.lb files In-Reply-To: <20070905223921.GD23467@localdomain> References: <20070905223921.GD23467@localdomain> Message-ID: <20070906024625.GF23823@cosmic.amd.com> Acked by: Jordan CRouse On 05/09/07 18:39 -0400, Ward Vandewege wrote: > Two new patch files for LAB/kernel and FILO payload respectively. > > Thanks, > Ward. > > -- > Ward Vandewege > Free Software Foundation - Senior System Administrator > > The LinuxBIOS Config.lb file for filo payload. > > Signed-off-by: Ward Vandewege > > Index: packages/linuxbios/patches/m57sli-filo-Config.lb.patch > =================================================================== > --- packages/linuxbios/patches/m57sli-filo-Config.lb.patch (revision 0) > +++ packages/linuxbios/patches/m57sli-filo-Config.lb.patch (revision 0) > @@ -0,0 +1,97 @@ > +Index: Config.lb > +=================================================================== > +--- LinuxBIOSv2/targets/gigabyte/m57sli/Config.lb-orig 2007-08-14 14:49:13.000000000 -0400 > ++++ LinuxBIOSv2/targets/gigabyte/m57sli/Config.lb 2007-08-21 17:56:34.000000000 -0400 > +@@ -22,83 +22,30 @@ > + target m57sli > + mainboard gigabyte/m57sli > + > +-# serengeti_leopard > + romimage "normal" > +-# 48K for SCSI FW > +-# option ROM_SIZE = 475136 > +-# 48K for SCSI FW and 48K for ATI ROM > +-# option ROM_SIZE = 425984 > +-# 64K for Etherboot > +-# option ROM_SIZE = 458752 > +-# 44k for atixx.rom > +-# option ROM_SIZE = 479232 > +- option USE_FAILOVER_IMAGE=0 > ++ option USE_FAILOVER_IMAGE=0 > + option USE_FALLBACK_IMAGE=0 > +-# option ROM_IMAGE_SIZE=0x13800 > +-# option ROM_IMAGE_SIZE=0x18800 > + option ROM_IMAGE_SIZE=0x20000 > +-# option ROM_IMAGE_SIZE=0x15800 > + option XIP_ROM_SIZE=0x40000 > + option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" > +-# payload ../../../payloads/tg3--ide_disk.zelf > +-# payload ../../../payloads/filo.elf > +-# payload ../../../payloads/filo_mem.elf > +-# payload ../../../payloads/filo.zelf > +-# payload ../../../payloads/tg3--filo_hda2.zelf > +-# payload ../../../payloads/tg3.zelf > +-# payload ../../../../payloads/tg3_vga.zelf > +-# payload ../../../../payloads/tg3--filo_hda2_vga.zelf > +-# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf > +-# payload ../../../../payloads/forcedeth--filo_hda2_vga.zelf > +- payload ../../../../payloads/forcedeth--filo_hda2_vga_5_4_2_mcp55.zelf > +-# payload ../../../payloads/tg3_com2.zelf > +-# payload ../../../payloads/e1000--filo.zelf > +-# payload ../../../payloads/tg3--e1000--filo.zelf > +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf > +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf > +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf > ++ payload ../payload.elf > + end > + > + romimage "fallback" > +- option USE_FAILOVER_IMAGE=0 > ++ option USE_FAILOVER_IMAGE=0 > + option USE_FALLBACK_IMAGE=1 > +-# option ROM_IMAGE_SIZE=0x13800 > +-# option ROM_IMAGE_SIZE=0x19800 > + option ROM_IMAGE_SIZE=0x20000 > +-# option ROM_IMAGE_SIZE=0x15800 > + option XIP_ROM_SIZE=0x40000 > + option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" > +-# payload ../../../payloads/tg3--ide_disk.zelf > +-# payload ../../../payloads/filo.elf > +-# payload ../../../payloads/filo_mem.elf > +-# payload ../../../payloads/filo.zelf > +-# payload ../../../payloads/tg3--filo_hda2.zelf > +-# payload ../../../payloads/tg3.zelf > +-# payload ../../../../payloads/tg3_vga.zelf > +-# payload ../../../../payloads/memtest > +-# payload ../../../../payloads/e1000_vga.zelf > +-# payload ../../../../payloads/tg3--filo_hda2_vga.zelf > +-# payload ../../../../payloads/filo_hda.zelf > +-# payload ../../../../payloads/adlo.elf > +-# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf > +-# payload ../../../../payloads/forcedeth_mcp55_filo_hda2.zelf > +- payload ../../../../payloads/forcedeth--filo_hda2_vga_5_4_2_mcp55.zelf > +-# payload ../../../../payloads/forcedeth--filo_hda2_vga.zelf > +-# payload ../../../payloads/tg3_com2.zelf > +-# payload ../../../payloads/e1000--filo.zelf > +-# payload ../../../payloads/tg3--e1000--filo.zelf > +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf > +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf > +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf > ++ payload ../payload.elf > + end > + > + romimage "failover" > +- option USE_FAILOVER_IMAGE=1 > +- option USE_FALLBACK_IMAGE=0 > +- option ROM_IMAGE_SIZE=FAILOVER_SIZE > +- option XIP_ROM_SIZE=FAILOVER_SIZE > +- option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Failover" > ++ option USE_FAILOVER_IMAGE=1 > ++ option USE_FALLBACK_IMAGE=0 > ++ option ROM_IMAGE_SIZE=FAILOVER_SIZE > ++ option XIP_ROM_SIZE=FAILOVER_SIZE > ++ option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Failover" > + end > + > +-#buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" > + buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" "failover" > > The LinuxBIOS Config.lb file for LAB/kernel payload. > > Signed-off-by: Ward Vandewege > > Index: packages/linuxbios/patches/m57sli-kernel-and-lab-Config.lb.patch > =================================================================== > --- packages/linuxbios/patches/m57sli-kernel-and-lab-Config.lb.patch (revision 0) > +++ packages/linuxbios/patches/m57sli-kernel-and-lab-Config.lb.patch (revision 0) > @@ -0,0 +1,101 @@ > +--- LinuxBIOSv2/targets/gigabyte/m57sli/Config.lb-orig 2007-08-14 14:49:13.000000000 -0400 > ++++ LinuxBIOSv2/targets/gigabyte/m57sli/Config.lb 2007-08-21 17:56:34.000000000 -0400 > +@@ -19,86 +19,32 @@ > + ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > + ## > + > ++# Sample config file for > ++ > + target m57sli > + mainboard gigabyte/m57sli > + > +-# serengeti_leopard > +-romimage "normal" > +-# 48K for SCSI FW > +-# option ROM_SIZE = 475136 > +-# 48K for SCSI FW and 48K for ATI ROM > +-# option ROM_SIZE = 425984 > +-# 64K for Etherboot > +-# option ROM_SIZE = 458752 > +-# 44k for atixx.rom > +-# option ROM_SIZE = 479232 > +- option USE_FAILOVER_IMAGE=0 > +- option USE_FALLBACK_IMAGE=0 > +-# option ROM_IMAGE_SIZE=0x13800 > +-# option ROM_IMAGE_SIZE=0x18800 > +- option ROM_IMAGE_SIZE=0x20000 > +-# option ROM_IMAGE_SIZE=0x15800 > +- option XIP_ROM_SIZE=0x40000 > +- option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" > +-# payload ../../../payloads/tg3--ide_disk.zelf > +-# payload ../../../payloads/filo.elf > +-# payload ../../../payloads/filo_mem.elf > +-# payload ../../../payloads/filo.zelf > +-# payload ../../../payloads/tg3--filo_hda2.zelf > +-# payload ../../../payloads/tg3.zelf > +-# payload ../../../../payloads/tg3_vga.zelf > +-# payload ../../../../payloads/tg3--filo_hda2_vga.zelf > +-# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf > +-# payload ../../../../payloads/forcedeth--filo_hda2_vga.zelf > +- payload ../../../../payloads/forcedeth--filo_hda2_vga_5_4_2_mcp55.zelf > +-# payload ../../../payloads/tg3_com2.zelf > +-# payload ../../../payloads/e1000--filo.zelf > +-# payload ../../../payloads/tg3--e1000--filo.zelf > +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf > +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf > +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf > +-end > ++option ROM_SIZE=0x100000 > ++option FALLBACK_SIZE=(ROM_SIZE-0x1000) > + > + romimage "fallback" > +- option USE_FAILOVER_IMAGE=0 > ++ option USE_FAILOVER_IMAGE=0 > + option USE_FALLBACK_IMAGE=1 > +-# option ROM_IMAGE_SIZE=0x13800 > +-# option ROM_IMAGE_SIZE=0x19800 > +- option ROM_IMAGE_SIZE=0x20000 > +-# option ROM_IMAGE_SIZE=0x15800 > ++ option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 > ++ option CONFIG_PRECOMPRESSED_PAYLOAD=1 > ++ option ROM_IMAGE_SIZE=0x17000 > + option XIP_ROM_SIZE=0x40000 > + option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" > +-# payload ../../../payloads/tg3--ide_disk.zelf > +-# payload ../../../payloads/filo.elf > +-# payload ../../../payloads/filo_mem.elf > +-# payload ../../../payloads/filo.zelf > +-# payload ../../../payloads/tg3--filo_hda2.zelf > +-# payload ../../../payloads/tg3.zelf > +-# payload ../../../../payloads/tg3_vga.zelf > +-# payload ../../../../payloads/memtest > +-# payload ../../../../payloads/e1000_vga.zelf > +-# payload ../../../../payloads/tg3--filo_hda2_vga.zelf > +-# payload ../../../../payloads/filo_hda.zelf > +-# payload ../../../../payloads/adlo.elf > +-# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf > +-# payload ../../../../payloads/forcedeth_mcp55_filo_hda2.zelf > +- payload ../../../../payloads/forcedeth--filo_hda2_vga_5_4_2_mcp55.zelf > +-# payload ../../../../payloads/forcedeth--filo_hda2_vga.zelf > +-# payload ../../../payloads/tg3_com2.zelf > +-# payload ../../../payloads/e1000--filo.zelf > +-# payload ../../../payloads/tg3--e1000--filo.zelf > +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf > +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf > +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf > ++ payload ../payload.elf > + end > + > + romimage "failover" > +- option USE_FAILOVER_IMAGE=1 > ++ option USE_FAILOVER_IMAGE=1 > + option USE_FALLBACK_IMAGE=0 > + option ROM_IMAGE_SIZE=FAILOVER_SIZE > + option XIP_ROM_SIZE=FAILOVER_SIZE > + option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Failover" > + end > + > +-#buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" > +-buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" "failover" > ++ > ++buildrom ./linuxbios.rom ROM_SIZE "fallback" "failover" > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From jordan.crouse at amd.com Thu Sep 6 04:50:24 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 5 Sep 2007 20:50:24 -0600 Subject: [LinuxBIOS] buildrom: packages/linuxbios/m57sli-linuxbios.mk In-Reply-To: <20070905224404.GF23467@localdomain> References: <20070905224404.GF23467@localdomain> Message-ID: <20070906025024.GH23823@cosmic.amd.com> On 05/09/07 18:44 -0400, Ward Vandewege wrote: > > > -- > Ward Vandewege > Free Software Foundation - Senior System Administrator > > Add the makefile for the m57sli LinuxBIOS build. > > Signed-off-by: Ward Vandewege Acked-by: Jordan Crouse > Index: packages/linuxbios/m57sli-linuxbios.mk > =================================================================== > --- packages/linuxbios/m57sli-linuxbios.mk (revision 0) > +++ packages/linuxbios/m57sli-linuxbios.mk (revision 0) > @@ -0,0 +1,44 @@ > +# This is the Generic LinuxBIOS target > + > +ifeq ($(CONFIG_PLATFORM),y) > +ifeq ($(LINUXBIOS_TAG),) > +$(error You need to specify a version to pull in your platform config) > +endif > +endif > + > +LINUXBIOS_PATCHES = $(PACKAGE_DIR)/linuxbios/patches/no-stack-protector.patch > + > +ifeq ($(CONFIG_PAYLOAD_FILO),y) > + LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/m57sli-filo-Config.lb.patch > +endif > + > +ifeq ($(CONFIG_PAYLOAD_KERNEL),y) > + LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/m57sli-kernel-and-lab-Config.lb.patch > +endif > + > +ifeq ($(CONFIG_PAYLOAD_LAB),y) > + LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/m57sli-kernel-and-lab-Config.lb.patch > +endif > + > + > +LINUXBIOS_BASE_DIR=svn > +LINUXBIOS_URL=svn://openbios.org/repos/trunk/LinuxBIOSv2 > +LINUXBIOS_TARBALL=linuxbios-svn-$(LINUXBIOS_TAG).tar.gz > +LINUXBIOS_PAYLOAD_TARGET=$(LINUXBIOS_BUILD_DIR)/payload.elf > +TARGET_ROM = $(LINUXBIOS_VENDOR)-$(LINUXBIOS_BOARD).rom > + > +include $(PACKAGE_DIR)/linuxbios/linuxbios.inc > + > +$(SOURCE_DIR)/$(LINUXBIOS_TARBALL): > + @ echo "Fetching the LinuxBIOS code..." > + @ mkdir -p $(SOURCE_DIR)/linuxbios > + @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \ > + $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ > + > $(LINUXBIOS_FETCH_LOG) 2>&1 > + > +$(OUTPUT_DIR)/$(TARGET_ROM): $(LINUXBIOS_OUTPUT) > + @ cat $(LINUXBIOS_OUTPUT) > $@ > + > +linuxbios: $(OUTPUT_DIR)/$(TARGET_ROM) > +linuxbios-clean: generic-linuxbios-clean > +linuxbios-distclean: generic-linuxbios-distclean > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From jordan.crouse at amd.com Thu Sep 6 04:50:00 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 5 Sep 2007 20:50:00 -0600 Subject: [LinuxBIOS] buildrom: no-stack-protector for building LinuxBIOS (m57sli target) In-Reply-To: <20070905224116.GE23467@localdomain> References: <20070905224116.GE23467@localdomain> Message-ID: <20070906025000.GG23823@cosmic.amd.com> Hmmm - buildrom should have already been taking care of this. In script/build.settings, we do the kernel trick for trying -fno-stack-protector and set STACKPROTECT if it doesn't make it through, and that gets passed through to CPU_OPT in linuxbios.inc. I guess maybe I need to overload a different variable? Jordan On 05/09/07 18:41 -0400, Ward Vandewege wrote: > Add -fno-stack-protector to the GCC options. > > Thanks, > Ward. > > -- > Ward Vandewege > Free Software Foundation - Senior System Administrator > > Modern distros seem to need this. > > Signed-off-by: Ward Vandewege > > Index: packages/linuxbios/patches/no-stack-protector.patch > =================================================================== > --- packages/linuxbios/patches/no-stack-protector.patch (revision 0) > +++ packages/linuxbios/patches/no-stack-protector.patch (revision 0) > @@ -0,0 +1,13 @@ > +Index: src/mainboard/gigabyte/m57sli/Options.lb > +=================================================================== > +--- LinuxBIOSv2.orig/src/mainboard/gigabyte/m57sli/Options.lb (revision 2742) > ++++ LinuxBIOSv2/src/mainboard/gigabyte/m57sli/Options.lb (working copy) > +@@ -297,7 +297,7 @@ > + ## > + ## The default compiler > + ## > +-default CC="$(CROSS_COMPILE)gcc -m32" > ++default CC="$(CROSS_COMPILE)gcc -m32 -fno-stack-protector" > + default HOSTCC="gcc" > + > + ## > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From ward at gnu.org Thu Sep 6 05:18:10 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 5 Sep 2007 23:18:10 -0400 Subject: [LinuxBIOS] buildrom: no-stack-protector for building LinuxBIOS (m57sli target) In-Reply-To: <20070906025000.GG23823@cosmic.amd.com> References: <20070905224116.GE23467@localdomain> <20070906025000.GG23823@cosmic.amd.com> Message-ID: <20070906031810.GA26150@localdomain> On Wed, Sep 05, 2007 at 08:50:00PM -0600, Jordan Crouse wrote: > Hmmm - buildrom should have already been taking care of this. In > script/build.settings, we do the kernel trick for trying -fno-stack-protector > and set STACKPROTECT if it doesn't make it through, and that gets passed > through to CPU_OPT in linuxbios.inc. I guess maybe I need to overload a > different variable? Very strange, I just removed the -fno-stack-protector patch and it still works, the CPU_OPT code is being passed through properly. But I definitely ran into this a few weeks ago when I started working on buildrom. I'm not sure what happened here; maybe I was working against an old version of the code. So; please disregard this patch. I still have 3 final patches pending for this changeset; I'm trying to clarify the licensing situation of the linux-tiny patches (http://elinux.org/Linux_Tiny) before I post them to this list. Thanks, Jordan! Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From ward at gnu.org Thu Sep 6 05:38:48 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 5 Sep 2007 23:38:48 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: packages/linuxbios/m57sli-linuxbios.mk (revised) Message-ID: <20070906033848.GB26150@localdomain> Removed the reference to the no-stack-protector patch. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: m57sli-linuxbios.mk.patch Type: text/x-diff Size: 1753 bytes Desc: not available URL: From joe at smittys.pointclark.net Thu Sep 6 06:39:26 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Thu, 06 Sep 2007 00:39:26 -0400 Subject: [LinuxBIOS] RCA RM4100 almost running - help In-Reply-To: <20070904052140.1kiwmfm0co40wkc4@www.smittys.pointclark.net> References: <20070904003300.jtpivs51c0www4g8@www.smittys.pointclark.net> <46DCE517.4010806@gmail.com> <20070904014027.mumag6jjvowos88c@www.smittys.pointclark.net> <46DD0DA7.7020706@gmail.com> <20070904052140.1kiwmfm0co40wkc4@www.smittys.pointclark.net> Message-ID: <20070906003926.en0tu9e4roswksws@www.smittys.pointclark.net> >> >> No, this means that your ram isn't being initialized correctly >> somewhere. Start by checking that your northbridge timing registers are >> set correctly, drbs set correctly, etc. As long as the init itself >> follows the same procedure as the 440bx and 810, that should be correct. >> Comparing lspci -xxx -s 0:0.0 and dump_dev(0) (from debug.c) might also >> provide some help. >> >> -Corey >> I think I figured it out. It was the GCC1-?GMCH Control Register #1. This is the register where you indicate the memory pre-allocated for the frame buffer for IGD (Internel Graphics Display). Plus, this is a 16 bit register and the upper 15:7 bits are reserved. The memory space LinuxBIOS gets copied to must have been conflicting with this?? I will have to set it up so it just sets the lower 6:0 bits. Anyways, I am now so close I can taste it:-) Thanks - Joe From ward at gnu.org Thu Sep 6 16:24:43 2007 From: ward at gnu.org (Ward Vandewege) Date: Thu, 6 Sep 2007 10:24:43 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: add packages/kernel/patches/tiny_m57sli Message-ID: <20070906142443.GC29891@localdomain> These patches are released under the GPLv2, so we can just include them in our buildrom tree. Do we need a license header for each file? -- Ward Vandewege Free Software Foundation - Senior System Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: 2.6.22.2.tiny.patch.gz Type: application/octet-stream Size: 177656 bytes Desc: not available URL: From ward at gnu.org Thu Sep 6 16:25:07 2007 From: ward at gnu.org (Ward Vandewege) Date: Thu, 6 Sep 2007 10:25:07 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: m57sli linux kernel config + makefile Message-ID: <20070906142507.GD29891@localdomain> This adds the stripped down linux kernel config and the makefile necessary to build it. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: defconfig-m57sli.patch Type: text/x-diff Size: 29023 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: m57sli-kernel.mk.patch Type: text/x-diff Size: 927 bytes Desc: not available URL: From ward at gnu.org Thu Sep 6 16:25:19 2007 From: ward at gnu.org (Ward Vandewege) Date: Thu, 6 Sep 2007 10:25:19 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: initramfs skeleton Message-ID: <20070906142519.GE29891@localdomain> Update the initramfs skeleton to be less olpc specific. This skeleton needs more generalization, but that's for later. -- Ward Vandewege Free Software Foundation - Senior System Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: skeleton.patch Type: text/x-diff Size: 4338 bytes Desc: not available URL: From alex at rtfs.hu Thu Sep 6 17:53:56 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Thu, 06 Sep 2007 17:53:56 +0200 Subject: [LinuxBIOS] [PATCH] [V3] LAR: merge common parts of copy/run_file Message-ID: <1189094037.26302.37.camel@localhost> Hi, attached patch creates a file-local process_file() function which has the common pats of copy_file and run_file. -- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: lar-merge-copyrun.diff Type: text/x-patch Size: 3082 bytes Desc: not available URL: From joe at smittys.pointclark.net Thu Sep 6 21:31:54 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Thu, 06 Sep 2007 15:31:54 -0400 Subject: [LinuxBIOS] RCA RM4100 almost running - help In-Reply-To: <20070906003926.en0tu9e4roswksws@www.smittys.pointclark.net> References: <20070904003300.jtpivs51c0www4g8@www.smittys.pointclark.net> <46DCE517.4010806@gmail.com> <20070904014027.mumag6jjvowos88c@www.smittys.pointclark.net> <46DD0DA7.7020706@gmail.com> <20070904052140.1kiwmfm0co40wkc4@www.smittys.pointclark.net> <20070906003926.en0tu9e4roswksws@www.smittys.pointclark.net> Message-ID: <20070906153154.ugapwqblnowk00kk@www.smittys.pointclark.net> i82830 Northbridge i82801db Southbridge (using i82801XX) SMSC lpc47m192 Superio (using smscsuperio) OK, I got the GCC1 register problem resolved, and I thought it was going to boot but now I hit another snag. It just freezes at this point, any ideas?? I have attach my bootlog so you can see all the messages (only 27k). ------------------------ Done setting resources. Done allocating resources. Enabling resources... PCI: 00:00.0 cmd <- 146 PCI: 00:1d.0 cmd <- 141 PCI: 00:1d.1 cmd <- 141 PCI: 00:1d.2 cmd <- 141 PCI: 00:1d.7 cmd <- 142 PCI: 00:1e.0 bridge ctrl <- 0003 PCI: 00:1e.0 cmd <- 141 ------------------------ Help? Thanks - Joe -------------- next part -------------- LinuxBIOS-2.0.0.0Fallback Thu Sep 6 14:53:32 EDT 2007 starting... Setting initial registers.... Initial registers have been set. No DIMM found in slot 00 DRB 0x60 has been set to 0x00 DRB1 0x61 has been set to 0x00 Found DIMM in slot 01 DIMM is 0x0080 on side 1 DIMM is 0x0000 on side 2 DRB2 0x62 has been set to 0x04 DRB3 0x63 has been set to 0x04 No DIMM found in slot 00, setting DRA to 0xFF DRA 0x70 has been set to 0xff Found DIMM in slot 01, setting DRA... DRA 0x71 has been set to 0xf1 RAM Enable 1: Apply NOP Sending RAM command 0x00000010 to 0x00000000 RAM Enable 2: Precharge all Sending RAM command 0x00000020 to 0x00000000 RAM Enable 3: CBR Sending RAM command 0x00000060 to 0x00000000 RAM Enable 4: Mode register set Sending RAM command 0x00000030 to 0x000001d0 RAM Enable 5: Normal operation Sending RAM command 0x20000170 to 0x00000000 Northbridge following SDRAM init: PCI: 00:00.00 00: 86 80 75 35 06 00 10 00 04 00 00 06 00 00 00 00 10: 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 40: 09 00 05 01 00 00 00 00 00 00 00 00 02 28 00 0e 50: 72 a0 20 00 00 00 00 00 00 30 33 33 33 33 33 33 60: 00 00 04 04 00 00 00 00 00 00 00 00 00 00 00 00 70: ff f1 ff ff 00 00 00 00 10 00 00 00 70 01 00 20 80: 00 00 00 00 00 00 00 00 00 d0 00 40 00 00 00 00 90: 02 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 02 00 20 00 17 02 00 1f 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 54 0e 41 a2 99 01 00 c0 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 09 c9 9f fc f0: 11 11 01 00 00 00 0b 05 34 d6 30 cf 22 cf 23 cf Testing DRAM : 00000000-000a0000 DRAM fill: 00000000-000a0000 00000000 00010000 00020000 00030000 00040000 00050000 00060000 00070000 00080000 00090000 000a0000 DRAM filled DRAM verify: 00000000-000a0000 00000000 00010000 00020000 00030000 00040000 00050000 00060000 00070000 00080000 00090000 000a0000 DRAM range verified. Done. Copying LinuxBIOS to RAM. Jumping to LinuxBIOS. LinuxBIOS-2.0.0.0Fallback Thu Sep 6 14:53:32 EDT 2007 booting... end 6f9c817f, start 0 32-bit delta 1566 calibrate_tsc 32-bit result is 1566 clocks_per_usec: 1566 Enumerating buses... scan_static_bus for Root Device Finding PCI configuration type. PCI: Using configuration type 1 PCI_DOMAIN: 0000 enabled PCI_DOMAIN: 0000 scanning... PCI: pci_scan_bus for bus 00 PCI: 00:00.0 [8086/3575] ops PCI: 00:00.0 [8086/3575] enabled PCI: devfn 0x9, bad id 0xffffffff PCI: devfn 0xa, bad id 0xffffffff PCI: devfn 0xb, bad id 0xffffffff PCI: devfn 0xc, bad id 0xffffffff PCI: devfn 0xd, bad id 0xffffffff PCI: devfn 0xe, bad id 0xffffffff PCI: devfn 0xf, bad id 0xffffffff PCI: 00:02.0 [8086/3577] disabled PCI: devfn 0x11, bad id 0xffffffff PCI: devfn 0x12, bad id 0xffffffff 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 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: 00:1d.0 [8086/24c2] ops PCI: 00:1d.0 [8086/24c2] enabled PCI: 00:1d.1 [8086/24c4] ops PCI: 00:1d.1 [8086/24c4] enabled PCI: 00:1d.2 [8086/24c7] ops PCI: 00:1d.2 [8086/24c7] enabled PCI: devfn 0xeb, bad id 0xffffffff PCI: devfn 0xec, bad id 0xffffffff PCI: devfn 0xed, bad id 0xffffffff PCI: devfn 0xee, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0001a000 malloc 0x0001a000 PCI: 00:1d.7 [8086/24cd] ops PCI: 00:1d.7 [8086/24cd] enabled PCI: 00:1e.0 [8086/244e] bus ops PCI: 00:1e.0 [8086/244e] enabled PCI: 00:1f.0 [8086/24c0] bus ops PCI: 00:1f.0 [8086/24c0] enabled PCI: 00:1f.1 [8086/24cb] ops PCI: 00:1f.1 [8086/24cb] enabled PCI: devfn 0xfa, bad id 0xffffffff PCI: 00:1f.3 [8086/24c3] enabled PCI: devfn 0xfc, bad id 0xffffffff PCI: 00:1f.5 [8086/24c5] ops PCI: 00:1f.5 [8086/24c5] enabled PCI: 00:1f.6 [8086/24c6] ops PCI: 00:1f.6 [8086/24c6] enabled PCI: devfn 0xff, bad id 0xffffffff do_pci_scan_bridge for PCI: 00:1e.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 Disabling static device: PCI: 01:08.0 PCI: devfn 0x41, bad id 0xffffffff PCI: devfn 0x42, bad id 0xffffffff PCI: devfn 0x43, bad id 0xffffffff PCI: devfn 0x44, bad id 0xffffffff PCI: devfn 0x45, bad id 0xffffffff PCI: devfn 0x46, bad id 0xffffffff PCI: devfn 0x47, 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 scan_static_bus for PCI: 00:1f.0 Found SMSC Super I/O (ID=0x60, rev=0x01) PNP: 002e.0 disabled PNP: 002e.3 disabled PNP: 002e.4 enabled PNP: 002e.5 disabled PNP: 002e.7 enabled PNP: 002e.9 disabled PNP: 002e.a disabled PNP: 002e.b disabled scan_static_bus for PCI: 00:1f.0 done PCI: pci_scan_bus returning with max=001 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:00.0 register 10(00000008), read-only ignoring it PCI: 00:1e.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 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: 0000f000 size: 00000000 align: 12 gran: 12 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 link: 0 done PCI: 00:1e.0 compute_allocate_io: base: 0000f000 size: 00000000 align: 12 gran: 12 done PCI: 00:1e.0 1c <- [0x000000f000 - 0x000000efff] bus 01 io PCI: 00:1e.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 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: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 link: 0 done PCI: 00:1e.0 compute_allocate_prefmem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1e.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 01 prefmem PCI: 00:1e.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 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 1 link: 0 PCI: 00:1e.0 read_resources bus 1 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 01 mem PCI: 00:1f.0 read_resources bus 0 link: 0 PCI: 00:1f.0 read_resources bus 0 link: 0 done PCI: 00:1f.5 register 10(00000001), read-only ignoring it PCI: 00:1f.5 register 14(00000001), 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:1f.6 10 * [0x00000400 - 0x000004ff] io PCI: 00:1f.6 14 * [0x00000800 - 0x0000087f] io PCI: 00:1d.0 20 * [0x00000880 - 0x0000089f] io PCI: 00:1d.1 20 * [0x000008a0 - 0x000008bf] io PCI: 00:1d.2 20 * [0x000008c0 - 0x000008df] io PCI: 00:1f.3 20 * [0x000008e0 - 0x000008ff] io PCI: 00:1f.1 20 * [0x00000c00 - 0x00000c0f] io PCI: 00:1f.1 10 * [0x00000c10 - 0x00000c17] io PCI: 00:1f.1 18 * [0x00000c20 - 0x00000c27] io PCI: 00:1f.1 14 * [0x00000c30 - 0x00000c33] io PCI: 00:1f.1 1c * [0x00000c40 - 0x00000c43] io Root Device compute_allocate_io: base: 00000c44 size: 00000844 align: 8 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:1d.7 10 * [0x00000000 - 0x000003ff] mem PCI: 00:1f.1 24 * [0x00001000 - 0x000013ff] mem PCI: 00:1f.5 18 * [0x00002000 - 0x000021ff] mem PCI: 00:1f.5 1c * [0x00003000 - 0x000030ff] mem Root Device compute_allocate_mem: base: 00003100 size: 00003100 align: 10 gran: 0 done Done reading resources. Setting resources... Root Device compute_allocate_io: base: 00001000 size: 00000844 align: 8 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:1f.6 10 * [0x00001000 - 0x000010ff] io PCI: 00:1f.6 14 * [0x00001400 - 0x0000147f] io PCI: 00:1d.0 20 * [0x00001480 - 0x0000149f] io PCI: 00:1d.1 20 * [0x000014a0 - 0x000014bf] io PCI: 00:1d.2 20 * [0x000014c0 - 0x000014df] io PCI: 00:1f.3 20 * [0x000014e0 - 0x000014ff] io PCI: 00:1f.1 20 * [0x00001800 - 0x0000180f] io PCI: 00:1f.1 10 * [0x00001810 - 0x00001817] io PCI: 00:1f.1 18 * [0x00001820 - 0x00001827] io PCI: 00:1f.1 14 * [0x00001830 - 0x00001833] io PCI: 00:1f.1 1c * [0x00001840 - 0x00001843] io Root Device compute_allocate_io: base: 00001844 size: 00000844 align: 8 gran: 0 done Root Device compute_allocate_mem: base: febfcc00 size: 00003100 align: 10 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:1d.7 10 * [0xfebfd000 - 0xfebfd3ff] mem PCI: 00:1f.1 24 * [0xfebfe000 - 0xfebfe3ff] mem PCI: 00:1f.5 18 * [0xfebff000 - 0xfebff1ff] mem PCI: 00:1f.5 1c * [0xfec00000 - 0xfec000ff] mem Root Device compute_allocate_mem: base: fec00100 size: 00003500 align: 10 gran: 0 done Root Device assign_resources, bus 0 link: 0 Setting RAM size to 131072 PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 PCI: 00:1d.0 20 <- [0x0000001480 - 0x000000149f] io PCI: 00:1d.1 20 <- [0x00000014a0 - 0x00000014bf] io PCI: 00:1d.2 20 <- [0x00000014c0 - 0x00000014df] io PCI: 00:1d.7 10 <- [0x00febfd000 - 0x00febfd3ff] mem PCI: 00:1f.0 assign_resources, bus 0 link: 0 PNP: 002e.4 60 <- [0x00000003f8 - 0x00000003ff] io PNP: 002e.4 70 <- [0x0000000004 - 0x0000000004] irq PNP: 002e.7 60 <- [0x0000000060 - 0x0000000060] io PNP: 002e.7 62 <- [0x0000000064 - 0x0000000064] io PNP: 002e.7 70 <- [0x0000000001 - 0x0000000001] irq PNP: 002e.7 72 <- [0x000000000c - 0x000000000c] irq PCI: 00:1f.0 assign_resources, bus 0 link: 0 PCI: 00:1f.1 10 <- [0x0000001810 - 0x0000001817] io PCI: 00:1f.1 14 <- [0x0000001830 - 0x0000001833] io PCI: 00:1f.1 18 <- [0x0000001820 - 0x0000001827] io PCI: 00:1f.1 1c <- [0x0000001840 - 0x0000001843] io PCI: 00:1f.1 20 <- [0x0000001800 - 0x000000180f] io PCI: 00:1f.1 24 <- [0x00febfe000 - 0x00febfe3ff] mem PCI: 00:1f.3 20 <- [0x00000014e0 - 0x00000014ff] io PCI: 00:1f.5 18 <- [0x00febff000 - 0x00febff1ff] mem PCI: 00:1f.5 1c <- [0x00fec00000 - 0x00fec000ff] mem PCI: 00:1f.6 10 <- [0x0000001000 - 0x00000010ff] io PCI: 00:1f.6 14 <- [0x0000001400 - 0x000000147f] io 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:00.0 cmd <- 146 PCI: 00:1d.0 cmd <- 141 PCI: 00:1d.1 cmd <- 141 PCI: 00:1d.2 cmd <- 141 PCI: 00:1d.7 cmd <- 142 PCI: 00:1e.0 bridge ctrl <- 0003 PCI: 00:1e.0 cmd <- 141 LinuxBIOS-2.0.0.0Fallback Thu Sep 6 14:53:32 EDT 2007 starting... Setting initial registers.... Initial registers have been set. No DIMM found in slot 00 DRB 0x60 has been set to 0x00 DRB1 0x61 has been set to 0x00 Found DIMM in slot 01 DIMM is 0x0080 on side 1 DIMM is 0x0000 on side 2 DRB2 0x62 has been set to 0x04 DRB3 0x63 has been set to 0x04 No DIMM found in slot 00, setting DRA to 0xFF DRA 0x70 has been set to 0xff Found DIMM in slot 01, setting DRA... DRA 0x71 has been set to 0xf1 RAM Enable 1: Apply NOP Sending RAM command 0x00000010 to 0x00000000 RAM Enable 2: Precharge all Sending RAM command 0x00000020 to 0x00000000 RAM Enable 3: CBR Sending RAM command 0x00000060 to 0x00000000 RAM Enable 4: Mode register set Sending RAM command 0x00000030 to 0x000001d0 RAM Enable 5: Normal operation Sending RAM command 0x20000170 to 0x00000000 Northbridge following SDRAM init: PCI: 00:00.00 00: 86 80 75 35 06 00 10 00 04 00 00 06 00 00 00 00 10: 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 40: 09 00 05 01 00 00 00 00 00 00 00 00 02 28 00 0e 50: 72 a0 20 00 00 00 00 00 00 30 33 33 33 33 33 33 60: 00 00 04 04 00 00 00 00 00 00 00 00 00 00 00 00 70: ff f1 ff ff 00 00 00 00 10 00 00 00 70 01 00 20 80: 00 00 00 00 00 00 00 00 00 d0 00 40 00 00 00 00 90: 02 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 02 00 20 00 17 02 00 1f 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 54 0e 41 a2 99 01 00 c0 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 09 c9 9f fc f0: 11 11 01 00 00 00 0b 05 34 d6 33 cf 22 cf 24 cf Testing DRAM : 00000000-000a0000 DRAM fill: 00000000-000a0000 00000000 00010000 00020000 00030000 00040000 00050000 00060000 00070000 00080000 00090000 000a0000 DRAM filled DRAM verify: 00000000-000a0000 00000000 00010000 00020000 00030000 00040000 00050000 00060000 00070000 00080000 00090000 000a0000 DRAM range verified. Done. Copying LinuxBIOS to RAM. Jumping to LinuxBIOS. LinuxBIOS-2.0.0.0Fallback Thu Sep 6 14:53:32 EDT 2007 booting... end 6f9d3757, start 0 32-bit delta 1566 calibrate_tsc 32-bit result is 1566 clocks_per_usec: 1566 Enumerating buses... scan_static_bus for Root Device Finding PCI configuration type. PCI: Using configuration type 1 PCI_DOMAIN: 0000 enabled PCI_DOMAIN: 0000 scanning... PCI: pci_scan_bus for bus 00 PCI: 00:00.0 [8086/3575] ops PCI: 00:00.0 [8086/3575] enabled PCI: devfn 0x9, bad id 0xffffffff PCI: devfn 0xa, bad id 0xffffffff PCI: devfn 0xb, bad id 0xffffffff PCI: devfn 0xc, bad id 0xffffffff PCI: devfn 0xd, bad id 0xffffffff PCI: devfn 0xe, bad id 0xffffffff PCI: devfn 0xf, bad id 0xffffffff PCI: 00:02.0 [8086/3577] disabled PCI: devfn 0x11, bad id 0xffffffff PCI: devfn 0x12, bad id 0xffffffff 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 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: 00:1d.0 [8086/24c2] ops PCI: 00:1d.0 [8086/24c2] enabled PCI: 00:1d.1 [8086/24c4] ops PCI: 00:1d.1 [8086/24c4] enabled PCI: 00:1d.2 [8086/24c7] ops PCI: 00:1d.2 [8086/24c7] enabled PCI: devfn 0xeb, bad id 0xffffffff PCI: devfn 0xec, bad id 0xffffffff PCI: devfn 0xed, bad id 0xffffffff PCI: devfn 0xee, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 0001a000 malloc 0x0001a000 PCI: 00:1d.7 [8086/24cd] ops PCI: 00:1d.7 [8086/24cd] enabled PCI: 00:1e.0 [8086/244e] bus ops PCI: 00:1e.0 [8086/244e] enabled PCI: 00:1f.0 [8086/24c0] bus ops PCI: 00:1f.0 [8086/24c0] enabled PCI: 00:1f.1 [8086/24cb] ops PCI: 00:1f.1 [8086/24cb] enabled PCI: devfn 0xfa, bad id 0xffffffff PCI: 00:1f.3 [8086/24c3] enabled PCI: devfn 0xfc, bad id 0xffffffff PCI: 00:1f.5 [8086/24c5] ops PCI: 00:1f.5 [8086/24c5] enabled PCI: 00:1f.6 [8086/24c6] ops PCI: 00:1f.6 [8086/24c6] enabled PCI: devfn 0xff, bad id 0xffffffff do_pci_scan_bridge for PCI: 00:1e.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 Disabling static device: PCI: 01:08.0 PCI: devfn 0x41, bad id 0xffffffff PCI: devfn 0x42, bad id 0xffffffff PCI: devfn 0x43, bad id 0xffffffff PCI: devfn 0x44, bad id 0xffffffff PCI: devfn 0x45, bad id 0xffffffff PCI: devfn 0x46, bad id 0xffffffff PCI: devfn 0x47, 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 scan_static_bus for PCI: 00:1f.0 Found SMSC Super I/O (ID=0x60, rev=0x01) PNP: 002e.0 disabled PNP: 002e.3 disabled PNP: 002e.4 enabled PNP: 002e.5 disabled PNP: 002e.7 enabled PNP: 002e.9 disabled PNP: 002e.a disabled PNP: 002e.b disabled scan_static_bus for PCI: 00:1f.0 done PCI: pci_scan_bus returning with max=001 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:00.0 register 10(00000008), read-only ignoring it PCI: 00:1e.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 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: 0000f000 size: 00000000 align: 12 gran: 12 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 link: 0 done PCI: 00:1e.0 compute_allocate_io: base: 0000f000 size: 00000000 align: 12 gran: 12 done PCI: 00:1e.0 1c <- [0x000000f000 - 0x000000efff] bus 01 io PCI: 00:1e.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 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: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 link: 0 done PCI: 00:1e.0 compute_allocate_prefmem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1e.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 01 prefmem PCI: 00:1e.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 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 1 link: 0 PCI: 00:1e.0 read_resources bus 1 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 01 mem PCI: 00:1f.0 read_resources bus 0 link: 0 PCI: 00:1f.0 read_resources bus 0 link: 0 done PCI: 00:1f.5 register 10(00000001), read-only ignoring it PCI: 00:1f.5 register 14(00000001), 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:1f.6 10 * [0x00000400 - 0x000004ff] io PCI: 00:1f.6 14 * [0x00000800 - 0x0000087f] io PCI: 00:1d.0 20 * [0x00000880 - 0x0000089f] io PCI: 00:1d.1 20 * [0x000008a0 - 0x000008bf] io PCI: 00:1d.2 20 * [0x000008c0 - 0x000008df] io PCI: 00:1f.3 20 * [0x000008e0 - 0x000008ff] io PCI: 00:1f.1 20 * [0x00000c00 - 0x00000c0f] io PCI: 00:1f.1 10 * [0x00000c10 - 0x00000c17] io PCI: 00:1f.1 18 * [0x00000c20 - 0x00000c27] io PCI: 00:1f.1 14 * [0x00000c30 - 0x00000c33] io PCI: 00:1f.1 1c * [0x00000c40 - 0x00000c43] io Root Device compute_allocate_io: base: 00000c44 size: 00000844 align: 8 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:1d.7 10 * [0x00000000 - 0x000003ff] mem PCI: 00:1f.1 24 * [0x00001000 - 0x000013ff] mem PCI: 00:1f.5 18 * [0x00002000 - 0x000021ff] mem PCI: 00:1f.5 1c * [0x00003000 - 0x000030ff] mem Root Device compute_allocate_mem: base: 00003100 size: 00003100 align: 10 gran: 0 done Done reading resources. Setting resources... Root Device compute_allocate_io: base: 00001000 size: 00000844 align: 8 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:1f.6 10 * [0x00001000 - 0x000010ff] io PCI: 00:1f.6 14 * [0x00001400 - 0x0000147f] io PCI: 00:1d.0 20 * [0x00001480 - 0x0000149f] io PCI: 00:1d.1 20 * [0x000014a0 - 0x000014bf] io PCI: 00:1d.2 20 * [0x000014c0 - 0x000014df] io PCI: 00:1f.3 20 * [0x000014e0 - 0x000014ff] io PCI: 00:1f.1 20 * [0x00001800 - 0x0000180f] io PCI: 00:1f.1 10 * [0x00001810 - 0x00001817] io PCI: 00:1f.1 18 * [0x00001820 - 0x00001827] io PCI: 00:1f.1 14 * [0x00001830 - 0x00001833] io PCI: 00:1f.1 1c * [0x00001840 - 0x00001843] io Root Device compute_allocate_io: base: 00001844 size: 00000844 align: 8 gran: 0 done Root Device compute_allocate_mem: base: febfcc00 size: 00003100 align: 10 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:1d.7 10 * [0xfebfd000 - 0xfebfd3ff] mem PCI: 00:1f.1 24 * [0xfebfe000 - 0xfebfe3ff] mem PCI: 00:1f.5 18 * [0xfebff000 - 0xfebff1ff] mem PCI: 00:1f.5 1c * [0xfec00000 - 0xfec000ff] mem Root Device compute_allocate_mem: base: fec00100 size: 00003500 align: 10 gran: 0 done Root Device assign_resources, bus 0 link: 0 Setting RAM size to 131072 PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 PCI: 00:1d.0 20 <- [0x0000001480 - 0x000000149f] io PCI: 00:1d.1 20 <- [0x00000014a0 - 0x00000014bf] io PCI: 00:1d.2 20 <- [0x00000014c0 - 0x00000014df] io PCI: 00:1d.7 10 <- [0x00febfd000 - 0x00febfd3ff] mem PCI: 00:1f.0 assign_resources, bus 0 link: 0 PNP: 002e.4 60 <- [0x00000003f8 - 0x00000003ff] io PNP: 002e.4 70 <- [0x0000000004 - 0x0000000004] irq PNP: 002e.7 60 <- [0x0000000060 - 0x0000000060] io PNP: 002e.7 62 <- [0x0000000064 - 0x0000000064] io PNP: 002e.7 70 <- [0x0000000001 - 0x0000000001] irq PNP: 002e.7 72 <- [0x000000000c - 0x000000000c] irq PCI: 00:1f.0 assign_resources, bus 0 link: 0 PCI: 00:1f.1 10 <- [0x0000001810 - 0x0000001817] io PCI: 00:1f.1 14 <- [0x0000001830 - 0x0000001833] io PCI: 00:1f.1 18 <- [0x0000001820 - 0x0000001827] io PCI: 00:1f.1 1c <- [0x0000001840 - 0x0000001843] io PCI: 00:1f.1 20 <- [0x0000001800 - 0x000000180f] io PCI: 00:1f.1 24 <- [0x00febfe000 - 0x00febfe3ff] mem PCI: 00:1f.3 20 <- [0x00000014e0 - 0x00000014ff] io PCI: 00:1f.5 18 <- [0x00febff000 - 0x00febff1ff] mem PCI: 00:1f.5 1c <- [0x00fec00000 - 0x00fec000ff] mem PCI: 00:1f.6 10 <- [0x0000001000 - 0x00000010ff] io PCI: 00:1f.6 14 <- [0x0000001400 - 0x000000147f] io 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:00.0 cmd <- 146 PCI: 00:1d.0 cmd <- 141 PCI: 00:1d.1 cmd <- 141 PCI: 00:1d.2 cmd <- 141 PCI: 00:1d.7 cmd <- 142 PCI: 00:1e.0 bridge ctrl <- 0003 PCI: 00:1e.0 cmd <- 141 From myles at pel.cs.byu.edu Fri Sep 7 00:16:28 2007 From: myles at pel.cs.byu.edu (Myles Watson) Date: Thu, 6 Sep 2007 16:16:28 -0600 Subject: [LinuxBIOS] [RFC] ADLO2 In-Reply-To: <1189008580.17055.99.camel@localhost> References: <1188947195.17055.59.camel@localhost><1188947538.17055.64.camel@localhost><13426df10709042123h60e235d6sf47855ef4774a26f@mail.gmail.com> <1189008580.17055.99.camel@localhost> Message-ID: <020401c7f0d3$939c2cc0$4d22040a@chimp> > > Hi, > > On Tue, 2007-09-04 at 21:23 -0700, ron minnich wrote: > > can someone with an XP license try to recreate Alex's fine work? The > > more people we get to try this, the better! I'm interested in trying this on my machine, but I have a couple of questions for you. 1. Can I use LinuxBIOS -> FILO -> ADLO? a. It seems like since ADLO is an elf file, this should work, but I get an error "Unsupported file format" b. This would be the easiest path for me, since I wouldn't have to re-flash my ROM 2. Where do I set the boot drive in the CMOS (as per the README)? Thanks, Myles > You can try this with a standard GRUB, any Linux / BSD installation, or > the better: with FreeDOS. > > -- > Alex From alex at rtfs.hu Fri Sep 7 00:27:30 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Fri, 07 Sep 2007 00:27:30 +0200 Subject: [LinuxBIOS] [RFC] ADLO2 In-Reply-To: <020401c7f0d3$939c2cc0$4d22040a@chimp> References: <1188947195.17055.59.camel@localhost> <1188947538.17055.64.camel@localhost> <13426df10709042123h60e235d6sf47855ef4774a26f@mail.gmail.com> <1189008580.17055.99.camel@localhost> <020401c7f0d3$939c2cc0$4d22040a@chimp> Message-ID: <1189117650.26302.47.camel@localhost> Hi, > > On Tue, 2007-09-04 at 21:23 -0700, ron minnich wrote: > > > can someone with an XP license try to recreate Alex's fine work? The > > > more people we get to try this, the better! > > I'm interested in trying this on my machine, but I have a couple of > questions for you. > > 1. Can I use LinuxBIOS -> FILO -> ADLO? > a. It seems like since ADLO is an elf file, this should work, but I > get an error "Unsupported file format" > b. This would be the easiest path for me, since I wouldn't have to > re-flash my ROM I am not familiar how FILO loads and starts an image, but one thing comes to my mind: the ELF is a minimalistic one, with lar in mind, it has only program headers and no section headers. Maybe this is a problem for FILO. Do the old ADLO images loaded for you? > 2. Where do I set the boot drive in the CMOS (as per the README)? The README and every description file comes from the original source. ; III) tell BOCHS' BIOS we want to boot from hdd. ; 0x00 - floppy ; 0x02 - hdd ; In future there will be 'fd failover'option in bochs. ;CMOS_OUT(#0x3d, #0x02) Uncomment this field in loader.s to boot from HDD. Logic for boot device priority must be implemented in Bochs BIOS, currently it will try the device it is told to and stop if that is not working. -- Alex From alex at rtfs.hu Fri Sep 7 12:54:34 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Fri, 07 Sep 2007 12:54:34 +0200 Subject: [LinuxBIOS] [PATCH] pci_rom.c checksum extension rom In-Reply-To: <20070905022911.GA31013@coresystems.de> References: <1188904675.17055.2.camel@localhost> <20070905022911.GA31013@coresystems.de> Message-ID: <1189162475.26302.55.camel@localhost> Hi, On Wed, 2007-09-05 at 04:29 +0200, Stefan Reinauer wrote: > * Alex Beregszaszi [070904 13:17]: > > Hi, > > > > the attached patch adds code to checksum the pci extension rom and stop > > if the stored and calculated checksum differ. > > Is this checksum reliably correct? I am hesitating to add new > restrictions that might break otherwise working cards. You are right, attached is a correct method. There is no fixed checksum byte, instead the whole should sum to zero. -- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: optionrom-checksum.diff Type: text/x-patch Size: 917 bytes Desc: not available URL: From st at iss.tu-darmstadt.de Fri Sep 7 13:49:17 2007 From: st at iss.tu-darmstadt.de (ST) Date: Fri, 7 Sep 2007 13:49:17 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <20070905175559.11458.qmail@stuge.se> References: <20070829202148.24398.qmail@stuge.se> <200709051520.08757.st@iss.tu-darmstadt.de> <20070905175559.11458.qmail@stuge.se> Message-ID: <200709071349.18360.st@iss.tu-darmstadt.de> Hi > > Mh, i don't know anything about SPI, but i think if they also have > > #init pins it should work. > They don't. Not good. If i remember correctly on my v1.0 M57SLI-S4 there have been SPI pins within the PLCC connectors. These pins where not connected to any of the open presumably SPI pins. But well i don't have a new board and i don't know SPI stuff. But you should try to measure all the pins i used for my stuff. Probably there is a connection... or the CS# of both SPI chips is connected to different pins of the SuperIO? Regards Tim From echelon at free.fr Fri Sep 7 15:57:04 2007 From: echelon at free.fr (echelon at free.fr) Date: Fri, 07 Sep 2007 15:57:04 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <200709071349.18360.st@iss.tu-darmstadt.de> References: <20070829202148.24398.qmail@stuge.se> <200709051520.08757.st@iss.tu-darmstadt.de> <20070905175559.11458.qmail@stuge.se> <200709071349.18360.st@iss.tu-darmstadt.de> Message-ID: <1189173424.46e158b067d83@imp.free.fr> Quoting ST : > But well i don't have a new board and i don't know SPI stuff. But you should > try to measure all the pins i used for my stuff. Probably there is a > connection... or the CS# of both SPI chips is connected to different pins of > the SuperIO? No, the second SPI CS# isn't connected directly with any SuperIO pin. OTOH, I found (using Peter's labeling): U9-CS# -> Q4-1 Q4-3 -> Q3-3 Q5-1 -> U5-CS# -> SuperIO-61 Please note that that there is no serial resistor btw U5-CS# and SuperIO-61, so you cannot force the pullup of Q5-1 (IMHO) Florentin From echelon at free.fr Fri Sep 7 16:07:12 2007 From: echelon at free.fr (echelon at free.fr) Date: Fri, 07 Sep 2007 16:07:12 +0200 Subject: [LinuxBIOS] NVidia southbridge question In-Reply-To: <200709071349.18360.st@iss.tu-darmstadt.de> References: <20070829202148.24398.qmail@stuge.se> <200709051520.08757.st@iss.tu-darmstadt.de> <20070905175559.11458.qmail@stuge.se> <200709071349.18360.st@iss.tu-darmstadt.de> Message-ID: <1189174032.46e15b10d38fa@imp.free.fr> Hi all, Just some little newbee questions: * What is the "romstrap" section? Does it have to be located @ a fixed physical address? * What is a "SIP table"? thanks in advance for your answers, Florentin From myles at pel.cs.byu.edu Fri Sep 7 18:21:55 2007 From: myles at pel.cs.byu.edu (Myles Watson) Date: Fri, 7 Sep 2007 10:21:55 -0600 Subject: [LinuxBIOS] [RFC] ADLO2 In-Reply-To: <1189117650.26302.47.camel@localhost> References: <1188947195.17055.59.camel@localhost> <1188947538.17055.64.camel@localhost> <13426df10709042123h60e235d6sf47855ef4774a26f@mail.gmail.com> <1189008580.17055.99.camel@localhost> <020401c7f0d3$939c2cc0$4d22040a@chimp> <1189117650.26302.47.camel@localhost> Message-ID: <022301c7f16b$357911b0$4d22040a@chimp> > Hi, > > > > On Tue, 2007-09-04 at 21:23 -0700, ron minnich wrote: > > > > can someone with an XP license try to recreate Alex's fine work? The > > > > more people we get to try this, the better! > > > > I'm interested in trying this on my machine, but I have a couple of > > questions for you. > > > > 1. Can I use LinuxBIOS -> FILO -> ADLO? > > a. It seems like since ADLO is an elf file, this should work, but I > > get an error "Unsupported file format" > > b. This would be the easiest path for me, since I wouldn't have to > > re-flash my ROM > > I am not familiar how FILO loads and starts an image, but one thing > comes to my mind: the ELF is a minimalistic one, with lar in mind, it > has only program headers and no section headers. Maybe this is a problem > for FILO. > > Do the old ADLO images loaded for you? I used your BIOS-bochs-legacy with the 64k elf header from the repository and your BIOS-bochs-latest with the 129k elf header. Here is the output from the serial console for the 64k version: hdb1:/boot/adlo.legacy.elf hda: LBA: IC35L020AVER07-0 hdb: LBA: WDC WD800JB-00JJC0 Mounted ext2fs Loading image... Loaded 66560 bytes in 55ms (1210KB/s) Jumping to entry point... BIOS entry. FATAL: Keyboard error:31 With the 129k version I get no output from the BIOS: Enter boot: hdb1:/boot/adlo.elf hda: LBA: IC35L020AVER07-0 hdb: LBA: WDC WD800JB-00JJC0 Mounted ext2fs Loading image... Loaded 132096 bytes in 111ms (1190KB/s) Jumping to entry point... Both of these got farther than the simpler elf. Myles From myles at pel.cs.byu.edu Fri Sep 7 18:45:10 2007 From: myles at pel.cs.byu.edu (Myles Watson) Date: Fri, 7 Sep 2007 10:45:10 -0600 Subject: [LinuxBIOS] bcc and ADLO In-Reply-To: <022301c7f16b$357911b0$4d22040a@chimp> References: <1188947195.17055.59.camel@localhost><1188947538.17055.64.camel@localhost><13426df10709042123h60e235d6sf47855ef4774a26f@mail.gmail.com><1189008580.17055.99.camel@localhost><020401c7f0d3$939c2cc0$4d22040a@chimp><1189117650.26302.47.camel@localhost> <022301c7f16b$357911b0$4d22040a@chimp> Message-ID: <022401c7f16e$74710910$4d22040a@chimp> Where can I get the bcc that's required to compile ADLO? I just used your images, but if I need to change something then bcc will come in handy. Thanks, Myles From fainshf at gmail.com Fri Sep 7 19:26:20 2007 From: fainshf at gmail.com (Fridel Fainshtein) Date: Fri, 7 Sep 2007 20:26:20 +0300 Subject: [LinuxBIOS] quadcore opteron Message-ID: Hi, Does quad core opteron needs some special software? If yes, is there any supporting open source code? (May be just first steps, cache as ram etc.) Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From myles at pel.cs.byu.edu Fri Sep 7 19:32:55 2007 From: myles at pel.cs.byu.edu (Myles Watson) Date: Fri, 7 Sep 2007 11:32:55 -0600 Subject: [LinuxBIOS] bcc and ADLO In-Reply-To: <022401c7f16e$74710910$4d22040a@chimp> References: <1188947195.17055.59.camel@localhost><1188947538.17055.64.camel@localhost><13426df10709042123h60e235d6sf47855ef4774a26f@mail.gmail.com><1189008580.17055.99.camel@localhost><020401c7f0d3$939c2cc0$4d22040a@chimp><1189117650.26302.47.camel@localhost><022301c7f16b$357911b0$4d22040a@chimp> <022401c7f16e$74710910$4d22040a@chimp> Message-ID: <023001c7f175$20142fd0$4d22040a@chimp> > Where can I get the bcc that's required to compile ADLO? In a package called dev86. From chris at stockwith.co.uk Fri Sep 7 19:46:17 2007 From: chris at stockwith.co.uk (Chris Lingard) Date: Fri, 07 Sep 2007 18:46:17 +0100 Subject: [LinuxBIOS] M57SLI Revision 2 SPI Message-ID: <46E18E69.4060905@stockwith.co.uk> Gigabyte have told me that the BIOS chip is made by SST, and the model name is SST25LF040A BIOS ROM which is PLCC32 type. The data sheet and details are at http://www.sst.com/products.xhtml/serial_flash/25/SST25LF040A I am now very confused because I have PLCC32 sockets and these are nothing like the BIOS chip which has 8 connections. (I have two PLCC32 sockets and four unused flash chips to give away, if they are no use to this version of the motherboard). I will probably try to source some of these chips, just in case the rest of the problems can be solved. Chris Lingard From svn at openbios.org Fri Sep 7 19:52:38 2007 From: svn at openbios.org (svn at openbios.org) Date: Fri, 7 Sep 2007 19:52:38 +0200 Subject: [LinuxBIOS] r2763 - trunk/LinuxBIOSv2/util Message-ID: Author: uwe Date: 2007-09-07 19:52:37 +0200 (Fri, 07 Sep 2007) New Revision: 2763 Modified: trunk/LinuxBIOSv2/util/ Log: Get superiotool via svn:externals into v2. Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Property changes on: trunk/LinuxBIOSv2/util ___________________________________________________________________ Name: svn:externals - flashrom svn://linuxbios.org/repos/trunk/util/flashrom lxbios svn://linuxbios.org/repos/trunk/util/lxbios + flashrom svn://linuxbios.org/repos/trunk/util/flashrom lxbios svn://linuxbios.org/repos/trunk/util/lxbios superiotool svn://linuxbios.org/repos/trunk/util/superiotool From svn at openbios.org Fri Sep 7 19:53:47 2007 From: svn at openbios.org (svn at openbios.org) Date: Fri, 7 Sep 2007 19:53:47 +0200 Subject: [LinuxBIOS] r495 - LinuxBIOSv3/util Message-ID: Author: uwe Date: 2007-09-07 19:53:47 +0200 (Fri, 07 Sep 2007) New Revision: 495 Modified: LinuxBIOSv3/util/ Log: Get superiotool via svn:externals into v3. Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Property changes on: LinuxBIOSv3/util ___________________________________________________________________ Name: svn:externals - flashrom svn://linuxbios.org/repos/trunk/util/flashrom lxbios svn://linuxbios.org/repos/trunk/util/lxbios + flashrom svn://linuxbios.org/repos/trunk/util/flashrom lxbios svn://linuxbios.org/repos/trunk/util/lxbios superiotool svn://linuxbios.org/repos/trunk/util/superiotool From talbotx at comcast.net Fri Sep 7 20:10:53 2007 From: talbotx at comcast.net (Adam Talbot) Date: Fri, 07 Sep 2007 11:10:53 -0700 Subject: [LinuxBIOS] Status of the via vt82c686 southbridge? Message-ID: <46E1942D.4090403@comcast.net> What is the current status of the via vt82c686 southbridge? -Adam From yinghailu at gmail.com Fri Sep 7 20:22:54 2007 From: yinghailu at gmail.com (yhlu) Date: Fri, 7 Sep 2007 11:22:54 -0700 Subject: [LinuxBIOS] quadcore opteron In-Reply-To: References: Message-ID: <2ea3fae10709071122g32a01590w8c91d5c1533e86a@mail.gmail.com> On 9/7/07, Fridel Fainshtein wrote: > Hi, > > Does quad core opteron needs some special software? > If yes, is there any supporting open source code? > (May be just first steps, cache as ram etc.) before I was leaving AMD, 1. the code works well in simulator even with 64node... 2. on the real silicon, the code could run on seregenti_cheetah..., but still need some time to debug the mem code (workaround silicon bug)... ===> anyway it was too late/hard for me to get chip and i didn't have enough to time to test it.... the code is quite different to dual core opteron... YH From yinghailu at gmail.com Fri Sep 7 20:24:50 2007 From: yinghailu at gmail.com (yhlu) Date: Fri, 7 Sep 2007 11:24:50 -0700 Subject: [LinuxBIOS] NVidia southbridge question In-Reply-To: <1189174032.46e15b10d38fa@imp.free.fr> References: <20070829202148.24398.qmail@stuge.se> <200709051520.08757.st@iss.tu-darmstadt.de> <20070905175559.11458.qmail@stuge.se> <200709071349.18360.st@iss.tu-darmstadt.de> <1189174032.46e15b10d38fa@imp.free.fr> Message-ID: <2ea3fae10709071124i5fd2c3a8r710c84c576078ab7@mail.gmail.com> On 9/7/07, echelon at free.fr wrote: > Hi all, > Just some little newbee questions: > * What is the "romstrap" section? Does it have to be located @ a fixed physical > address? > * What is a "SIP table"? you need to access Nvidia NDA info about that... YH From info at coresystems.de Fri Sep 7 20:38:03 2007 From: info at coresystems.de (LinuxBIOS information) Date: Fri, 07 Sep 2007 20:38:03 +0200 Subject: [LinuxBIOS] r2763 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2763 to the LinuxBIOS source repository and caused the following changes: Change Log: Get superiotool via svn:externals into v2. Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2763&device=hdama&vendor=arima Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2763&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2763&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2763&device=juki-511p&vendor=iei Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2763&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2763&device=dk8x&vendor=iwill If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From echelon at free.fr Fri Sep 7 20:43:29 2007 From: echelon at free.fr (echelon at free.fr) Date: Fri, 07 Sep 2007 20:43:29 +0200 Subject: [LinuxBIOS] M57SLI Revision 2 SPI In-Reply-To: <46E18E69.4060905@stockwith.co.uk> References: <46E18E69.4060905@stockwith.co.uk> Message-ID: <1189190609.46e19bd1c9b9d@imp.free.fr> Hmmm.. When you took contact with Gigabyte, did you clearly told them that you have a SPI revision of their board? For my part, I desoldered the SPI flash chip on my board and took a look at it with a powerfull glass and found that, in fact, they use a MX25L4005A chip from MXC. But that doesn't matter a lot I think.. I found that many SPI flash use the same protocol (CFI?) for programming, so adding support in flashrom should be easy, now that we already know that the controller of the SPI signals is the SuperIO chip.. Hope this helps.. Florentin Quoting Chris Lingard : > > Gigabyte have told me that the BIOS chip is made by SST, and the model > name is SST25LF040A BIOS ROM which is PLCC32 type. > > The data sheet and details are at > > http://www.sst.com/products.xhtml/serial_flash/25/SST25LF040A > > I am now very confused because I have PLCC32 sockets and these are > nothing like the BIOS chip which has 8 connections. > > (I have two PLCC32 sockets and four unused flash chips to give away, if > they are no use to this version of the motherboard). > > I will probably try to source some of these chips, just in case the rest > of the problems can be solved. > > Chris Lingard > > > > > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > From uwe at hermann-uwe.de Fri Sep 7 21:01:05 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 7 Sep 2007 21:01:05 +0200 Subject: [LinuxBIOS] r2758 - in trunk: LinuxBIOSv2/util util In-Reply-To: <46DDFA64.5040805@gmx.net> References: <20070901194454.26802gmx1@mx084.gmx.net> <46DC544B.8030305@gmx.net> <20070904235256.GA19641@coresystems.de> <46DDFA64.5040805@gmx.net> Message-ID: <20070907190105.GD10747@greenwood> On Wed, Sep 05, 2007 at 02:37:56AM +0200, Carl-Daniel Hailfinger wrote: > > Wrote LinuxBIOS table at: 0x00000500 - 0x00000a54 checksum 401f > > Show all devs... > > cpus: Unknown device path type: 0 > > Stage2 code done. > > LAR: Attempting to open 'normal/payload'. > > LAR: Attempting to open 'normal/payload/segment0'. > > LAR: load_file: No such file 'normal/payload/segment0' > > > > It just hangs somewhere bogus and never gets to the defined error in > > > > arch/x86/stage1.c:194: die("FATAL: No usable payload found.\n"); > > > > also the current code contains quite some warnings again regarding > > int-to-pointer casts in lar.c and pointer-to-int cast and uninitialized > > variable use in stage1.c > > Which gcc? I seem to have trouble getting my gcc to warn about anything > on i386. "gcc (GCC) 4.1.0 (SUSE Linux)". On my other machine, I get a > few warnings: Hm, I don't see any warnings either at the moment (r495), neither on i386 nor on amd64, but maybe they were fixed inbetween; I'll have to catch up with all the recent patches... 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 alex at rtfs.hu Fri Sep 7 21:11:26 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Fri, 07 Sep 2007 21:11:26 +0200 Subject: [LinuxBIOS] r2758 - in trunk: LinuxBIOSv2/util util In-Reply-To: <20070907190105.GD10747@greenwood> References: <20070901194454.26802gmx1@mx084.gmx.net> <46DC544B.8030305@gmx.net> <20070904235256.GA19641@coresystems.de> <46DDFA64.5040805@gmx.net> <20070907190105.GD10747@greenwood> Message-ID: <1189192286.26302.59.camel@localhost> Hi, On Fri, 2007-09-07 at 21:01 +0200, Uwe Hermann wrote: > On Wed, Sep 05, 2007 at 02:37:56AM +0200, Carl-Daniel Hailfinger wrote: > > > Wrote LinuxBIOS table at: 0x00000500 - 0x00000a54 checksum 401f > > > Show all devs... > > > cpus: Unknown device path type: 0 > > > Stage2 code done. > > > LAR: Attempting to open 'normal/payload'. > > > LAR: Attempting to open 'normal/payload/segment0'. > > > LAR: load_file: No such file 'normal/payload/segment0' > > > > > > It just hangs somewhere bogus and never gets to the defined error in > > > > > > arch/x86/stage1.c:194: die("FATAL: No usable payload found.\n"); > > > > > > also the current code contains quite some warnings again regarding > > > int-to-pointer casts in lar.c and pointer-to-int cast and uninitialized > > > variable use in stage1.c > > > > Which gcc? I seem to have trouble getting my gcc to warn about anything > > on i386. "gcc (GCC) 4.1.0 (SUSE Linux)". On my other machine, I get a > > few warnings: > > Hm, I don't see any warnings either at the moment (r495), neither on i386 > nor on amd64, but maybe they were fixed inbetween; I'll have to catch up > with all the recent patches... Fixed with r488. -- Alex From todthgie at hotmail.com Fri Sep 7 21:17:14 2007 From: todthgie at hotmail.com (todthgie) Date: Fri, 7 Sep 2007 21:17:14 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) References: <20070829202148.24398.qmail@stuge.se><46D6AB93.9080607@stockwith.co.uk><20070830120920.GB10696@localdomain><200709051520.08757.st@iss.tu-darmstadt.de> <20070905175559.11458.qmail@stuge.se> Message-ID: how about #HOLD ? ----- Original Message ----- From: "Peter Stuge" To: Sent: Wednesday, September 05, 2007 19:55 Subject: Re: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) > On Wed, Sep 05, 2007 at 03:20:08PM +0200, ST wrote: >> > > Is the modification now wrong? >> > ST, can you chime in here? >> Mh, i don't know anything about SPI, but i think if they also have >> #init pins it should work. > > They don't. > > The only signal we can work with is CS# which is connected directly > to the super io, which means we want to be a bit careful about > driving it, to be on the safe side. > > I'd lift the pin. At least it's in a corner. > > > //Peter > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > From uwe at hermann-uwe.de Fri Sep 7 21:19:44 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 7 Sep 2007 21:19:44 +0200 Subject: [LinuxBIOS] r2758 - in trunk: LinuxBIOSv2/util util In-Reply-To: <46DC544B.8030305@gmx.net> References: <20070901194454.26802gmx1@mx084.gmx.net> <46DC544B.8030305@gmx.net> Message-ID: <20070907191944.GE10747@greenwood> On Mon, Sep 03, 2007 at 08:36:59PM +0200, Carl-Daniel Hailfinger wrote: > This commit removed probe_superio from v2. It has not been referenced as > svn:externals, so none of the v2 and v3 trees have probe_superio or > superiotool. Yes, and that was by design. I don't think we _really_ need them in either of the repositories (v2 or v3), you can easily get the tool via svn co svn://linuxbios.org/repos/trunk/util/superiotool But it seems several people prefer to have it in both repos, so why not... It's in v2 and v3 now via svn:externals. > As of revision 2762, the v2 repository is still BROKEN and superiotool > doesn't appear in v3 either (checked revision 486). It's not broken, I guess you had local modifications thus the v2 directory ended up crappy. A fresh checkout has no problems at all. 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 myles at pel.cs.byu.edu Fri Sep 7 21:53:59 2007 From: myles at pel.cs.byu.edu (Myles Watson) Date: Fri, 7 Sep 2007 13:53:59 -0600 Subject: [LinuxBIOS] LinuxBIOS - Booting Windows XP In-Reply-To: References: Message-ID: <024301c7f188$d4e59350$4d22040a@chimp> > http://www.linuxbios.org/Booting_Windows_using_LinuxBIOS > Feel free to test it and give some feedback!! I can get it to find my CD-ROM drive, but it fails with code: 0003. According to http://bochs.sourceforge.net/doc/docbook/user/bios-tips.html that means: For this error, the cdrom support has not been compiled in Bochs, or Bochs could not open the file or device. This is what you get if Bochs is not able to read the cd. Could you give me pointers as to what CD support I should add/enable in ADLO? Thanks, Myles Here is the output of the boot (First it tries the CD, then the HDD): Enter boot: hdb1:/boot/adlo.cd.elf hda: LBA: IC35L020AVER07-0 hdb: LBA: WDC WD800JB-00JJC0 Mounted ext2fs Loading image... Loaded 66560 bytes in 55ms (1210KB/s) Jumping to entry point... $Revision: 1.163 $ $Date: 2006/07/07 16:10:37 $ Bochs BIOS - build: 06/23/99 $Revision: 1.163 $ $Date: 2006/07/07 16:10:37 $ Options: eltorito ata0 master: Unknown device ata1 master: SONY DVD-ROM DDU1615 ATAPI-7 CD-Rom/DVD-Rom CDROM boot failure code : 0003 Boot from CD-Rom failed int13_harddisk: function 02, unmapped device for ELDL=80 Boot from Hard Disk 0 failed FATAL: INT18: BOOT FAILURE From todthgie at hotmail.com Fri Sep 7 21:58:48 2007 From: todthgie at hotmail.com (todthgie) Date: Fri, 7 Sep 2007 21:58:48 +0200 Subject: [LinuxBIOS] Status of the via vt82c686 southbridge? References: <46E1942D.4090403@comcast.net> Message-ID: im working on a board with this one ... here it is also the supreio ! my findings: - early_serial works - early_smbus is missing (i added it here and what i added works ... i will post patches soon) - ide is also missing im adding this right now - i could not test the rest yet .... ----- Original Message ----- From: "Adam Talbot" To: Sent: Friday, September 07, 2007 20:10 Subject: [LinuxBIOS] Status of the via vt82c686 southbridge? > What is the current status of the via vt82c686 southbridge? > -Adam > > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > From rminnich at gmail.com Fri Sep 7 21:58:44 2007 From: rminnich at gmail.com (ron minnich) Date: Fri, 7 Sep 2007 12:58:44 -0700 Subject: [LinuxBIOS] PATCH: add the pcengines ALIX1 Message-ID: <13426df10709071258u5096ea78x2514c53dfb509e08@mail.gmail.com> Attached: ron -------------- next part -------------- A non-text attachment was scrubbed... Name: ALIX1.diff Type: text/x-patch Size: 6876 bytes Desc: not available URL: From bari at onelabs.com Fri Sep 7 23:26:32 2007 From: bari at onelabs.com (bari) Date: Fri, 07 Sep 2007 16:26:32 -0500 Subject: [LinuxBIOS] Another SPI Programmer Message-ID: <46E1C208.4020509@onelabs.com> We're still working on the PLAICE but I came across this if someone wants to try it. It's an inexpensive in-circuit PC Parallel Port SPI Flash Programmer design. It could be used along with the clip-on adapters we are going to use for the PLAICE http://flash-plaice.wikispaces.com/ Simple PC Parallel Port SPI Flash Programmer Design http://www.kmitl.ac.th/~kswichit%20/SPI_Pgm/SPI-Pgm37.html The free application software is windoz only. Pomona SOIC Clip Test Adapter, 8-Pin Datasheet http://www.pomonaelectronics.com/pdf/d5250-54_5437_1_01.pdf Pomona SOIC Clip Test Adapter, 8-Pin $9.80 US http://www.hmcelectronics.com/cgi-bin/scripts/product/7420-0001/ -Bari From uwe at hermann-uwe.de Fri Sep 7 23:35:32 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 7 Sep 2007 23:35:32 +0200 Subject: [LinuxBIOS] PATCH: add the pcengines ALIX1 In-Reply-To: <13426df10709071258u5096ea78x2514c53dfb509e08@mail.gmail.com> References: <13426df10709071258u5096ea78x2514c53dfb509e08@mail.gmail.com> Message-ID: <20070907213532.GG10747@greenwood> On Fri, Sep 07, 2007 at 12:58:44PM -0700, ron minnich wrote: > This is the initial config for the ALIX1 > Signed-off-by: Ronald G. Minnich Nice, but needs some fixing I think: $ ./buildtarget pcengines/ALIX1 build_dir=pcengines/ALIX1/ALIX1 No linuxbios config script found. Rebuilding it.. Input Grammar: /tmp/v2/util/newconfig/config.g Output File: pcengines/ALIX1/ALIX1/config.py Configuring TARGET ALIX1 Will place Makefile, crt0.S, etc. in pcengines/ALIX1/ALIX1 ===> ERROR: Could not open file "/tmp/v2/src/mainboard/pcengines/ALIX1/Options.lb" pcengines/ALIX1/Config.lb:0 > Index: src/mainboard/pcengines/ALIX1/Config.lb Please use all-lowercase for the directory name on the filesystem, i.e. src/mainboard/pcengines/alix1 But use the correct name when referring to the board in strings or comments or READMEs etc. Is this the board we're talking about? http://www.pcengines.ch/alix1c.htm In that case the directory name should be 'alix1c' IMO, and the full name should be 'ALIX1.C' as per website and vendor PDF. > Index: targets/pcengines/ALIX1/Config.lb > =================================================================== > --- targets/pcengines/ALIX1/Config.lb (revision 0) > +++ targets/pcengines/ALIX1/Config.lb (revision 0) > @@ -0,0 +1,26 @@ > +target ALIX1 target alix1c > +mainboard pcengines/ALIX1 mainboard pcengines/alix1c Do you have a full list of tested and working devices (floppy, USB, IDE, audio, etc. etc. as appropriate for this board)? And even more important a list of stuff which does _not_ yet work? 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 rminnich at gmail.com Sat Sep 8 00:19:02 2007 From: rminnich at gmail.com (ron minnich) Date: Fri, 7 Sep 2007 15:19:02 -0700 Subject: [LinuxBIOS] PATCH: add the pcengines ALIX1 In-Reply-To: <20070907213532.GG10747@greenwood> References: <13426df10709071258u5096ea78x2514c53dfb509e08@mail.gmail.com> <20070907213532.GG10747@greenwood> Message-ID: <13426df10709071519j573fc684ta3f803fc669c7f0b@mail.gmail.com> Hi, the vendor requested ALIX1 but I will go back and ask. Sorry for the screwup on the name. As for "what works", I tried to make the Config.lb match "what works" thanks, I will repost the patch. ron From uwe at hermann-uwe.de Sat Sep 8 00:30:01 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 8 Sep 2007 00:30:01 +0200 Subject: [LinuxBIOS] [PATCH] v3: Add support for building on Debian GNU/kFreeBSD Message-ID: <20070907223001.GH10747@greenwood> See patch. The hostname/dnsdomainname stuff might need to be reworked a bit, I'll post another patch for that later... 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: v3_kfreebsd.patch Type: text/x-diff Size: 2530 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 augusto.pedroza at gmail.com Sat Sep 8 02:23:29 2007 From: augusto.pedroza at gmail.com (Augusto Pedroza) Date: Fri, 7 Sep 2007 21:23:29 -0300 Subject: [LinuxBIOS] LinuxBIOS - Booting Windows XP In-Reply-To: <024301c7f188$d4e59350$4d22040a@chimp> References: <024301c7f188$d4e59350$4d22040a@chimp> Message-ID: Hi Myles, in the xpboot.diff the following alterations should be made: In the file: util/ADLO/loader.s comment out or remove the lines 177 until 180: ;mov al, #0x3d ;; cmos_reg ;out 0x70, al ;mov al, #0x02 ;; val (hdd) ;out 0x71, al In the file: util/ADLO/bochs/bios/rombios.c uncomment line 147: #define BX_ELTORITO_BOOT 1 Have you done these alterations already? Also try booting your windows installation CD with qemu default's BIOS and let me know the result please. Thanks, Augusto Pedroza On 9/7/07, Myles Watson wrote: > > > http://www.linuxbios.org/Booting_Windows_using_LinuxBIOS > > > Feel free to test it and give some feedback!! > > I can get it to find my CD-ROM drive, but it fails with code: 0003. > > According to http://bochs.sourceforge.net/doc/docbook/user/bios-tips.html > that means: > > For this error, the cdrom support has not been compiled in Bochs, or Bochs > could not open the file or device. This is what you get if Bochs is not > able > to read the cd. > > Could you give me pointers as to what CD support I should add/enable in > ADLO? > > Thanks, > Myles > > Here is the output of the boot (First it tries the CD, then the HDD): > > Enter boot: hdb1:/boot/adlo.cd.elf > hda: LBA: IC35L020AVER07-0 > hdb: LBA: WDC WD800JB-00JJC0 > Mounted ext2fs > Loading image... > Loaded 66560 bytes in 55ms (1210KB/s) > Jumping to entry point... > $Revision: 1.163 $ $Date: 2006/07/07 16:10:37 $ > Bochs BIOS - build: 06/23/99 > $Revision: 1.163 $ $Date: 2006/07/07 16:10:37 $ > Options: eltorito > > ata0 master: Unknown device > ata1 master: SONY DVD-ROM DDU1615 ATAPI-7 CD-Rom/DVD-Rom > > CDROM boot failure code : 0003 > Boot from CD-Rom failed > int13_harddisk: function 02, unmapped device for ELDL=80 > Boot from Hard Disk 0 failed > FATAL: INT18: BOOT FAILURE > > > > > -- Augusto Pedroza -------------- next part -------------- An HTML attachment was scrubbed... URL: From augusto.pedroza at gmail.com Sat Sep 8 02:27:47 2007 From: augusto.pedroza at gmail.com (Augusto Pedroza) Date: Fri, 7 Sep 2007 21:27:47 -0300 Subject: [LinuxBIOS] [RFC] ADLO2 In-Reply-To: <13426df10709042123h60e235d6sf47855ef4774a26f@mail.gmail.com> References: <1188947195.17055.59.camel@localhost> <1188947538.17055.64.camel@localhost> <13426df10709042123h60e235d6sf47855ef4774a26f@mail.gmail.com> Message-ID: Hi, Do you think this new version of ADLO is able of booting Windows XP the way it is? Should I add my modifications to it ? (xpboot.diff) On 9/5/07, ron minnich wrote: > > can someone with an XP license try to recreate Alex's fine work? The > more people we get to try this, the better! > > thanks > > ron > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > -- Augusto Pedroza -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Sat Sep 8 02:41:53 2007 From: rminnich at gmail.com (ron minnich) Date: Fri, 7 Sep 2007 17:41:53 -0700 Subject: [LinuxBIOS] http://linuxbios.eu/ Message-ID: <13426df10709071741o8508da9w4bef2c1ec0cdad85@mail.gmail.com> I don't know if I am supposed to mention this, but time is running short for those of you who might need to make plans. If you can hold these dates open, I will try to find out if it is on or not. Also, there will likely be a linuxbios symposium in denver, CO, USA, next april. ron From peter at stuge.se Sat Sep 8 04:21:58 2007 From: peter at stuge.se (Peter Stuge) Date: Sat, 8 Sep 2007 04:21:58 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: References: <20070905175559.11458.qmail@stuge.se> Message-ID: <20070908022158.5237.qmail@stuge.se> On Fri, Sep 07, 2007 at 09:17:14PM +0200, todthgie wrote: > ----- Original Message ----- > From: "Peter Stuge" > To: > Sent: Wednesday, September 05, 2007 19:55 > > > The only signal we can work with is CS# > > how about #HOLD ? It's not good enough on it's own. Check out the MX flash chip data sheet. The HOLD state in the chip depends on CS# as well, plus the HOLD# pin is connected across both U5 and U9 which makes it annoying to work with if we're going to use the U9 pads. //Peter From alex at rtfs.hu Sat Sep 8 14:02:50 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Sat, 08 Sep 2007 14:02:50 +0200 Subject: [LinuxBIOS] [RFC] Payload selector method Message-ID: <1189252970.26302.125.camel@localhost> Hi, After playing around with lbmenu, I came up with the following idea to select payloads in a clean way. 1a, linuxbios parses the payload number cmos position, and starts the selected payload or 1b, linuxbios loads a payload (lbmenu), and passes control to it 2, lbmenu parses the lar 3, the user selects which payload to run 4, lbmenu writes the payloads number (position in lar) to a cmos variable and gives back control (point 1a) Imho it is better to have always the 1a, way running, but we have to be sure the cmos contains a valid value. Of course with this method payload selection can be repeated as much times as we want in a single run. -- Alex From lemenkov at gmail.com Sat Sep 8 15:05:02 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Sat, 8 Sep 2007 17:05:02 +0400 Subject: [LinuxBIOS] FYI flashrom included in Fedora Linux since yesterday. Message-ID: Hello All! Now not only a debian users can install it w/o any effords, but Fedora Linux users too. $ sudo yum install flashrom Although this handy tool still in pending state for pushing into Fedora 7 updates testing repository (just formal procedure but it takes some time) users of Fedora Core 6 and Fedora Development may install it as soon as mirrors will be synchronized with main Fedora source. Another one think I want to say - we have wishlist with small amount of entries: ================================================== ---------- Forwarded message ---------- From: bugzilla at redhat.com Date: 06.09.2007 19:50 Subject: [Bug 250924] Review Request: flashrom - Simple program for reading/writing BIOS chips content To: lemenkov at gmail.com [sorry, skipped] Optional: Can you ask upstream to add an license header to udelay.c and include a copy of their license in the repository? There are some build warnings that should be reported upstream: layout.c: In function 'read_romlayout': layout.c:114: warning: ignoring return value of 'fscanf', declared with attribute warn_unused_result flashrom.c: In function 'main': flashrom.c:402: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result flashrom.c:421: warning: ignoring return value of 'fread', declared with attribute warn_unused_result -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter. ================================================== And another one note - flashrom can't be built at PowerPC arch due to lack of . Does anybody also tried to build it at this arch? How powerpc-users of LinuxBIOS (if any) flash their machines? -- With best regards! From svn at openbios.org Sat Sep 8 16:36:01 2007 From: svn at openbios.org (svn at openbios.org) Date: Sat, 8 Sep 2007 16:36:01 +0200 Subject: [LinuxBIOS] r2764 - trunk/util/flashrom Message-ID: Author: uwe Date: 2007-09-08 16:36:01 +0200 (Sat, 08 Sep 2007) New Revision: 2764 Added: trunk/util/flashrom/COPYING Log: Add a copy of the GPL in the flashrom repository as it's an independent project (being packaged by distros, among other things). Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Added: trunk/util/flashrom/COPYING =================================================================== --- trunk/util/flashrom/COPYING (rev 0) +++ trunk/util/flashrom/COPYING 2007-09-08 14:36:01 UTC (rev 2764) @@ -0,0 +1,339 @@ + GNU GENERAL PUBLIC LICENSE + Version 2, June 1991 + + Copyright (C) 1989, 1991 Free Software Foundation, Inc., + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +License is intended to guarantee your freedom to share and change free +software--to make sure the software is free for all its users. This +General Public License applies to most of the Free Software +Foundation's software and to any other program whose authors commit to +using it. (Some other Free Software Foundation software is covered by +the GNU Lesser General Public License instead.) You can apply it to +your programs, too. + + When we speak of free software, we are referring to freedom, not +price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +this service if you wish), that you receive source code or can get it +if you want it, that you can change the software or use pieces of it +in new free programs; and that you know you can do these things. + + To protect your rights, we need to make restrictions that forbid +anyone to deny you these rights or to ask you to surrender the rights. +These restrictions translate to certain responsibilities for you if you +distribute copies of the software, or if you modify it. + + For example, if you distribute copies of such a program, whether +gratis or for a fee, you must give the recipients all the rights that +you have. You must make sure that they, too, receive or can get the +source code. And you must show them these terms so they know their +rights. + + We protect your rights with two steps: (1) copyright the software, and +(2) offer you this license which gives you legal permission to copy, +distribute and/or modify the software. + + Also, for each author's protection and ours, we want to make certain +that everyone understands that there is no warranty for this free +software. If the software is modified by someone else and passed on, we +want its recipients to know that what they have is not the original, so +that any problems introduced by others will not reflect on the original +authors' reputations. + + Finally, any free program is threatened constantly by software +patents. We wish to avoid the danger that redistributors of a free +program will individually obtain patent licenses, in effect making the +program proprietary. To prevent this, we have made it clear that any +patent must be licensed for everyone's free use or not licensed at all. + + The precise terms and conditions for copying, distribution and +modification follow. + + GNU GENERAL PUBLIC LICENSE + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION + + 0. This License applies to any program or other work which contains +a notice placed by the copyright holder saying it may be distributed +under the terms of this General Public License. The "Program", below, +refers to any such program or work, and a "work based on the Program" +means either the Program or any derivative work under copyright law: +that is to say, a work containing the Program or a portion of it, +either verbatim or with modifications and/or translated into another +language. (Hereinafter, translation is included without limitation in +the term "modification".) Each licensee is addressed as "you". + +Activities other than copying, distribution and modification are not +covered by this License; they are outside its scope. The act of +running the Program is not restricted, and the output from the Program +is covered only if its contents constitute a work based on the +Program (independent of having been made by running the Program). +Whether that is true depends on what the Program does. + + 1. You may copy and distribute verbatim copies of the Program's +source code as you receive it, in any medium, provided that you +conspicuously and appropriately publish on each copy an appropriate +copyright notice and disclaimer of warranty; keep intact all the +notices that refer to this License and to the absence of any warranty; +and give any other recipients of the Program a copy of this License +along with the Program. + +You may charge a fee for the physical act of transferring a copy, and +you may at your option offer warranty protection in exchange for a fee. + + 2. You may modify your copy or copies of the Program or any portion +of it, thus forming a work based on the Program, and copy and +distribute such modifications or work under the terms of Section 1 +above, provided that you also meet all of these conditions: + + a) You must cause the modified files to carry prominent notices + stating that you changed the files and the date of any change. + + b) You must cause any work that you distribute or publish, that in + whole or in part contains or is derived from the Program or any + part thereof, to be licensed as a whole at no charge to all third + parties under the terms of this License. + + c) If the modified program normally reads commands interactively + when run, you must cause it, when started running for such + interactive use in the most ordinary way, to print or display an + announcement including an appropriate copyright notice and a + notice that there is no warranty (or else, saying that you provide + a warranty) and that users may redistribute the program under + these conditions, and telling the user how to view a copy of this + License. (Exception: if the Program itself is interactive but + does not normally print such an announcement, your work based on + the Program is not required to print an announcement.) + +These requirements apply to the modified work as a whole. If +identifiable sections of that work are not derived from the Program, +and can be reasonably considered independent and separate works in +themselves, then this License, and its terms, do not apply to those +sections when you distribute them as separate works. But when you +distribute the same sections as part of a whole which is a work based +on the Program, the distribution of the whole must be on the terms of +this License, whose permissions for other licensees extend to the +entire whole, and thus to each and every part regardless of who wrote it. + +Thus, it is not the intent of this section to claim rights or contest +your rights to work written entirely by you; rather, the intent is to +exercise the right to control the distribution of derivative or +collective works based on the Program. + +In addition, mere aggregation of another work not based on the Program +with the Program (or with a work based on the Program) on a volume of +a storage or distribution medium does not bring the other work under +the scope of this License. + + 3. You may copy and distribute the Program (or a work based on it, +under Section 2) in object code or executable form under the terms of +Sections 1 and 2 above provided that you also do one of the following: + + a) Accompany it with the complete corresponding machine-readable + source code, which must be distributed under the terms of Sections + 1 and 2 above on a medium customarily used for software interchange; or, + + b) Accompany it with a written offer, valid for at least three + years, to give any third party, for a charge no more than your + cost of physically performing source distribution, a complete + machine-readable copy of the corresponding source code, to be + distributed under the terms of Sections 1 and 2 above on a medium + customarily used for software interchange; or, + + c) Accompany it with the information you received as to the offer + to distribute corresponding source code. (This alternative is + allowed only for noncommercial distribution and only if you + received the program in object code or executable form with such + an offer, in accord with Subsection b above.) + +The source code for a work means the preferred form of the work for +making modifications to it. For an executable work, complete source +code means all the source code for all modules it contains, plus any +associated interface definition files, plus the scripts used to +control compilation and installation of the executable. However, as a +special exception, the source code distributed need not include +anything that is normally distributed (in either source or binary +form) with the major components (compiler, kernel, and so on) of the +operating system on which the executable runs, unless that component +itself accompanies the executable. + +If distribution of executable or object code is made by offering +access to copy from a designated place, then offering equivalent +access to copy the source code from the same place counts as +distribution of the source code, even though third parties are not +compelled to copy the source along with the object code. + + 4. You may not copy, modify, sublicense, or distribute the Program +except as expressly provided under this License. Any attempt +otherwise to copy, modify, sublicense or distribute the Program is +void, and will automatically terminate your rights under this License. +However, parties who have received copies, or rights, from you under +this License will not have their licenses terminated so long as such +parties remain in full compliance. + + 5. You are not required to accept this License, since you have not +signed it. However, nothing else grants you permission to modify or +distribute the Program or its derivative works. These actions are +prohibited by law if you do not accept this License. Therefore, by +modifying or distributing the Program (or any work based on the +Program), you indicate your acceptance of this License to do so, and +all its terms and conditions for copying, distributing or modifying +the Program or works based on it. + + 6. Each time you redistribute the Program (or any work based on the +Program), the recipient automatically receives a license from the +original licensor to copy, distribute or modify the Program subject to +these terms and conditions. You may not impose any further +restrictions on the recipients' exercise of the rights granted herein. +You are not responsible for enforcing compliance by third parties to +this License. + + 7. If, as a consequence of a court judgment or allegation of patent +infringement or for any other reason (not limited to patent issues), +conditions are imposed on you (whether by court order, agreement or +otherwise) that contradict the conditions of this License, they do not +excuse you from the conditions of this License. If you cannot +distribute so as to satisfy simultaneously your obligations under this +License and any other pertinent obligations, then as a consequence you +may not distribute the Program at all. For example, if a patent +license would not permit royalty-free redistribution of the Program by +all those who receive copies directly or indirectly through you, then +the only way you could satisfy both it and this License would be to +refrain entirely from distribution of the Program. + +If any portion of this section is held invalid or unenforceable under +any particular circumstance, the balance of the section is intended to +apply and the section as a whole is intended to apply in other +circumstances. + +It is not the purpose of this section to induce you to infringe any +patents or other property right claims or to contest validity of any +such claims; this section has the sole purpose of protecting the +integrity of the free software distribution system, which is +implemented by public license practices. Many people have made +generous contributions to the wide range of software distributed +through that system in reliance on consistent application of that +system; it is up to the author/donor to decide if he or she is willing +to distribute software through any other system and a licensee cannot +impose that choice. + +This section is intended to make thoroughly clear what is believed to +be a consequence of the rest of this License. + + 8. If the distribution and/or use of the Program is restricted in +certain countries either by patents or by copyrighted interfaces, the +original copyright holder who places the Program under this License +may add an explicit geographical distribution limitation excluding +those countries, so that distribution is permitted only in or among +countries not thus excluded. In such case, this License incorporates +the limitation as if written in the body of this License. + + 9. The Free Software Foundation may publish revised and/or new versions +of the General Public License from time to time. Such new versions will +be similar in spirit to the present version, but may differ in detail to +address new problems or concerns. + +Each version is given a distinguishing version number. If the Program +specifies a version number of this License which applies to it and "any +later version", you have the option of following the terms and conditions +either of that version or of any later version published by the Free +Software Foundation. If the Program does not specify a version number of +this License, you may choose any version ever published by the Free Software +Foundation. + + 10. If you wish to incorporate parts of the Program into other free +programs whose distribution conditions are different, write to the author +to ask for permission. For software which is copyrighted by the Free +Software Foundation, write to the Free Software Foundation; we sometimes +make exceptions for this. Our decision will be guided by the two goals +of preserving the free status of all derivatives of our free software and +of promoting the sharing and reuse of software generally. + + NO WARRANTY + + 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY +FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN +OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES +PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED +OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS +TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE +PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, +REPAIR OR CORRECTION. + + 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING +WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR +REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, +INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING +OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED +TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY +YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER +PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE +POSSIBILITY OF SUCH DAMAGES. + + END OF TERMS AND CONDITIONS + + How to Apply These Terms to Your New Programs + + If you develop a new program, and you want it to be of the greatest +possible use to the public, the best way to achieve this is to make it +free software which everyone can redistribute and change under these terms. + + To do so, attach the following notices to the program. It is safest +to attach them to the start of each source file to most effectively +convey the exclusion of warranty; and each file should have at least +the "copyright" line and a pointer to where the full notice is found. + + + Copyright (C) + + 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 Street, Fifth Floor, Boston, MA 02110-1301 USA. + +Also add information on how to contact you by electronic and paper mail. + +If the program is interactive, make it output a short notice like this +when it starts in an interactive mode: + + Gnomovision version 69, Copyright (C) year name of author + Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. + This is free software, and you are welcome to redistribute it + under certain conditions; type `show c' for details. + +The hypothetical commands `show w' and `show c' should show the appropriate +parts of the General Public License. Of course, the commands you use may +be called something other than `show w' and `show c'; they could even be +mouse-clicks or menu items--whatever suits your program. + +You should also get your employer (if you work as a programmer) or your +school, if any, to sign a "copyright disclaimer" for the program, if +necessary. Here is a sample; alter the names: + + Yoyodyne, Inc., hereby disclaims all copyright interest in the program + `Gnomovision' (which makes passes at compilers) written by James Hacker. + + , 1 April 1989 + Ty Coon, President of Vice + +This General Public License does not permit incorporating your program into +proprietary programs. If your program is a subroutine library, you may +consider it more useful to permit linking proprietary applications with the +library. If this is what you want to do, use the GNU Lesser General +Public License instead of this License. From alex at rtfs.hu Sat Sep 8 16:49:46 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Sat, 08 Sep 2007 16:49:46 +0200 Subject: [LinuxBIOS] [PATCH] Flashrom: sis630 simplification Message-ID: <1189262986.26302.129.camel@localhost> Hi, attached patch changes out/in combinations to pci_read/write_byte in sis630 chipset enable. -- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: sis630.diff Type: text/x-patch Size: 701 bytes Desc: not available URL: From info at coresystems.de Sat Sep 8 17:21:22 2007 From: info at coresystems.de (LinuxBIOS information) Date: Sat, 08 Sep 2007 17:21:22 +0200 Subject: [LinuxBIOS] r2764 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2764 to the LinuxBIOS source repository and caused the following changes: Change Log: Add a copy of the GPL in the flashrom repository as it's an independent project (being packaged by distros, among other things). Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2764&device=hdama&vendor=arima Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2764&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2764&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2764&device=juki-511p&vendor=iei Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2764&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2764&device=dk8x&vendor=iwill If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From joe at smittys.pointclark.net Sat Sep 8 18:00:28 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Sat, 08 Sep 2007 12:00:28 -0400 Subject: [LinuxBIOS] RCA RM4100 almost running PLEASE HELP! In-Reply-To: <20070906153154.ugapwqblnowk00kk@www.smittys.pointclark.net> References: <20070904003300.jtpivs51c0www4g8@www.smittys.pointclark.net> <46DCE517.4010806@gmail.com> <20070904014027.mumag6jjvowos88c@www.smittys.pointclark.net> <46DD0DA7.7020706@gmail.com> <20070904052140.1kiwmfm0co40wkc4@www.smittys.pointclark.net> <20070906003926.en0tu9e4roswksws@www.smittys.pointclark.net> <20070906153154.ugapwqblnowk00kk@www.smittys.pointclark.net> Message-ID: <20070908120028.k1gxdg4rj4kwwcww@simittys.pointclark.net> Quoting Joseph Smith : > i82830 Northbridge > i82801db Southbridge (using i82801XX) > SMSC lpc47m192 Superio (using smscsuperio) > > It just freezes at this point, any ideas?? > I have attach my bootlog so you can see all the messages (only 27k). > > ------------------------ Done setting resources. Done allocating resources. Enabling resources... PCI: 00:00.0 cmd <- 146 PCI: 00:02.0 subsystem <- 00/00 PCI: 00:02.0 cmd <- 142 PCI: 00:1d.0 cmd <- 141 PCI: 00:1d.1 cmd <- 141 PCI: 00:1d.2 cmd <- 141 PCI: 00:1d.7 subsystem <- 00/00 PCI: 00:1d.7 cmd <- 142 PCI: 00:1e.0 bridge ctrl <- 0003 PCI: 00:1e.0 cmd <- 141 > ------------------------ > > Help? > > Thanks - Joe Can someone please take a look at this? It is driving me crazy I don't know what is wrong? Thanks - Joe -------------- next part -------------- LinuxBIOS-2.0.0.0Fallback Sat Sep 8 11:46:01 EDT 2007 starting... Setting initial registers.... Initial registers have been set. No DIMM found in slot 00 DRB 0x60 has been set to 0x00 DRB1 0x61 has been set to 0x00 Found DIMM in slot 01 DIMM is 0x0080 on side 1 DIMM is 0x0000 on side 2 DRB2 0x62 has been set to 0x04 DRB3 0x63 has been set to 0x04 No DIMM found in slot 00, setting DRA to 0xFF DRA 0x70 has been set to 0xff Found DIMM in slot 01, setting DRA... DRA 0x71 has been set to 0xf1 RAM Enable 1: Apply NOP Sending RAM command 0x00000010 to 0x00000000 RAM Enable 2: Precharge all Sending RAM command 0x00000020 to 0x00000000 RAM Enable 3: CBR Sending RAM command 0x00000060 to 0x00000000 RAM Enable 4: Mode register set Sending RAM command 0x00000030 to 0x000001d0 RAM Enable 5: Normal operation Sending RAM command 0x20000170 to 0x00000000 Northbridge following SDRAM init: PCI: 00:00.00 00: 86 80 75 35 06 00 10 00 04 00 00 06 00 00 00 00 10: 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 40: 09 00 05 01 00 00 00 00 00 00 00 00 02 28 00 0e 50: 72 a0 20 00 00 00 00 00 00 30 33 33 33 33 33 33 60: 00 00 04 04 00 00 00 00 00 00 00 00 00 00 00 00 70: ff f1 ff ff 00 00 00 00 10 00 00 00 70 01 00 20 80: 00 00 00 00 00 00 00 00 00 d0 20 40 00 00 00 00 90: 02 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 02 00 20 00 17 02 00 1f 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 54 0e 41 a2 99 01 00 c0 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 09 c9 9f fc f0: 11 11 01 00 00 00 0b 05 34 d6 30 cf 22 cf 23 cf Copying LinuxBIOS to RAM. Jumping to LinuxBIOS. LinuxBIOS-2.0.0.0Fallback Sat Sep 8 11:46:01 EDT 2007 booting... end 6cf785e5, start 0 32-bit delta 1566 calibrate_tsc 32-bit result is 1566 clocks_per_usec: 1566 Enumerating buses... scan_static_bus for Root Device Finding PCI configuration type. PCI: Using configuration type 1 PCI_DOMAIN: 0000 enabled PCI_DOMAIN: 0000 scanning... PCI: pci_scan_bus for bus 00 PCI: 00:00.0 [8086/3575] ops PCI: 00:00.0 [8086/3575] enabled PCI: devfn 0x9, bad id 0xffffffff PCI: devfn 0xa, bad id 0xffffffff PCI: devfn 0xb, bad id 0xffffffff PCI: devfn 0xc, bad id 0xffffffff PCI: devfn 0xd, bad id 0xffffffff PCI: devfn 0xe, bad id 0xffffffff PCI: devfn 0xf, bad id 0xffffffff PCI: 00:02.0 [8086/3577] enabled 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: 00:1d.0 [8086/24c2] ops PCI: 00:1d.0 [8086/24c2] enabled PCI: 00:1d.1 [8086/24c4] ops PCI: 00:1d.1 [8086/24c4] enabled PCI: 00:1d.2 [8086/24c7] ops PCI: 00:1d.2 [8086/24c7] enabled PCI: devfn 0xeb, bad id 0xffffffff PCI: devfn 0xec, bad id 0xffffffff PCI: devfn 0xed, bad id 0xffffffff PCI: devfn 0xee, bad id 0xffffffff PCI: 00:1d.7 [8086/24cd] ops PCI: 00:1d.7 [8086/24cd] enabled PCI: 00:1e.0 [8086/244e] bus ops PCI: 00:1e.0 [8086/244e] enabled PCI: 00:1f.0 [8086/24c0] bus ops PCI: 00:1f.0 [8086/24c0] enabled PCI: 00:1f.1 [8086/24cb] ops PCI: 00:1f.1 [8086/24cb] enabled PCI: devfn 0xfa, bad id 0xffffffff PCI: 00:1f.3 [8086/24c3] enabled PCI: devfn 0xfc, bad id 0xffffffff PCI: 00:1f.5 [8086/24c5] ops PCI: 00:1f.5 [8086/24c5] enabled PCI: 00:1f.6 [8086/24c6] ops PCI: 00:1f.6 [8086/24c6] enabled PCI: devfn 0xff, bad id 0xffffffff do_pci_scan_bridge for PCI: 00:1e.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 scan_static_bus for PCI: 00:1f.0 Found SMSC Super I/O (ID=0x60, rev=0x01) PNP: 002e.0 disabled PNP: 002e.3 disabled PNP: 002e.4 enabled PNP: 002e.5 disabled PNP: 002e.7 enabled PNP: 002e.9 disabled PNP: 002e.a enabled PNP: 002e.b disabled scan_static_bus for PCI: 00:1f.0 done PCI: pci_scan_bus returning with max=001 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:00.0 register 10(00000008), read-only ignoring it PCI: 00:1e.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 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: 0000f000 size: 00000000 align: 12 gran: 12 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 link: 0 done PCI: 00:1e.0 compute_allocate_io: base: 0000f000 size: 00000000 align: 12 gran: 12 done PCI: 00:1e.0 1c <- [0x000000f000 - 0x000000efff] bus 01 io PCI: 00:1e.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 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: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 link: 0 done PCI: 00:1e.0 compute_allocate_prefmem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1e.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 01 prefmem PCI: 00:1e.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 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 1 link: 0 PCI: 00:1e.0 read_resources bus 1 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 01 mem PCI: 00:1f.0 read_resources bus 0 link: 0 PCI: 00:1f.0 read_resources bus 0 link: 0 done PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done Root Device read_resources bus 0 link: 0 done PCI: 00:1f.5 10 * [0x00000400 - 0x000004ff] io PCI: 00:1f.6 10 * [0x00000800 - 0x000008ff] io PCI: 00:1f.6 14 * [0x00000c00 - 0x00000c7f] io PCI: 00:1f.5 14 * [0x00000c80 - 0x00000cbf] io PCI: 00:1d.0 20 * [0x00000cc0 - 0x00000cdf] io PCI: 00:1d.1 20 * [0x00000ce0 - 0x00000cff] io PCI: 00:1d.2 20 * [0x00001000 - 0x0000101f] io PCI: 00:1f.3 20 * [0x00001020 - 0x0000103f] io PCI: 00:1f.1 20 * [0x00001040 - 0x0000104f] io PCI: 00:1f.1 10 * [0x00001050 - 0x00001057] io PCI: 00:1f.1 18 * [0x00001060 - 0x00001067] io PCI: 00:1f.1 14 * [0x00001070 - 0x00001073] io PCI: 00:1f.1 1c * [0x00001080 - 0x00001083] io Root Device compute_allocate_io: base: 00001084 size: 00000c84 align: 8 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:02.0 10 * [0x00000000 - 0x07ffffff] prefmem PCI: 00:02.0 14 * [0x08000000 - 0x0807ffff] mem PCI: 00:1d.7 10 * [0x08080000 - 0x080803ff] mem PCI: 00:1f.1 24 * [0x08081000 - 0x080813ff] mem PCI: 00:1f.5 18 * [0x08082000 - 0x080821ff] mem PCI: 00:1f.5 1c * [0x08083000 - 0x080830ff] mem Root Device compute_allocate_mem: base: 08083100 size: 08083100 align: 27 gran: 0 done Done reading resources. Setting resources... Root Device compute_allocate_io: base: 00001000 size: 00000c84 align: 8 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:1f.5 10 * [0x00001000 - 0x000010ff] io PCI: 00:1f.6 10 * [0x00001400 - 0x000014ff] io PCI: 00:1f.6 14 * [0x00001800 - 0x0000187f] io PCI: 00:1f.5 14 * [0x00001880 - 0x000018bf] io PCI: 00:1d.0 20 * [0x000018c0 - 0x000018df] io PCI: 00:1d.1 20 * [0x000018e0 - 0x000018ff] io PCI: 00:1d.2 20 * [0x00001c00 - 0x00001c1f] io PCI: 00:1f.3 20 * [0x00001c20 - 0x00001c3f] io PCI: 00:1f.1 20 * [0x00001c40 - 0x00001c4f] io PCI: 00:1f.1 10 * [0x00001c50 - 0x00001c57] io PCI: 00:1f.1 18 * [0x00001c60 - 0x00001c67] io PCI: 00:1f.1 14 * [0x00001c70 - 0x00001c73] io PCI: 00:1f.1 1c * [0x00001c80 - 0x00001c83] io Root Device compute_allocate_io: base: 00001c84 size: 00000c84 align: 8 gran: 0 done Root Device compute_allocate_mem: base: f0000000 size: 08083100 align: 27 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:02.0 10 * [0xf0000000 - 0xf7ffffff] prefmem PCI: 00:02.0 14 * [0xf8000000 - 0xf807ffff] mem PCI: 00:1d.7 10 * [0xf8080000 - 0xf80803ff] mem PCI: 00:1f.1 24 * [0xf8081000 - 0xf80813ff] mem PCI: 00:1f.5 18 * [0xf8082000 - 0xf80821ff] mem PCI: 00:1f.5 1c * [0xf8083000 - 0xf80830ff] mem Root Device compute_allocate_mem: base: f8083100 size: 08083100 align: 27 gran: 0 done Root Device assign_resources, bus 0 link: 0 Setting RAM size to 131072 PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 PCI: 00:02.0 10 <- [0x00f0000000 - 0x00f7ffffff] prefmem PCI: 00:02.0 14 <- [0x00f8000000 - 0x00f807ffff] mem PCI: 00:1d.0 20 <- [0x00000018c0 - 0x00000018df] io PCI: 00:1d.1 20 <- [0x00000018e0 - 0x00000018ff] io PCI: 00:1d.2 20 <- [0x0000001c00 - 0x0000001c1f] io PCI: 00:1d.7 10 <- [0x00f8080000 - 0x00f80803ff] mem PCI: 00:1f.0 assign_resources, bus 0 link: 0 PNP: 002e.4 60 <- [0x00000003f8 - 0x00000003ff] io PNP: 002e.4 70 <- [0x0000000004 - 0x0000000004] irq PNP: 002e.7 60 <- [0x0000000060 - 0x0000000060] io PNP: 002e.7 62 <- [0x0000000064 - 0x0000000064] io PNP: 002e.7 70 <- [0x0000000001 - 0x0000000001] irq PNP: 002e.7 72 <- [0x000000000c - 0x000000000c] irq PNP: 002e.a 5d <- [0x0000000047 - 0x0000000046] io PNP: 002e.a 5e <- [0x0000000048 - 0x0000000047] io PCI: 00:1f.0 assign_resources, bus 0 link: 0 PCI: 00:1f.1 10 <- [0x0000001c50 - 0x0000001c57] io PCI: 00:1f.1 14 <- [0x0000001c70 - 0x0000001c73] io PCI: 00:1f.1 18 <- [0x0000001c60 - 0x0000001c67] io PCI: 00:1f.1 1c <- [0x0000001c80 - 0x0000001c83] io PCI: 00:1f.1 20 <- [0x0000001c40 - 0x0000001c4f] io PCI: 00:1f.1 24 <- [0x00f8081000 - 0x00f80813ff] mem PCI: 00:1f.3 20 <- [0x0000001c20 - 0x0000001c3f] io PCI: 00:1f.5 10 <- [0x0000001000 - 0x00000010ff] io PCI: 00:1f.5 14 <- [0x0000001880 - 0x00000018bf] io PCI: 00:1f.5 18 <- [0x00f8082000 - 0x00f80821ff] mem PCI: 00:1f.5 1c <- [0x00f8083000 - 0x00f80830ff] mem PCI: 00:1f.6 10 <- [0x0000001400 - 0x00000014ff] io PCI: 00:1f.6 14 <- [0x0000001800 - 0x000000187f] io 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:00.0 cmd <- 146 PCI: 00:02.0 subsystem <- 00/00 PCI: 00:02.0 cmd <- 142 PCI: 00:1d.0 cmd <- 141 PCI: 00:1d.1 cmd <- 141 PCI: 00:1d.2 cmd <- 141 PCI: 00:1d.7 subsystem <- 00/00 PCI: 00:1d.7 cmd <- 142 PCI: 00:1e.0 bridge ctrl <- 0003 PCI: 00:1e.0 cmd <- 141 LinuxBIOS-2.0.0.0Fallback Sat Sep 8 11:46:01 EDT 2007 starting... Setting initial registers.... Initial registers have been set. No DIMM found in slot 00 DRB 0x60 has been set to 0x00 DRB1 0x61 has been set to 0x00 Found DIMM in slot 01 DIMM is 0x0080 on side 1 DIMM is 0x0000 on side 2 DRB2 0x62 has been set to 0x04 DRB3 0x63 has been set to 0x04 No DIMM found in slot 00, setting DRA to 0xFF DRA 0x70 has been set to 0xff Found DIMM in slot 01, setting DRA... DRA 0x71 has been set to 0xf1 RAM Enable 1: Apply NOP Sending RAM command 0x00000010 to 0x00000000 RAM Enable 2: Precharge all Sending RAM command 0x00000020 to 0x00000000 RAM Enable 3: CBR Sending RAM command 0x00000060 to 0x00000000 RAM Enable 4: Mode register set Sending RAM command 0x00000030 to 0x000001d0 RAM Enable 5: Normal operation Sending RAM command 0x20000170 to 0x00000000 Northbridge following SDRAM init: PCI: 00:00.00 00: 86 80 75 35 06 00 10 00 04 00 00 06 00 00 00 00 10: 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 40: 09 00 05 01 00 00 00 00 00 00 00 00 02 28 00 0e 50: 72 a0 20 00 00 00 00 00 00 30 33 33 33 33 33 33 60: 00 00 04 04 00 00 00 00 00 00 00 00 00 00 00 00 70: ff f1 ff ff 00 00 00 00 10 00 00 00 70 01 00 20 80: 00 00 00 00 00 00 00 00 00 d0 20 40 00 00 00 00 90: 02 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 02 00 20 00 17 02 00 1f 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 54 0e 41 a2 99 01 00 c0 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 09 c9 9f fc f0: 11 11 01 00 00 00 0b 05 34 d6 33 cf 22 cf 27 cf Copying LinuxBIOS to RAM. Jumping to LinuxBIOS. LinuxBIOS-2.0.0.0Fallback Sat Sep 8 11:46:01 EDT 2007 booting... end 6cf6edcf, start 0 32-bit delta 1566 calibrate_tsc 32-bit result is 1566 clocks_per_usec: 1566 Enumerating buses... scan_static_bus for Root Device Finding PCI configuration type. PCI: Using configuration type 1 PCI_DOMAIN: 0000 enabled PCI_DOMAIN: 0000 scanning... PCI: pci_scan_bus for bus 00 PCI: 00:00.0 [8086/3575] ops PCI: 00:00.0 [8086/3575] enabled PCI: devfn 0x9, bad id 0xffffffff PCI: devfn 0xa, bad id 0xffffffff PCI: devfn 0xb, bad id 0xffffffff PCI: devfn 0xc, bad id 0xffffffff PCI: devfn 0xd, bad id 0xffffffff PCI: devfn 0xe, bad id 0xffffffff PCI: devfn 0xf, bad id 0xffffffff PCI: 00:02.0 [8086/3577] enabled 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: 00:1d.0 [8086/24c2] ops PCI: 00:1d.0 [8086/24c2] enabled PCI: 00:1d.1 [8086/24c4] ops PCI: 00:1d.1 [8086/24c4] enabled PCI: 00:1d.2 [8086/24c7] ops PCI: 00:1d.2 [8086/24c7] enabled PCI: devfn 0xeb, bad id 0xffffffff PCI: devfn 0xec, bad id 0xffffffff PCI: devfn 0xed, bad id 0xffffffff PCI: devfn 0xee, bad id 0xffffffff PCI: 00:1d.7 [8086/24cd] ops PCI: 00:1d.7 [8086/24cd] enabled PCI: 00:1e.0 [8086/244e] bus ops PCI: 00:1e.0 [8086/244e] enabled PCI: 00:1f.0 [8086/24c0] bus ops PCI: 00:1f.0 [8086/24c0] enabled PCI: 00:1f.1 [8086/24cb] ops PCI: 00:1f.1 [8086/24cb] enabled PCI: devfn 0xfa, bad id 0xffffffff PCI: 00:1f.3 [8086/24c3] enabled PCI: devfn 0xfc, bad id 0xffffffff PCI: 00:1f.5 [8086/24c5] ops PCI: 00:1f.5 [8086/24c5] enabled PCI: 00:1f.6 [8086/24c6] ops PCI: 00:1f.6 [8086/24c6] enabled PCI: devfn 0xff, bad id 0xffffffff do_pci_scan_bridge for PCI: 00:1e.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 scan_static_bus for PCI: 00:1f.0 Found SMSC Super I/O (ID=0x60, rev=0x01) PNP: 002e.0 disabled PNP: 002e.3 disabled PNP: 002e.4 enabled PNP: 002e.5 disabled PNP: 002e.7 enabled PNP: 002e.9 disabled PNP: 002e.a enabled PNP: 002e.b disabled scan_static_bus for PCI: 00:1f.0 done PCI: pci_scan_bus returning with max=001 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:00.0 register 10(00000008), read-only ignoring it PCI: 00:1e.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 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: 0000f000 size: 00000000 align: 12 gran: 12 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 link: 0 done PCI: 00:1e.0 compute_allocate_io: base: 0000f000 size: 00000000 align: 12 gran: 12 done PCI: 00:1e.0 1c <- [0x000000f000 - 0x000000efff] bus 01 io PCI: 00:1e.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 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: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 link: 0 done PCI: 00:1e.0 compute_allocate_prefmem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1e.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 01 prefmem PCI: 00:1e.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 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 1 link: 0 PCI: 00:1e.0 read_resources bus 1 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 01 mem PCI: 00:1f.0 read_resources bus 0 link: 0 PCI: 00:1f.0 read_resources bus 0 link: 0 done PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done Root Device read_resources bus 0 link: 0 done PCI: 00:1f.5 10 * [0x00000400 - 0x000004ff] io PCI: 00:1f.6 10 * [0x00000800 - 0x000008ff] io PCI: 00:1f.6 14 * [0x00000c00 - 0x00000c7f] io PCI: 00:1f.5 14 * [0x00000c80 - 0x00000cbf] io PCI: 00:1d.0 20 * [0x00000cc0 - 0x00000cdf] io PCI: 00:1d.1 20 * [0x00000ce0 - 0x00000cff] io PCI: 00:1d.2 20 * [0x00001000 - 0x0000101f] io PCI: 00:1f.3 20 * [0x00001020 - 0x0000103f] io PCI: 00:1f.1 20 * [0x00001040 - 0x0000104f] io PCI: 00:1f.1 10 * [0x00001050 - 0x00001057] io PCI: 00:1f.1 18 * [0x00001060 - 0x00001067] io PCI: 00:1f.1 14 * [0x00001070 - 0x00001073] io PCI: 00:1f.1 1c * [0x00001080 - 0x00001083] io Root Device compute_allocate_io: base: 00001084 size: 00000c84 align: 8 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:02.0 10 * [0x00000000 - 0x07ffffff] prefmem PCI: 00:02.0 14 * [0x08000000 - 0x0807ffff] mem PCI: 00:1d.7 10 * [0x08080000 - 0x080803ff] mem PCI: 00:1f.1 24 * [0x08081000 - 0x080813ff] mem PCI: 00:1f.5 18 * [0x08082000 - 0x080821ff] mem PCI: 00:1f.5 1c * [0x08083000 - 0x080830ff] mem Root Device compute_allocate_mem: base: 08083100 size: 08083100 align: 27 gran: 0 done Done reading resources. Setting resources... Root Device compute_allocate_io: base: 00001000 size: 00000c84 align: 8 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:1f.5 10 * [0x00001000 - 0x000010ff] io PCI: 00:1f.6 10 * [0x00001400 - 0x000014ff] io PCI: 00:1f.6 14 * [0x00001800 - 0x0000187f] io PCI: 00:1f.5 14 * [0x00001880 - 0x000018bf] io PCI: 00:1d.0 20 * [0x000018c0 - 0x000018df] io PCI: 00:1d.1 20 * [0x000018e0 - 0x000018ff] io PCI: 00:1d.2 20 * [0x00001c00 - 0x00001c1f] io PCI: 00:1f.3 20 * [0x00001c20 - 0x00001c3f] io PCI: 00:1f.1 20 * [0x00001c40 - 0x00001c4f] io PCI: 00:1f.1 10 * [0x00001c50 - 0x00001c57] io PCI: 00:1f.1 18 * [0x00001c60 - 0x00001c67] io PCI: 00:1f.1 14 * [0x00001c70 - 0x00001c73] io PCI: 00:1f.1 1c * [0x00001c80 - 0x00001c83] io Root Device compute_allocate_io: base: 00001c84 size: 00000c84 align: 8 gran: 0 done Root Device compute_allocate_mem: base: f0000000 size: 08083100 align: 27 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:02.0 10 * [0xf0000000 - 0xf7ffffff] prefmem PCI: 00:02.0 14 * [0xf8000000 - 0xf807ffff] mem PCI: 00:1d.7 10 * [0xf8080000 - 0xf80803ff] mem PCI: 00:1f.1 24 * [0xf8081000 - 0xf80813ff] mem PCI: 00:1f.5 18 * [0xf8082000 - 0xf80821ff] mem PCI: 00:1f.5 1c * [0xf8083000 - 0xf80830ff] mem Root Device compute_allocate_mem: base: f8083100 size: 08083100 align: 27 gran: 0 done Root Device assign_resources, bus 0 link: 0 Setting RAM size to 131072 PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 PCI: 00:02.0 10 <- [0x00f0000000 - 0x00f7ffffff] prefmem PCI: 00:02.0 14 <- [0x00f8000000 - 0x00f807ffff] mem PCI: 00:1d.0 20 <- [0x00000018c0 - 0x00000018df] io PCI: 00:1d.1 20 <- [0x00000018e0 - 0x00000018ff] io PCI: 00:1d.2 20 <- [0x0000001c00 - 0x0000001c1f] io PCI: 00:1d.7 10 <- [0x00f8080000 - 0x00f80803ff] mem PCI: 00:1f.0 assign_resources, bus 0 link: 0 PNP: 002e.4 60 <- [0x00000003f8 - 0x00000003ff] io PNP: 002e.4 70 <- [0x0000000004 - 0x0000000004] irq PNP: 002e.7 60 <- [0x0000000060 - 0x0000000060] io PNP: 002e.7 62 <- [0x0000000064 - 0x0000000064] io PNP: 002e.7 70 <- [0x0000000001 - 0x0000000001] irq PNP: 002e.7 72 <- [0x000000000c - 0x000000000c] irq PNP: 002e.a 5d <- [0x0000000047 - 0x0000000046] io PNP: 002e.a 5e <- [0x0000000048 - 0x0000000047] io PCI: 00:1f.0 assign_resources, bus 0 link: 0 PCI: 00:1f.1 10 <- [0x0000001c50 - 0x0000001c57] io PCI: 00:1f.1 14 <- [0x0000001c70 - 0x0000001c73] io PCI: 00:1f.1 18 <- [0x0000001c60 - 0x0000001c67] io PCI: 00:1f.1 1c <- [0x0000001c80 - 0x0000001c83] io PCI: 00:1f.1 20 <- [0x0000001c40 - 0x0000001c4f] io PCI: 00:1f.1 24 <- [0x00f8081000 - 0x00f80813ff] mem PCI: 00:1f.3 20 <- [0x0000001c20 - 0x0000001c3f] io PCI: 00:1f.5 10 <- [0x0000001000 - 0x00000010ff] io PCI: 00:1f.5 14 <- [0x0000001880 - 0x00000018bf] io PCI: 00:1f.5 18 <- [0x00f8082000 - 0x00f80821ff] mem PCI: 00:1f.5 1c <- [0x00f8083000 - 0x00f80830ff] mem PCI: 00:1f.6 10 <- [0x0000001400 - 0x00000014ff] io PCI: 00:1f.6 14 <- [0x0000001800 - 0x000000187f] io 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:00.0 cmd <- 146 PCI: 00:02.0 subsystem <- 00/00 PCI: 00:02.0 cmd <- 142 PCI: 00:1d.0 cmd <- 141 PCI: 00:1d.1 cmd <- 141 PCI: 00:1d.2 cmd <- 141 PCI: 00:1d.7 subsystem <- 00/00 PCI: 00:1d.7 cmd <- 142 PCI: 00:1e.0 bridge ctrl <- 0003 PCI: 00:1e.0 cmd <- 141 From rminnich at gmail.com Sat Sep 8 18:28:34 2007 From: rminnich at gmail.com (ron minnich) Date: Sat, 8 Sep 2007 09:28:34 -0700 Subject: [LinuxBIOS] PATCH: add the pcengines ALIX1 In-Reply-To: <20070907213532.GG10747@greenwood> References: <13426df10709071258u5096ea78x2514c53dfb509e08@mail.gmail.com> <20070907213532.GG10747@greenwood> Message-ID: <13426df10709080928o1e6d8febwa97572c9d263352@mail.gmail.com> Hi, here is try 2. This one builds :-) ron -------------- next part -------------- A non-text attachment was scrubbed... Name: alix1c.diff Type: text/x-patch Size: 32980 bytes Desc: not available URL: From peter at stuge.se Sat Sep 8 18:58:11 2007 From: peter at stuge.se (Peter Stuge) Date: Sat, 8 Sep 2007 18:58:11 +0200 Subject: [LinuxBIOS] [PATCH] v3: Add support for building on Debian GNU/kFreeBSD In-Reply-To: <20070907223001.GH10747@greenwood> References: <20070907223001.GH10747@greenwood> Message-ID: <20070908165811.17380.qmail@stuge.se> On Sat, Sep 08, 2007 at 12:30:01AM +0200, Uwe Hermann wrote: > Add support for building LinuxBIOSv3 on Debian GNU/kFreeBSD systems. Acked-by: Peter Stuge > - kFreeBSD has 'dnsdomainname' (as has Linux) instead of > 'domainname'. dnsdomainname is for DNS, domainname for NIS. //Peter From rminnich at gmail.com Sat Sep 8 19:25:41 2007 From: rminnich at gmail.com (ron minnich) Date: Sat, 8 Sep 2007 10:25:41 -0700 Subject: [LinuxBIOS] [PATCH] buildrom: initramfs skeleton In-Reply-To: <20070906142519.GE29891@localdomain> References: <20070906142519.GE29891@localdomain> Message-ID: <13426df10709081025w2b9d0cd4oc85d47a88f93428d@mail.gmail.com> Acked-by: Ronald G. Minnich On 9/6/07, Ward Vandewege wrote: > Update the initramfs skeleton to be less olpc specific. This skeleton needs > more generalization, but that's for later. > > -- > Ward Vandewege > Free Software Foundation - Senior System Administrator > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > > From rminnich at gmail.com Sat Sep 8 19:26:41 2007 From: rminnich at gmail.com (ron minnich) Date: Sat, 8 Sep 2007 10:26:41 -0700 Subject: [LinuxBIOS] [PATCH] buildrom: m57sli linux kernel config + makefile In-Reply-To: <20070906142507.GD29891@localdomain> References: <20070906142507.GD29891@localdomain> Message-ID: <13426df10709081026k35f67563w2fd99f24c35e90e8@mail.gmail.com> Acked-by: Ronald G. Minnich Ward you can commit right? ron On 9/6/07, Ward Vandewege wrote: > This adds the stripped down linux kernel config and the makefile necessary to > build it. > > Thanks, > Ward. > > -- > Ward Vandewege > Free Software Foundation - Senior System Administrator > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > > From rminnich at gmail.com Sat Sep 8 19:28:45 2007 From: rminnich at gmail.com (ron minnich) Date: Sat, 8 Sep 2007 10:28:45 -0700 Subject: [LinuxBIOS] [PATCH] buildrom: add packages/kernel/patches/tiny_m57sli In-Reply-To: <20070906142443.GC29891@localdomain> References: <20070906142443.GC29891@localdomain> Message-ID: <13426df10709081028m3fcaefc1k1a9113d26fa8e0d1@mail.gmail.com> On 9/6/07, Ward Vandewege wrote: > These patches are released under the GPLv2, so we can just include them in > our buildrom tree. Do we need a license header for each file? This comes from tiny, right? I think since it is a patch we are ok? Acked-by: Ronald G. Minnich I am glad to see LAB coming back. ron From rminnich at gmail.com Sat Sep 8 19:30:05 2007 From: rminnich at gmail.com (ron minnich) Date: Sat, 8 Sep 2007 10:30:05 -0700 Subject: [LinuxBIOS] [PATCH] buildrom: packages/linuxbios/m57sli-linuxbios.mk (revised) In-Reply-To: <20070906033848.GB26150@localdomain> References: <20070906033848.GB26150@localdomain> Message-ID: <13426df10709081030o2b122cdcr343f71e0c0471161@mail.gmail.com> Acked-by: Ronald G. Minnich On 9/5/07, Ward Vandewege wrote: > Removed the reference to the no-stack-protector patch. > > Thanks, > Ward. > > -- > Ward Vandewege > Free Software Foundation - Senior System Administrator > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > > From rminnich at gmail.com Sat Sep 8 19:31:18 2007 From: rminnich at gmail.com (ron minnich) Date: Sat, 8 Sep 2007 10:31:18 -0700 Subject: [LinuxBIOS] [PATCH] LAR: linearly count segment numbers In-Reply-To: <1189045829.26302.20.camel@localhost> References: <1189045829.26302.20.camel@localhost> Message-ID: <13426df10709081031k26eeb9a2s238f6ee45cee70c6@mail.gmail.com> Acked-by: Ronald G. Minnich On 9/5/07, Alex Beregszaszi wrote: > Hi, > > when outputting ELF segments in LAR, the utility will use the segment > number from ELF as segment number in the file. This works nicely when > there are no skips (e.g. not PT_LOAD segments, which are discarded). > > If one segment is skipped, we get a bump: > > normal/payload0/segment0 (27288 bytes, lzma compressed to 14506 bytes > @0x64c0) > normal/payload0/segment2 (211136 bytes, lzma compressed to 70905 bytes > @0x9dc0) > > The LAR loader wont load segment2, and in this particular case, grub2-lb > will only boot into rescue mode (segment0 contains it). > > Attached patch adds a counter for segment number in the LAR utility to > solve this bug: > > normal/payload0/segment0 (27288 bytes, lzma compressed to 14506 bytes > @0x64c0) > normal/payload0/segment1 (211136 bytes, lzma compressed to 70905 bytes > @0x9dc0) > > Also the eagle eyed can see that I merged in Uwe's multiple-payload > patch into current stage1, which includes the segment support. And this > means that grub2-lb without any hacks works when loaded from LAR > segments. > > -- > Alex > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > > From rminnich at gmail.com Sat Sep 8 19:38:03 2007 From: rminnich at gmail.com (ron minnich) Date: Sat, 8 Sep 2007 10:38:03 -0700 Subject: [LinuxBIOS] [RFC] Multiple payload support in v3 In-Reply-To: <1189046215.26302.26.camel@localhost> References: <1189046215.26302.26.camel@localhost> Message-ID: <13426df10709081038j2dcd6ccfob27bf04536ba5f5a@mail.gmail.com> This is a slight change. Did you verify this with a kernel payload? thanks ron From rminnich at gmail.com Sat Sep 8 19:39:37 2007 From: rminnich at gmail.com (ron minnich) Date: Sat, 8 Sep 2007 10:39:37 -0700 Subject: [LinuxBIOS] [PATCH] LAR verison field In-Reply-To: <1189040359.26302.7.camel@localhost> References: <1189040359.26302.7.camel@localhost> Message-ID: <13426df10709081039l5247cb5ai6b12860deaace799@mail.gmail.com> hi, we rejected this idea, right? I am trying to catch up on un-acked patches. ron On 9/5/07, Alex Beregszaszi wrote: > Hi, > > this adds a 32bit version field after the magic. I choose 200709061 as a starting version, where the last 1 is a counter ranging to 9, thus there can be 9 different version per day (lol). > > It is not going to try any backward compatibility or workaround based on version, just bail out or skip when a different version than we are running is encountered. > > It might be a better idea grouping len and offset fields after or before version field, and make then fixed by design, so we can do correct skipping instead the 16-byte aligned walking. > > Note: the "/* NOTE -- This and the user-mode lar.h are NOT IN SYNC. Be careful. */" message (which is present both in include/lar.h and utils/lar/lar.h) is not valid anymore. > -- > Alex > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > > From uwe at hermann-uwe.de Sat Sep 8 19:56:32 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 8 Sep 2007 19:56:32 +0200 Subject: [LinuxBIOS] [PATCH] Flashrom: sis630 simplification In-Reply-To: <1189262986.26302.129.camel@localhost> References: <1189262986.26302.129.camel@localhost> Message-ID: <20070908175631.GA18334@greenwood> On Sat, Sep 08, 2007 at 04:49:46PM +0200, Alex Beregszaszi wrote: > attached patch changes out/in combinations to pci_read/write_byte in > sis630 chipset enable. Why? Did you test the patch on hardware? Was the code broken before and works after the patch? If not, why change it? 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 rminnich at gmail.com Sat Sep 8 19:59:39 2007 From: rminnich at gmail.com (ron minnich) Date: Sat, 8 Sep 2007 10:59:39 -0700 Subject: [LinuxBIOS] [PATCH] Flashrom: sis630 simplification In-Reply-To: <1189262986.26302.129.camel@localhost> References: <1189262986.26302.129.camel@localhost> Message-ID: <13426df10709081059p547adebcud430e6243753f690@mail.gmail.com> I don't think this should be done unless someone can test. It looks right to me, but ... well ... hardware, you know :-) ron From stepan at coresystems.de Sat Sep 8 20:12:27 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 8 Sep 2007 20:12:27 +0200 Subject: [LinuxBIOS] [PATCH] v3: Add support for building on Debian GNU/kFreeBSD In-Reply-To: <20070907223001.GH10747@greenwood> References: <20070907223001.GH10747@greenwood> Message-ID: <20070908181227.GC14851@coresystems.de> * Uwe Hermann [070908 00:30]: > + $(Q)# On Debian GNU/kFreeBSD we need the linker output format > + $(Q)# 'elf32-i386-freebsd' instead of just 'elf32-i386'. > +ifneq (, $(filter Linux GNU GNU_%, $(shell uname -s))) I think stuff like this belongs in xcompile! -- 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 Sep 8 20:13:25 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 8 Sep 2007 20:13:25 +0200 Subject: [LinuxBIOS] PATCH: add the pcengines ALIX1 In-Reply-To: <13426df10709080928o1e6d8febwa97572c9d263352@mail.gmail.com> References: <13426df10709071258u5096ea78x2514c53dfb509e08@mail.gmail.com> <20070907213532.GG10747@greenwood> <13426df10709080928o1e6d8febwa97572c9d263352@mail.gmail.com> Message-ID: <20070908181325.GD14851@coresystems.de> * ron minnich [070908 18:28]: > Hi, here is try 2. This one builds :-) > > ron > Welcome to PC Engines and the ALIX 1C! > > This is a geode LX board. There are timing settings that are not right yet, we are > still trying to get our board to boot Linux :-) > > Signed-off-by: Ronald G. Minnich Acked-by: Stefan Reinauer 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 Sat Sep 8 20:15:51 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 8 Sep 2007 20:15:51 +0200 Subject: [LinuxBIOS] [PATCH] buildrom: m57sli linux kernel config + makefile In-Reply-To: <13426df10709081026k35f67563w2fd99f24c35e90e8@mail.gmail.com> References: <20070906142507.GD29891@localdomain> <13426df10709081026k35f67563w2fd99f24c35e90e8@mail.gmail.com> Message-ID: <20070908181551.GE14851@coresystems.de> * ron minnich [070908 19:26]: > Acked-by: Ronald G. Minnich > > Ward you can commit right? Yes indeed. Please go ahead and commit your fine patches. -- 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/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From yinghailu at gmail.com Sat Sep 8 20:16:13 2007 From: yinghailu at gmail.com (yhlu) Date: Sat, 8 Sep 2007 11:16:13 -0700 Subject: [LinuxBIOS] [PATCH] buildrom: m57sli linux kernel config + makefile In-Reply-To: <13426df10709081026k35f67563w2fd99f24c35e90e8@mail.gmail.com> References: <20070906142507.GD29891@localdomain> <13426df10709081026k35f67563w2fd99f24c35e90e8@mail.gmail.com> Message-ID: <2ea3fae10709081116g2d97a898o503a9bfb77b56a9@mail.gmail.com> can someone put the buildrom2.amd64 into the tree too? YH -------------- next part -------------- A non-text attachment was scrubbed... Name: buildrom2.amd64.tar.bz2 Type: application/x-bzip2 Size: 85610 bytes Desc: not available URL: From yinghailu at gmail.com Sat Sep 8 20:31:13 2007 From: yinghailu at gmail.com (yhlu) Date: Sat, 8 Sep 2007 11:31:13 -0700 Subject: [LinuxBIOS] [PATCH] buildrom: add packages/kernel/patches/tiny_m57sli In-Reply-To: <13426df10709081028m3fcaefc1k1a9113d26fa8e0d1@mail.gmail.com> References: <20070906142443.GC29891@localdomain> <13426df10709081028m3fcaefc1k1a9113d26fa8e0d1@mail.gmail.com> Message-ID: <2ea3fae10709081131m7c275f9fha9f7b18e1c65b0f4@mail.gmail.com> On 9/8/07, ron minnich wrote: > On 9/6/07, Ward Vandewege wrote: > > These patches are released under the GPLv2, so we can just include them in > > our buildrom tree. Do we need a license header for each file? > > > This comes from tiny, right? I think since it is a patch we are ok? we should put the URL in buildrom to download that quilt patchset from elinux.org like download linux tar ball... YH From svn at openbios.org Sat Sep 8 20:32:53 2007 From: svn at openbios.org (svn at openbios.org) Date: Sat, 8 Sep 2007 20:32:53 +0200 Subject: [LinuxBIOS] r2765 - in trunk/LinuxBIOSv2: src/mainboard src/mainboard/pcengines src/mainboard/pcengines/alix1c targets targets/pcengines targets/pcengines/alix1c Message-ID: Author: rminnich Date: 2007-09-08 20:32:53 +0200 (Sat, 08 Sep 2007) New Revision: 2765 Added: trunk/LinuxBIOSv2/src/mainboard/pcengines/ trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/ trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/Config.lb trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/Options.lb trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/cache_as_ram_auto.c trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/chip.h trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/cmos.layout trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/debug.c trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/failover.c trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/irq_tables.c trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/mainboard.c trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/reset.c trunk/LinuxBIOSv2/targets/pcengines/ trunk/LinuxBIOSv2/targets/pcengines/alix1c/ trunk/LinuxBIOSv2/targets/pcengines/alix1c/Config.lb Log: Welcome to PC Engines and the ALIX 1C! This is a geode LX board. There are timing settings that are not right yet, we are still trying to get our board to boot Linux :-) Signed-off-by: Ronald G. Minnich Acked-by: Stefan Reinauer Added: trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/Config.lb (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/Config.lb 2007-09-08 18:32:53 UTC (rev 2765) @@ -0,0 +1,206 @@ +## +## Compute the location and size of where this firmware image +## (linuxBIOS plus bootloader) will live in the boot rom chip. +## +if USE_FALLBACK_IMAGE + default ROM_SECTION_SIZE = FALLBACK_SIZE + default ROM_SECTION_OFFSET = ( ROM_SIZE - FALLBACK_SIZE ) +else + default ROM_SECTION_SIZE = ( ROM_SIZE - FALLBACK_SIZE ) + default ROM_SECTION_OFFSET = 0 +end + +## +## Compute the start location and size size of +## The linuxBIOS bootloader. +## +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_PAYLOAD_START + PAYLOAD_SIZE ) + +## +## Compute a range of ROM that can cached to speed up linuxBIOS, +## execution speed. +## +## XIP_ROM_SIZE must be a power of 2. +## XIP_ROM_BASE must be a multiple of XIP_ROM_SIZE +## +default XIP_ROM_SIZE=65536 +default XIP_ROM_BASE = ( _ROMBASE + ROM_IMAGE_SIZE - XIP_ROM_SIZE ) + +## +## Set all of the defaults for an x86 architecture +## + +arch i386 end + +## +## Build the objects we have code for in this directory. +## + +driver mainboard.o + +if HAVE_PIRQ_TABLE + object irq_tables.o +end + +if USE_DCACHE_RAM + #compile cache_as_ram.c to auto.inc + makerule ./cache_as_ram_auto.inc + depends "$(MAINBOARD)/cache_as_ram_auto.c option_table.h" + action "$(CC) -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/cache_as_ram_auto.c -Os -nostdinc -nostdlib -fno-builtin -Wall -c -S -o $@" + action "perl -e 's/.rodata/.rom.data/g' -pi $@" + action "perl -e 's/.text/.section .rom.text/g' -pi $@" + end +end + + + +## +## Build our 16 bit and 32 bit linuxBIOS entry code +## +mainboardinit cpu/x86/16bit/entry16.inc +mainboardinit cpu/x86/32bit/entry32.inc +ldscript /cpu/x86/16bit/entry16.lds +ldscript /cpu/x86/32bit/entry32.lds + +## +## Build our reset vector (This is where linuxBIOS is entered) +## +if USE_FALLBACK_IMAGE + mainboardinit cpu/x86/16bit/reset16.inc + ldscript /cpu/x86/16bit/reset16.lds +else + mainboardinit cpu/x86/32bit/reset32.inc + ldscript /cpu/x86/32bit/reset32.lds +end + +### Should this be in the northbridge code? +mainboardinit arch/i386/lib/cpu_reset.inc + +## +## Include an id string (For safe flashing) +## +mainboardinit arch/i386/lib/id.inc +ldscript /arch/i386/lib/id.lds + +### +### This is the early phase of linuxBIOS startup +### Things are delicate and we test to see if we should +### failover to another image. +### +if USE_FALLBACK_IMAGE + ldscript /arch/i386/lib/failover.lds +# mainboardinit ./failover.inc +end + +### +### O.k. We aren't just an intermediary anymore! +### + +## +## Setup RAM +## +mainboardinit cpu/x86/fpu/enable_fpu.inc + +if USE_DCACHE_RAM + mainboardinit cpu/amd/model_lx/cache_as_ram.inc + mainboardinit ./cache_as_ram_auto.inc +end + +## +## Include the secondary Configuration files +## +dir /pc80 +config chip.h + +chip northbridge/amd/lx + device pci_domain 0 on + device pci 1.0 on end + device pci 1.1 on end + chip southbridge/amd/cs5536 + # IRQ 12 and 1 unmasked, Keyboard and Mouse IRQs. OK + # SIRQ Mode = Active(Quiet) mode. Save power.... + # Invert mask = IRQ 12 and 1 are active high. Keyboard and Mouse IRQs. OK + # How to get these? Boot linux and do this: + # rdmsr 0x51400025 + register "lpc_serirq_enable" = "0x000010da" + # rdmsr 0x5140004e -- polairy is high 16 bits of low 32 bits + register "lpc_serirq_polarity" = "0x0000EF25" + # mode is high 10 bits (determined from code) + register "lpc_serirq_mode" = "1" + # Don't yet know how to find this. + register "enable_gpio_int_route" = "0x0D0C0700" + register "enable_ide_nand_flash" = "0" # 0:ide mode, 1:flash + register "enable_USBP4_device" = "0" #0: host, 1:device + register "enable_USBP4_overcurrent" = "0" #0:off, xxxx:overcurrent setting CS5536 Data Book (pages 380-381) + register "com1_enable" = "0" + register "com1_address" = "0x3F8" + register "com1_irq" = "4" + register "com2_enable" = "0" + register "com2_address" = "0x2F8" + register "com2_irq" = "3" + register "unwanted_vpci[0]" = "0" # End of list has a zero + device pci f.0 on # ISA Bridge + chip superio/winbond/w83627hf + device pnp 2e.0 off # Floppy + io 0x60 = 0x3f0 + irq 0x70 = 6 + drq 0x74 = 2 + end + device pnp 2e.1 on # Parallel Port + io 0x60 = 0x378 + irq 0x70 = 7 + end + device pnp 2e.2 on # Com1 + io 0x60 = 0x3f8 + irq 0x70 = 4 + end + device pnp 2e.3 on # Com2 + io 0x60 = 0x2f8 + irq 0x70 = 3 + end + device pnp 2e.5 on # Keyboard + io 0x60 = 0x60 + io 0x62 = 0x64 + irq 0x70 = 1 + irq 0x72 = 12 + end + device pnp 2e.6 off # CIR + io 0x60 = 0x100 + end + device pnp 2e.7 off # GAME_MIDI_GIPO1 + io 0x60 = 0x220 + io 0x62 = 0x300 + irq 0x70 = 9 + end + device pnp 2e.8 on end # GPIO2 + device pnp 2e.9 on end # GPIO3 + device pnp 2e.a on end # ACPI + device pnp 2e.b on # HW Monitor + io 0x60 = 0x290 + irq 0x70 = 5 + end + end + end + device pci f.1 on end # Flash controller + device pci f.2 on end # IDE controller + device pci f.3 on end # Audio + device pci f.4 on end # OHCI + device pci f.5 on end # EHCI + end + end + + # APIC cluster is late CPU init. + device apic_cluster 0 on + chip cpu/amd/model_lx + device apic 0 on end + end + end + +end + Added: trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/Options.lb (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/Options.lb 2007-09-08 18:32:53 UTC (rev 2765) @@ -0,0 +1,179 @@ +uses HAVE_MP_TABLE +uses HAVE_PIRQ_TABLE +uses USE_FALLBACK_IMAGE +uses HAVE_FALLBACK_BOOT +uses HAVE_HARD_RESET +uses HAVE_OPTION_TABLE +uses USE_OPTION_TABLE +uses CONFIG_ROM_PAYLOAD +uses IRQ_SLOT_COUNT +uses MAINBOARD +uses MAINBOARD_VENDOR +uses MAINBOARD_PART_NUMBER +uses LINUXBIOS_EXTRA_VERSION +uses ARCH +uses FALLBACK_SIZE +uses STACK_SIZE +uses HEAP_SIZE +uses ROM_SIZE +uses ROM_SECTION_SIZE +uses ROM_IMAGE_SIZE +uses ROM_SECTION_SIZE +uses ROM_SECTION_OFFSET +uses CONFIG_ROM_PAYLOAD_START +uses CONFIG_COMPRESSED_PAYLOAD_NRV2B +uses CONFIG_COMPRESSED_PAYLOAD_LZMA +uses CONFIG_PRECOMPRESSED_PAYLOAD +uses PAYLOAD_SIZE +uses _ROMBASE +uses _RAMBASE +uses XIP_ROM_SIZE +uses XIP_ROM_BASE +uses HAVE_MP_TABLE +uses CROSS_COMPILE +uses CC +uses HOSTCC +uses OBJCOPY +uses DEFAULT_CONSOLE_LOGLEVEL +uses MAXIMUM_CONSOLE_LOGLEVEL +uses CONFIG_CONSOLE_SERIAL8250 +uses TTYS0_BAUD +uses TTYS0_BASE +uses TTYS0_LCS +uses CONFIG_UDELAY_TSC +uses CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 +uses CONFIG_CONSOLE_VGA +uses CONFIG_PCI_ROM_RUN +uses CONFIG_VIDEO_MB +uses USE_DCACHE_RAM +uses DCACHE_RAM_BASE +uses DCACHE_RAM_SIZE + +## ROM_SIZE is the size of boot ROM that this board will use. +default ROM_SIZE = 512*1024 + +### +### Build options +### +default CONFIG_CONSOLE_VGA=0 +default CONFIG_VIDEO_MB=8 +default CONFIG_PCI_ROM_RUN=0 + +## +## Build code for the fallback boot +## +default HAVE_FALLBACK_BOOT=1 + +## +## no MP table +## +default HAVE_MP_TABLE=0 + +## +## Build code to reset the motherboard from linuxBIOS +## +default HAVE_HARD_RESET=0 + +## Delay timer options +## +default CONFIG_UDELAY_TSC=1 +default CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2=1 + +## +## Build code to export a programmable irq routing table +## +default HAVE_PIRQ_TABLE=1 +default IRQ_SLOT_COUNT=6 +#object irq_tables.o + +## +## Build code to export a CMOS option table +## +default HAVE_OPTION_TABLE=0 + +### +### LinuxBIOS layout values +### + +## ROM_IMAGE_SIZE is the amount of space to allow linuxBIOS to occupy. +default ROM_IMAGE_SIZE = 65536 +default FALLBACK_SIZE = 131072 + +## +## enable CACHE_AS_RAM specifics +## +default USE_DCACHE_RAM=1 +default DCACHE_RAM_BASE=0xc8000 +default DCACHE_RAM_SIZE=0x08000 + +## +## Use a small 8K stack +## +default STACK_SIZE=0x2000 + +## +## Use a small 16K heap +## +default HEAP_SIZE=0x4000 + +## +## Only use the option table in a normal image +## +#default USE_OPTION_TABLE = !USE_FALLBACK_IMAGE +default USE_OPTION_TABLE = 0 + +default _RAMBASE = 0x00004000 + +default CONFIG_ROM_PAYLOAD = 1 + +## +## The default compiler +## +default CROSS_COMPILE="" +default CC="$(CROSS_COMPILE)gcc -m32" +default HOSTCC="gcc" + +## +## The Serial Console +## + +# To Enable the Serial Console +default CONFIG_CONSOLE_SERIAL8250=1 + +## Select the serial console baud rate +default TTYS0_BAUD=115200 +#default TTYS0_BAUD=57600 +#default TTYS0_BAUD=38400 +#default TTYS0_BAUD=19200 +#default TTYS0_BAUD=9600 +#default TTYS0_BAUD=4800 +#default TTYS0_BAUD=2400 +#default TTYS0_BAUD=1200 + +# Select the serial console base port +default TTYS0_BASE=0x3f8 + +# Select the serial protocol +# This defaults to 8 data bits, 1 stop bit, and no parity +default TTYS0_LCS=0x3 + +## +### Select the linuxBIOS loglevel +## +## EMERG 1 system is unusable +## ALERT 2 action must be taken immediately +## CRIT 3 critical conditions +## ERR 4 error conditions +## WARNING 5 warning conditions +## NOTICE 6 normal but significant condition +## INFO 7 informational +## DEBUG 8 debug-level messages +## SPEW 9 Way too many details + +## Request this level of debugging output +default DEFAULT_CONSOLE_LOGLEVEL=8 +## At a maximum only compile in this level of debugging +default MAXIMUM_CONSOLE_LOGLEVEL=8 + +end + Added: trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/cache_as_ram_auto.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/cache_as_ram_auto.c (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/cache_as_ram_auto.c 2007-09-08 18:32:53 UTC (rev 2765) @@ -0,0 +1,118 @@ +#define ASSEMBLY 1 + +#include +#include +#include +#include +#include +#include +#include "pc80/serial.c" +#include "arch/i386/lib/console.c" +#include "ram/ramtest.c" +#include "cpu/x86/bist.h" +#include "cpu/x86/msr.h" +#include +#include +#include "southbridge/amd/cs5536/cs5536.h" + +#define POST_CODE(x) outb(x, 0x80) +#define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1) + +#include "southbridge/amd/cs5536/cs5536_early_smbus.c" +#include "southbridge/amd/cs5536/cs5536_early_setup.c" +#include "superio/winbond/w83627hf/w83627hf_early_serial.c" + +static inline int spd_read_byte(unsigned device, unsigned address) +{ + return smbus_read_byte(device, address); +} + +#define ManualConf 0 /* Do automatic strapped PLL config */ +#define PLLMSRhi 0x00001490 /* manual settings for the PLL */ +#define PLLMSRlo 0x02000030 +#define DIMM0 0xA0 +#define DIMM1 0xA2 +#include "northbridge/amd/lx/raminit.h" +#include "northbridge/amd/lx/pll_reset.c" +#include "northbridge/amd/lx/raminit.c" +#include "sdram/generic_sdram.c" +#include "cpu/amd/model_lx/cpureginit.c" +#include "cpu/amd/model_lx/syspreinit.c" + +static void msr_init(void) +{ + msr_t msr; + /* Setup access to the MC for under 1MB. Note MC not setup yet. */ + msr.hi = 0x24fffc02; + msr.lo = 0x10010000; + wrmsr(CPU_RCONF_DEFAULT, msr); + + msr.hi = 0x20000000; + msr.lo = 0xfff00; + wrmsr(MSR_GLIU0 + 0x20, msr); + + msr.hi = 0x20000000; + msr.lo = 0xfff00; + wrmsr(MSR_GLIU1 + 0x20, msr); + +} + +static void mb_gpio_init(void) +{ + /* Early mainboard specific GPIO setup */ +} + +void cache_as_ram_main(void) +{ + extern void RestartCAR(); + POST_CODE(0x01); + + static const struct mem_controller memctrl [] = { + {.channel0 = {(0xa<<3)|0, (0xa<<3)|1}} + }; + + SystemPreInit(); + msr_init(); + + cs5536_early_setup(); + + /* NOTE: must do this AFTER the early_setup! + * it is counting on some early MSR setup + * for cs5536 + */ + cs5536_disable_internal_uart(); + w83627hf_enable_serial(SERIAL_DEV, TTYS0_BASE); + mb_gpio_init(); + uart_init(); + console_init(); + + pll_reset(ManualConf); + + cpuRegInit(); + + sdram_initialize(1, memctrl); + + /* Check all of memory */ + ram_check(0x00000000, 640*1024); + + /* Switch from Cache as RAM to real RAM */ + /* There are two ways we could think about this. + 1. If we are using the auto.inc ROMCC way, the stack is going to be re-setup in the code following this code. + Just wbinvd the stack to clear the cache tags. We don't care where the stack used to be. + 2. This file is built as a normal .c -> .o and linked in etc. The stack might be used to return etc. + That means we care about what is in the stack. If we are smart we set the CAR stack to the same location + as the rest of LinuxBIOS. If that is the case we can just do a wbinvd. The stack will be written into real + RAM that is now setup and we continue like nothing happened. If the stack is located somewhere other than + where LB would like it, you need to write some code to do a copy from cache to RAM + + We use method 1 on Norwich and on this board too. + */ + POST_CODE(0x02); + print_err("POST 02\n"); + __asm__("wbinvd\n"); + print_err("Past wbinvd\n"); + /* we are finding the return does not work on this board. Explicitly call the label that is + * after the call to us. This is gross, but sometimes at this level it is the only way out + */ + done_cache_as_ram_main(); +} Added: trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/chip.h (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/chip.h 2007-09-08 18:32:53 UTC (rev 2765) @@ -0,0 +1,5 @@ +extern struct chip_operations mainboard_pcengines_alix1c_ops; + +struct mainboard_pcengines_alix1c_config { + int nothing; +}; Added: trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/cmos.layout =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/cmos.layout (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/cmos.layout 2007-09-08 18:32:53 UTC (rev 2765) @@ -0,0 +1,74 @@ +entries + +#start-bit length config config-ID name +#0 8 r 0 seconds +#8 8 r 0 alarm_seconds +#16 8 r 0 minutes +#24 8 r 0 alarm_minutes +#32 8 r 0 hours +#40 8 r 0 alarm_hours +#48 8 r 0 day_of_week +#56 8 r 0 day_of_month +#64 8 r 0 month +#72 8 r 0 year +#80 4 r 0 rate_select +#84 3 r 0 REF_Clock +#87 1 r 0 UIP +#88 1 r 0 auto_switch_DST +#89 1 r 0 24_hour_mode +#90 1 r 0 binary_values_enable +#91 1 r 0 square-wave_out_enable +#92 1 r 0 update_finished_enable +#93 1 r 0 alarm_interrupt_enable +#94 1 r 0 periodic_interrupt_enable +#95 1 r 0 disable_clock_updates +#96 288 r 0 temporary_filler +0 384 r 0 reserved_memory +384 1 e 4 boot_option +385 1 e 4 last_boot +386 1 e 1 ECC_memory +388 4 r 0 reboot_bits +392 3 e 5 baud_rate +400 1 e 1 power_on_after_fail +412 4 e 6 debug_level +416 4 e 7 boot_first +420 4 e 7 boot_second +424 4 e 7 boot_third +428 4 h 0 boot_index +432 8 h 0 boot_countdown +1008 16 h 0 check_sum + +enumerations + +#ID value text +1 0 Disable +1 1 Enable +2 0 Enable +2 1 Disable +4 0 Fallback +4 1 Normal +5 0 115200 +5 1 57600 +5 2 38400 +5 3 19200 +5 4 9600 +5 5 4800 +5 6 2400 +5 7 1200 +6 6 Notice +6 7 Info +6 8 Debug +6 9 Spew +7 0 Network +7 1 HDD +7 2 Floppy +7 8 Fallback_Network +7 9 Fallback_HDD +7 10 Fallback_Floppy +#7 3 ROM + +checksums + +checksum 392 1007 1008 + + Added: trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/debug.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/debug.c (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/debug.c 2007-09-08 18:32:53 UTC (rev 2765) @@ -0,0 +1,66 @@ + +static void print_debug_pci_dev(unsigned dev) +{ + print_debug("PCI: "); + print_debug_hex8((dev >> 16) & 0xff); + print_debug_char(':'); + print_debug_hex8((dev >> 11) & 0x1f); + print_debug_char('.'); + print_debug_hex8((dev >> 8) & 7); +} + +static void print_pci_devices(void) +{ + device_t dev; + for(dev = PCI_DEV(0, 0, 0); + dev <= PCI_DEV(0, 0x1f, 0x7); + dev += PCI_DEV(0,0,1)) { + uint32_t id; + id = pci_read_config32(dev, PCI_VENDOR_ID); + if (((id & 0xffff) == 0x0000) || ((id & 0xffff) == 0xffff) || + (((id >> 16) & 0xffff) == 0xffff) || + (((id >> 16) & 0xffff) == 0x0000)) { + continue; + } + print_debug_pci_dev(dev); + print_debug("\r\n"); + } +} + +static void dump_pci_device(unsigned dev) +{ + int i; + print_debug_pci_dev(dev); + print_debug("\r\n"); + + for(i = 0; i <= 255; i++) { + unsigned char val; + if ((i & 0x0f) == 0) { + print_debug_hex8(i); + print_debug_char(':'); + } + val = pci_read_config8(dev, i); + print_debug_char(' '); + print_debug_hex8(val); + if ((i & 0x0f) == 0x0f) { + print_debug("\r\n"); + } + } +} + +static void dump_pci_devices(void) +{ + device_t dev; + for(dev = PCI_DEV(0, 0, 0); + dev <= PCI_DEV(0, 0x1f, 0x7); + dev += PCI_DEV(0,0,1)) { + uint32_t id; + id = pci_read_config32(dev, PCI_VENDOR_ID); + if (((id & 0xffff) == 0x0000) || ((id & 0xffff) == 0xffff) || + (((id >> 16) & 0xffff) == 0xffff) || + (((id >> 16) & 0xffff) == 0x0000)) { + continue; + } + dump_pci_device(dev); + } +} Added: trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/failover.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/failover.c (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/failover.c 2007-09-08 18:32:53 UTC (rev 2765) @@ -0,0 +1,32 @@ +#define ASSEMBLY 1 +#include +#include +#include +#include +#include "arch/romcc_io.h" +#include "pc80/mc146818rtc_early.c" + +static unsigned long main(unsigned long bist) +{ + /* This is the primary cpu how should I boot? */ + if (do_normal_boot()) { + goto normal_image; + } + else { + goto fallback_image; + } + normal_image: + asm volatile ("jmp __normal_image" + : /* outputs */ + : "a" (bist) /* inputs */ + : /* clobbers */ + ); + cpu_reset: + asm volatile ("jmp __cpu_reset" + : /* outputs */ + : "a"(bist) /* inputs */ + : /* clobbers */ + ); + fallback_image: + return bist; +} Added: trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/irq_tables.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/irq_tables.c (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/irq_tables.c 2007-09-08 18:32:53 UTC (rev 2765) @@ -0,0 +1,107 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2007 Advanced Micro Devices, Inc. + * + * 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 +#include +#include +#include "../../../southbridge/amd/cs5536/cs5536.h" + +/* Platform IRQs */ +#define PIRQA 11 +#define PIRQB 5 +#define PIRQC 10 +#define PIRQD 10 + +/* Map */ +#define M_PIRQA (1 << PIRQA) /* Bitmap of supported IRQs */ +#define M_PIRQB (1 << PIRQB) /* Bitmap of supported IRQs */ +#define M_PIRQC (1 << PIRQC) /* Bitmap of supported IRQs */ +#define M_PIRQD (1 << PIRQD) /* Bitmap of supported IRQs */ + +/* Link */ +#define L_PIRQA 1 /* Means Slot INTx# Connects To Chipset INTA# */ +#define L_PIRQB 2 /* Means Slot INTx# Connects To Chipset INTB# */ +#define L_PIRQC 3 /* Means Slot INTx# Connects To Chipset INTC# */ +#define L_PIRQD 4 /* Means Slot INTx# Connects To Chipset INTD# */ + +const struct irq_routing_table intel_irq_routing_table = { + PIRQ_SIGNATURE, /* u32 signature */ + PIRQ_VERSION, /* u16 version */ + 32+16*9, /* There can be total 9 devices on the bus */ + 0x00, /* Where the interrupt router lies (bus) */ + (0x0f<<3)|0x0, /* Where the interrupt router lies (dev) */ + 0, /* IRQs devoted exclusively to PCI usage */ + 0x100b, /* Vendor */ + 0x2b, /* Device */ + 0, /* Crap (miniport) */ + { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */ + 0xe, /* u8 checksum. This has to be set to some + value that would give 0 after the sum of all + bytes for this structure (including checksum) */ + { + /* bus, dev|fn, {link, bitmap}, {link, bitmap}, {link, bitmap}, {link, bitmap}, slot, rfu */ + {0x00,(0x01<<3)|0x0, {{0x01, 0x0400}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0}, + {0x00,(0x0f<<3)|0x0, {{0x01, 0x0400}, {0x02, 0x0800}, {0x03, 0x0400}, {0x04, 0x00800}}, 0x0, 0x0}, + {0x00,(0x13<<3)|0x0, {{0x01, 0x0400}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0}, + {0x00,(0x12<<3)|0x0, {{0x03, 0x0400}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0}, + {0x00,(0x11<<3)|0x0, {{0x01, 0x0400}, {0x02, 0x0800}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0}, + {0x00,(0x0a<<3)|0x0, {{0x01, 0x0400}, {0x02, 0x0800}, {0x03, 0x0400}, {0x04, 0x00800}}, 0x1, 0x0}, + {0x00,(0x0b<<3)|0x0, {{0x02, 0x0800}, {0x03, 0x0400}, {0x04, 0x0800}, {0x01, 0x00400}}, 0x2, 0x0}, + {0x00,(0x0c<<3)|0x0, {{0x03, 0x0400}, {0x04, 0x0800}, {0x01, 0x0400}, {0x02, 0x00800}}, 0x3, 0x0}, + {0x00,(0x0d<<3)|0x0, {{0x04, 0x0800}, {0x01, 0x0400}, {0x02, 0x0800}, {0x03, 0x00400}}, 0x4, 0x0}, + } +}; + + +unsigned long write_pirq_routing_table(unsigned long addr){ + int i, j, k, num_entries; + unsigned int pirq[4]; + uint16_t chipset_irq_map; + uint32_t pciAddr, pirtable_end; + struct irq_routing_table *pirq_tbl; + + pirtable_end = copy_pirq_routing_table(addr); + + /* Set up chipset IRQ steering */ + pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C; + chipset_irq_map = (11 << 12 | 10 << 8 | 11 << 4 | 10); + printk_debug("%s(%08X, %04X)\n", __FUNCTION__, pciAddr, chipset_irq_map); + outl(pciAddr & ~3, 0xCF8); + outl(chipset_irq_map, 0xCFC); + + pirq_tbl = (struct irq_routing_table *)(addr); + num_entries = (pirq_tbl->size - 32)/16; + + /* Set PCI IRQs */ + for (i=0; i < num_entries; i++){ + printk_debug("PIR Entry %d Dev/Fn: %X Slot: %d\n", i, pirq_tbl->slots[i].devfn, pirq_tbl->slots[i].slot); + for (j = 0; j < 4; j++){ + printk_debug("INT: %c bitmap: %x ", 'A'+j, pirq_tbl->slots[i].irq[j].bitmap); + for (k = 0; (!((pirq_tbl->slots[i].irq[j].bitmap >> k) & 1)) && (pirq_tbl->slots[i].irq[j].bitmap != 0); k++); /* finds lsb in bitmap to IRQ# */ + pirq[j] = k; + printk_debug("PIRQ: %d\n", k); + } + pci_assign_irqs(pirq_tbl->slots[i].bus, pirq_tbl->slots[i].devfn, pirq); /* bus, device, slots IRQs for {A,B,C,D} */ + } + + /* put the PIR table in memory and checksum */ + return pirtable_end; +} + Added: trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/mainboard.c (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/mainboard.c 2007-09-08 18:32:53 UTC (rev 2765) @@ -0,0 +1,154 @@ +#include +#include +#include +#include +#include +#include +#include +#include +#include "../../../southbridge/amd/cs5536/cs5536.h" +#include "chip.h" + +/* Print the platform configuration */ +void print_conf(void) { +#if DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR + int i; + unsigned long iol; + msr_t msr; + + int cpu_msr_defs[] = { CPU_BC_L2_CONF, CPU_IM_CONFIG, + CPU_DM_CONFIG0, CPU_RCONF_DEFAULT, + CPU_RCONF_BYPASS, CPU_RCONF_A0_BF, CPU_RCONF_C0_DF, CPU_RCONF_E0_FF, + CPU_RCONF_SMM, CPU_RCONF_DMM, GLCP_DELAY_CONTROLS, GL_END + }; + + int gliu0_msr_defs[] = {MSR_GLIU0_BASE1, MSR_GLIU0_BASE2, MSR_GLIU0_BASE4, MSR_GLIU0_BASE5, MSR_GLIU0_BASE6, + GLIU0_P2D_BMO_0, GLIU0_P2D_BMO_1, MSR_GLIU0_SYSMEM, + GLIU0_P2D_RO_0, GLIU0_P2D_RO_1, GLIU0_P2D_RO_2, MSR_GLIU0_SHADOW, + GLIU0_IOD_BM_0, GLIU0_IOD_BM_1, GLIU0_IOD_BM_2, + GLIU0_IOD_SC_0, GLIU0_IOD_SC_1, GLIU0_IOD_SC_2, GLIU0_IOD_SC_3, GLIU0_IOD_SC_4, GLIU0_IOD_SC_5, + GLIU0_GLD_MSR_COH, GL_END + }; + + int gliu1_msr_defs[] = {MSR_GLIU1_BASE1, MSR_GLIU1_BASE2, MSR_GLIU1_BASE3, MSR_GLIU1_BASE4, MSR_GLIU1_BASE5, MSR_GLIU1_BASE6, + MSR_GLIU1_BASE7, MSR_GLIU1_BASE8, MSR_GLIU1_BASE9, MSR_GLIU1_BASE10, + GLIU1_P2D_R_0, GLIU1_P2D_R_1, GLIU1_P2D_R_2, GLIU1_P2D_R_3, MSR_GLIU1_SHADOW, + GLIU1_IOD_BM_0, GLIU1_IOD_BM_1, GLIU1_IOD_BM_2, + GLIU1_IOD_SC_0, GLIU1_IOD_SC_1, GLIU1_IOD_SC_2, GLIU1_IOD_SC_3, + GLIU1_GLD_MSR_COH, GL_END + }; + + int rconf_msr[] = { CPU_RCONF0, CPU_RCONF1, CPU_RCONF2, CPU_RCONF3, CPU_RCONF4, + CPU_RCONF5, CPU_RCONF6, CPU_RCONF7, GL_END + }; + + int cs5536_msr[] = { MDD_LBAR_GPIO, MDD_LBAR_FLSH0, MDD_LBAR_FLSH1, MDD_LEG_IO, MDD_PIN_OPT, + MDD_IRQM_ZLOW, MDD_IRQM_ZHIGH, MDD_IRQM_PRIM, GL_END + }; + + int pci_msr[] = { GLPCI_CTRL, GLPCI_ARB, GLPCI_REN, GLPCI_A0_BF, GLPCI_C0_DF, GLPCI_E0_FF, + GLPCI_RC0, GLPCI_RC1, GLPCI_RC2, GLPCI_RC3, GLPCI_ExtMSR, GLPCI_SPARE, + GL_END + }; + + int dma_msr[] = { MDD_DMA_MAP, MDD_DMA_SHAD1, MDD_DMA_SHAD2, MDD_DMA_SHAD3, MDD_DMA_SHAD4, + MDD_DMA_SHAD5, MDD_DMA_SHAD6, MDD_DMA_SHAD7, MDD_DMA_SHAD8, + MDD_DMA_SHAD9, GL_END + }; + + + printk_debug("---------- CPU ------------\n"); + + for(i = 0; cpu_msr_defs[i] != GL_END; i++) { + msr = rdmsr(cpu_msr_defs[i]); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", cpu_msr_defs[i], msr.hi, msr.lo); + } + + printk_debug("---------- GLIU 0 ------------\n"); + + for(i = 0; gliu0_msr_defs[i] != GL_END; i++) { + msr = rdmsr(gliu0_msr_defs[i]); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", gliu0_msr_defs[i], msr.hi, msr.lo); + } + + printk_debug("---------- GLIU 1 ------------\n"); + + for(i = 0; gliu1_msr_defs[i] != GL_END; i++) { + msr = rdmsr(gliu1_msr_defs[i]); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", gliu1_msr_defs[i], msr.hi, msr.lo); + } + + printk_debug("---------- RCONF ------------\n"); + + for(i = 0; rconf_msr[i] != GL_END; i++) { + msr = rdmsr(rconf_msr[i]); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", rconf_msr[i], msr.hi, msr.lo); + } + + printk_debug("---------- VARIA ------------\n"); + msr = rdmsr(0x51300010); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51300010, msr.hi, msr.lo); + + msr = rdmsr(0x51400015); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51400015, msr.hi, msr.lo); + + printk_debug("---------- DIVIL IRQ ------------\n"); + msr = rdmsr(MDD_IRQM_YLOW); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YLOW, msr.hi, msr.lo); + msr = rdmsr(MDD_IRQM_YHIGH); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YHIGH, msr.hi, msr.lo); + msr = rdmsr(MDD_IRQM_ZLOW); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZLOW, msr.hi, msr.lo); + msr = rdmsr(MDD_IRQM_ZHIGH); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZHIGH, msr.hi, msr.lo); + + + printk_debug("---------- PCI ------------\n"); + + for(i = 0; pci_msr[i] != GL_END; i++) { + msr = rdmsr(pci_msr[i]); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", pci_msr[i], msr.hi, msr.lo); + } + + printk_debug("---------- LPC/UART DMA ------------\n"); + + for(i = 0; dma_msr[i] != GL_END; i++) { + msr = rdmsr(dma_msr[i]); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", dma_msr[i], msr.hi, msr.lo); + } + + printk_debug("---------- CS5536 ------------\n"); + + for(i = 0; cs5536_msr[i] != GL_END; i++) { + msr = rdmsr(cs5536_msr[i]); + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", cs5536_msr[i], msr.hi, msr.lo); + } + + iol = inl(GPIOL_INPUT_ENABLE); + printk_debug("IOR 0x%08X is now 0x%08X\n", GPIOL_INPUT_ENABLE, iol); + iol = inl(GPIOL_EVENTS_ENABLE); + printk_debug("IOR 0x%08X is now 0x%08X\n", GPIOL_EVENTS_ENABLE, iol); + iol = inl(GPIOL_INPUT_INVERT_ENABLE); + printk_debug("IOR 0x%08X is now 0x%08X\n", GPIOL_INPUT_INVERT_ENABLE, iol); + iol = inl(GPIO_MAPPER_X); + printk_debug("IOR 0x%08X is now 0x%08X\n", GPIO_MAPPER_X, iol); +#endif //DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR +} + +static void init(struct device *dev) { + + printk_debug("ALIX1C ENTER %s\n", __FUNCTION__); + + printk_debug("ALIX1C EXIT %s\n", __FUNCTION__); +} + +static void enable_dev(struct device *dev) +{ + dev->ops->init = init; +} + +struct chip_operations mainboard_pcengines_alix1c_ops = { + CHIP_NAME("PC ENGINES ALIX1C Mainboard") + .enable_dev = enable_dev, +}; + Added: trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/reset.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/reset.c (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/reset.c 2007-09-08 18:32:53 UTC (rev 2765) @@ -0,0 +1,43 @@ +#if 0 +//#include "arch/romcc_io.h" +#include + +typedef unsigned device_t; + +#define PCI_DEV(BUS, DEV, FN) ( \ + (((BUS) & 0xFF) << 16) | \ + (((DEV) & 0x1f) << 11) | \ + (((FN) & 0x7) << 8)) + +static void pci_write_config8(device_t dev, unsigned where, unsigned char value) +{ + unsigned addr; + addr = dev | where; + outl(0x80000000 | (addr & ~3), 0xCF8); + outb(value, 0xCFC + (addr & 3)); +} + +static void pci_write_config32(device_t dev, unsigned where, unsigned value) +{ + unsigned addr; + addr = dev | where; + outl(0x80000000 | (addr & ~3), 0xCF8); + outl(value, 0xCFC); +} + +static unsigned pci_read_config32(device_t dev, unsigned where) +{ + unsigned addr; + addr = dev | where; + outl(0x80000000 | (addr & ~3), 0xCF8); + return inl(0xCFC); +} + +#include "../../../northbridge/amd/amdk8/reset_test.c" + +void hard_reset(void) +{ + set_bios_reset(); + pci_write_config8(PCI_DEV(1, 0x04, 0), 0x47, 1); +} +#endif Added: trunk/LinuxBIOSv2/targets/pcengines/alix1c/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/pcengines/alix1c/Config.lb (rev 0) +++ trunk/LinuxBIOSv2/targets/pcengines/alix1c/Config.lb 2007-09-08 18:32:53 UTC (rev 2765) @@ -0,0 +1,26 @@ +target alix1c +mainboard pcengines/alix1c + +option CONFIG_COMPRESSED_PAYLOAD_NRV2B=0 + +## ROM_SIZE is the total number of bytes allocated for LinuxBIOS use +## (normal AND fallback images and payloads). +## leave 36k for vsa +## +option ROM_SIZE = 512*1024 - 36 * 1024 + +## ROM_IMAGE_SIZE is the maximum number of bytes allowed for a LinuxBIOS image, +## not including any payload. +option ROM_IMAGE_SIZE=64*1024 + +option FALLBACK_SIZE = ROM_SIZE + +option DEFAULT_CONSOLE_LOGLEVEL = 11 +option MAXIMUM_CONSOLE_LOGLEVEL = 11 +romimage "fallback" + option USE_FALLBACK_IMAGE=1 + option LINUXBIOS_EXTRA_VERSION=".0Fallback" + payload /tmp/filo.elf +end + +buildrom ./linuxbios.rom ROM_SIZE "fallback" From rminnich at gmail.com Sat Sep 8 20:33:34 2007 From: rminnich at gmail.com (ron minnich) Date: Sat, 8 Sep 2007 11:33:34 -0700 Subject: [LinuxBIOS] PATCH: add the pcengines ALIX1 In-Reply-To: <20070908181325.GD14851@coresystems.de> References: <13426df10709071258u5096ea78x2514c53dfb509e08@mail.gmail.com> <20070907213532.GG10747@greenwood> <13426df10709080928o1e6d8febwa97572c9d263352@mail.gmail.com> <20070908181325.GD14851@coresystems.de> Message-ID: <13426df10709081133h28cdfda0ve2b96ea12b7e6f77@mail.gmail.com> On 9/8/07, Stefan Reinauer wrote: > * ron minnich [070908 18:28]: > > Welcome to PC Engines and the ALIX 1C! > > Signed-off-by: Ronald G. Minnich > Acked-by: Stefan Reinauer Committed revision 2765. From rminnich at gmail.com Sat Sep 8 20:34:01 2007 From: rminnich at gmail.com (ron minnich) Date: Sat, 8 Sep 2007 11:34:01 -0700 Subject: [LinuxBIOS] [PATCH] buildrom: add packages/kernel/patches/tiny_m57sli In-Reply-To: <2ea3fae10709081131m7c275f9fha9f7b18e1c65b0f4@mail.gmail.com> References: <20070906142443.GC29891@localdomain> <13426df10709081028m3fcaefc1k1a9113d26fa8e0d1@mail.gmail.com> <2ea3fae10709081131m7c275f9fha9f7b18e1c65b0f4@mail.gmail.com> Message-ID: <13426df10709081134r209f0c33vc893a46e39c39458@mail.gmail.com> On 9/8/07, yhlu wrote: > On 9/8/07, ron minnich wrote: > > On 9/6/07, Ward Vandewege wrote: > > > These patches are released under the GPLv2, so we can just include them in > > > our buildrom tree. Do we need a license header for each file? > > > > > > This comes from tiny, right? I think since it is a patch we are ok? > > we should put the URL in buildrom to download that quilt patchset from > elinux.org like download linux tar ball... good point, ward, is that doable? ron From rminnich at gmail.com Sat Sep 8 20:36:33 2007 From: rminnich at gmail.com (ron minnich) Date: Sat, 8 Sep 2007 11:36:33 -0700 Subject: [LinuxBIOS] [RFC] Payload selector method In-Reply-To: <1189252970.26302.125.camel@localhost> References: <1189252970.26302.125.camel@localhost> Message-ID: <13426df10709081136l7853c90ej16bce4ebe3582389@mail.gmail.com> On 9/8/07, Alex Beregszaszi wrote: > Hi, > > After playing around with lbmenu, I came up with the following idea to > select payloads in a clean way. > > 1a, linuxbios parses the payload number cmos position, and starts the > selected payload or, if it is out of range, an emergency payload :-) > Imho it is better to have always the 1a, way running, but we have to be > sure the cmos contains a valid value. we want an unattended boot ability. I hope to try lbmenu out soon. ron From uwe at hermann-uwe.de Sat Sep 8 20:37:21 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 8 Sep 2007 20:37:21 +0200 Subject: [LinuxBIOS] PATCH: add the pcengines ALIX1 In-Reply-To: <13426df10709080928o1e6d8febwa97572c9d263352@mail.gmail.com> References: <13426df10709071258u5096ea78x2514c53dfb509e08@mail.gmail.com> <20070907213532.GG10747@greenwood> <13426df10709080928o1e6d8febwa97572c9d263352@mail.gmail.com> Message-ID: <20070908183721.GB18334@greenwood> On Sat, Sep 08, 2007 at 09:28:34AM -0700, ron minnich wrote: > Hi, here is try 2. This one builds :-) Yep, confirmed :) > Index: src/mainboard/pcengines/alix1c/Config.lb > =================================================================== > --- src/mainboard/pcengines/alix1c/Config.lb (revision 0) > +++ src/mainboard/pcengines/alix1c/Config.lb (revision 0) Add a license header, please. > @@ -0,0 +1,206 @@ > +## > +## Compute the location and size of where this firmware image > +## (linuxBIOS plus bootloader) will live in the boot rom chip. > +## > +if USE_FALLBACK_IMAGE > + default ROM_SECTION_SIZE = FALLBACK_SIZE > + default ROM_SECTION_OFFSET = ( ROM_SIZE - FALLBACK_SIZE ) > +else > + default ROM_SECTION_SIZE = ( ROM_SIZE - FALLBACK_SIZE ) > + default ROM_SECTION_OFFSET = 0 > +end > + > +## > +## Compute the start location and size size of > +## The linuxBIOS bootloader. > +## > +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_PAYLOAD_START + PAYLOAD_SIZE ) > + > +## > +## Compute a range of ROM that can cached to speed up linuxBIOS, > +## execution speed. > +## > +## XIP_ROM_SIZE must be a power of 2. > +## XIP_ROM_BASE must be a multiple of XIP_ROM_SIZE > +## > +default XIP_ROM_SIZE=65536 > +default XIP_ROM_BASE = ( _ROMBASE + ROM_IMAGE_SIZE - XIP_ROM_SIZE ) > + > +## > +## Set all of the defaults for an x86 architecture > +## > + > +arch i386 end > + > +## > +## Build the objects we have code for in this directory. > +## > + > +driver mainboard.o > + > +if HAVE_PIRQ_TABLE > + object irq_tables.o > +end > + > +if USE_DCACHE_RAM > + #compile cache_as_ram.c to auto.inc > + makerule ./cache_as_ram_auto.inc > + depends "$(MAINBOARD)/cache_as_ram_auto.c option_table.h" > + action "$(CC) -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/cache_as_ram_auto.c -Os -nostdinc -nostdlib -fno-builtin -Wall -c -S -o $@" > + action "perl -e 's/.rodata/.rom.data/g' -pi $@" > + action "perl -e 's/.text/.section .rom.text/g' -pi $@" > + end > +end > + > + > + > +## > +## Build our 16 bit and 32 bit linuxBIOS entry code > +## > +mainboardinit cpu/x86/16bit/entry16.inc > +mainboardinit cpu/x86/32bit/entry32.inc > +ldscript /cpu/x86/16bit/entry16.lds > +ldscript /cpu/x86/32bit/entry32.lds > + > +## > +## Build our reset vector (This is where linuxBIOS is entered) > +## > +if USE_FALLBACK_IMAGE > + mainboardinit cpu/x86/16bit/reset16.inc > + ldscript /cpu/x86/16bit/reset16.lds > +else > + mainboardinit cpu/x86/32bit/reset32.inc > + ldscript /cpu/x86/32bit/reset32.lds > +end > + > +### Should this be in the northbridge code? > +mainboardinit arch/i386/lib/cpu_reset.inc > + > +## > +## Include an id string (For safe flashing) > +## > +mainboardinit arch/i386/lib/id.inc > +ldscript /arch/i386/lib/id.lds > + > +### > +### This is the early phase of linuxBIOS startup > +### Things are delicate and we test to see if we should > +### failover to another image. > +### > +if USE_FALLBACK_IMAGE > + ldscript /arch/i386/lib/failover.lds > +# mainboardinit ./failover.inc > +end > + > +### > +### O.k. We aren't just an intermediary anymore! > +### > + > +## > +## Setup RAM > +## > +mainboardinit cpu/x86/fpu/enable_fpu.inc > + > +if USE_DCACHE_RAM > + mainboardinit cpu/amd/model_lx/cache_as_ram.inc > + mainboardinit ./cache_as_ram_auto.inc > +end > + > +## > +## Include the secondary Configuration files > +## > +dir /pc80 > +config chip.h > + > +chip northbridge/amd/lx > + device pci_domain 0 on > + device pci 1.0 on end > + device pci 1.1 on end > + chip southbridge/amd/cs5536 > + # IRQ 12 and 1 unmasked, Keyboard and Mouse IRQs. OK > + # SIRQ Mode = Active(Quiet) mode. Save power.... > + # Invert mask = IRQ 12 and 1 are active high. Keyboard and Mouse IRQs. OK > + # How to get these? Boot linux and do this: > + # rdmsr 0x51400025 > + register "lpc_serirq_enable" = "0x000010da" > + # rdmsr 0x5140004e -- polairy is high 16 bits of low 32 bits > + register "lpc_serirq_polarity" = "0x0000EF25" > + # mode is high 10 bits (determined from code) > + register "lpc_serirq_mode" = "1" > + # Don't yet know how to find this. > + register "enable_gpio_int_route" = "0x0D0C0700" > + register "enable_ide_nand_flash" = "0" # 0:ide mode, 1:flash > + register "enable_USBP4_device" = "0" #0: host, 1:device > + register "enable_USBP4_overcurrent" = "0" #0:off, xxxx:overcurrent setting CS5536 Data Book (pages 380-381) > + register "com1_enable" = "0" > + register "com1_address" = "0x3F8" > + register "com1_irq" = "4" > + register "com2_enable" = "0" > + register "com2_address" = "0x2F8" > + register "com2_irq" = "3" > + register "unwanted_vpci[0]" = "0" # End of list has a zero > + device pci f.0 on # ISA Bridge > + chip superio/winbond/w83627hf > + device pnp 2e.0 off # Floppy > + io 0x60 = 0x3f0 > + irq 0x70 = 6 > + drq 0x74 = 2 > + end > + device pnp 2e.1 on # Parallel Port > + io 0x60 = 0x378 > + irq 0x70 = 7 > + end > + device pnp 2e.2 on # Com1 > + io 0x60 = 0x3f8 > + irq 0x70 = 4 > + end > + device pnp 2e.3 on # Com2 > + io 0x60 = 0x2f8 > + irq 0x70 = 3 > + end > + device pnp 2e.5 on # Keyboard > + io 0x60 = 0x60 > + io 0x62 = 0x64 > + irq 0x70 = 1 > + irq 0x72 = 12 > + end > + device pnp 2e.6 off # CIR > + io 0x60 = 0x100 > + end > + device pnp 2e.7 off # GAME_MIDI_GIPO1 > + io 0x60 = 0x220 > + io 0x62 = 0x300 > + irq 0x70 = 9 > + end > + device pnp 2e.8 on end # GPIO2 > + device pnp 2e.9 on end # GPIO3 > + device pnp 2e.a on end # ACPI > + device pnp 2e.b on # HW Monitor > + io 0x60 = 0x290 > + irq 0x70 = 5 > + end > + end > + end > + device pci f.1 on end # Flash controller > + device pci f.2 on end # IDE controller > + device pci f.3 on end # Audio > + device pci f.4 on end # OHCI > + device pci f.5 on end # EHCI > + end > + end > + > + # APIC cluster is late CPU init. > + device apic_cluster 0 on > + chip cpu/amd/model_lx > + device apic 0 on end > + end > + end > + > +end > + > Index: src/mainboard/pcengines/alix1c/reset.c > =================================================================== > --- src/mainboard/pcengines/alix1c/reset.c (revision 0) > +++ src/mainboard/pcengines/alix1c/reset.c (revision 0) > @@ -0,0 +1,43 @@ > +#if 0 As it's commented out (and likely copied from some other target), please drop the file completely for now. We can add a working version (or preferrably use a global/common file if possible) if and when we need it. I don't like adding dummy files which aren't really necessary. Is this file even used ATM? I see a default HAVE_HARD_RESET=0 in Options.lb. > +//#include "arch/romcc_io.h" > +#include > + > +typedef unsigned device_t; > + > +#define PCI_DEV(BUS, DEV, FN) ( \ > + (((BUS) & 0xFF) << 16) | \ > + (((DEV) & 0x1f) << 11) | \ > + (((FN) & 0x7) << 8)) > + > +static void pci_write_config8(device_t dev, unsigned where, unsigned char value) > +{ > + unsigned addr; > + addr = dev | where; > + outl(0x80000000 | (addr & ~3), 0xCF8); > + outb(value, 0xCFC + (addr & 3)); > +} > + > +static void pci_write_config32(device_t dev, unsigned where, unsigned value) > +{ > + unsigned addr; > + addr = dev | where; > + outl(0x80000000 | (addr & ~3), 0xCF8); > + outl(value, 0xCFC); > +} > + > +static unsigned pci_read_config32(device_t dev, unsigned where) > +{ > + unsigned addr; > + addr = dev | where; > + outl(0x80000000 | (addr & ~3), 0xCF8); > + return inl(0xCFC); > +} > + > +#include "../../../northbridge/amd/amdk8/reset_test.c" > + > +void hard_reset(void) > +{ > + set_bios_reset(); > + pci_write_config8(PCI_DEV(1, 0x04, 0), 0x47, 1); > +} > +#endif > Index: src/mainboard/pcengines/alix1c/irq_tables.c > =================================================================== > --- src/mainboard/pcengines/alix1c/irq_tables.c (revision 0) > +++ src/mainboard/pcengines/alix1c/irq_tables.c (revision 0) > @@ -0,0 +1,107 @@ > +/* > + * This file is part of the LinuxBIOS project. > + * > + * Copyright (C) 2007 Advanced Micro Devices, Inc. > + * > + * 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 > +#include > +#include > +#include "../../../southbridge/amd/cs5536/cs5536.h" > + > +/* Platform IRQs */ > +#define PIRQA 11 > +#define PIRQB 5 > +#define PIRQC 10 > +#define PIRQD 10 > + > +/* Map */ > +#define M_PIRQA (1 << PIRQA) /* Bitmap of supported IRQs */ > +#define M_PIRQB (1 << PIRQB) /* Bitmap of supported IRQs */ > +#define M_PIRQC (1 << PIRQC) /* Bitmap of supported IRQs */ > +#define M_PIRQD (1 << PIRQD) /* Bitmap of supported IRQs */ > + > +/* Link */ > +#define L_PIRQA 1 /* Means Slot INTx# Connects To Chipset INTA# */ > +#define L_PIRQB 2 /* Means Slot INTx# Connects To Chipset INTB# */ > +#define L_PIRQC 3 /* Means Slot INTx# Connects To Chipset INTC# */ > +#define L_PIRQD 4 /* Means Slot INTx# Connects To Chipset INTD# */ > + > +const struct irq_routing_table intel_irq_routing_table = { > + PIRQ_SIGNATURE, /* u32 signature */ > + PIRQ_VERSION, /* u16 version */ > + 32+16*9, /* There can be total 9 devices on the bus */ Is the 9 (and the rest of this file) correct and tested? Below in Options.lb there's a default IRQ_SLOT_COUNT=6 which contradicts the 9 here(?) > + 0x00, /* Where the interrupt router lies (bus) */ > + (0x0f<<3)|0x0, /* Where the interrupt router lies (dev) */ > + 0, /* IRQs devoted exclusively to PCI usage */ > + 0x100b, /* Vendor */ > + 0x2b, /* Device */ > + 0, /* Crap (miniport) */ > + { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */ > + 0xe, /* u8 checksum. This has to be set to some > + value that would give 0 after the sum of all > + bytes for this structure (including checksum) */ > + { > + /* bus, dev|fn, {link, bitmap}, {link, bitmap}, {link, bitmap}, {link, bitmap}, slot, rfu */ > + {0x00,(0x01<<3)|0x0, {{0x01, 0x0400}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0}, > + {0x00,(0x0f<<3)|0x0, {{0x01, 0x0400}, {0x02, 0x0800}, {0x03, 0x0400}, {0x04, 0x00800}}, 0x0, 0x0}, > + {0x00,(0x13<<3)|0x0, {{0x01, 0x0400}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0}, > + {0x00,(0x12<<3)|0x0, {{0x03, 0x0400}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0}, > + {0x00,(0x11<<3)|0x0, {{0x01, 0x0400}, {0x02, 0x0800}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0}, > + {0x00,(0x0a<<3)|0x0, {{0x01, 0x0400}, {0x02, 0x0800}, {0x03, 0x0400}, {0x04, 0x00800}}, 0x1, 0x0}, > + {0x00,(0x0b<<3)|0x0, {{0x02, 0x0800}, {0x03, 0x0400}, {0x04, 0x0800}, {0x01, 0x00400}}, 0x2, 0x0}, > + {0x00,(0x0c<<3)|0x0, {{0x03, 0x0400}, {0x04, 0x0800}, {0x01, 0x0400}, {0x02, 0x00800}}, 0x3, 0x0}, > + {0x00,(0x0d<<3)|0x0, {{0x04, 0x0800}, {0x01, 0x0400}, {0x02, 0x0800}, {0x03, 0x00400}}, 0x4, 0x0}, > + } > +}; > + > + > +unsigned long write_pirq_routing_table(unsigned long addr){ > + int i, j, k, num_entries; > + unsigned int pirq[4]; > + uint16_t chipset_irq_map; > + uint32_t pciAddr, pirtable_end; > + struct irq_routing_table *pirq_tbl; > + > + pirtable_end = copy_pirq_routing_table(addr); > + > + /* Set up chipset IRQ steering */ > + pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C; > + chipset_irq_map = (11 << 12 | 10 << 8 | 11 << 4 | 10); > + printk_debug("%s(%08X, %04X)\n", __FUNCTION__, pciAddr, chipset_irq_map); > + outl(pciAddr & ~3, 0xCF8); > + outl(chipset_irq_map, 0xCFC); > + > + pirq_tbl = (struct irq_routing_table *)(addr); > + num_entries = (pirq_tbl->size - 32)/16; > + > + /* Set PCI IRQs */ > + for (i=0; i < num_entries; i++){ > + printk_debug("PIR Entry %d Dev/Fn: %X Slot: %d\n", i, pirq_tbl->slots[i].devfn, pirq_tbl->slots[i].slot); > + for (j = 0; j < 4; j++){ > + printk_debug("INT: %c bitmap: %x ", 'A'+j, pirq_tbl->slots[i].irq[j].bitmap); > + for (k = 0; (!((pirq_tbl->slots[i].irq[j].bitmap >> k) & 1)) && (pirq_tbl->slots[i].irq[j].bitmap != 0); k++); /* finds lsb in bitmap to IRQ# */ > + pirq[j] = k; > + printk_debug("PIRQ: %d\n", k); > + } > + pci_assign_irqs(pirq_tbl->slots[i].bus, pirq_tbl->slots[i].devfn, pirq); /* bus, device, slots IRQs for {A,B,C,D} */ > + } > + > + /* put the PIR table in memory and checksum */ > + return pirtable_end; > +} > + > Index: src/mainboard/pcengines/alix1c/Options.lb > =================================================================== > --- src/mainboard/pcengines/alix1c/Options.lb (revision 0) > +++ src/mainboard/pcengines/alix1c/Options.lb (revision 0) Add a license header, please. > @@ -0,0 +1,179 @@ > +uses HAVE_MP_TABLE > +uses HAVE_PIRQ_TABLE > +uses USE_FALLBACK_IMAGE > +uses HAVE_FALLBACK_BOOT > +uses HAVE_HARD_RESET > +uses HAVE_OPTION_TABLE > +uses USE_OPTION_TABLE > +uses CONFIG_ROM_PAYLOAD > +uses IRQ_SLOT_COUNT > +uses MAINBOARD > +uses MAINBOARD_VENDOR > +uses MAINBOARD_PART_NUMBER > +uses LINUXBIOS_EXTRA_VERSION > +uses ARCH > +uses FALLBACK_SIZE > +uses STACK_SIZE > +uses HEAP_SIZE > +uses ROM_SIZE > +uses ROM_SECTION_SIZE > +uses ROM_IMAGE_SIZE > +uses ROM_SECTION_SIZE > +uses ROM_SECTION_OFFSET > +uses CONFIG_ROM_PAYLOAD_START > +uses CONFIG_COMPRESSED_PAYLOAD_NRV2B > +uses CONFIG_COMPRESSED_PAYLOAD_LZMA > +uses CONFIG_PRECOMPRESSED_PAYLOAD > +uses PAYLOAD_SIZE > +uses _ROMBASE > +uses _RAMBASE > +uses XIP_ROM_SIZE > +uses XIP_ROM_BASE > +uses HAVE_MP_TABLE > +uses CROSS_COMPILE > +uses CC > +uses HOSTCC > +uses OBJCOPY > +uses DEFAULT_CONSOLE_LOGLEVEL > +uses MAXIMUM_CONSOLE_LOGLEVEL > +uses CONFIG_CONSOLE_SERIAL8250 > +uses TTYS0_BAUD > +uses TTYS0_BASE > +uses TTYS0_LCS > +uses CONFIG_UDELAY_TSC > +uses CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 > +uses CONFIG_CONSOLE_VGA > +uses CONFIG_PCI_ROM_RUN > +uses CONFIG_VIDEO_MB > +uses USE_DCACHE_RAM > +uses DCACHE_RAM_BASE > +uses DCACHE_RAM_SIZE > + > +## ROM_SIZE is the size of boot ROM that this board will use. > +default ROM_SIZE = 512*1024 > + > +### > +### Build options > +### > +default CONFIG_CONSOLE_VGA=0 > +default CONFIG_VIDEO_MB=8 > +default CONFIG_PCI_ROM_RUN=0 > + > +## > +## Build code for the fallback boot > +## > +default HAVE_FALLBACK_BOOT=1 > + > +## > +## no MP table > +## > +default HAVE_MP_TABLE=0 > + > +## > +## Build code to reset the motherboard from linuxBIOS > +## > +default HAVE_HARD_RESET=0 > + > +## Delay timer options > +## > +default CONFIG_UDELAY_TSC=1 > +default CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2=1 > + > +## > +## Build code to export a programmable irq routing table > +## > +default HAVE_PIRQ_TABLE=1 > +default IRQ_SLOT_COUNT=6 > +#object irq_tables.o > + > +## > +## Build code to export a CMOS option table > +## > +default HAVE_OPTION_TABLE=0 > + > +### > +### LinuxBIOS layout values > +### > + > +## ROM_IMAGE_SIZE is the amount of space to allow linuxBIOS to occupy. > +default ROM_IMAGE_SIZE = 65536 > +default FALLBACK_SIZE = 131072 > + > +## > +## enable CACHE_AS_RAM specifics > +## > +default USE_DCACHE_RAM=1 > +default DCACHE_RAM_BASE=0xc8000 > +default DCACHE_RAM_SIZE=0x08000 > + > +## > +## Use a small 8K stack > +## > +default STACK_SIZE=0x2000 > + > +## > +## Use a small 16K heap > +## > +default HEAP_SIZE=0x4000 > + > +## > +## Only use the option table in a normal image > +## > +#default USE_OPTION_TABLE = !USE_FALLBACK_IMAGE > +default USE_OPTION_TABLE = 0 > + > +default _RAMBASE = 0x00004000 > + > +default CONFIG_ROM_PAYLOAD = 1 > + > +## > +## The default compiler > +## > +default CROSS_COMPILE="" > +default CC="$(CROSS_COMPILE)gcc -m32" > +default HOSTCC="gcc" > + > +## > +## The Serial Console > +## > + > +# To Enable the Serial Console > +default CONFIG_CONSOLE_SERIAL8250=1 > + > +## Select the serial console baud rate > +default TTYS0_BAUD=115200 > +#default TTYS0_BAUD=57600 > +#default TTYS0_BAUD=38400 > +#default TTYS0_BAUD=19200 > +#default TTYS0_BAUD=9600 > +#default TTYS0_BAUD=4800 > +#default TTYS0_BAUD=2400 > +#default TTYS0_BAUD=1200 > + > +# Select the serial console base port > +default TTYS0_BASE=0x3f8 > + > +# Select the serial protocol > +# This defaults to 8 data bits, 1 stop bit, and no parity > +default TTYS0_LCS=0x3 > + > +## > +### Select the linuxBIOS loglevel > +## > +## EMERG 1 system is unusable > +## ALERT 2 action must be taken immediately > +## CRIT 3 critical conditions > +## ERR 4 error conditions > +## WARNING 5 warning conditions > +## NOTICE 6 normal but significant condition > +## INFO 7 informational > +## DEBUG 8 debug-level messages > +## SPEW 9 Way too many details > + > +## Request this level of debugging output > +default DEFAULT_CONSOLE_LOGLEVEL=8 > +## At a maximum only compile in this level of debugging > +default MAXIMUM_CONSOLE_LOGLEVEL=8 > + > +end > + > Index: src/mainboard/pcengines/alix1c/debug.c > =================================================================== > --- src/mainboard/pcengines/alix1c/debug.c (revision 0) > +++ src/mainboard/pcengines/alix1c/debug.c (revision 0) NACK. Not yet another copy of this file, please. Move it into lib/ or somewhere globally, and use that in all targets. We should stop replicating there files again and again. > @@ -0,0 +1,66 @@ > + > +static void print_debug_pci_dev(unsigned dev) > +{ > + print_debug("PCI: "); > + print_debug_hex8((dev >> 16) & 0xff); > + print_debug_char(':'); > + print_debug_hex8((dev >> 11) & 0x1f); > + print_debug_char('.'); > + print_debug_hex8((dev >> 8) & 7); > +} > + > +static void print_pci_devices(void) > +{ > + device_t dev; > + for(dev = PCI_DEV(0, 0, 0); > + dev <= PCI_DEV(0, 0x1f, 0x7); > + dev += PCI_DEV(0,0,1)) { > + uint32_t id; > + id = pci_read_config32(dev, PCI_VENDOR_ID); > + if (((id & 0xffff) == 0x0000) || ((id & 0xffff) == 0xffff) || > + (((id >> 16) & 0xffff) == 0xffff) || > + (((id >> 16) & 0xffff) == 0x0000)) { > + continue; > + } > + print_debug_pci_dev(dev); > + print_debug("\r\n"); > + } > +} > + > +static void dump_pci_device(unsigned dev) > +{ > + int i; > + print_debug_pci_dev(dev); > + print_debug("\r\n"); > + > + for(i = 0; i <= 255; i++) { > + unsigned char val; > + if ((i & 0x0f) == 0) { > + print_debug_hex8(i); > + print_debug_char(':'); > + } > + val = pci_read_config8(dev, i); > + print_debug_char(' '); > + print_debug_hex8(val); > + if ((i & 0x0f) == 0x0f) { > + print_debug("\r\n"); > + } > + } > +} > + > +static void dump_pci_devices(void) > +{ > + device_t dev; > + for(dev = PCI_DEV(0, 0, 0); > + dev <= PCI_DEV(0, 0x1f, 0x7); > + dev += PCI_DEV(0,0,1)) { > + uint32_t id; > + id = pci_read_config32(dev, PCI_VENDOR_ID); > + if (((id & 0xffff) == 0x0000) || ((id & 0xffff) == 0xffff) || > + (((id >> 16) & 0xffff) == 0xffff) || > + (((id >> 16) & 0xffff) == 0x0000)) { > + continue; > + } > + dump_pci_device(dev); > + } > +} > Index: src/mainboard/pcengines/alix1c/failover.c > =================================================================== > --- src/mainboard/pcengines/alix1c/failover.c (revision 0) > +++ src/mainboard/pcengines/alix1c/failover.c (revision 0) NACK, see above. This is common code just about every board duplicate? again and again. I have a patch which adds a global failover.c into lib/ (which my recent i810 board patch already uses, btw). I'll post the patch ASAP. > Index: src/mainboard/pcengines/alix1c/chip.h > =================================================================== > --- src/mainboard/pcengines/alix1c/chip.h (revision 0) > +++ src/mainboard/pcengines/alix1c/chip.h (revision 0) Trivial, but please add a license header. > @@ -0,0 +1,5 @@ > +extern struct chip_operations mainboard_pcengines_alix1c_ops; > + > +struct mainboard_pcengines_alix1c_config { > + int nothing; > +}; > Index: src/mainboard/pcengines/alix1c/cmos.layout > =================================================================== > --- src/mainboard/pcengines/alix1c/cmos.layout (revision 0) > +++ src/mainboard/pcengines/alix1c/cmos.layout (revision 0) This should be dropped for now (needs a small fix in Config.lb to make it still compile), as you use default HAVE_OPTION_TABLE=0 above. > @@ -0,0 +1,74 @@ > +entries > + > +#start-bit length config config-ID name > +#0 8 r 0 seconds > +#8 8 r 0 alarm_seconds > +#16 8 r 0 minutes > +#24 8 r 0 alarm_minutes > +#32 8 r 0 hours > +#40 8 r 0 alarm_hours > +#48 8 r 0 day_of_week > +#56 8 r 0 day_of_month > +#64 8 r 0 month > +#72 8 r 0 year > +#80 4 r 0 rate_select > +#84 3 r 0 REF_Clock > +#87 1 r 0 UIP > +#88 1 r 0 auto_switch_DST > +#89 1 r 0 24_hour_mode > +#90 1 r 0 binary_values_enable > +#91 1 r 0 square-wave_out_enable > +#92 1 r 0 update_finished_enable > +#93 1 r 0 alarm_interrupt_enable > +#94 1 r 0 periodic_interrupt_enable > +#95 1 r 0 disable_clock_updates > +#96 288 r 0 temporary_filler > +0 384 r 0 reserved_memory > +384 1 e 4 boot_option > +385 1 e 4 last_boot > +386 1 e 1 ECC_memory > +388 4 r 0 reboot_bits > +392 3 e 5 baud_rate > +400 1 e 1 power_on_after_fail > +412 4 e 6 debug_level > +416 4 e 7 boot_first > +420 4 e 7 boot_second > +424 4 e 7 boot_third > +428 4 h 0 boot_index > +432 8 h 0 boot_countdown > +1008 16 h 0 check_sum > + > +enumerations > + > +#ID value text > +1 0 Disable > +1 1 Enable > +2 0 Enable > +2 1 Disable > +4 0 Fallback > +4 1 Normal > +5 0 115200 > +5 1 57600 > +5 2 38400 > +5 3 19200 > +5 4 9600 > +5 5 4800 > +5 6 2400 > +5 7 1200 > +6 6 Notice > +6 7 Info > +6 8 Debug > +6 9 Spew > +7 0 Network > +7 1 HDD > +7 2 Floppy > +7 8 Fallback_Network > +7 9 Fallback_HDD > +7 10 Fallback_Floppy > +#7 3 ROM > + > +checksums > + > +checksum 392 1007 1008 > + > + > Index: src/mainboard/pcengines/alix1c/mainboard.c > =================================================================== > --- src/mainboard/pcengines/alix1c/mainboard.c (revision 0) > +++ src/mainboard/pcengines/alix1c/mainboard.c (revision 0) Add a license header, please. > @@ -0,0 +1,154 @@ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include "../../../southbridge/amd/cs5536/cs5536.h" > +#include "chip.h" > + > +/* Print the platform configuration */ > +void print_conf(void) { Is this really needed here? Should it go in some common lib/ file? Doesn't look board-specific to me. > +#if DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR > + int i; > + unsigned long iol; > + msr_t msr; > + > + int cpu_msr_defs[] = { CPU_BC_L2_CONF, CPU_IM_CONFIG, > + CPU_DM_CONFIG0, CPU_RCONF_DEFAULT, > + CPU_RCONF_BYPASS, CPU_RCONF_A0_BF, CPU_RCONF_C0_DF, CPU_RCONF_E0_FF, > + CPU_RCONF_SMM, CPU_RCONF_DMM, GLCP_DELAY_CONTROLS, GL_END > + }; > + > + int gliu0_msr_defs[] = {MSR_GLIU0_BASE1, MSR_GLIU0_BASE2, MSR_GLIU0_BASE4, MSR_GLIU0_BASE5, MSR_GLIU0_BASE6, > + GLIU0_P2D_BMO_0, GLIU0_P2D_BMO_1, MSR_GLIU0_SYSMEM, > + GLIU0_P2D_RO_0, GLIU0_P2D_RO_1, GLIU0_P2D_RO_2, MSR_GLIU0_SHADOW, > + GLIU0_IOD_BM_0, GLIU0_IOD_BM_1, GLIU0_IOD_BM_2, > + GLIU0_IOD_SC_0, GLIU0_IOD_SC_1, GLIU0_IOD_SC_2, GLIU0_IOD_SC_3, GLIU0_IOD_SC_4, GLIU0_IOD_SC_5, > + GLIU0_GLD_MSR_COH, GL_END > + }; > + > + int gliu1_msr_defs[] = {MSR_GLIU1_BASE1, MSR_GLIU1_BASE2, MSR_GLIU1_BASE3, MSR_GLIU1_BASE4, MSR_GLIU1_BASE5, MSR_GLIU1_BASE6, > + MSR_GLIU1_BASE7, MSR_GLIU1_BASE8, MSR_GLIU1_BASE9, MSR_GLIU1_BASE10, > + GLIU1_P2D_R_0, GLIU1_P2D_R_1, GLIU1_P2D_R_2, GLIU1_P2D_R_3, MSR_GLIU1_SHADOW, > + GLIU1_IOD_BM_0, GLIU1_IOD_BM_1, GLIU1_IOD_BM_2, > + GLIU1_IOD_SC_0, GLIU1_IOD_SC_1, GLIU1_IOD_SC_2, GLIU1_IOD_SC_3, > + GLIU1_GLD_MSR_COH, GL_END > + }; > + > + int rconf_msr[] = { CPU_RCONF0, CPU_RCONF1, CPU_RCONF2, CPU_RCONF3, CPU_RCONF4, > + CPU_RCONF5, CPU_RCONF6, CPU_RCONF7, GL_END > + }; > + > + int cs5536_msr[] = { MDD_LBAR_GPIO, MDD_LBAR_FLSH0, MDD_LBAR_FLSH1, MDD_LEG_IO, MDD_PIN_OPT, > + MDD_IRQM_ZLOW, MDD_IRQM_ZHIGH, MDD_IRQM_PRIM, GL_END > + }; > + > + int pci_msr[] = { GLPCI_CTRL, GLPCI_ARB, GLPCI_REN, GLPCI_A0_BF, GLPCI_C0_DF, GLPCI_E0_FF, > + GLPCI_RC0, GLPCI_RC1, GLPCI_RC2, GLPCI_RC3, GLPCI_ExtMSR, GLPCI_SPARE, > + GL_END > + }; > + > + int dma_msr[] = { MDD_DMA_MAP, MDD_DMA_SHAD1, MDD_DMA_SHAD2, MDD_DMA_SHAD3, MDD_DMA_SHAD4, > + MDD_DMA_SHAD5, MDD_DMA_SHAD6, MDD_DMA_SHAD7, MDD_DMA_SHAD8, > + MDD_DMA_SHAD9, GL_END > + }; > + > + > + printk_debug("---------- CPU ------------\n"); > + > + for(i = 0; cpu_msr_defs[i] != GL_END; i++) { > + msr = rdmsr(cpu_msr_defs[i]); > + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", cpu_msr_defs[i], msr.hi, msr.lo); > + } > + > + printk_debug("---------- GLIU 0 ------------\n"); > + > + for(i = 0; gliu0_msr_defs[i] != GL_END; i++) { > + msr = rdmsr(gliu0_msr_defs[i]); > + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", gliu0_msr_defs[i], msr.hi, msr.lo); > + } > + > + printk_debug("---------- GLIU 1 ------------\n"); > + > + for(i = 0; gliu1_msr_defs[i] != GL_END; i++) { > + msr = rdmsr(gliu1_msr_defs[i]); > + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", gliu1_msr_defs[i], msr.hi, msr.lo); > + } > + > + printk_debug("---------- RCONF ------------\n"); > + > + for(i = 0; rconf_msr[i] != GL_END; i++) { > + msr = rdmsr(rconf_msr[i]); > + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", rconf_msr[i], msr.hi, msr.lo); > + } > + > + printk_debug("---------- VARIA ------------\n"); > + msr = rdmsr(0x51300010); > + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51300010, msr.hi, msr.lo); > + > + msr = rdmsr(0x51400015); > + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51400015, msr.hi, msr.lo); > + > + printk_debug("---------- DIVIL IRQ ------------\n"); > + msr = rdmsr(MDD_IRQM_YLOW); > + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YLOW, msr.hi, msr.lo); > + msr = rdmsr(MDD_IRQM_YHIGH); > + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YHIGH, msr.hi, msr.lo); > + msr = rdmsr(MDD_IRQM_ZLOW); > + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZLOW, msr.hi, msr.lo); > + msr = rdmsr(MDD_IRQM_ZHIGH); > + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZHIGH, msr.hi, msr.lo); > + > + > + printk_debug("---------- PCI ------------\n"); > + > + for(i = 0; pci_msr[i] != GL_END; i++) { > + msr = rdmsr(pci_msr[i]); > + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", pci_msr[i], msr.hi, msr.lo); > + } > + > + printk_debug("---------- LPC/UART DMA ------------\n"); > + > + for(i = 0; dma_msr[i] != GL_END; i++) { > + msr = rdmsr(dma_msr[i]); > + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", dma_msr[i], msr.hi, msr.lo); > + } > + > + printk_debug("---------- CS5536 ------------\n"); > + > + for(i = 0; cs5536_msr[i] != GL_END; i++) { > + msr = rdmsr(cs5536_msr[i]); > + printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", cs5536_msr[i], msr.hi, msr.lo); > + } > + > + iol = inl(GPIOL_INPUT_ENABLE); > + printk_debug("IOR 0x%08X is now 0x%08X\n", GPIOL_INPUT_ENABLE, iol); > + iol = inl(GPIOL_EVENTS_ENABLE); > + printk_debug("IOR 0x%08X is now 0x%08X\n", GPIOL_EVENTS_ENABLE, iol); > + iol = inl(GPIOL_INPUT_INVERT_ENABLE); > + printk_debug("IOR 0x%08X is now 0x%08X\n", GPIOL_INPUT_INVERT_ENABLE, iol); > + iol = inl(GPIO_MAPPER_X); > + printk_debug("IOR 0x%08X is now 0x%08X\n", GPIO_MAPPER_X, iol); > +#endif //DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR > +} > + > +static void init(struct device *dev) { > + > + printk_debug("ALIX1C ENTER %s\n", __FUNCTION__); > + > + printk_debug("ALIX1C EXIT %s\n", __FUNCTION__); Drop both printks? Are they useful? > +} > + > +static void enable_dev(struct device *dev) > +{ > + dev->ops->init = init; > +} > + > +struct chip_operations mainboard_pcengines_alix1c_ops = { > + CHIP_NAME("PC ENGINES ALIX1C Mainboard") CHIP_NAME("PC Engines ALIX1.C Mainboard") > + .enable_dev = enable_dev, > +}; > + > Index: src/mainboard/pcengines/alix1c/cache_as_ram_auto.c > =================================================================== > --- src/mainboard/pcengines/alix1c/cache_as_ram_auto.c (revision 0) > +++ src/mainboard/pcengines/alix1c/cache_as_ram_auto.c (revision 0) Add a license header, please. > @@ -0,0 +1,118 @@ > +#define ASSEMBLY 1 > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include "pc80/serial.c" > +#include "arch/i386/lib/console.c" > +#include "ram/ramtest.c" > +#include "cpu/x86/bist.h" > +#include "cpu/x86/msr.h" > +#include > +#include > +#include "southbridge/amd/cs5536/cs5536.h" > + > +#define POST_CODE(x) outb(x, 0x80) We have a global implementation already. > +#define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1) > + > +#include "southbridge/amd/cs5536/cs5536_early_smbus.c" > +#include "southbridge/amd/cs5536/cs5536_early_setup.c" > +#include "superio/winbond/w83627hf/w83627hf_early_serial.c" > + > +static inline int spd_read_byte(unsigned device, unsigned address) > +{ > + return smbus_read_byte(device, address); > +} > + > +#define ManualConf 0 /* Do automatic strapped PLL config */ > +#define PLLMSRhi 0x00001490 /* manual settings for the PLL */ > +#define PLLMSRlo 0x02000030 > +#define DIMM0 0xA0 > +#define DIMM1 0xA2 > +#include "northbridge/amd/lx/raminit.h" > +#include "northbridge/amd/lx/pll_reset.c" > +#include "northbridge/amd/lx/raminit.c" > +#include "sdram/generic_sdram.c" > +#include "cpu/amd/model_lx/cpureginit.c" > +#include "cpu/amd/model_lx/syspreinit.c" > + > +static void msr_init(void) > +{ > + msr_t msr; > + /* Setup access to the MC for under 1MB. Note MC not setup yet. */ > + msr.hi = 0x24fffc02; > + msr.lo = 0x10010000; > + wrmsr(CPU_RCONF_DEFAULT, msr); > + > + msr.hi = 0x20000000; > + msr.lo = 0xfff00; > + wrmsr(MSR_GLIU0 + 0x20, msr); > + > + msr.hi = 0x20000000; > + msr.lo = 0xfff00; > + wrmsr(MSR_GLIU1 + 0x20, msr); > + > +} Is this board-specific or chipset-specific? If the latter, it should not be here. > +static void mb_gpio_init(void) > +{ > + /* Early mainboard specific GPIO setup */ > +} > + > +void cache_as_ram_main(void) > +{ > + extern void RestartCAR(); > + POST_CODE(0x01); > + > + static const struct mem_controller memctrl [] = { > + {.channel0 = {(0xa<<3)|0, (0xa<<3)|1}} > + }; > + > + SystemPreInit(); > + msr_init(); > + > + cs5536_early_setup(); > + > + /* NOTE: must do this AFTER the early_setup! > + * it is counting on some early MSR setup > + * for cs5536 > + */ > + cs5536_disable_internal_uart(); > + w83627hf_enable_serial(SERIAL_DEV, TTYS0_BASE); > + mb_gpio_init(); > + uart_init(); > + console_init(); > + > + pll_reset(ManualConf); > + > + cpuRegInit(); > + > + sdram_initialize(1, memctrl); > + > + /* Check all of memory */ Only checks _some_ memory. > + ram_check(0x00000000, 640*1024); > + > + /* Switch from Cache as RAM to real RAM */ > + /* There are two ways we could think about this. > + 1. If we are using the auto.inc ROMCC way, the stack is going to be re-setup in the code following this code. > + Just wbinvd the stack to clear the cache tags. We don't care where the stack used to be. > + 2. This file is built as a normal .c -> .o and linked in etc. The stack might be used to return etc. > + That means we care about what is in the stack. If we are smart we set the CAR stack to the same location > + as the rest of LinuxBIOS. If that is the case we can just do a wbinvd. The stack will be written into real > + RAM that is now setup and we continue like nothing happened. If the stack is located somewhere other than > + where LB would like it, you need to write some code to do a copy from cache to RAM > + > + We use method 1 on Norwich and on this board too. > + */ This comment is in some other file, too. Maybe it should go in the wiki or in the generic CAR code somewhere? No need to duplicate it in every LX board... > + POST_CODE(0x02); > + print_err("POST 02\n"); > + __asm__("wbinvd\n"); Don't we have a wbinvd() function? Or is that in v3 only? > + print_err("Past wbinvd\n"); > + /* we are finding the return does not work on this board. Explicitly call the label that is > + * after the call to us. This is gross, but sometimes at this level it is the only way out > + */ > + done_cache_as_ram_main(); > +} > Index: targets/pcengines/alix1c/Config.lb > =================================================================== > --- targets/pcengines/alix1c/Config.lb (revision 0) > +++ targets/pcengines/alix1c/Config.lb (revision 0) Add a license header, please. > @@ -0,0 +1,26 @@ > +target alix1c > +mainboard pcengines/alix1c > + > +option CONFIG_COMPRESSED_PAYLOAD_NRV2B=0 > + > +## ROM_SIZE is the total number of bytes allocated for LinuxBIOS use > +## (normal AND fallback images and payloads). > +## leave 36k for vsa > +## > +option ROM_SIZE = 512*1024 - 36 * 1024 > + > +## ROM_IMAGE_SIZE is the maximum number of bytes allowed for a LinuxBIOS image, > +## not including any payload. > +option ROM_IMAGE_SIZE=64*1024 > + > +option FALLBACK_SIZE = ROM_SIZE > + > +option DEFAULT_CONSOLE_LOGLEVEL = 11 > +option MAXIMUM_CONSOLE_LOGLEVEL = 11 Is 11 valid? Isn't 9 the maximum? Anyway, I guess this can be dropped and the defaults in Options.lb set to 11 then? Yeah, just a minor issue. > +romimage "fallback" > + option USE_FALLBACK_IMAGE=1 > + option LINUXBIOS_EXTRA_VERSION=".0Fallback" > + payload /tmp/filo.elf > +end > + > +buildrom ./linuxbios.rom ROM_SIZE "fallback" HTH, 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 rminnich at gmail.com Sat Sep 8 20:37:54 2007 From: rminnich at gmail.com (ron minnich) Date: Sat, 8 Sep 2007 11:37:54 -0700 Subject: [LinuxBIOS] [PATCH] buildrom: m57sli linux kernel config + makefile In-Reply-To: <2ea3fae10709081116g2d97a898o503a9bfb77b56a9@mail.gmail.com> References: <20070906142507.GD29891@localdomain> <13426df10709081026k35f67563w2fd99f24c35e90e8@mail.gmail.com> <2ea3fae10709081116g2d97a898o503a9bfb77b56a9@mail.gmail.com> Message-ID: <13426df10709081137s64d7d943k935b9ac71c1b7c59@mail.gmail.com> On 9/8/07, yhlu wrote: > can someone put the buildrom2.amd64 into the tree too? someone who knows buildrom better than I will have to do this one :-) but let's get it in, it is needed. ron From peter at stuge.se Sat Sep 8 20:38:25 2007 From: peter at stuge.se (Peter Stuge) Date: Sat, 8 Sep 2007 20:38:25 +0200 Subject: [LinuxBIOS] M57SLI Revision 2 SPI In-Reply-To: <46E18E69.4060905@stockwith.co.uk> References: <46E18E69.4060905@stockwith.co.uk> <1189190609.46e19bd1c9b9d@imp.free.fr> <46E18E69.4060905@stockwith.co.uk> Message-ID: <20070908183825.1018.qmail@stuge.se> On Fri, Sep 07, 2007 at 06:46:17PM +0100, Chris Lingard wrote: > Gigabyte have told me that the BIOS chip is made by SST, and the > model name is SST25LF040A BIOS ROM which is PLCC32 type. Nonsense, I'm afraid. SST25LF040A is only available in 8-contact packages. (SOIC and WSON) Whoever you had contact with at Gigabyte didn't know about the different revisions of the board and their differences. > I am now very confused because I have PLCC32 sockets and these are > nothing like the BIOS chip which has 8 connections. > > (I have two PLCC32 sockets and four unused flash chips to give away, > if they are no use to this version of the motherboard). Correct, since you don't have PLCC chips you have the revision with SOIC chips. > I will probably try to source some of these chips, just in case the > rest of the problems can be solved. The hardware part is solved, but there's no support for flashing in flashrom yet, you would have to reboot into another OS (DOS or Windows) and use the Gigabyte-supplied flashing utility. For the hardware mod you would need: 1x SST25LF040A or MX25L4005A 2x 100k resistors (0.125W ones are good size-wise) 1x SPDT (single pole dual throw) switch (break-before-make or make-before-break doesn't matter much - neither will reliably allow the switch to be flipped while the flash chip is being accessed.) See http://stuge.se/m57sli_soic_detail_labels.jpg for contact names. 1. Lift the U5-CS# pin from the board. 2. Solder 1x 100k resistor between U5-VCC and the lifted U5-CS# pin. 3. Solder the center contact on the switch to the U5-CS# pad on the mainboard. 4. Solder one outer contact on the switch to the U5-CS# pin, where one end of the resistor in step 2 is also soldered. 5. Solder the new flash chip to the U9 pads. Note pin 1! There should be a marking on the flash chip near one corner pin, that's pin 1, U9-CS#. 6. Lift U9-CS# from the board. (Or just don't solder it in step 5.) 7. Solder 1x 100k resistor between U9-VCC and the lifted U9-CS# pin. 8. Solder the second outer contact on the switch to the U9-CS# pin, where one end of the resistor in step 7 is also soldered. Done! Now the switch controls which of U5 and U9 is actually selected when the super io wants to access the flash chip. You could get a biased (spring-loaded) switch in order to help avoiding accidentally leaving the system running with the factory BIOS chip selected when you're doing LB work - so that the next flashing operation does not overwrite the wrong chip. You would need to hold the switch while booting the factory BIOS, but that may be worthwhile if you can't easily redo the soldering work if both flash chips contain junk. //Peter From peter at stuge.se Sat Sep 8 20:41:18 2007 From: peter at stuge.se (Peter Stuge) Date: Sat, 8 Sep 2007 20:41:18 +0200 Subject: [LinuxBIOS] [PATCH] Flashrom: sis630 simplification In-Reply-To: <13426df10709081059p547adebcud430e6243753f690@mail.gmail.com> <20070908175631.GA18334@greenwood> References: <1189262986.26302.129.camel@localhost> <13426df10709081059p547adebcud430e6243753f690@mail.gmail.com> <1189262986.26302.129.camel@localhost> <20070908175631.GA18334@greenwood> Message-ID: <20070908184118.1541.qmail@stuge.se> On Sat, Sep 08, 2007 at 07:56:32PM +0200, Uwe Hermann wrote: > On Sat, Sep 08, 2007 at 04:49:46PM +0200, Alex Beregszaszi wrote: > > attached patch changes out/in combinations to pci_read/write_byte in > > sis630 chipset enable. > > Why? There is abstraction available - so it should be used everywhere. > Did you test the patch on hardware? On Sat, Sep 08, 2007 at 10:59:39AM -0700, ron minnich wrote: > I don't think this should be done unless someone can test. I agree with the patch - I want the change, but I also agree it would be nice to have it tested. We could argue that we decided to go through with the patch in order to improve the code and until someone has a problem with the code not working there is no real problem. //Peter From peter at stuge.se Sat Sep 8 20:52:57 2007 From: peter at stuge.se (Peter Stuge) Date: Sat, 8 Sep 2007 20:52:57 +0200 Subject: [LinuxBIOS] PATCH: add the pcengines ALIX1 In-Reply-To: <20070908183721.GB18334@greenwood> References: <13426df10709071258u5096ea78x2514c53dfb509e08@mail.gmail.com> <20070907213532.GG10747@greenwood> <13426df10709080928o1e6d8febwa97572c9d263352@mail.gmail.com> <20070908183721.GB18334@greenwood> Message-ID: <20070908185257.3264.qmail@stuge.se> Hey, On Sat, Sep 08, 2007 at 08:37:21PM +0200, Uwe Hermann wrote: > On Sat, Sep 08, 2007 at 09:28:34AM -0700, ron minnich wrote: > > Hi, here is try 2. This one builds :-) > > +++ src/mainboard/pcengines/alix1c/reset.c (revision 0) > > @@ -0,0 +1,43 @@ > > +#if 0 > > As it's commented out (and likely copied from some other target), > please drop the file completely for now. We can add a working > version (or preferrably use a global/common file if possible) if > and when we need it. > I don't like adding dummy files which aren't really necessary. Agreed. I don't think this file can be made generic though - but I'm not completely sure. > Is this file even used ATM? I see a > default HAVE_HARD_RESET=0 > in Options.lb. Right - this means the file is not used, and it should be removed. .. > HTH, Uwe. Thanks for the review Uwe. You found a lot of (IMHO) important issues in the patch. It would be great if all of these issues could be investigated and fixed now that the patch has been committed already. (Or we could decide that we don't care at all about the state or quality of v2 but then code will rot and we will lose support for more boards - like we did with v1. Let's not repeat that mistake.) Thanks! //Peter From info at coresystems.de Sat Sep 8 21:19:16 2007 From: info at coresystems.de (LinuxBIOS information) Date: Sat, 08 Sep 2007 21:19:16 +0200 Subject: [LinuxBIOS] r2765 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "rminnich" checked in revision 2765 to the LinuxBIOS source repository and caused the following changes: Change Log: Welcome to PC Engines and the ALIX 1C! This is a geode LX board. There are timing settings that are not right yet, we are still trying to get our board to boot Linux :-) Signed-off-by: Ronald G. Minnich Acked-by: Stefan Reinauer Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2765&device=hdama&vendor=arima Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2765&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2765&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2765&device=juki-511p&vendor=iei Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2765&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2765&device=dk8x&vendor=iwill If something broke during this checkin please be a pain in rminnich's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From chris at stockwith.co.uk Sat Sep 8 21:21:07 2007 From: chris at stockwith.co.uk (Chris Lingard) Date: Sat, 08 Sep 2007 20:21:07 +0100 Subject: [LinuxBIOS] M57SLI Revision 2 SPI In-Reply-To: <20070908183825.1018.qmail@stuge.se> References: <46E18E69.4060905@stockwith.co.uk> <1189190609.46e19bd1c9b9d@imp.free.fr> <46E18E69.4060905@stockwith.co.uk> <20070908183825.1018.qmail@stuge.se> Message-ID: <46E2F623.70803@stockwith.co.uk> Peter Stuge wrote: > On Fri, Sep 07, 2007 at 06:46:17PM +0100, Chris Lingard wrote: >> Gigabyte have told me that the BIOS chip is made by SST, and the >> model name is SST25LF040A BIOS ROM which is PLCC32 type. > > Nonsense, I'm afraid. > > SST25LF040A is only available in 8-contact packages. (SOIC and WSON) > > Whoever you had contact with at Gigabyte didn't know about the > different revisions of the board and their differences. > > >> I am now very confused because I have PLCC32 sockets and these are >> nothing like the BIOS chip which has 8 connections. >> >> (I have two PLCC32 sockets and four unused flash chips to give away, >> if they are no use to this version of the motherboard). > > Correct, since you don't have PLCC chips you have the revision with > SOIC chips. > > >> I will probably try to source some of these chips, just in case the >> rest of the problems can be solved. > > The hardware part is solved, but there's no support for flashing > in flashrom yet, you would have to reboot into another OS (DOS or > Windows) and use the Gigabyte-supplied flashing utility. > > > For the hardware mod you would need: > > 1x SST25LF040A or MX25L4005A > 2x 100k resistors (0.125W ones are good size-wise) > 1x SPDT (single pole dual throw) switch (break-before-make or > make-before-break doesn't matter much - neither will reliably allow > the switch to be flipped while the flash chip is being accessed.) > > See http://stuge.se/m57sli_soic_detail_labels.jpg for contact names. > > 1. Lift the U5-CS# pin from the board. > 2. Solder 1x 100k resistor between U5-VCC and the lifted U5-CS# pin. > 3. Solder the center contact on the switch to the U5-CS# pad on the > mainboard. > 4. Solder one outer contact on the switch to the U5-CS# pin, where > one end of the resistor in step 2 is also soldered. > 5. Solder the new flash chip to the U9 pads. Note pin 1! There should > be a marking on the flash chip near one corner pin, that's pin 1, > U9-CS#. > 6. Lift U9-CS# from the board. (Or just don't solder it in step 5.) > 7. Solder 1x 100k resistor between U9-VCC and the lifted U9-CS# pin. > 8. Solder the second outer contact on the switch to the U9-CS# pin, > where one end of the resistor in step 7 is also soldered. > > Done! Now the switch controls which of U5 and U9 is actually > selected when the super io wants to access the flash chip. > > > You could get a biased (spring-loaded) switch in order to help > avoiding accidentally leaving the system running with the factory > BIOS chip selected when you're doing LB work - so that the next > flashing operation does not overwrite the wrong chip. You would need > to hold the switch while booting the factory BIOS, but that may be > worthwhile if you can't easily redo the soldering work if both flash > chips contain junk. > > > //Peter Thank you, that is brilliant. OK, two PLCC32 sockets and four unused flash chips free to good home :-) Apply by email, (or 2 sets of one socket and two chips). Will start sourcing SST25LF040A on Monday, then rebook the workshop. My second newbie dumb question. If I make copies of the Factory BIOS on a floppy, I can overwrite one of them with LinuxBios. I then use the BIOS, and when it asks for confirmation, I switch over to the new chip, and hope. (The Gigabyte BIOS can overwrite itself, press key during post to enter Q-flash) Chris Lingard From uwe at hermann-uwe.de Sat Sep 8 21:23:07 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 8 Sep 2007 21:23:07 +0200 Subject: [LinuxBIOS] [PATCH] Global failover.c Message-ID: <20070908192307.GC18334@greenwood> See patch. This is required for my MSI MS-6178 patch to work (which already uses the global failover.c file) and will enable us to drop quite a bunch of duplicate files from the repo (which will be an extra patch, though). 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: v2_failover.patch Type: text/x-diff Size: 1903 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 Sep 8 21:24:47 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 8 Sep 2007 21:24:47 +0200 Subject: [LinuxBIOS] [PATCH] buildrom: packages/linuxbios/m57sli-linuxbios.mk (revised) In-Reply-To: <20070906033848.GB26150@localdomain> References: <20070906033848.GB26150@localdomain> Message-ID: <20070908192447.GD18334@greenwood> On Wed, Sep 05, 2007 at 11:38:48PM -0400, Ward Vandewege wrote: > Index: packages/linuxbios/m57sli-linuxbios.mk > =================================================================== > --- packages/linuxbios/m57sli-linuxbios.mk (revision 0) > +++ packages/linuxbios/m57sli-linuxbios.mk (revision 0) > @@ -0,0 +1,44 @@ > +# This is the Generic LinuxBIOS target > + > +ifeq ($(CONFIG_PLATFORM),y) > +ifeq ($(LINUXBIOS_TAG),) > +$(error You need to specify a version to pull in your platform config) > +endif > +endif > + > +LINUXBIOS_PATCHES= > + > +ifeq ($(CONFIG_PAYLOAD_FILO),y) > + LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/m57sli-filo-Config.lb.patch > +endif > + > +ifeq ($(CONFIG_PAYLOAD_KERNEL),y) > + LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/m57sli-kernel-and-lab-Config.lb.patch > +endif > + > +ifeq ($(CONFIG_PAYLOAD_LAB),y) > + LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/m57sli-kernel-and-lab-Config.lb.patch > +endif > + > + > +LINUXBIOS_BASE_DIR=svn > +LINUXBIOS_URL=svn://openbios.org/repos/trunk/LinuxBIOSv2 Minor issue, but why not use linuxbios.org here? 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 svn at openbios.org Sat Sep 8 21:36:35 2007 From: svn at openbios.org (svn at openbios.org) Date: Sat, 8 Sep 2007 21:36:35 +0200 Subject: [LinuxBIOS] r496 - in LinuxBIOSv3: include lib Message-ID: Author: uwe Date: 2007-09-08 21:36:35 +0200 (Sat, 08 Sep 2007) New Revision: 496 Modified: LinuxBIOSv3/include/string.h LinuxBIOSv3/lib/lar.c Log: Add a simple strncmp() implementation in include/string.h. Change lib/lar.c to use strncmp() for magic check. Current code depends on that the len field will never hold a value bigger than 0xffffff, which is a working assumption given current flash sizes, but my next patch might affect this. Signed-off-by: Alex Beregszaszi Acked-by: Uwe Hermann Modified: LinuxBIOSv3/include/string.h =================================================================== --- LinuxBIOSv3/include/string.h 2007-09-07 17:53:47 UTC (rev 495) +++ LinuxBIOSv3/include/string.h 2007-09-08 19:36:35 UTC (rev 496) @@ -110,4 +110,24 @@ return c1 - c2; } +/** + * Compare two strings with fixed length. + * + * @param s1 The first string. + * @param s2 The second string. + * @param maxlen Return at most maxlen characters as length of the string. + * @return A non-zero value if s1 and s2 differ, or zero if s1 equals s2. + */ +static inline int strncmp(const char *s1, const char *s2, int maxlen) +{ + int i; + + for (i = 0; i < maxlen; i++) { + if (s1[i] != s2[i]) + return s1[i] - s2[i]; + } + + return 0; +} + #endif /* STRING_H */ Modified: LinuxBIOSv3/lib/lar.c =================================================================== --- LinuxBIOSv3/lib/lar.c 2007-09-07 17:53:47 UTC (rev 495) +++ LinuxBIOSv3/lib/lar.c 2007-09-08 19:36:35 UTC (rev 496) @@ -92,7 +92,7 @@ for (walk = archive->start; (walk < (char *)(archive->start + archive->len - sizeof(struct lar_header))) && (walk >= (char *)archive->start); walk += 16) { - if (strcmp(walk, MAGIC) != 0) + if (strncmp(walk, MAGIC, 8) != 0) continue; header = (struct lar_header *)walk; From uwe at hermann-uwe.de Sat Sep 8 21:37:09 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 8 Sep 2007 21:37:09 +0200 Subject: [LinuxBIOS] [PATCH] use strncmp in lar In-Reply-To: <1189039855.26302.2.camel@localhost> References: <1189039855.26302.2.camel@localhost> Message-ID: <20070908193709.GE18334@greenwood> On Thu, Sep 06, 2007 at 02:50:55AM +0200, Alex Beregszaszi wrote: > 1, simple strncmp implementation in include/string.h > 2, changes lib/lar.c to use strncmp for magic check. Current code > depends on that the len field will never hold a value bigger than > 0xffffff, which is a working assumption given current flash sizes, but > my next patch might affect this. Looks good. Committed in r496 with some minor modifications. 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 marc-andre_beck at gmx.ch Sat Sep 8 21:41:05 2007 From: marc-andre_beck at gmx.ch (=?UTF-8?B?TWFyYy1BbmRyw6kgQmVjaw==?=) Date: Sat, 08 Sep 2007 21:41:05 +0200 Subject: [LinuxBIOS] LinuxBIOS Summit Europe 2007 Message-ID: <46E2FAD1.5050700@gmx.ch> Dear LinuxBIOS community, after the LinuxBIOS summit in Hamburg, Germany last October, we are looking forward to have a LinuxBIOS summit again this year. We are planning to have the summit at two locations in Switzerland. Biel October 17th-19th(afternoon) and Berne 19th(night)-21st. Topics will roughly cover the development news since last year, the goals for LinuxBIOS in the future and of course having a good time together. The registration process is open for everyone willing to attend or talk at: http://linuxbios.eu Thanks and have a nice weekend, Marc-Andr? From uwe at hermann-uwe.de Sat Sep 8 21:41:28 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 8 Sep 2007 21:41:28 +0200 Subject: [LinuxBIOS] [PATCH] buildrom: m57sli linux kernel config + makefile In-Reply-To: <2ea3fae10709081116g2d97a898o503a9bfb77b56a9@mail.gmail.com> References: <20070906142507.GD29891@localdomain> <13426df10709081026k35f67563w2fd99f24c35e90e8@mail.gmail.com> <2ea3fae10709081116g2d97a898o503a9bfb77b56a9@mail.gmail.com> Message-ID: <20070908194127.GF18334@greenwood> On Sat, Sep 08, 2007 at 11:16:13AM -0700, yhlu wrote: > can someone put the buildrom2.amd64 into the tree too? What exactly is this? An enhancement for buildrom or a fork of buildrom? If so, why? What's different? If not a fork, please post this as a patch against the current svn version so we can review and commit... Thanks, 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 peter at stuge.se Sat Sep 8 22:11:07 2007 From: peter at stuge.se (Peter Stuge) Date: Sat, 8 Sep 2007 22:11:07 +0200 Subject: [LinuxBIOS] LinuxBIOS Summit Europe 2007 In-Reply-To: <46E2FAD1.5050700@gmx.ch> References: <46E2FAD1.5050700@gmx.ch> Message-ID: <20070908201107.15748.qmail@stuge.se> On Sat, Sep 08, 2007 at 09:41:05PM +0200, Marc-Andr? Beck wrote: > We are planning to have the summit at two locations in Switzerland. > Biel October 17th-19th(afternoon) and Berne 19th(night)-21st. I'm going to miss this one, unfortunately. :\ Impossible week for me, already booked for another event. It would be awesome for me (and hopefully others) if audio could be distributed from the meetings. I can help with some bandwidth in .se fairly close to GIX if needed. Maybe also take input from stream listeners on IRC? //Peter From yinghailu at gmail.com Sat Sep 8 22:21:33 2007 From: yinghailu at gmail.com (yhlu) Date: Sat, 8 Sep 2007 13:21:33 -0700 Subject: [LinuxBIOS] [PATCH] buildrom: m57sli linux kernel config + makefile In-Reply-To: <20070908194127.GF18334@greenwood> References: <20070906142507.GD29891@localdomain> <13426df10709081026k35f67563w2fd99f24c35e90e8@mail.gmail.com> <2ea3fae10709081116g2d97a898o503a9bfb77b56a9@mail.gmail.com> <20070908194127.GF18334@greenwood> Message-ID: <2ea3fae10709081321p75291697s556f210eed5821b6@mail.gmail.com> On 9/8/07, Uwe Hermann wrote: > On Sat, Sep 08, 2007 at 11:16:13AM -0700, yhlu wrote: > > can someone put the buildrom2.amd64 into the tree too? > > What exactly is this? An enhancement for buildrom or a fork of buildrom? > If so, why? What's different? 64 bit version. esp mkelfImage patch that will take elf64 vmlinux to produce elf32, so can load that from 32 bit LinuxBIOS in AMD64 platform. For amd64 platform, I think that we should use 64 bit tiny kernel in flash. YH From peter at stuge.se Sat Sep 8 22:26:13 2007 From: peter at stuge.se (Peter Stuge) Date: Sat, 8 Sep 2007 22:26:13 +0200 Subject: [LinuxBIOS] M57SLI Revision 2 SPI In-Reply-To: <46E2F623.70803@stockwith.co.uk> References: <46E18E69.4060905@stockwith.co.uk> <1189190609.46e19bd1c9b9d@imp.free.fr> <46E18E69.4060905@stockwith.co.uk> <20070908183825.1018.qmail@stuge.se> <46E2F623.70803@stockwith.co.uk> Message-ID: <20070908202613.18015.qmail@stuge.se> On Sat, Sep 08, 2007 at 08:21:07PM +0100, Chris Lingard wrote: > Peter Stuge wrote: > > For the hardware mod you would need: .. > Thank you, that is brilliant. Note that I have not tested it since I don't have the board, but in theory it should work based on the measurements done by others. > Will start sourcing SST25LF040A on Monday, then rebook the > workshop. No guarantees from me that it will work - but if you still want to give it a go we sure would appreciate hearing from you when it's done. I think there are some more electronics savvy people reading the list who could try the mod on their own boards with less effort than booking a workshop - to confirm that it actually works in practice. But if you can't wait I completely understand! =) > My second newbie dumb question. If I make copies of the Factory > BIOS on a floppy, I can overwrite one of them with LinuxBios. I > then use the BIOS, and when it asks for confirmation, I switch over > to the new chip, and hope. (The Gigabyte BIOS can overwrite > itself, press key during post to enter Q-flash) Yes - make copies of the factory BIOS. Several of them, ideally. I'd even recommend flashing the factory BIOS into the new chip and then going back to the shop and replacing one flash chip with a blank one so you know you have one working flash chip safely stored away from the board. I would also recommend using a flashing program separate from the one in the factory BIOS however, since Q-flash may be making assumptions about the flash chip contents (since it knows it is stored in flash) which are no longer true when you flip the switch, and could cause the flashing to fail. But it could also just work. :) //Peter From uwe at hermann-uwe.de Sat Sep 8 22:37:08 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 8 Sep 2007 22:37:08 +0200 Subject: [LinuxBIOS] [PATCH] v3: Add support for building on Debian GNU/kFreeBSD In-Reply-To: <20070908181227.GC14851@coresystems.de> References: <20070907223001.GH10747@greenwood> <20070908181227.GC14851@coresystems.de> Message-ID: <20070908203708.GG18334@greenwood> On Sat, Sep 08, 2007 at 08:12:27PM +0200, Stefan Reinauer wrote: > * Uwe Hermann [070908 00:30]: > > + $(Q)# On Debian GNU/kFreeBSD we need the linker output format > > + $(Q)# 'elf32-i386-freebsd' instead of just 'elf32-i386'. > > +ifneq (, $(filter Linux GNU GNU_%, $(shell uname -s))) > > I think stuff like this belongs in xcompile! Good point. Updated patch attached. 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: v3_kfreebsd2.patch Type: text/x-diff Size: 2788 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 corey.osgood at gmail.com Sat Sep 8 22:37:07 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Sat, 08 Sep 2007 16:37:07 -0400 Subject: [LinuxBIOS] Program to load vga bios after kernel init that was linked? Message-ID: <46E307F3.3020000@gmail.com> I know someone (Peter?) linked to something like this, IIRC it consisted of a kernel patch and userspace program. Does anyone have the link? I think it was about 2 months ago that it was sent, and I can't seem to find it anywhere. Thanks, Corey From peter at stuge.se Sat Sep 8 22:55:03 2007 From: peter at stuge.se (Peter Stuge) Date: Sat, 8 Sep 2007 22:55:03 +0200 Subject: [LinuxBIOS] Program to load vga bios after kernel init that was linked? In-Reply-To: <46E307F3.3020000@gmail.com> References: <46E307F3.3020000@gmail.com> Message-ID: <20070908205503.23679.qmail@stuge.se> On Sat, Sep 08, 2007 at 04:37:07PM -0400, Corey Osgood wrote: > I know someone (Peter?) linked to something like this, Aye: http://dev.gentoo.org/~spock/projects/uvesafb/ From corey.osgood at gmail.com Sat Sep 8 22:57:51 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Sat, 08 Sep 2007 16:57:51 -0400 Subject: [LinuxBIOS] Program to load vga bios after kernel init that was linked? In-Reply-To: <20070908205503.23679.qmail@stuge.se> References: <46E307F3.3020000@gmail.com> <20070908205503.23679.qmail@stuge.se> Message-ID: <46E30CCF.1080708@gmail.com> Peter Stuge wrote: > On Sat, Sep 08, 2007 at 04:37:07PM -0400, Corey Osgood wrote: > >> I know someone (Peter?) linked to something like this, >> > > Aye: http://dev.gentoo.org/~spock/projects/uvesafb/ > > Thank you! -Corey From rminnich at gmail.com Sun Sep 9 00:54:30 2007 From: rminnich at gmail.com (ron minnich) Date: Sat, 8 Sep 2007 15:54:30 -0700 Subject: [LinuxBIOS] The linuxbios summit in oct. Message-ID: <13426df10709081554k2c7d44e8sdade1c7e512cf6f5@mail.gmail.com> It will be lots of hacking! Please bring your toys. Maybe we can get the hotel to threaten to toss us out again. Oh, and bring cameras and such stuff. Our goal, following on last year, is to get v3 done on our first hardware. I am talking to vendors to try and get us a nice standard platform that you can buy for cheap, in time for the meeting. I also hope to see XP booting this year, so if you have a licensed XP, bring it so we can try the ADLO2 work out. Then of course lots of show and tell with other's hardware. hope to see you there. I am VERY sorry it was short notice, it was a lot of effort to get it done at all (NOT that I did everything, it was those other guys!) thanks ron From rminnich at gmail.com Sun Sep 9 00:59:36 2007 From: rminnich at gmail.com (ron minnich) Date: Sat, 8 Sep 2007 15:59:36 -0700 Subject: [LinuxBIOS] PATCH: add the pcengines ALIX1 In-Reply-To: <20070908183721.GB18334@greenwood> References: <13426df10709071258u5096ea78x2514c53dfb509e08@mail.gmail.com> <20070907213532.GG10747@greenwood> <13426df10709080928o1e6d8febwa97572c9d263352@mail.gmail.com> <20070908183721.GB18334@greenwood> Message-ID: <13426df10709081559g7948048dl2b34445f9aa18588@mail.gmail.com> Uwe, thanks for the review. I am going to repatch later today or tomorrow and submit the corrections. I do appreciate the work you all do in keeping the code base cleaner. wbinvd -- I think we only have that in v3. I won't change that for now. POST_CODE -- I may apply this to both this and the msm800sev and, yes, I did copy code here. I sometimes am unsure what bits to drop but, clearly, I should have dropped more :-) Thanks! ron p.s. And, peter, I am very sorry to hear you can't make it to the meeting in Oct. I hope that you can find a way to come to Denver. From rminnich at gmail.com Sun Sep 9 01:43:25 2007 From: rminnich at gmail.com (ron minnich) Date: Sat, 8 Sep 2007 16:43:25 -0700 Subject: [LinuxBIOS] M57SLI Revision 2 SPI In-Reply-To: <20070908183825.1018.qmail@stuge.se> References: <1189190609.46e19bd1c9b9d@imp.free.fr> <46E18E69.4060905@stockwith.co.uk> <20070908183825.1018.qmail@stuge.se> Message-ID: <13426df10709081643q76bc3066y4a29bb1759d7093c@mail.gmail.com> Does this set of directions fit on the wiki somewhere? pictures? ron From peter at stuge.se Sun Sep 9 03:10:40 2007 From: peter at stuge.se (Peter Stuge) Date: Sun, 9 Sep 2007 03:10:40 +0200 Subject: [LinuxBIOS] The linuxbios summit in oct. In-Reply-To: <13426df10709081559g7948048dl2b34445f9aa18588@mail.gmail.com> <13426df10709081554k2c7d44e8sdade1c7e512cf6f5@mail.gmail.com> References: <13426df10709071258u5096ea78x2514c53dfb509e08@mail.gmail.com> <20070907213532.GG10747@greenwood> <13426df10709080928o1e6d8febwa97572c9d263352@mail.gmail.com> <20070908183721.GB18334@greenwood> <13426df10709081559g7948048dl2b34445f9aa18588@mail.gmail.com> <13426df10709081554k2c7d44e8sdade1c7e512cf6f5@mail.gmail.com> Message-ID: <20070909011040.1091.qmail@stuge.se> On Sat, Sep 08, 2007 at 03:54:30PM -0700, ron minnich wrote: > Maybe we can get the hotel to threaten to toss us out again. :) > Our goal, following on last year, is to get v3 done on our first > hardware. I'm really sorry to miss this. I am confident it will get done! > I am talking to vendors to try and get us a nice standard > platform that you can buy for cheap, in time for the meeting. Cool - there should be a few good LX candidates. > I also hope to see XP booting this year, so if you have a licensed > XP, bring it so we can try the ADLO2 work out. On Sat, Sep 08, 2007 at 03:59:36PM -0700, ron minnich wrote: > p.s. And, peter, I am very sorry to hear you can't make it to the > meeting in Oct. Thanks - me too. Everyone will surely have a lot of fun there. I would really have liked to attend but am head of sound engineering in a theatre/musical ensemble in the evenings all that week. I would love to at least follow the meeting during the days either with audio or on IRC. I hope that can be done. > I hope that you can find a way to come to Denver. Have you set a rough date already? Dunno about traveling to the US though.. //Peter From peter at stuge.se Sun Sep 9 03:15:57 2007 From: peter at stuge.se (Peter Stuge) Date: Sun, 9 Sep 2007 03:15:57 +0200 Subject: [LinuxBIOS] M57SLI Revision 2 SPI In-Reply-To: <13426df10709081643q76bc3066y4a29bb1759d7093c@mail.gmail.com> References: <1189190609.46e19bd1c9b9d@imp.free.fr> <46E18E69.4060905@stockwith.co.uk> <20070908183825.1018.qmail@stuge.se> <13426df10709081643q76bc3066y4a29bb1759d7093c@mail.gmail.com> Message-ID: <20070909011557.1807.qmail@stuge.se> On Sat, Sep 08, 2007 at 04:43:25PM -0700, ron minnich wrote: > Does this set of directions fit on the wiki somewhere? Too early until it has actually been tested? Maybe not. > pictures? I can take some pictures of the process using an experiment board and another SO-8 chip, that might be useful to illustrate how the resistors can be mounted even if it's not the Gigabyte board. Maybe whoever does the first testing on actual hardware can also take some pictures? //Peter From rminnich at gmail.com Sun Sep 9 07:12:11 2007 From: rminnich at gmail.com (ron minnich) Date: Sat, 8 Sep 2007 22:12:11 -0700 Subject: [LinuxBIOS] PATCH: add the pcengines ALIX1 In-Reply-To: <20070908183721.GB18334@greenwood> References: <13426df10709071258u5096ea78x2514c53dfb509e08@mail.gmail.com> <20070907213532.GG10747@greenwood> <13426df10709080928o1e6d8febwa97572c9d263352@mail.gmail.com> <20070908183721.GB18334@greenwood> Message-ID: <13426df10709082212h42c9091dxdf77ac4585f74a53@mail.gmail.com> Partial diff attached, .... here are comments. Still builds. On 9/8/07, Uwe Hermann wrote: > Add a license header, please. done > As it's commented out (and likely copied from some other target), please > drop the file completely for now. We can add a working version (or > preferrably use a global/common file if possible) if and when we need it. > I don't like adding dummy files which aren't really necessary. removed. > > + 32+16*9, /* There can be total 9 devices on the bus */ > > Is the 9 (and the rest of this file) correct and tested? fixed constant in options.lb and replace 9 with the IRQ_SLOT_COUNT. > Add a license header, please. done > > NACK. Not yet another copy of this file, please. Move it into lib/ or > somewhere globally, and use that in all targets. We should stop > replicating there files again and again. patch 2 as attached. > > NACK, see above. This is common code just about every board duplicate?? > again and again. I have a patch which adds a global failover.c into > lib/ (which my recent i810 board patch already uses, btw). > > I'll post the patch ASAP. I'll wait for your failover.c patch, but beware: they are not ALWAYS totally identical. > > > > Index: src/mainboard/pcengines/alix1c/chip.h > > =================================================================== > > --- src/mainboard/pcengines/alix1c/chip.h (revision 0) > > +++ src/mainboard/pcengines/alix1c/chip.h (revision 0) > > Trivial, but please add a license header. done. > > +++ src/mainboard/pcengines/alix1c/cmos.layout (revision 0) > > This should be dropped for now (needs a small fix in Config.lb to make > it still compile), as you use not, I want it here as we will want CMOS support on this board at some point. > Add a license header, please. done. > > + > > +/* Print the platform configuration */ > > +void print_conf(void) { > > Is this really needed here? Should it go in some common lib/ file? > Doesn't look board-specific to me. let's unify it but later. It's not always non-board-specific. > > + printk_debug("ALIX1C ENTER %s\n", __FUNCTION__); > > + > > + printk_debug("ALIX1C EXIT %s\n", __FUNCTION__); > > Drop both printks? Are they useful? They are useful for debug, so that people can see what's getting run and when. I would prefer to leave them in. > > CHIP_NAME("PC Engines ALIX1.C Mainboard") done I think. > > +++ src/mainboard/pcengines/alix1c/cache_as_ram_auto.c (revision 0) > > Add a license header, please. done > > +#define POST_CODE(x) outb(x, 0x80) > > We have a global implementation already. cache as ram is weird, I want to test this before I use the library. The library can do lots more than outb, what with serial post and timers etc. > > + > > +} > > Is this board-specific or chipset-specific? If the latter, it should not > be here. I am not sure. Marc? > > + /* Check all of memory */ > > Only checks _some_ memory. :-) Will fix in next go round, I forgot to. > > + > > + We use method 1 on Norwich and on this board too. > > + */ > > This comment is in some other file, too. Maybe it should go in the wiki > or in the generic CAR code somewhere? No need to duplicate it in every > LX board... I want this comment in, since not all users of LX read all files that use LX ;-) > > > > + POST_CODE(0x02); > > + print_err("POST 02\n"); > > + __asm__("wbinvd\n"); > > Don't we have a wbinvd() function? Or is that in v3 only? v3 only AFAIK. > > +++ targets/pcengines/alix1c/Config.lb (revision 0) > > Add a license header, please. done So, try 2. ron -------------- next part -------------- A non-text attachment was scrubbed... Name: pcengines.diff Type: text/x-patch Size: 8421 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: removedebug.diff Type: text/x-patch Size: 1856 bytes Desc: not available URL: From peter at stuge.se Sun Sep 9 13:41:36 2007 From: peter at stuge.se (Peter Stuge) Date: Sun, 9 Sep 2007 13:41:36 +0200 Subject: [LinuxBIOS] PATCH: add the pcengines ALIX1 In-Reply-To: <13426df10709082212h42c9091dxdf77ac4585f74a53@mail.gmail.com> References: <13426df10709071258u5096ea78x2514c53dfb509e08@mail.gmail.com> <20070907213532.GG10747@greenwood> <13426df10709080928o1e6d8febwa97572c9d263352@mail.gmail.com> <20070908183721.GB18334@greenwood> <13426df10709082212h42c9091dxdf77ac4585f74a53@mail.gmail.com> Message-ID: <20070909114136.1926.qmail@stuge.se> I just had a thought.. On Sat, Sep 08, 2007 at 10:12:11PM -0700, ron minnich wrote: > > > + printk_debug("ALIX1C ENTER %s\n", __FUNCTION__); > > > + > > > + printk_debug("ALIX1C EXIT %s\n", __FUNCTION__); .. > > CHIP_NAME("PC Engines ALIX1.C Mainboard") Maybe we want a board name #define or global const char * somewhere so that the board name is consistent across files. Maybe it can be the directory name to close the loop back to source at the same time? //Peter From joe at smittys.pointclark.net Sun Sep 9 20:14:18 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Sun, 09 Sep 2007 14:14:18 -0400 Subject: [LinuxBIOS] RCA RM4100 almost running PLEASE HELP! In-Reply-To: <46E35AF0.7000401@gmail.com> References: <20070908214340.ef6zd6wmk4gcgksk@www.smittys.pointclark.net> <46E352B2.7000201@gmail.com> <46E35AF0.7000401@gmail.com> Message-ID: <20070909141418.z2hcvn40g8wowkgc@www.smittys.pointclark.net> >> Can you try >> rebuilding with the i82801db or dbm (whichever yours is) instead of the >> generic i82801xx? If that works, let me know and I'll see where the >> difference lies, and try to fix it. >> >> Good luck, >> Corey >> Thanks for your time Corey. As I look at the i82801DB code I don't think anyone ever got it working anyways. I got it to run but it does the same thing. It looks like someone just copied the code from ICH5 and never got it going (WIP maybe?). Well I have narrowed it down to 2 things, The PCI BRIDGE, or the NIC. The nic is down from the PCI bridge on bus 1. For some reason what ever do it keeps telling me "Disabling static device: PCI: 01:08.0". Because this is down from the PCI bridge, could this be what is causing the PCI bridge to lock up? On the PCI Bridge, I tried to disable eveything in Config.lb except the pci 00:0.0 Host bridge and pci 00:1f.0 ISA bridge-LPC. and it boots (attached) (well not really, I just have /etc/hosts as a payload). Then I tried to enable the 00:1e.0 PCI bridge and it locks up again. Could there be a register setting on the PCI Bridge causing this? Any ideas what it could be? Should I try to compaire it to lspci -xxx?? Thanks - Joe -------------- next part -------------- LinuxBIOS-2.0.0.0Fallback Sat Sep 8 23:36:22 EDT 2007 starting... Setting initial registers.... Initial registers have been set. No DIMM found in slot 00 DRB 0x60 has been set to 0x00 DRB1 0x61 has been set to 0x00 Found DIMM in slot 01 DIMM is 0x0080 on side 1 DIMM is 0x0000 on side 2 DRB2 0x62 has been set to 0x04 DRB3 0x63 has been set to 0x04 No DIMM found in slot 00, setting DRA to 0xFF DRA 0x70 has been set to 0xff Found DIMM in slot 01, setting DRA... DRA 0x71 has been set to 0xf1 RAM Enable 1: Apply NOP Sending RAM command 0x00000010 to 0x00000000 RAM Enable 2: Precharge all Sending RAM command 0x00000020 to 0x00000000 RAM Enable 3: CBR Sending RAM command 0x00000060 to 0x00000000 RAM Enable 4: Mode register set Sending RAM command 0x00000030 to 0x000001d0 RAM Enable 5: Normal operation Sending RAM command 0x20000170 to 0x00000000 Northbridge following SDRAM init: PCI: 00:00.00 00: 86 80 75 35 06 00 10 00 04 00 00 06 00 00 00 00 10: 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 40: 09 00 05 01 00 00 00 00 00 00 00 00 02 28 00 0e 50: 72 a0 20 00 00 00 00 00 00 30 33 33 33 33 33 33 60: 00 00 04 04 00 00 00 00 00 00 00 00 00 00 00 00 70: ff f1 ff ff 00 00 00 00 10 00 00 00 70 01 00 20 80: 00 00 00 00 00 00 00 00 00 d0 20 40 00 00 00 00 90: 02 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 02 00 20 00 17 02 00 1f 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 54 0e 41 a2 99 01 00 c0 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 09 c9 9f fc f0: 11 11 01 00 00 00 0b 05 34 d6 30 cf 22 cf 27 cf Copying LinuxBIOS to RAM. Jumping to LinuxBIOS. LinuxBIOS-2.0.0.0Fallback Sat Sep 8 23:36:22 EDT 2007 booting... end 6cf7b1d5, start 0 32-bit delta 1566 calibrate_tsc 32-bit result is 1566 clocks_per_usec: 1566 Enumerating buses... scan_static_bus for Root Device Finding PCI configuration type. PCI: Using configuration type 1 PCI_DOMAIN: 0000 enabled PCI_DOMAIN: 0000 scanning... PCI: pci_scan_bus for bus 00 PCI: 00:00.0 [8086/3575] ops PCI: 00:00.0 [8086/3575] enabled PCI: devfn 0x9, bad id 0xffffffff PCI: devfn 0xa, bad id 0xffffffff PCI: devfn 0xb, bad id 0xffffffff PCI: devfn 0xc, bad id 0xffffffff PCI: devfn 0xd, bad id 0xffffffff PCI: devfn 0xe, bad id 0xffffffff PCI: devfn 0xf, bad id 0xffffffff PCI: 00:02.0 [8086/3577] disabled PCI: devfn 0x11, bad id 0xffffffff PCI: devfn 0x12, bad id 0xffffffff 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 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: 00:1d.0 [8086/24c2] ops PCI: 00:1d.0 [8086/24c2] disabled PCI: devfn 0xeb, bad id 0xffffffff PCI: devfn 0xec, bad id 0xffffffff PCI: devfn 0xed, bad id 0xffffffff PCI: devfn 0xee, bad id 0xffffffff PCI: 00:1e.0 [8086/244e] bus ops PCI: 00:1e.0 [8086/244e] disabled PCI: devfn 0xf1, bad id 0xffffffff PCI: devfn 0xf2, bad id 0xffffffff PCI: devfn 0xf3, bad id 0xffffffff PCI: devfn 0xf4, bad id 0xffffffff PCI: devfn 0xf5, bad id 0xffffffff PCI: devfn 0xf6, bad id 0xffffffff PCI: devfn 0xf7, bad id 0xffffffff PCI: 00:1f.0 [8086/24c0] bus ops PCI: 00:1f.0 [8086/24c0] enabled PCI: 00:1f.1 [8086/24cb] ops PCI: 00:1f.1 [8086/24cb] disabled PCI: devfn 0xfa, bad id 0xffffffff PCI: 00:1f.3 [8086/24c3] disabled PCI: devfn 0xfc, bad id 0xffffffff PCI: 00:1f.5 [8086/24c5] ops PCI: 00:1f.5 [8086/24c5] disabled PCI: 00:1f.6 [8086/24c6] ops PCI: 00:1f.6 [8086/24c6] disabled PCI: devfn 0xff, bad id 0xffffffff scan_static_bus for PCI: 00:1f.0 Found SMSC Super I/O (ID=0x60, rev=0x01) PNP: 002e.0 disabled PNP: 002e.3 disabled PNP: 002e.4 enabled PNP: 002e.5 disabled PNP: 002e.7 enabled PNP: 002e.9 disabled PNP: 002e.a disabled PNP: 002e.b disabled scan_static_bus for PCI: 00:1f.0 done PCI: pci_scan_bus returning with max=000 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:00.0 register 10(00000008), read-only ignoring it PCI: 00:1f.0 read_resources bus 0 link: 0 PCI: 00:1f.0 read_resources bus 0 link: 0 done PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done Root Device read_resources bus 0 link: 0 done Root Device compute_allocate_io: base: 00000400 size: 00000000 align: 0 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 Root Device compute_allocate_mem: base: 00000000 size: 00000000 align: 0 gran: 0 done Done reading resources. Setting resources... Root Device compute_allocate_io: base: 00001000 size: 00000000 align: 0 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done Root Device compute_allocate_io: base: 00001000 size: 00000000 align: 0 gran: 0 done Root Device compute_allocate_mem: base: 100000000 size: 00000000 align: 0 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done Root Device compute_allocate_mem: base: 100000000 size: 00000000 align: 0 gran: 0 done Root Device assign_resources, bus 0 link: 0 Setting RAM size to 131072 PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 PCI: 00:1f.0 assign_resources, bus 0 link: 0 PNP: 002e.4 60 <- [0x00000003f8 - 0x00000003ff] io PNP: 002e.4 70 <- [0x0000000004 - 0x0000000004] irq PNP: 002e.7 60 <- [0x0000000060 - 0x0000000060] io PNP: 002e.7 62 <- [0x0000000064 - 0x0000000064] io PNP: 002e.7 70 <- [0x0000000001 - 0x0000000001] irq PNP: 002e.7 72 <- [0x000000000c - 0x000000000c] irq PCI: 00:1f.0 assign_resources, bus 0 link: 0 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:00.0 cmd <- 146 PCI: 00:1f.0 cmd <- 14f done. Initializing devices... Root Device init PCI: 00:00.0 init Northbridge init PCI: 00:1f.0 init IOAPIC Southbridge enabled 2186 Southbridge APIC ID = 2000000 Set power on if power fails RTC Init PNP: 002e.4 init PNP: 002e.7 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. Moving GDT to 0x500...ok Adjust low_table_end from 0x00000530 to 0x00001000 Adjust rom_table_end from 0x000f0400 to 0x00100000 Wrote linuxbios table at: 00000530 - 000006d8 checksum d403 Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3 rom_stream: 0xfffd0000 - 0xfffdffff No header at 0 - 8096 (shortened) header_offset is -1 Can not load ELF Image. From rminnich at gmail.com Sun Sep 9 20:14:37 2007 From: rminnich at gmail.com (ron minnich) Date: Sun, 9 Sep 2007 11:14:37 -0700 Subject: [LinuxBIOS] PATCH: add the pcengines ALIX1 In-Reply-To: <20070909114136.1926.qmail@stuge.se> References: <13426df10709071258u5096ea78x2514c53dfb509e08@mail.gmail.com> <20070907213532.GG10747@greenwood> <13426df10709080928o1e6d8febwa97572c9d263352@mail.gmail.com> <20070908183721.GB18334@greenwood> <13426df10709082212h42c9091dxdf77ac4585f74a53@mail.gmail.com> <20070909114136.1926.qmail@stuge.se> Message-ID: <13426df10709091114m211de795q59b83d3948667894@mail.gmail.com> On 9/9/07, Peter Stuge wrote: > I just had a thought.. > Maybe we want a board name #define or global const char * somewhere > so that the board name is consistent across files. Maybe it can be > the directory name to close the loop back to source at the same time? great thought; keep having thoughts. In v3 this comes from the Kconfig. In v2, it could come from config but note the name: pcengines/alix1c but we print ALIX.1C or some such. And . has meaning in C. not sure ron From uwe at hermann-uwe.de Sun Sep 9 20:30:16 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 9 Sep 2007 20:30:16 +0200 Subject: [LinuxBIOS] PATCH: add the pcengines ALIX1 In-Reply-To: <13426df10709091114m211de795q59b83d3948667894@mail.gmail.com> References: <13426df10709071258u5096ea78x2514c53dfb509e08@mail.gmail.com> <20070907213532.GG10747@greenwood> <13426df10709080928o1e6d8febwa97572c9d263352@mail.gmail.com> <20070908183721.GB18334@greenwood> <13426df10709082212h42c9091dxdf77ac4585f74a53@mail.gmail.com> <20070909114136.1926.qmail@stuge.se> <13426df10709091114m211de795q59b83d3948667894@mail.gmail.com> Message-ID: <20070909183016.GA19841@greenwood> On Sun, Sep 09, 2007 at 11:14:37AM -0700, ron minnich wrote: > In v3 this comes from the Kconfig. In v2, it could come from config > but note the name: pcengines/alix1c but we print ALIX.1C or some such. > And . has meaning in C. Yeah, this is fixed in v3, and I wonder whether it's worth messing with it in v2. It's definately a good thing to have in v3, though. 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 svn at openbios.org Sun Sep 9 21:43:31 2007 From: svn at openbios.org (svn at openbios.org) Date: Sun, 9 Sep 2007 21:43:31 +0200 Subject: [LinuxBIOS] r2766 - trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c Message-ID: Author: uwe Date: 2007-09-09 21:43:31 +0200 (Sun, 09 Sep 2007) New Revision: 2766 Removed: trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/debug.c trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/reset.c Modified: trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/Config.lb trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/Options.lb trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/cache_as_ram_auto.c trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/chip.h trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/irq_tables.c trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/mainboard.c Log: Partial changes and fixup. Removed reset.c and added copyright headers. Remove debug.c. It is not used and should not be here. Signed-off-by: Ronald G. Minnich Acked-by: Uwe Hermann Modified: trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/Config.lb 2007-09-08 18:32:53 UTC (rev 2765) +++ trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/Config.lb 2007-09-09 19:43:31 UTC (rev 2766) @@ -1,4 +1,24 @@ ## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2006-2007 Ronald G. Minnich +## +## 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 +## + +## ## Compute the location and size of where this firmware image ## (linuxBIOS plus bootloader) will live in the boot rom chip. ## Modified: trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/Options.lb 2007-09-08 18:32:53 UTC (rev 2765) +++ trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/Options.lb 2007-09-09 19:43:31 UTC (rev 2766) @@ -1,3 +1,23 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2006-2007 Ronald G. Minnich +## +## 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 +## + uses HAVE_MP_TABLE uses HAVE_PIRQ_TABLE uses USE_FALLBACK_IMAGE @@ -83,7 +103,7 @@ ## Build code to export a programmable irq routing table ## default HAVE_PIRQ_TABLE=1 -default IRQ_SLOT_COUNT=6 +default IRQ_SLOT_COUNT=9 #object irq_tables.o ## Modified: trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/cache_as_ram_auto.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/cache_as_ram_auto.c 2007-09-08 18:32:53 UTC (rev 2765) +++ trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/cache_as_ram_auto.c 2007-09-09 19:43:31 UTC (rev 2766) @@ -1,3 +1,22 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2007 Advanced Micro Devices, Inc. + * + * 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 + */ + #define ASSEMBLY 1 #include @@ -92,8 +111,8 @@ sdram_initialize(1, memctrl); - /* Check all of memory */ - ram_check(0x00000000, 640*1024); + /* Check memory */ + ram_check(0x00000000, 640 * 1024); /* Switch from Cache as RAM to real RAM */ /* There are two ways we could think about this. Modified: trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/chip.h 2007-09-08 18:32:53 UTC (rev 2765) +++ trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/chip.h 2007-09-09 19:43:31 UTC (rev 2766) @@ -1,3 +1,22 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2007 Advanced Micro Devices, Inc. + * + * 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 + */ + extern struct chip_operations mainboard_pcengines_alix1c_ops; struct mainboard_pcengines_alix1c_config { Deleted: trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/debug.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/debug.c 2007-09-08 18:32:53 UTC (rev 2765) +++ trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/debug.c 2007-09-09 19:43:31 UTC (rev 2766) @@ -1,66 +0,0 @@ - -static void print_debug_pci_dev(unsigned dev) -{ - print_debug("PCI: "); - print_debug_hex8((dev >> 16) & 0xff); - print_debug_char(':'); - print_debug_hex8((dev >> 11) & 0x1f); - print_debug_char('.'); - print_debug_hex8((dev >> 8) & 7); -} - -static void print_pci_devices(void) -{ - device_t dev; - for(dev = PCI_DEV(0, 0, 0); - dev <= PCI_DEV(0, 0x1f, 0x7); - dev += PCI_DEV(0,0,1)) { - uint32_t id; - id = pci_read_config32(dev, PCI_VENDOR_ID); - if (((id & 0xffff) == 0x0000) || ((id & 0xffff) == 0xffff) || - (((id >> 16) & 0xffff) == 0xffff) || - (((id >> 16) & 0xffff) == 0x0000)) { - continue; - } - print_debug_pci_dev(dev); - print_debug("\r\n"); - } -} - -static void dump_pci_device(unsigned dev) -{ - int i; - print_debug_pci_dev(dev); - print_debug("\r\n"); - - for(i = 0; i <= 255; i++) { - unsigned char val; - if ((i & 0x0f) == 0) { - print_debug_hex8(i); - print_debug_char(':'); - } - val = pci_read_config8(dev, i); - print_debug_char(' '); - print_debug_hex8(val); - if ((i & 0x0f) == 0x0f) { - print_debug("\r\n"); - } - } -} - -static void dump_pci_devices(void) -{ - device_t dev; - for(dev = PCI_DEV(0, 0, 0); - dev <= PCI_DEV(0, 0x1f, 0x7); - dev += PCI_DEV(0,0,1)) { - uint32_t id; - id = pci_read_config32(dev, PCI_VENDOR_ID); - if (((id & 0xffff) == 0x0000) || ((id & 0xffff) == 0xffff) || - (((id >> 16) & 0xffff) == 0xffff) || - (((id >> 16) & 0xffff) == 0x0000)) { - continue; - } - dump_pci_device(dev); - } -} Modified: trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/irq_tables.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/irq_tables.c 2007-09-08 18:32:53 UTC (rev 2765) +++ trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/irq_tables.c 2007-09-09 19:43:31 UTC (rev 2766) @@ -44,7 +44,7 @@ const struct irq_routing_table intel_irq_routing_table = { PIRQ_SIGNATURE, /* u32 signature */ PIRQ_VERSION, /* u16 version */ - 32+16*9, /* There can be total 9 devices on the bus */ + 32+16*IRQ_SLOT_COUNT, /* There can be total IRQ_SLOT_COUNT devices on the bus */ 0x00, /* Where the interrupt router lies (bus) */ (0x0f<<3)|0x0, /* Where the interrupt router lies (dev) */ 0, /* IRQs devoted exclusively to PCI usage */ Modified: trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/mainboard.c 2007-09-08 18:32:53 UTC (rev 2765) +++ trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/mainboard.c 2007-09-09 19:43:31 UTC (rev 2766) @@ -1,3 +1,22 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2007 Advanced Micro Devices, Inc. + * + * 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 #include @@ -135,20 +154,19 @@ #endif //DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR } -static void init(struct device *dev) { - +static void init(struct device *dev) +{ printk_debug("ALIX1C ENTER %s\n", __FUNCTION__); - printk_debug("ALIX1C EXIT %s\n", __FUNCTION__); } static void enable_dev(struct device *dev) { - dev->ops->init = init; + dev->ops->init = init; } struct chip_operations mainboard_pcengines_alix1c_ops = { - CHIP_NAME("PC ENGINES ALIX1C Mainboard") - .enable_dev = enable_dev, + CHIP_NAME("PC Engines ALIX1.C Mainboard") + .enable_dev = enable_dev, }; Deleted: trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/reset.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/reset.c 2007-09-08 18:32:53 UTC (rev 2765) +++ trunk/LinuxBIOSv2/src/mainboard/pcengines/alix1c/reset.c 2007-09-09 19:43:31 UTC (rev 2766) @@ -1,43 +0,0 @@ -#if 0 -//#include "arch/romcc_io.h" -#include - -typedef unsigned device_t; - -#define PCI_DEV(BUS, DEV, FN) ( \ - (((BUS) & 0xFF) << 16) | \ - (((DEV) & 0x1f) << 11) | \ - (((FN) & 0x7) << 8)) - -static void pci_write_config8(device_t dev, unsigned where, unsigned char value) -{ - unsigned addr; - addr = dev | where; - outl(0x80000000 | (addr & ~3), 0xCF8); - outb(value, 0xCFC + (addr & 3)); -} - -static void pci_write_config32(device_t dev, unsigned where, unsigned value) -{ - unsigned addr; - addr = dev | where; - outl(0x80000000 | (addr & ~3), 0xCF8); - outl(value, 0xCFC); -} - -static unsigned pci_read_config32(device_t dev, unsigned where) -{ - unsigned addr; - addr = dev | where; - outl(0x80000000 | (addr & ~3), 0xCF8); - return inl(0xCFC); -} - -#include "../../../northbridge/amd/amdk8/reset_test.c" - -void hard_reset(void) -{ - set_bios_reset(); - pci_write_config8(PCI_DEV(1, 0x04, 0), 0x47, 1); -} -#endif From uwe at hermann-uwe.de Sun Sep 9 21:45:04 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 9 Sep 2007 21:45:04 +0200 Subject: [LinuxBIOS] PATCH: add the pcengines ALIX1 In-Reply-To: <13426df10709082212h42c9091dxdf77ac4585f74a53@mail.gmail.com> References: <13426df10709071258u5096ea78x2514c53dfb509e08@mail.gmail.com> <20070907213532.GG10747@greenwood> <13426df10709080928o1e6d8febwa97572c9d263352@mail.gmail.com> <20070908183721.GB18334@greenwood> <13426df10709082212h42c9091dxdf77ac4585f74a53@mail.gmail.com> Message-ID: <20070909194504.GB19841@greenwood> On Sat, Sep 08, 2007 at 10:12:11PM -0700, ron minnich wrote: > Partial diff attached, .... here are comments. > > Still builds. Yep, look good. Committed in r2766 with some minor cosmetics. Shall we list the board in the wiki as "WIP" (as it doesn't boot Linux yet)? > > NACK, see above. This is common code just about every board duplicate?? > > again and again. I have a patch which adds a global failover.c into > > lib/ (which my recent i810 board patch already uses, btw). > > > > I'll post the patch ASAP. > > I'll wait for your failover.c patch, but beware: they are not ALWAYS > totally identical. Yes, unfortunately, but I think 90% or so are the same. Maybe we can even make failover.c generic enough for 100% of the boards? Anyway, my failover.c patch is posted, please review. > > Only checks _some_ memory. > > :-) > > Will fix in next go round, I forgot to. I fixed it while I was at it. > > > + > > > + We use method 1 on Norwich and on this board too. > > > + */ > > > > This comment is in some other file, too. Maybe it should go in the wiki > > or in the generic CAR code somewhere? No need to duplicate it in every > > LX board... > > I want this comment in, since not all users of LX read all files that use LX ;-) Well, yeah, but I think we should still put it somewhere globally and then just "link" to it from here a la "for details see XXXX"... 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 svn at openbios.org Sun Sep 9 22:02:45 2007 From: svn at openbios.org (svn at openbios.org) Date: Sun, 9 Sep 2007 22:02:45 +0200 Subject: [LinuxBIOS] r2767 - trunk/util/flashrom Message-ID: Author: uwe Date: 2007-09-09 22:02:45 +0200 (Sun, 09 Sep 2007) New Revision: 2767 Modified: trunk/util/flashrom/udelay.c Log: Add missing license header to udelay.c. I'm self-ack'ing this, as the origin of the code in udelay.c (and thus the license and copyright owner) is pretty clear. The code which is now in udelay.c was split out from flash_rom.c in r1428, and flash_rom.c, in turn, has been around since the beginning and had a 'Copyright 2000 Silicon Integrated System Corporation' line as well as the usual GPLv2-or-later license header. Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Modified: trunk/util/flashrom/udelay.c =================================================================== --- trunk/util/flashrom/udelay.c 2007-09-09 19:43:31 UTC (rev 2766) +++ trunk/util/flashrom/udelay.c 2007-09-09 20:02:45 UTC (rev 2767) @@ -1,3 +1,23 @@ +/* + * This file is part of the flashrom project. + * + * Copyright 2000 Silicon Integrated System 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 + */ + #include #include #include "flash.h" From uwe at hermann-uwe.de Sun Sep 9 22:09:03 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 9 Sep 2007 22:09:03 +0200 Subject: [LinuxBIOS] FYI flashrom included in Fedora Linux since yesterday. In-Reply-To: References: Message-ID: <20070909200903.GC19841@greenwood> On Sat, Sep 08, 2007 at 05:05:02PM +0400, Peter Lemenkov wrote: > Now not only a debian users can install it w/o any effords, but Fedora > Linux users too. > > $ sudo yum install flashrom Great, thanks! I documented this in the wiki, too, see http://linuxbios.org/Flashrom > Optional: > Can you ask upstream to add an license header to udelay.c and include a copy of Done. > their license in the repository? Done. > There are some build warnings that should be reported upstream: > layout.c: In function 'read_romlayout': > > layout.c:114: warning: ignoring return value of 'fscanf', declared with > attribute warn_unused_result > flashrom.c: In function 'main': > > flashrom.c:402: warning: ignoring return value of 'fwrite', declared with > attribute warn_unused_result > flashrom.c:421: warning: ignoring return value of 'fread', declared with > attribute warn_unused_result Which compiler options did you use here? I don't see any warnings using the stock svn code and Makefile. The warnings don't look critical to me, btw. > And another one note - flashrom can't be built at PowerPC arch due to > lack of . Does anybody also tried to build it at this arch? > How powerpc-users of LinuxBIOS (if any) flash their machines? Yep, flashrom doesn't build on all platforms, yet. On some it might not even make sense to have flashrom at all (maybe S/390, a mainframe which probably doesn't even have a "BIOS", or at least not in the traditional sense; I'm just guessing, though). See http://buildd.debian.org/pkg.cgi?pkg=flashrom for the current architecture build status of the Debian package. Any help with porting flashrom is highly welcome! 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 Sun Sep 9 22:11:57 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 9 Sep 2007 22:11:57 +0200 Subject: [LinuxBIOS] [PATCH] Flashrom: sis630 simplification In-Reply-To: <20070908184118.1541.qmail@stuge.se> References: <1189262986.26302.129.camel@localhost> <13426df10709081059p547adebcud430e6243753f690@mail.gmail.com> <1189262986.26302.129.camel@localhost> <20070908175631.GA18334@greenwood> <20070908184118.1541.qmail@stuge.se> Message-ID: <20070909201157.GD19841@greenwood> On Sat, Sep 08, 2007 at 08:41:18PM +0200, Peter Stuge wrote: > On Sat, Sep 08, 2007 at 07:56:32PM +0200, Uwe Hermann wrote: > > On Sat, Sep 08, 2007 at 04:49:46PM +0200, Alex Beregszaszi wrote: > > > attached patch changes out/in combinations to pci_read/write_byte in > > > sis630 chipset enable. > > > > Why? > > There is abstraction available - so it should be used everywhere. Ah, yes. I missed the fact that those functions do the same as the replaced code. > > Did you test the patch on hardware? > > On Sat, Sep 08, 2007 at 10:59:39AM -0700, ron minnich wrote: > > I don't think this should be done unless someone can test. > > > I agree with the patch - I want the change, but I also agree it would > be nice to have it tested. > > We could argue that we decided to go through with the patch in order > to improve the code and until someone has a problem with the code not > working there is no real problem. I'm not too eager to find out the hard way. This is low-level enough that I think there _might_ be unintended/unnoticed consequences. Anybody with such a chipset willing to test the patch? 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 svn at openbios.org Sun Sep 9 22:21:06 2007 From: svn at openbios.org (svn at openbios.org) Date: Sun, 9 Sep 2007 22:21:06 +0200 Subject: [LinuxBIOS] r2768 - trunk/util/flashrom Message-ID: Author: uwe Date: 2007-09-09 22:21:05 +0200 (Sun, 09 Sep 2007) New Revision: 2768 Modified: trunk/util/flashrom/82802ab.c trunk/util/flashrom/am29f040b.c trunk/util/flashrom/flash.h trunk/util/flashrom/flashchips.c trunk/util/flashrom/flashrom.c trunk/util/flashrom/jedec.c trunk/util/flashrom/m29f400bt.c trunk/util/flashrom/msys_doc.c trunk/util/flashrom/msys_doc.h trunk/util/flashrom/mx29f002.c trunk/util/flashrom/pm49fl004.c trunk/util/flashrom/sharplhf00l04.c trunk/util/flashrom/sst28sf040.c trunk/util/flashrom/sst39sf020.c trunk/util/flashrom/sst49lf040.c trunk/util/flashrom/sst49lfxxxc.c trunk/util/flashrom/sst_fwhub.c trunk/util/flashrom/udelay.c trunk/util/flashrom/w49f002u.c Log: Add '(C)' where it's missing (for consistency reasons). Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Modified: trunk/util/flashrom/82802ab.c =================================================================== --- trunk/util/flashrom/82802ab.c 2007-09-09 20:02:45 UTC (rev 2767) +++ trunk/util/flashrom/82802ab.c 2007-09-09 20:21:05 UTC (rev 2768) @@ -1,7 +1,7 @@ /* * This file is part of the flashrom project. * - * Copyright 2000 Silicon Integrated System Corporation + * Copyright (C) 2000 Silicon Integrated System 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 Modified: trunk/util/flashrom/am29f040b.c =================================================================== --- trunk/util/flashrom/am29f040b.c 2007-09-09 20:02:45 UTC (rev 2767) +++ trunk/util/flashrom/am29f040b.c 2007-09-09 20:21:05 UTC (rev 2768) @@ -1,7 +1,7 @@ /* * This file is part of the flashrom project. * - * Copyright 2000 Silicon Integrated System Corporation + * Copyright (C) 2000 Silicon Integrated System 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 Modified: trunk/util/flashrom/flash.h =================================================================== --- trunk/util/flashrom/flash.h 2007-09-09 20:02:45 UTC (rev 2767) +++ trunk/util/flashrom/flash.h 2007-09-09 20:21:05 UTC (rev 2768) @@ -1,9 +1,9 @@ /* * This file is part of the flashrom project. * - * Copyright 2000 Silicon Integrated System Corporation - * Copyright 2000 Ronald G. Minnich - * Copyright 2005-2007 coresystems GmbH + * Copyright (C) 2000 Silicon Integrated System Corporation + * Copyright (C) 2000 Ronald G. Minnich + * Copyright (C) 2005-2007 coresystems GmbH * * 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 Modified: trunk/util/flashrom/flashchips.c =================================================================== --- trunk/util/flashrom/flashchips.c 2007-09-09 20:02:45 UTC (rev 2767) +++ trunk/util/flashrom/flashchips.c 2007-09-09 20:21:05 UTC (rev 2768) @@ -1,9 +1,9 @@ /* * This file is part of the flashrom project. * - * Copyright 2000 Silicon Integrated System Corporation - * Copyright 2004 Tyan Corp - * Copyright 2005-2007 coresystems GmbH + * Copyright (C) 2000 Silicon Integrated System Corporation + * Copyright (C) 2004 Tyan Corp + * Copyright (C) 2005-2007 coresystems GmbH * * 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 Modified: trunk/util/flashrom/flashrom.c =================================================================== --- trunk/util/flashrom/flashrom.c 2007-09-09 20:02:45 UTC (rev 2767) +++ trunk/util/flashrom/flashrom.c 2007-09-09 20:21:05 UTC (rev 2768) @@ -1,9 +1,9 @@ /* * This file is part of the flashrom project. * - * Copyright 2000 Silicon Integrated System Corporation - * Copyright 2004 Tyan Corp - * Copyright 2005-2007 coresystems GmbH + * Copyright (C) 2000 Silicon Integrated System Corporation + * Copyright (C) 2004 Tyan Corp + * Copyright (C) 2005-2007 coresystems GmbH * * 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 Modified: trunk/util/flashrom/jedec.c =================================================================== --- trunk/util/flashrom/jedec.c 2007-09-09 20:02:45 UTC (rev 2767) +++ trunk/util/flashrom/jedec.c 2007-09-09 20:21:05 UTC (rev 2768) @@ -1,9 +1,9 @@ /* * This file is part of the flashrom project. * - * Copyright 2000 Silicon Integrated System Corporation - * Copyright 2006 Giampiero Giancipoli - * Copyright 2006 coresystems GmbH + * Copyright (C) 2000 Silicon Integrated System Corporation + * Copyright (C) 2006 Giampiero Giancipoli + * Copyright (C) 2006 coresystems GmbH * * 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 Modified: trunk/util/flashrom/m29f400bt.c =================================================================== --- trunk/util/flashrom/m29f400bt.c 2007-09-09 20:02:45 UTC (rev 2767) +++ trunk/util/flashrom/m29f400bt.c 2007-09-09 20:21:05 UTC (rev 2768) @@ -1,7 +1,7 @@ /* * This file is part of the flashrom project. * - * Copyright 2000 Silicon Integrated System Corporation + * Copyright (C) 2000 Silicon Integrated System 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 Modified: trunk/util/flashrom/msys_doc.c =================================================================== --- trunk/util/flashrom/msys_doc.c 2007-09-09 20:02:45 UTC (rev 2767) +++ trunk/util/flashrom/msys_doc.c 2007-09-09 20:21:05 UTC (rev 2768) @@ -1,7 +1,7 @@ /* * This file is part of the flashrom project. * - * Copyright 2003 Niki W. Waibel + * Copyright (C) 2003 Niki W. Waibel * * 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 Modified: trunk/util/flashrom/msys_doc.h =================================================================== --- trunk/util/flashrom/msys_doc.h 2007-09-09 20:02:45 UTC (rev 2767) +++ trunk/util/flashrom/msys_doc.h 2007-09-09 20:21:05 UTC (rev 2768) @@ -1,7 +1,7 @@ /* * This file is part of the flashrom project. * - * Copyright 2003 Niki W. Waibel + * Copyright (C) 2003 Niki W. Waibel * * 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 Modified: trunk/util/flashrom/mx29f002.c =================================================================== --- trunk/util/flashrom/mx29f002.c 2007-09-09 20:02:45 UTC (rev 2767) +++ trunk/util/flashrom/mx29f002.c 2007-09-09 20:21:05 UTC (rev 2768) @@ -1,7 +1,7 @@ /* * This file is part of the flashrom project. * - * Copyright 2000 Silicon Integrated System Corporation + * Copyright (C) 2000 Silicon Integrated System 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 Modified: trunk/util/flashrom/pm49fl004.c =================================================================== --- trunk/util/flashrom/pm49fl004.c 2007-09-09 20:02:45 UTC (rev 2767) +++ trunk/util/flashrom/pm49fl004.c 2007-09-09 20:21:05 UTC (rev 2768) @@ -1,7 +1,7 @@ /* * This file is part of the flashrom project. * - * Copyright 2004 Tyan Corporation + * Copyright (C) 2004 Tyan 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 Modified: trunk/util/flashrom/sharplhf00l04.c =================================================================== --- trunk/util/flashrom/sharplhf00l04.c 2007-09-09 20:02:45 UTC (rev 2767) +++ trunk/util/flashrom/sharplhf00l04.c 2007-09-09 20:21:05 UTC (rev 2768) @@ -1,7 +1,7 @@ /* * This file is part of the flashrom project. * - * Copyright 2000 Silicon Integrated System Corporation + * Copyright (C) 2000 Silicon Integrated System 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 Modified: trunk/util/flashrom/sst28sf040.c =================================================================== --- trunk/util/flashrom/sst28sf040.c 2007-09-09 20:02:45 UTC (rev 2767) +++ trunk/util/flashrom/sst28sf040.c 2007-09-09 20:21:05 UTC (rev 2768) @@ -1,8 +1,8 @@ /* * This file is part of the flashrom project. * - * Copyright 2000 Silicon Integrated System Corporation - * Copyright 2005 coresystems GmbH + * Copyright (C) 2000 Silicon Integrated System Corporation + * Copyright (C) 2005 coresystems GmbH * * 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 Modified: trunk/util/flashrom/sst39sf020.c =================================================================== --- trunk/util/flashrom/sst39sf020.c 2007-09-09 20:02:45 UTC (rev 2767) +++ trunk/util/flashrom/sst39sf020.c 2007-09-09 20:21:05 UTC (rev 2768) @@ -1,7 +1,7 @@ /* * This file is part of the flashrom project. * - * Copyright 2000 Silicon Integrated System Corporation + * Copyright (C) 2000 Silicon Integrated System 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 Modified: trunk/util/flashrom/sst49lf040.c =================================================================== --- trunk/util/flashrom/sst49lf040.c 2007-09-09 20:02:45 UTC (rev 2767) +++ trunk/util/flashrom/sst49lf040.c 2007-09-09 20:21:05 UTC (rev 2768) @@ -1,7 +1,7 @@ /* * This file is part of the flashrom project. * - * Copyright 2000 Silicon Integrated System Corporation + * Copyright (C) 2000 Silicon Integrated System 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 Modified: trunk/util/flashrom/sst49lfxxxc.c =================================================================== --- trunk/util/flashrom/sst49lfxxxc.c 2007-09-09 20:02:45 UTC (rev 2767) +++ trunk/util/flashrom/sst49lfxxxc.c 2007-09-09 20:21:05 UTC (rev 2768) @@ -1,8 +1,8 @@ /* * This file is part of the flashrom project. * - * Copyright 2000 Silicon Integrated System Corporation - * Copyright 2005-2007 coresystems GmbH + * Copyright (C) 2000 Silicon Integrated System Corporation + * Copyright (C) 2005-2007 coresystems GmbH * * 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 Modified: trunk/util/flashrom/sst_fwhub.c =================================================================== --- trunk/util/flashrom/sst_fwhub.c 2007-09-09 20:02:45 UTC (rev 2767) +++ trunk/util/flashrom/sst_fwhub.c 2007-09-09 20:21:05 UTC (rev 2768) @@ -1,7 +1,7 @@ /* * This file is part of the flashrom project. * - * Copyright 2000 Silicon Integrated System Corporation + * Copyright (C) 2000 Silicon Integrated System 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 Modified: trunk/util/flashrom/udelay.c =================================================================== --- trunk/util/flashrom/udelay.c 2007-09-09 20:02:45 UTC (rev 2767) +++ trunk/util/flashrom/udelay.c 2007-09-09 20:21:05 UTC (rev 2768) @@ -1,7 +1,7 @@ /* * This file is part of the flashrom project. * - * Copyright 2000 Silicon Integrated System Corporation + * Copyright (C) 2000 Silicon Integrated System 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 Modified: trunk/util/flashrom/w49f002u.c =================================================================== --- trunk/util/flashrom/w49f002u.c 2007-09-09 20:02:45 UTC (rev 2767) +++ trunk/util/flashrom/w49f002u.c 2007-09-09 20:21:05 UTC (rev 2768) @@ -1,7 +1,7 @@ /* * This file is part of the flashrom project. * - * Copyright 2000 Silicon Integrated System Corporation + * Copyright (C) 2000 Silicon Integrated System 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 From svn at openbios.org Sun Sep 9 22:24:29 2007 From: svn at openbios.org (svn at openbios.org) Date: Sun, 9 Sep 2007 22:24:29 +0200 Subject: [LinuxBIOS] r2769 - trunk/util/flashrom Message-ID: Author: uwe Date: 2007-09-09 22:24:29 +0200 (Sun, 09 Sep 2007) New Revision: 2769 Modified: trunk/util/flashrom/flash.h trunk/util/flashrom/msys_doc.h Log: Remove useless 'extern' keywords (trivial). Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Modified: trunk/util/flashrom/flash.h =================================================================== --- trunk/util/flashrom/flash.h 2007-09-09 20:21:05 UTC (rev 2768) +++ trunk/util/flashrom/flash.h 2007-09-09 20:24:29 UTC (rev 2769) @@ -183,88 +183,88 @@ extern char *lb_part, *lb_vendor; /* 82802ab.c */ -extern int probe_82802ab(struct flashchip *flash); -extern int erase_82802ab(struct flashchip *flash); -extern int write_82802ab(struct flashchip *flash, uint8_t *buf); +int probe_82802ab(struct flashchip *flash); +int erase_82802ab(struct flashchip *flash); +int write_82802ab(struct flashchip *flash, uint8_t *buf); /* am29f040b.c */ -extern int probe_29f040b(struct flashchip *flash); -extern int erase_29f040b(struct flashchip *flash); -extern int write_29f040b(struct flashchip *flash, uint8_t *buf); +int probe_29f040b(struct flashchip *flash); +int erase_29f040b(struct flashchip *flash); +int write_29f040b(struct flashchip *flash, uint8_t *buf); /* jedec.c */ -extern void toggle_ready_jedec(volatile uint8_t *dst); -extern void data_polling_jedec(volatile uint8_t *dst, uint8_t data); -extern void unprotect_jedec(volatile uint8_t *bios); -extern void protect_jedec(volatile uint8_t *bios); +void toggle_ready_jedec(volatile uint8_t *dst); +void data_polling_jedec(volatile uint8_t *dst, uint8_t data); +void unprotect_jedec(volatile uint8_t *bios); +void protect_jedec(volatile uint8_t *bios); int write_byte_program_jedec(volatile uint8_t *bios, uint8_t *src, volatile uint8_t *dst); -extern int probe_jedec(struct flashchip *flash); -extern int erase_chip_jedec(struct flashchip *flash); -extern int write_jedec(struct flashchip *flash, uint8_t *buf); -extern int erase_sector_jedec(volatile uint8_t *bios, unsigned int page); -extern int erase_block_jedec(volatile uint8_t *bios, unsigned int page); -extern int write_sector_jedec(volatile uint8_t *bios, uint8_t *src, - volatile uint8_t *dst, unsigned int page_size); +int probe_jedec(struct flashchip *flash); +int erase_chip_jedec(struct flashchip *flash); +int write_jedec(struct flashchip *flash, uint8_t *buf); +int erase_sector_jedec(volatile uint8_t *bios, unsigned int page); +int erase_block_jedec(volatile uint8_t *bios, unsigned int page); +int write_sector_jedec(volatile uint8_t *bios, uint8_t *src, + volatile uint8_t *dst, unsigned int page_size); /* m29f400bt.c */ -extern int probe_m29f400bt(struct flashchip *flash); -extern int erase_m29f400bt(struct flashchip *flash); -extern int block_erase_m29f400bt(volatile uint8_t *bios, +int probe_m29f400bt(struct flashchip *flash); +int erase_m29f400bt(struct flashchip *flash); +int block_erase_m29f400bt(volatile uint8_t *bios, volatile uint8_t *dst); -extern int write_m29f400bt(struct flashchip *flash, uint8_t *buf); -extern int write_linuxbios_m29f400bt(struct flashchip *flash, uint8_t *buf); -extern void toggle_ready_m29f400bt(volatile uint8_t *dst); -extern void data_polling_m29f400bt(volatile uint8_t *dst, uint8_t data); -extern void protect_m29f400bt(volatile uint8_t *bios); -extern void write_page_m29f400bt(volatile uint8_t *bios, uint8_t *src, - volatile uint8_t *dst, int page_size); +int write_m29f400bt(struct flashchip *flash, uint8_t *buf); +int write_linuxbios_m29f400bt(struct flashchip *flash, uint8_t *buf); +void toggle_ready_m29f400bt(volatile uint8_t *dst); +void data_polling_m29f400bt(volatile uint8_t *dst, uint8_t data); +void protect_m29f400bt(volatile uint8_t *bios); +void write_page_m29f400bt(volatile uint8_t *bios, uint8_t *src, + volatile uint8_t *dst, int page_size); /* mx29f002.c */ -extern int probe_29f002(struct flashchip *flash); -extern int erase_29f002(struct flashchip *flash); -extern int write_29f002(struct flashchip *flash, uint8_t *buf); +int probe_29f002(struct flashchip *flash); +int erase_29f002(struct flashchip *flash); +int write_29f002(struct flashchip *flash, uint8_t *buf); /* pm49fl004.c */ -extern int probe_49fl004(struct flashchip *flash); -extern int erase_49fl004(struct flashchip *flash); -extern int write_49fl004(struct flashchip *flash, uint8_t *buf); +int probe_49fl004(struct flashchip *flash); +int erase_49fl004(struct flashchip *flash); +int write_49fl004(struct flashchip *flash, uint8_t *buf); /* sharplhf00l04.c */ -extern int probe_lhf00l04(struct flashchip *flash); -extern int erase_lhf00l04(struct flashchip *flash); -extern int write_lhf00l04(struct flashchip *flash, uint8_t *buf); -extern void toggle_ready_lhf00l04(volatile uint8_t *dst); -extern void data_polling_lhf00l04(volatile uint8_t *dst, uint8_t data); -extern void protect_lhf00l04(volatile uint8_t *bios); +int probe_lhf00l04(struct flashchip *flash); +int erase_lhf00l04(struct flashchip *flash); +int write_lhf00l04(struct flashchip *flash, uint8_t *buf); +void toggle_ready_lhf00l04(volatile uint8_t *dst); +void data_polling_lhf00l04(volatile uint8_t *dst, uint8_t data); +void protect_lhf00l04(volatile uint8_t *bios); /* sst28sf040.c */ -extern int probe_28sf040(struct flashchip *flash); -extern int erase_28sf040(struct flashchip *flash); -extern int write_28sf040(struct flashchip *flash, uint8_t *buf); +int probe_28sf040(struct flashchip *flash); +int erase_28sf040(struct flashchip *flash); +int write_28sf040(struct flashchip *flash, uint8_t *buf); /* sst39sf020.c */ -extern int probe_39sf020(struct flashchip *flash); -extern int write_39sf020(struct flashchip *flash, uint8_t *buf); +int probe_39sf020(struct flashchip *flash); +int write_39sf020(struct flashchip *flash, uint8_t *buf); /* sst49lf040.c */ -extern int erase_49lf040(struct flashchip *flash); -extern int write_49lf040(struct flashchip *flash, uint8_t *buf); +int erase_49lf040(struct flashchip *flash); +int write_49lf040(struct flashchip *flash, uint8_t *buf); /* sst49lfxxxc.c */ -extern int probe_49lfxxxc(struct flashchip *flash); -extern int erase_49lfxxxc(struct flashchip *flash); -extern int write_49lfxxxc(struct flashchip *flash, uint8_t *buf); +int probe_49lfxxxc(struct flashchip *flash); +int erase_49lfxxxc(struct flashchip *flash); +int write_49lfxxxc(struct flashchip *flash, uint8_t *buf); /* sst_fwhub.c */ -extern int probe_sst_fwhub(struct flashchip *flash); -extern int erase_sst_fwhub(struct flashchip *flash); -extern int write_sst_fwhub(struct flashchip *flash, uint8_t *buf); +int probe_sst_fwhub(struct flashchip *flash); +int erase_sst_fwhub(struct flashchip *flash); +int write_sst_fwhub(struct flashchip *flash, uint8_t *buf); /* w29ee011.c */ -extern int probe_w29ee011(struct flashchip *flash); +int probe_w29ee011(struct flashchip *flash); /* w49f002u.c */ -extern int write_49f002(struct flashchip *flash, uint8_t *buf); +int write_49f002(struct flashchip *flash, uint8_t *buf); #endif /* !__FLASH_H__ */ Modified: trunk/util/flashrom/msys_doc.h =================================================================== --- trunk/util/flashrom/msys_doc.h 2007-09-09 20:21:05 UTC (rev 2768) +++ trunk/util/flashrom/msys_doc.h 2007-09-09 20:24:29 UTC (rev 2769) @@ -91,9 +91,9 @@ #define doc_toggle(base) /* 0, 1, 0, 1, 0, 1, ... if a doc is present */ \ ( (doc_read(base, ECCConfiguration) & 0x04) >> 2 ) -extern int probe_md2802(struct flashchip *flash); -extern int read_md2802(struct flashchip *flash, uint8_t *buf); -extern int erase_md2802(struct flashchip *flash); -extern int write_md2802(struct flashchip *flash, uint8_t *buf); +int probe_md2802(struct flashchip *flash); +int read_md2802(struct flashchip *flash, uint8_t *buf); +int erase_md2802(struct flashchip *flash); +int write_md2802(struct flashchip *flash, uint8_t *buf); #endif /* !__MSYS_DOC_H__ */ From info at coresystems.de Sun Sep 9 22:29:39 2007 From: info at coresystems.de (LinuxBIOS information) Date: Sun, 09 Sep 2007 22:29:39 +0200 Subject: [LinuxBIOS] r2766 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2766 to the LinuxBIOS source repository and caused the following changes: Change Log: Partial changes and fixup. Removed reset.c and added copyright headers. Remove debug.c. It is not used and should not be here. Signed-off-by: Ronald G. Minnich Acked-by: Uwe Hermann Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2766&device=hdama&vendor=arima Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2766&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2766&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2766&device=juki-511p&vendor=iei Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2766&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2766&device=dk8x&vendor=iwill If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From todthgie at hotmail.com Sun Sep 9 23:14:40 2007 From: todthgie at hotmail.com (todthgie) Date: Sun, 9 Sep 2007 23:14:40 +0200 Subject: [LinuxBIOS] M57SLI Revision 2 SPI References: <46E18E69.4060905@stockwith.co.uk> <1189190609.46e19bd1c9b9d@imp.free.fr> <46E18E69.4060905@stockwith.co.uk><20070908183825.1018.qmail@stuge.se> <46E2F623.70803@stockwith.co.uk> Message-ID: > Peter Stuge wrote: .. >> See http://stuge.se/m57sli_soic_detail_labels.jpg for contact names. >> >> 1. Lift the U5-CS# pin from the board. maybe thaere is a resistor of 0 Ohm (maybe R509 ?) between the Superio and U5? it might be easier and a LOT saver to unsorder a resistor the it is to unsolder a singer soic pin ..... >> 2. Solder 1x 100k resistor between U5-VCC and the lifted U5-CS# pin. >> 3. Solder the center contact on the switch to the U5-CS# pad on the >> mainboard. >> 4. Solder one outer contact on the switch to the U5-CS# pin, where >> one end of the resistor in step 2 is also soldered. >> 5. Solder the new flash chip to the U9 pads. Note pin 1! There should >> be a marking on the flash chip near one corner pin, that's pin 1, >> U9-CS#. >> 6. Lift U9-CS# from the board. (Or just don't solder it in step 5.) >> 7. Solder 1x 100k resistor between U9-VCC and the lifted U9-CS# pin. >> 8. Solder the second outer contact on the switch to the U9-CS# pin, >> where one end of the resistor in step 7 is also soldered. >> >> Done! Now the switch controls which of U5 and U9 is actually >> selected when the super io wants to access the flash chip. >> >> >> You could get a biased (spring-loaded) switch in order to help >> avoiding accidentally leaving the system running with the factory >> BIOS chip selected when you're doing LB work - so that the next >> flashing operation does not overwrite the wrong chip. You would need >> to hold the switch while booting the factory BIOS, but that may be >> worthwhile if you can't easily redo the soldering work if both flash >> chips contain junk. Good suggestion another one: dont solder a chip to the U9 pads but solder a 8 pin connector to that pads... then solder a mating connector to the chip(s) greetings todthgie From info at coresystems.de Sun Sep 9 23:18:13 2007 From: info at coresystems.de (LinuxBIOS information) Date: Sun, 09 Sep 2007 23:18:13 +0200 Subject: [LinuxBIOS] r2767 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2767 to the LinuxBIOS source repository and caused the following changes: Change Log: Add missing license header to udelay.c. I'm self-ack'ing this, as the origin of the code in udelay.c (and thus the license and copyright owner) is pretty clear. The code which is now in udelay.c was split out from flash_rom.c in r1428, and flash_rom.c, in turn, has been around since the beginning and had a 'Copyright 2000 Silicon Integrated System Corporation' line as well as the usual GPLv2-or-later license header. Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2767&device=hdama&vendor=arima Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2767&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2767&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2767&device=juki-511p&vendor=iei Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2767&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2767&device=dk8x&vendor=iwill If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From info at coresystems.de Mon Sep 10 00:06:11 2007 From: info at coresystems.de (LinuxBIOS information) Date: Mon, 10 Sep 2007 00:06:11 +0200 Subject: [LinuxBIOS] r2768 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2768 to the LinuxBIOS source repository and caused the following changes: Change Log: Add '(C)' where it's missing (for consistency reasons). Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2768&device=hdama&vendor=arima Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2768&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2768&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2768&device=juki-511p&vendor=iei Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2768&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2768&device=dk8x&vendor=iwill If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From peter at stuge.se Mon Sep 10 00:24:27 2007 From: peter at stuge.se (Peter Stuge) Date: Mon, 10 Sep 2007 00:24:27 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <1188756804.46dafd4437693@imp.free.fr> References: <46D6AB93.9080607@stockwith.co.uk> <20070830120920.GB10696@localdomain> <20070901175718.1761.qmail@stuge.se> <46D9BDEE.9010402@gmx.net> <20070901195035.21050.qmail@stuge.se> <46D9C7E1.7080801@gmx.net> <20070901210818.1799.qmail@stuge.se> <20070902141108.GA9106@localdomain> <20070902173522.27942.qmail@stuge.se> <1188756804.46dafd4437693@imp.free.fr> Message-ID: <20070909222428.15040.qmail@stuge.se> On Sun, Sep 02, 2007 at 08:13:24PM +0200, echelon at free.fr wrote: > > * what Q4-1, Q5-1, R99-1 and R102-2 connects to on U5, if anything. > > Q4-1 -> U9-CS# > Q5-1 -> U5-CS# On Sun, Sep 09, 2007 at 11:14:40PM +0200, todthgie wrote: > >> 1. Lift the U5-CS# pin from the board. > > maybe thaere is a resistor of 0 Ohm (maybe R509 ?) between the > Superio and U5? Possible, but someone will have to spend some time checking connections on the board to find it. Really tedious work. It's not R509 though since Q5-1 is U5-CS#, not Q4-3/Q5-3. :\ > it might be easier and a LOT saver to unsorder a resistor the it is > to unsolder a singer soic pin ..... I think lifting a corner pin should be doable for pretty much anyone with a little soldering experience but if you can find a 0 ohm that's great! :) > dont solder a chip to the U9 pads but solder a 8 pin connector to > that pads... then solder a mating connector to the chip(s) Can you suggest some good connector part numbers? Needing a PCB for the chip+connector is no fun either.. //Peter From info at coresystems.de Mon Sep 10 00:59:55 2007 From: info at coresystems.de (LinuxBIOS information) Date: Mon, 10 Sep 2007 00:59:55 +0200 Subject: [LinuxBIOS] r2769 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2769 to the LinuxBIOS source repository and caused the following changes: Change Log: Remove useless 'extern' keywords (trivial). Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2769&device=hdama&vendor=arima Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2769&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2769&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2769&device=juki-511p&vendor=iei Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2769&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2769&device=dk8x&vendor=iwill If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From peter at stuge.se Mon Sep 10 01:15:24 2007 From: peter at stuge.se (Peter Stuge) Date: Mon, 10 Sep 2007 01:15:24 +0200 Subject: [LinuxBIOS] M57SLI Revision 2 SPI In-Reply-To: <20070909011557.1807.qmail@stuge.se> References: <1189190609.46e19bd1c9b9d@imp.free.fr> <46E18E69.4060905@stockwith.co.uk> <20070908183825.1018.qmail@stuge.se> <13426df10709081643q76bc3066y4a29bb1759d7093c@mail.gmail.com> <20070909011557.1807.qmail@stuge.se> Message-ID: <20070909231524.23360.qmail@stuge.se> On Sun, Sep 09, 2007 at 03:15:57AM +0200, Peter Stuge wrote: > On Sat, Sep 08, 2007 at 04:43:25PM -0700, ron minnich wrote: > > pictures? > > I can take some pictures of the process using an experiment board > and another SO-8 chip http://stuge.se/lb/m57sli/ These photos are of two completely different boards I dug up, but it does show how the mod should look, just using two other SO-8 chips. I put some labels in there too for clarification. Feel free to use {overview,U5,U9}.jpg in any way. It would be awesome if someone put the instructions in my previous email and the images together on the m57sli wiki page so the theory can be tested by anyone passing by with the right equipment and supplies. //Peter From peter at stuge.se Mon Sep 10 01:20:31 2007 From: peter at stuge.se (Peter Stuge) Date: Mon, 10 Sep 2007 01:20:31 +0200 Subject: [LinuxBIOS] FYI flashrom included in Fedora Linux since yesterday. In-Reply-To: <20070909200903.GC19841@greenwood> References: <20070909200903.GC19841@greenwood> Message-ID: <20070909232031.24116.qmail@stuge.se> On Sun, Sep 09, 2007 at 10:09:03PM +0200, Uwe Hermann wrote: > > flashrom.c:402: warning: ignoring return value of 'fwrite', > > declared with attribute warn_unused_result > > flashrom.c:421: warning: ignoring return value of 'fread', > > declared with attribute warn_unused_result > > The warnings don't look critical to me, btw. I guess glibc wants to emphasize that it's good form to check the return value and handle errors. //Peter From danny.piccirillo at gmail.com Mon Sep 10 03:59:29 2007 From: danny.piccirillo at gmail.com (Danny Piccirillo) Date: Sun, 9 Sep 2007 21:59:29 -0400 Subject: [LinuxBIOS] LinuxBIOS from Dell Message-ID: I'm sure some of you are aware that LinuxBIOS appeared on Dell's IdeaStorm website. At some point the status was set to ***ACKNOWLEDGED*** by a Dell admin but has since been removed. http://www.ideastorm.com/article/show/62549 Maybe we can build up support for this idea again? -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey.osgood at gmail.com Mon Sep 10 05:05:40 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Sun, 09 Sep 2007 23:05:40 -0400 Subject: [LinuxBIOS] LinuxBIOS from Dell In-Reply-To: References: Message-ID: <46E4B484.4050605@gmail.com> Danny Piccirillo wrote: > I'm sure some of you are aware that LinuxBIOS appeared on Dell's > IdeaStorm website. At some point the status was set to > ***ACKNOWLEDGED*** by a Dell admin but has since been removed. > http://www.ideastorm.com/article/show/62549 Maybe we can build up > support for this idea again? Hmm, what exactly does acknowledged mean, anyways? Seems like all it means is, "hey, we saw it". I don't think that until we can get Windows Vista running on a Core 2 Duo system that dell will seriously consider this idea. I could be wrong, and really hope I am, as I'd love to see them actually help with this. -Corey From vogel at ct.metrocast.net Mon Sep 10 05:20:07 2007 From: vogel at ct.metrocast.net (Robert Vogel) Date: Sun, 9 Sep 2007 23:20:07 -0400 Subject: [LinuxBIOS] LinuxBIOS from Dell References: <29501100.1189393828391.JavaMail.root@m48> Message-ID: <001201c7f359$81bd3c50$0200a8c0@your55e5f9e3d2> ----- Original Message ----- From: "Corey Osgood" To: "Danny Piccirillo" Cc: Sent: Sunday, September 09, 2007 11:05 PM Subject: Re: [LinuxBIOS] LinuxBIOS from Dell > Danny Piccirillo wrote: >> I'm sure some of you are aware that LinuxBIOS appeared on Dell's >> IdeaStorm website. At some point the status was set to >> ***ACKNOWLEDGED*** by a Dell admin but has since been removed. >> http://www.ideastorm.com/article/show/62549 Maybe we can build up >> support for this idea again? > > Hmm, what exactly does acknowledged mean, anyways? Seems like all it > means is, "hey, we saw it". I don't think that until we can get Windows > Vista running on a Core 2 Duo system that dell will seriously consider > this idea. I could be wrong, and really hope I am, as I'd love to see > them actually help with this. > > -Corey > I can't imagine why you want Windows Vista running on a machine that you took the trouble to configure with LinuxBIOS. Why would you do that ? I'm beginning to think that a LinuxBIOS machine may first come from embedded style boxes. OLPC is a pretty good role model. Don't you think ? From corey.osgood at gmail.com Mon Sep 10 05:55:13 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Sun, 09 Sep 2007 23:55:13 -0400 Subject: [LinuxBIOS] LinuxBIOS from Dell In-Reply-To: <001201c7f359$81bd3c50$0200a8c0@your55e5f9e3d2> References: <29501100.1189393828391.JavaMail.root@m48> <001201c7f359$81bd3c50$0200a8c0@your55e5f9e3d2> Message-ID: <46E4C021.1010505@gmail.com> Robert Vogel wrote: > > ----- Original Message ----- From: "Corey Osgood" > > To: "Danny Piccirillo" > Cc: > Sent: Sunday, September 09, 2007 11:05 PM > Subject: Re: [LinuxBIOS] LinuxBIOS from Dell > > >> Danny Piccirillo wrote: >>> I'm sure some of you are aware that LinuxBIOS appeared on Dell's >>> IdeaStorm website. At some point the status was set to >>> ***ACKNOWLEDGED*** by a Dell admin but has since been removed. >>> http://www.ideastorm.com/article/show/62549 Maybe we can build up >>> support for this idea again? >> >> Hmm, what exactly does acknowledged mean, anyways? Seems like all it >> means is, "hey, we saw it". I don't think that until we can get Windows >> Vista running on a Core 2 Duo system that dell will seriously consider >> this idea. I could be wrong, and really hope I am, as I'd love to see >> them actually help with this. >> >> -Corey >> > > I can't imagine why you want Windows Vista running on a machine that > you took the trouble to configure with LinuxBIOS. > Why would you do that ? I'm beginning to think that a LinuxBIOS > machine may first come from embedded style boxes. > OLPC is a pretty good role model. Don't you think ? *I* don't want Vista on my LinuxBIOS machine. *Dell* would. I ran the Vista betas for a while. I wasn't impressed, and haven't rushed out to purchase it yet. LinuxBIOS already runs on a handful of embedded mainboards, etc, look up the LinuTop for one example, and there are more in the wiki. -Corey From jtd at mtnl.net.in Mon Sep 10 08:33:37 2007 From: jtd at mtnl.net.in (jtd) Date: Mon, 10 Sep 2007 12:03:37 +0530 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <20070909222428.15040.qmail@stuge.se> References: <46D6AB93.9080607@stockwith.co.uk> <1188756804.46dafd4437693@imp.free.fr> <20070909222428.15040.qmail@stuge.se> Message-ID: <200709101203.37170.jtd@sparc.net> On Monday 10 September 2007 03:54, Peter Stuge wrote: > On Sun, Sep 02, 2007 at 08:13:24PM +0200, echelon at free.fr wrote: > > > * what Q4-1, Q5-1, R99-1 and R102-2 connects to on U5, if > > > anything. > > > > Q4-1 -> U9-CS# > > Q5-1 -> U5-CS# > > On Sun, Sep 09, 2007 at 11:14:40PM +0200, todthgie wrote: > > >> 1. Lift the U5-CS# pin from the board. > > > > maybe thaere is a resistor of 0 Ohm (maybe R509 ?) between the > > Superio and U5? > > Possible, but someone will have to spend some time checking > connections on the board to find it. Really tedious work. > > It's not R509 though since Q5-1 is U5-CS#, not Q4-3/Q5-3. :\ > > > it might be easier and a LOT saver to unsorder a resistor the it > > is to unsolder a singer soic pin ..... > > I think lifting a corner pin should be doable for pretty much > anyone with a little soldering experience but if you can find a 0 > ohm that's great! :) A nice method of desoldering soic pins is to use a 26 swg enamelled copper wire. Pass the wire under the ic and between the pin. Tug the wire so that it slides under the pin while heating the pin. You end up with the pin clear of the board. Can also be used to remove the entire chip without damaging the ic or the board. -- Rgds JTD From stepan at coresystems.de Mon Sep 10 11:44:00 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 10 Sep 2007 11:44:00 +0200 Subject: [LinuxBIOS] [PATCH] Global failover.c In-Reply-To: <20070908192307.GC18334@greenwood> References: <20070908192307.GC18334@greenwood> Message-ID: <20070910094400.GA12284@coresystems.de> * Uwe Hermann [070908 21:23]: > Add a common/global failover.c file which can be used by all > (or at least most) mainboards. This should put and end to > copy-paste'ing the same file again and again for every mainboard. > > Signed-off-by: Uwe Hermann This code is not common but x86 only. > +normal_image: > + __asm__ __volatile__("jmp __normal_image" : : "a" (bist) : ); > + > +cpu_reset: > + __asm__ __volatile__("jmp __cpu_reset" : : "a" (bist) : ); -- 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 Mon Sep 10 15:25:46 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Mon, 10 Sep 2007 15:25:46 +0200 Subject: [LinuxBIOS] [PATCH] Global failover.c In-Reply-To: <20070910094400.GA12284@coresystems.de> References: <20070908192307.GC18334@greenwood> <20070910094400.GA12284@coresystems.de> Message-ID: <20070910132546.GC26379@greenwood> On Mon, Sep 10, 2007 at 11:44:00AM +0200, Stefan Reinauer wrote: > * Uwe Hermann [070908 21:23]: > > Add a common/global failover.c file which can be used by all > > (or at least most) mainboards. This should put and end to > > copy-paste'ing the same file again and again for every mainboard. > > > > Signed-off-by: Uwe Hermann > > This code is not common but x86 only. Good point, moved to src/arch/i386/lib/failover.c. Updated patch attached. 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: v2_failover.patch Type: text/x-diff Size: 1933 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 Mon Sep 10 15:30:46 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Mon, 10 Sep 2007 15:30:46 +0200 Subject: [LinuxBIOS] [PATCH] buildrom: m57sli linux kernel config + makefile In-Reply-To: <2ea3fae10709081321p75291697s556f210eed5821b6@mail.gmail.com> References: <20070906142507.GD29891@localdomain> <13426df10709081026k35f67563w2fd99f24c35e90e8@mail.gmail.com> <2ea3fae10709081116g2d97a898o503a9bfb77b56a9@mail.gmail.com> <20070908194127.GF18334@greenwood> <2ea3fae10709081321p75291697s556f210eed5821b6@mail.gmail.com> Message-ID: <20070910133046.GD26379@greenwood> On Sat, Sep 08, 2007 at 01:21:33PM -0700, yhlu wrote: > On 9/8/07, Uwe Hermann wrote: > > On Sat, Sep 08, 2007 at 11:16:13AM -0700, yhlu wrote: > > > can someone put the buildrom2.amd64 into the tree too? > > > > What exactly is this? An enhancement for buildrom or a fork of buildrom? > > If so, why? What's different? > 64 bit version. esp mkelfImage patch that will take elf64 vmlinux to > produce elf32, so can load that from 32 bit LinuxBIOS in AMD64 > platform. > For amd64 platform, I think that we should use 64 bit tiny kernel in flash. Nice, thanks! I think this should indeed be merged into buildrom then (i.e. not be a separate project). Can you post patches? Thanks, 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 Mon Sep 10 15:44:09 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Mon, 10 Sep 2007 15:44:09 +0200 Subject: [LinuxBIOS] LinuxBIOS Summit Europe 2007 In-Reply-To: <20070908201107.15748.qmail@stuge.se> References: <46E2FAD1.5050700@gmx.ch> <20070908201107.15748.qmail@stuge.se> Message-ID: <20070910134409.GE26379@greenwood> On Sat, Sep 08, 2007 at 10:11:07PM +0200, Peter Stuge wrote: > On Sat, Sep 08, 2007 at 09:41:05PM +0200, Marc-Andr? Beck wrote: > > We are planning to have the summit at two locations in Switzerland. > > Biel October 17th-19th(afternoon) and Berne 19th(night)-21st. > > I'm going to miss this one, unfortunately. :\ > > Impossible week for me, already booked for another event. It would be > awesome for me (and hopefully others) if audio could be distributed > from the meetings. I can help with some bandwidth in .se fairly close > to GIX if needed. > > Maybe also take input from stream listeners on IRC? As I won't be able to come this time either, audio or video recordings (and/or streams) would be really cool! Alternatively, could someone prepare some "logs" of the discussions and the outcomes and post them to the list (each day, if possible)? Thanks, 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 jordan.crouse at amd.com Mon Sep 10 17:41:08 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Mon, 10 Sep 2007 09:41:08 -0600 Subject: [LinuxBIOS] Payload selector method In-Reply-To: <13426df10709081136l7853c90ej16bce4ebe3582389@mail.gmail.com> References: <1189252970.26302.125.camel@localhost> <13426df10709081136l7853c90ej16bce4ebe3582389@mail.gmail.com> Message-ID: <20070910154108.GE9001@cosmic.amd.com> On 08/09/07 11:36 -0700, ron minnich wrote: > On 9/8/07, Alex Beregszaszi wrote: > > Hi, > > > > After playing around with lbmenu, I came up with the following idea to > > select payloads in a clean way. > > > > 1a, linuxbios parses the payload number cmos position, and starts the > > selected payload > > or, if it is out of range, an emergency payload :-) > > > > Imho it is better to have always the 1a, way running, but we have to be > > sure the cmos contains a valid value. > > we want an unattended boot ability. Absolutely, if the number isn't at all sane, then we just freak out and load payload 0 by default. Also, the payload number should have some magic bits on it to ensure that what we see is intentional, Like make the top nibble 0xa or something (assuming that we can affort 8 bits of CMOS space, and that we'll only have 16 payloads). Anyway, you get my point. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From myles at pel.cs.byu.edu Mon Sep 10 17:54:55 2007 From: myles at pel.cs.byu.edu (Myles Watson) Date: Mon, 10 Sep 2007 09:54:55 -0600 Subject: [LinuxBIOS] LinuxBIOS - Booting Windows XP In-Reply-To: References: <024301c7f188$d4e59350$4d22040a@chimp> Message-ID: <030b01c7f3c2$eeefdad0$4d22040a@chimp> > Have you done these alterations already? > Also try booting your windows installation CD with qemu default's BIOS and > let me know the result please. > Thanks, > ? Augusto Pedroza I've tried your fixes. I'm trying to boot on a real machine, so I can't use qemu's BIOS. I'll keep trying. Myles From jordan.crouse at amd.com Mon Sep 10 17:34:30 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Mon, 10 Sep 2007 09:34:30 -0600 Subject: [LinuxBIOS] buildrom: add packages/kernel/patches/tiny_m57sli In-Reply-To: <13426df10709081134r209f0c33vc893a46e39c39458@mail.gmail.com> References: <20070906142443.GC29891@localdomain> <13426df10709081028m3fcaefc1k1a9113d26fa8e0d1@mail.gmail.com> <2ea3fae10709081131m7c275f9fha9f7b18e1c65b0f4@mail.gmail.com> <13426df10709081134r209f0c33vc893a46e39c39458@mail.gmail.com> Message-ID: <20070910153430.GC9001@cosmic.amd.com> On 08/09/07 11:34 -0700, ron minnich wrote: > On 9/8/07, yhlu wrote: > > On 9/8/07, ron minnich wrote: > > > On 9/6/07, Ward Vandewege wrote: > > > > These patches are released under the GPLv2, so we can just include them in > > > > our buildrom tree. Do we need a license header for each file? > > > > > > > > > This comes from tiny, right? I think since it is a patch we are ok? > > > > we should put the URL in buildrom to download that quilt patchset from > > elinux.org like download linux tar ball... > > good point, ward, is that doable? For OLPC, we wern't using the full linux-tiny set, so thats why we had the ones we were using local. If the whole set makes sense, then yeah, this is a good idea. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From ward at gnu.org Mon Sep 10 18:11:34 2007 From: ward at gnu.org (Ward Vandewege) Date: Mon, 10 Sep 2007 12:11:34 -0400 Subject: [LinuxBIOS] LinuxBIOS Summit Europe 2007 In-Reply-To: <20070910134409.GE26379@greenwood> References: <46E2FAD1.5050700@gmx.ch> <20070908201107.15748.qmail@stuge.se> <20070910134409.GE26379@greenwood> Message-ID: <20070910161134.GA8377@localdomain> On Mon, Sep 10, 2007 at 03:44:09PM +0200, Uwe Hermann wrote: > On Sat, Sep 08, 2007 at 10:11:07PM +0200, Peter Stuge wrote: > > On Sat, Sep 08, 2007 at 09:41:05PM +0200, Marc-Andr? Beck wrote: > > > We are planning to have the summit at two locations in Switzerland. > > > Biel October 17th-19th(afternoon) and Berne 19th(night)-21st. > > > > I'm going to miss this one, unfortunately. :\ > > > > Impossible week for me, already booked for another event. It would be > > awesome for me (and hopefully others) if audio could be distributed > > from the meetings. I can help with some bandwidth in .se fairly close > > to GIX if needed. > > > > Maybe also take input from stream listeners on IRC? > > As I won't be able to come this time either, audio or video recordings > (and/or streams) would be really cool! Alternatively, could someone > prepare some "logs" of the discussions and the outcomes and post them > to the list (each day, if possible)? That would be great - I'm not going to make it either, but I'd love to follow what's happening closely. But do count me in for the next summit in Denver next year! Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From ollie at lanl.gov Mon Sep 10 19:24:50 2007 From: ollie at lanl.gov (Li-Ta Lo) Date: Mon, 10 Sep 2007 11:24:50 -0600 Subject: [LinuxBIOS] [PATCH] Flashrom: sis630 simplification In-Reply-To: <20070909201157.GD19841@greenwood> References: <1189262986.26302.129.camel@localhost> <13426df10709081059p547adebcud430e6243753f690@mail.gmail.com> <1189262986.26302.129.camel@localhost> <20070908175631.GA18334@greenwood> <20070908184118.1541.qmail@stuge.se> <20070909201157.GD19841@greenwood> Message-ID: <1189445090.2155.18.camel@exponential.lanl.gov> On Sun, 2007-09-09 at 22:11 +0200, Uwe Hermann wrote: > On Sat, Sep 08, 2007 at 08:41:18PM +0200, Peter Stuge wrote: > > On Sat, Sep 08, 2007 at 07:56:32PM +0200, Uwe Hermann wrote: > > > On Sat, Sep 08, 2007 at 04:49:46PM +0200, Alex Beregszaszi wrote: > > > > attached patch changes out/in combinations to pci_read/write_byte in > > > > sis630 chipset enable. > > > > > > Why? > > > > There is abstraction available - so it should be used everywhere. > > Ah, yes. I missed the fact that those functions do the same as the > replaced code. > > > > > Did you test the patch on hardware? > > > > On Sat, Sep 08, 2007 at 10:59:39AM -0700, ron minnich wrote: > > > I don't think this should be done unless someone can test. > > > > > > I agree with the patch - I want the change, but I also agree it would > > be nice to have it tested. > > > > We could argue that we decided to go through with the patch in order > > to improve the code and until someone has a problem with the code not > > working there is no real problem. > > I'm not too eager to find out the hard way. This is low-level > enough that I think there _might_ be unintended/unnoticed consequences. > > Anybody with such a chipset willing to test the patch? > It was too long ago for me to remember why I was doing something like that. My guess is that the pci_dev passed to the function is the northbridge but you have to program the southbridge or the LPC or it was not linked with pci_util then. Ollie From marc.jones at amd.com Mon Sep 10 19:36:54 2007 From: marc.jones at amd.com (Marc Jones) Date: Mon, 10 Sep 2007 11:36:54 -0600 Subject: [LinuxBIOS] PATCH: add the pcengines ALIX1 In-Reply-To: <13426df10709082212h42c9091dxdf77ac4585f74a53@mail.gmail.com> References: <13426df10709071258u5096ea78x2514c53dfb509e08@mail.gmail.com> <20070907213532.GG10747@greenwood> <13426df10709080928o1e6d8febwa97572c9d263352@mail.gmail.com> <20070908183721.GB18334@greenwood> <13426df10709082212h42c9091dxdf77ac4585f74a53@mail.gmail.com> Message-ID: <46E580B6.9000103@amd.com> ron minnich wrote: > Partial diff attached, .... here are comments. > > Still builds. > > > On 9/8/07, Uwe Hermann wrote: > >> Add a license header, please. > >>> +#define POST_CODE(x) outb(x, 0x80) >> We have a global implementation already. > > cache as ram is weird, I want to test this before I use the library. > The library can do lots more than outb, what with serial post and > timers etc. > I think we discussed this when the LX CAR code went in. I don't recall the exact problem but I don't think that you can use the library function at this point. >>> + >>> +} >> Is this board-specific or chipset-specific? If the latter, it should not >> be here. > > I am not sure. Marc? > I think that this was for: /* Setup access to the MC for under 1MB. Note MC not setup yet. */ Yes, I think that routing to 1MB should be generic. I think you still need the MSR function at that point for platform specific settings. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From corey.osgood at gmail.com Mon Sep 10 21:37:54 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Mon, 10 Sep 2007 15:37:54 -0400 Subject: [LinuxBIOS] LinuxBIOS Summit Europe 2007 In-Reply-To: <20070910161134.GA8377@localdomain> References: <46E2FAD1.5050700@gmx.ch> <20070908201107.15748.qmail@stuge.se> <20070910134409.GE26379@greenwood> <20070910161134.GA8377@localdomain> Message-ID: <46E59D12.3000204@gmail.com> Ward Vandewege wrote: > On Mon, Sep 10, 2007 at 03:44:09PM +0200, Uwe Hermann wrote: > >> On Sat, Sep 08, 2007 at 10:11:07PM +0200, Peter Stuge wrote: >> >>> On Sat, Sep 08, 2007 at 09:41:05PM +0200, Marc-Andr? Beck wrote: >>> >>>> We are planning to have the summit at two locations in Switzerland. >>>> Biel October 17th-19th(afternoon) and Berne 19th(night)-21st. >>>> >>> I'm going to miss this one, unfortunately. :\ >>> >>> Impossible week for me, already booked for another event. It would be >>> awesome for me (and hopefully others) if audio could be distributed >>> from the meetings. I can help with some bandwidth in .se fairly close >>> to GIX if needed. >>> >>> Maybe also take input from stream listeners on IRC? >>> >> As I won't be able to come this time either, audio or video recordings >> (and/or streams) would be really cool! Alternatively, could someone >> prepare some "logs" of the discussions and the outcomes and post them >> to the list (each day, if possible)? >> > > That would be great - I'm not going to make it either, but I'd love to follow > what's happening closely. > Same here. Wish I could go this year, but traveling abroad is just out of my budget. > But do count me in for the next summit in Denver next year! > > Thanks, > Ward. If all goes well, I hope to be there too! -Corey From openembedded at haerwu.biz Mon Sep 10 22:49:03 2007 From: openembedded at haerwu.biz (Marcin Juszkiewicz) Date: Mon, 10 Sep 2007 22:49:03 +0200 Subject: [LinuxBIOS] EHCI Debug Port on ICH4/ICH4-M chipset Message-ID: <200709102249.04606.openembedded@haerwu.biz> On http://linuxbios.org/EHCI_Debug_Port wiki page there is an info that Intel ICH4/ICH4-M chipset does not supports Debug Port. I have Dell D400 laptop with that chipset and Debug Port is available according to lspci output: 22:47 hrw at maluch:~$ sudo lspci -ns $(lspci|grep EHCI|cut -f1 -d' ');sudo lspci -vs $(lspci|grep EHCI|cut -f1 -d' ') 00:1d.7 0c03: 8086:24cd (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) (prog-if 20 [EHCI]) Subsystem: Dell Latitude D400 Flags: bus master, medium devsel, latency 0, IRQ 11 Memory at faeffc00 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port -- JID: hrw-jabber.org OpenEmbedded developer/consultant Q: What's a light-year? A: One-third less calories than a regular year. From peter at stuge.se Tue Sep 11 00:20:06 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 11 Sep 2007 00:20:06 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <200709101203.37170.jtd@sparc.net> References: <46D6AB93.9080607@stockwith.co.uk> <1188756804.46dafd4437693@imp.free.fr> <20070909222428.15040.qmail@stuge.se> <200709101203.37170.jtd@sparc.net> Message-ID: <20070910222006.11349.qmail@stuge.se> On Mon, Sep 10, 2007 at 12:03:37PM +0530, jtd wrote: > > I think lifting a corner pin should be doable for pretty much > > anyone with a little soldering experience but if you can find a 0 > > ohm that's great! :) > > A nice method of desoldering soic pins is to use a 26 swg enamelled > copper wire. Pass the wire under the ic and between the pin. Tug > the wire so that it slides under the pin while heating the pin. Nice trick! Another similarly good tool is a plain sewing needle which can be used as a lever to bend the pin slightly while melting the solder with the soldering iron. //Peter From JJia at Fortinet.com Tue Sep 11 01:46:02 2007 From: JJia at Fortinet.com (Jia Jianwei) Date: Mon, 10 Sep 2007 16:46:02 -0700 Subject: [LinuxBIOS] ICH8(82801H) USB problem Message-ID: <059301c7f404$becde6c0$3a4610ac@fortinet.com> I'm portting BIOS on Q965+ICH8DO, USB port in ICH8 is not working anyway, It's always reporting address assign timeout when I plug in a usb device, the error message is like this: hub.c: new USB device 00:1d.0-1, assigned address 4 usb_control/bulk_msg: timeout usb.c: USB device not accepting new address=4 (error=-110) I checked interrupt, seems interupt increased after USB device plug in. Can anyone give me some clues? Thanks in advance! Regards, Jianwei From darmawan.salihun at gmail.com Tue Sep 11 04:37:04 2007 From: darmawan.salihun at gmail.com (Darmawan Salihun) Date: Tue, 11 Sep 2007 09:37:04 +0700 Subject: [LinuxBIOS] AMD 690G chipset support in LinuxBIOS v2 Message-ID: <46893e740709101937j32a4f32bu6dc296a628d36dc6@mail.gmail.com> Hi all, I've grepped through the source code last night but haven't found code for board that uses this chipset. Is there any support coming down the road? I'm planning to buy a new system for BIOS experiments in the next few days. This chipset is a candidate for me. I want a chipset with onboard video and K8 processor. I choose K8 because the datasheet for the memory controller is readily available. I'm open for any suggestion(s). Basically, I just want a system that can run Vista, support multicore processor and can be used for LinuxBIOS experiments (preferably without soldering stuff needed). Anyway, one further question: hot-flashing can be done on SPI chips as well, right? Regards, Darmawan Salihun -------------------------------------------------------------------- -= Human knowledge belongs to the world =- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marc.Jones at amd.com Tue Sep 11 05:05:30 2007 From: Marc.Jones at amd.com (Marc Jones) Date: Mon, 10 Sep 2007 21:05:30 -0600 Subject: [LinuxBIOS] quadcore opteron In-Reply-To: References: Message-ID: <46E605FA.5020102@AMD.com> Fridel Fainshtein wrote: > Hi, > > Does quad core opteron needs some special software? > If yes, is there any supporting open source code? > (May be just first steps, cache as ram etc.) > > Thanks Barcelona is very similar to the Opteron but does require some new initialization code. We are working on it and should have something to release in the next few months. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From Marc.Jones at AMD.com Tue Sep 11 06:48:13 2007 From: Marc.Jones at AMD.com (Marc Jones) Date: Mon, 10 Sep 2007 22:48:13 -0600 Subject: [LinuxBIOS] [Fwd: Re: AMD 690G chipset support in LinuxBIOS v2] Message-ID: <46E61E0D.7030304@AMD.com> Meant to send this to the list. Marc -------- Original Message -------- Subject: Re: [LinuxBIOS] AMD 690G chipset support in LinuxBIOS v2 Date: Mon, 10 Sep 2007 21:05:47 -0600 From: Marc Jones To: Darmawan Salihun References: <46893e740709101937j32a4f32bu6dc296a628d36dc6 at mail.gmail.com> Darmawan Salihun wrote: > Hi all, > I've grepped through the source code last night but haven't found > code for board that uses this chipset. Is there any support coming > down the road? I'm planning to buy a new system for BIOS experiments > in the next few days. This chipset is a candidate for me. I want a > chipset with onboard video and K8 processor. > I choose K8 because the datasheet for the memory controller is > readily available. I'm open for any suggestion(s). Basically, I just > want a system that can run Vista, support multicore processor and can > be used for LinuxBIOS experiments (preferably without soldering stuff > needed). > Anyway, one further question: hot-flashing can be done on SPI > chips as well, right? > > > Regards, > > Darmawan Salihun > -------------------------------------------------------------------- > -= Human knowledge belongs to the world =- Hi Darmawan, Currently there is no support in LinuxBIOS for any ATI(now AMD) chipsets. We do plan to work on this in the next six months but I don't have a specific release date. == Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From corey.osgood at gmail.com Tue Sep 11 07:00:17 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Tue, 11 Sep 2007 01:00:17 -0400 Subject: [LinuxBIOS] [Fwd: Re: AMD 690G chipset support in LinuxBIOS v2] In-Reply-To: <46E61E0D.7030304@AMD.com> References: <46E61E0D.7030304@AMD.com> Message-ID: <46E620E1.7040002@gmail.com> Marc Jones wrote: > Meant to send this to the list. > Marc > > > -------- Original Message -------- > Subject: Re: [LinuxBIOS] AMD 690G chipset support in LinuxBIOS v2 > Date: Mon, 10 Sep 2007 21:05:47 -0600 > From: Marc Jones > To: Darmawan Salihun > References: <46893e740709101937j32a4f32bu6dc296a628d36dc6 at mail.gmail.com> > > > > Darmawan Salihun wrote: > >> Hi all, >> I've grepped through the source code last night but haven't found >> code for board that uses this chipset. Is there any support coming >> down the road? I'm planning to buy a new system for BIOS experiments >> in the next few days. This chipset is a candidate for me. I want a >> chipset with onboard video and K8 processor. >> I choose K8 because the datasheet for the memory controller is >> readily available. I'm open for any suggestion(s). Basically, I just >> want a system that can run Vista, support multicore processor and can >> be used for LinuxBIOS experiments (preferably without soldering stuff >> needed). >> Anyway, one further question: hot-flashing can be done on SPI >> chips as well, right? >> >> >> Regards, >> >> Darmawan Salihun >> -------------------------------------------------------------------- >> -= Human knowledge belongs to the world =- >> > > Hi Darmawan, > Currently there is no support in LinuxBIOS for any ATI(now AMD) > chipsets. We do plan to work on this in the next six months but I don't > have a specific release date. > > == > Marc Jones > Senior Firmware Engineer > (970) 226-9684 Office > mailto:Marc.Jones at amd.com > http://www.amd.com/embeddedprocessors > > > Marc Great news! Is this only for current and future chipsets, or might we see some older ones as well? Most interested in the RS480/SB400, btw, I'd like to mess around with it on my laptop and see what happens. Thanks, Corey From rasmus at wiman.org Tue Sep 11 09:20:07 2007 From: rasmus at wiman.org (Rasmus Wiman) Date: Tue, 11 Sep 2007 09:20:07 +0200 Subject: [LinuxBIOS] AMD 690G chipset support in LinuxBIOS v2 In-Reply-To: <46893e740709101937j32a4f32bu6dc296a628d36dc6@mail.gmail.com> References: <46893e740709101937j32a4f32bu6dc296a628d36dc6@mail.gmail.com> Message-ID: <20070911092007.0915d2b7.rasmus@wiman.org> "Darmawan Salihun" wrote: > Hi all, > I've grepped through the source code last night but haven't found > code for board that uses this chipset. Is there any support coming > down the road? I'm planning to buy a new system for BIOS experiments > in the next few days. This chipset is a candidate for me. I want a > chipset with onboard video and K8 processor. > I choose K8 because the datasheet for the memory controller is > readily available. I'm open for any suggestion(s). Basically, I just > want a system that can run Vista, support multicore processor and can > be used for LinuxBIOS experiments (preferably without soldering stuff > needed). Anyway, one further question: hot-flashing can be done on > SPI chips as well, right? I am thinking along the same lines. My primary candidate is NForce 430 since MCP55 is already supported. But that could of course mean absolutely nothing at all. Just because there is working code for one NVidia chipset it doesn't mean that code will be easy to adapt th the 430. But one can always hope. :) /Rasmus From joop_boonen at web.de Tue Sep 11 10:33:41 2007 From: joop_boonen at web.de (Joop Boonen) Date: Tue, 11 Sep 2007 10:33:41 +0200 (CEST) Subject: [LinuxBIOS] Xen and LinuxBIOS Message-ID: <15925.194.237.142.21.1189499621.squirrel@www.boonen.name> All, I'm thinking of buying a GA-M57SLI-S4 mainboard. As AMD-V isn't activated in the BIOS I probably want to use LinuxBIOS. As i want to use virtualisation i would like to know if LinuxBIOS also supports Xen i.e. I use a Xen aware kernel in LinuxBIOS that works. I would like to use LinuxBIOS in combination with OpenSuSE. Regards, Joop Boonen. From joop_boonen at web.de Tue Sep 11 10:59:40 2007 From: joop_boonen at web.de (Joop Boonen) Date: Tue, 11 Sep 2007 10:59:40 +0200 (CEST) Subject: [LinuxBIOS] Xen and LinuxBIOS Message-ID: <28707.194.237.142.21.1189501180.squirrel@www.boonen.name> All, I'm thinking of buying a GA-M57SLI-S4 mainboard. As AMD-V isn't activated in the BIOS I probably want to use LinuxBIOS. As i want to use virtualisation i would like to know if LinuxBIOS also supports Xen i.e. I use a Xen aware kernel in LinuxBIOS that works. I would like to use LinuxBIOS in combination with OpenSuSE. Regards, Joop Boonen. From joe at smittys.pointclark.net Tue Sep 11 11:47:53 2007 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Tue, 11 Sep 2007 05:47:53 -0400 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <20070910222006.11349.qmail@stuge.se> References: <46D6AB93.9080607@stockwith.co.uk> <1188756804.46dafd4437693@imp.free.fr> <20070909222428.15040.qmail@stuge.se> <200709101203.37170.jtd@sparc.net> <20070910222006.11349.qmail@stuge.se> Message-ID: <20070911054753.7nfsbt4xwgkkcwc4@www.smittys.pointclark.net> I use Chemtronics Chem-Wik Desoldering Braid. It seems to work really well. It sucks up all the solder so the pads are left pretty much bare:-) Thanks - Joe Quoting Peter Stuge : > On Mon, Sep 10, 2007 at 12:03:37PM +0530, jtd wrote: >> > I think lifting a corner pin should be doable for pretty much >> > anyone with a little soldering experience but if you can find a 0 >> > ohm that's great! :) >> >> A nice method of desoldering soic pins is to use a 26 swg enamelled >> copper wire. Pass the wire under the ic and between the pin. Tug >> the wire so that it slides under the pin while heating the pin. > > Nice trick! > > Another similarly good tool is a plain sewing needle which can be > used as a lever to bend the pin slightly while melting the solder > with the soldering iron. > > > //Peter > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > From joe at smittys.pointclark.net Tue Sep 11 11:52:06 2007 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Tue, 11 Sep 2007 05:52:06 -0400 Subject: [LinuxBIOS] EHCI Debug Port on ICH4/ICH4-M chipset In-Reply-To: <200709102249.04606.openembedded@haerwu.biz> References: <200709102249.04606.openembedded@haerwu.biz> Message-ID: <20070911055206.j2jd747vok0ok48k@www.smittys.pointclark.net> The ICH4 datasheet also says it has a EHCI debug port. Why is it not supported in LB? Thanks - Joe Quoting Marcin Juszkiewicz : > > On http://linuxbios.org/EHCI_Debug_Port wiki page there is an info that > Intel ICH4/ICH4-M chipset does not supports Debug Port. I have Dell D400 > laptop with that chipset and Debug Port is available according to lspci > output: > > 22:47 hrw at maluch:~$ sudo lspci -ns $(lspci|grep EHCI|cut -f1 -d' ');sudo > lspci -vs $(lspci|grep EHCI|cut -f1 -d' ') > > 00:1d.7 0c03: 8086:24cd (rev 01) > 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 > EHCI Controller (rev 01) (prog-if 20 [EHCI]) > Subsystem: Dell Latitude D400 > Flags: bus master, medium devsel, latency 0, IRQ 11 > Memory at faeffc00 (32-bit, non-prefetchable) [size=1K] > Capabilities: [50] Power Management version 2 > Capabilities: [58] Debug port > > -- > JID: hrw-jabber.org > OpenEmbedded developer/consultant > > Q: What's a light-year? > A: One-third less calories than a regular year. > > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > From stepan at coresystems.de Tue Sep 11 11:52:33 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 11 Sep 2007 11:52:33 +0200 Subject: [LinuxBIOS] ICH8(82801H) USB problem In-Reply-To: <059301c7f404$becde6c0$3a4610ac@fortinet.com> References: <059301c7f404$becde6c0$3a4610ac@fortinet.com> Message-ID: <20070911095232.GB8677@coresystems.de> * Jia Jianwei [070911 01:46]: > > I'm portting BIOS on Q965+ICH8DO, USB port in ICH8 is not working anyway, > It's always reporting address assign timeout when I plug in a usb device, > the error message is like this: > > hub.c: new USB device 00:1d.0-1, assigned address 4 > usb_control/bulk_msg: timeout > usb.c: USB device not accepting new address=4 (error=-110) > > > I checked interrupt, seems interupt increased after USB device plug in. > Can anyone give me some clues? Thanks in advance! If this is LinuxBIOS, please post the source code, so we can help you find the bug. 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 Sep 11 11:53:58 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 11 Sep 2007 11:53:58 +0200 Subject: [LinuxBIOS] [PATCH] Flashrom: sis630 simplification In-Reply-To: <1189445090.2155.18.camel@exponential.lanl.gov> References: <1189262986.26302.129.camel@localhost> <13426df10709081059p547adebcud430e6243753f690@mail.gmail.com> <1189262986.26302.129.camel@localhost> <20070908175631.GA18334@greenwood> <20070908184118.1541.qmail@stuge.se> <20070909201157.GD19841@greenwood> <1189445090.2155.18.camel@exponential.lanl.gov> Message-ID: <20070911095358.GA9619@coresystems.de> * Li-Ta Lo [070910 19:24]: > > I'm not too eager to find out the hard way. This is low-level > > enough that I think there _might_ be unintended/unnoticed consequences. > > > > Anybody with such a chipset willing to test the patch? > > It was too long ago for me to remember why I was doing something like > that. My guess is that the pci_dev passed to the function is the > northbridge but you have to program the southbridge or the LPC or it > was not linked with pci_util then. Not linking against libpci was indeed the issue that caused this. I think we should check the code in like that. 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 pawn2be.wild at yahoo.de Tue Sep 11 12:21:08 2007 From: pawn2be.wild at yahoo.de (Quux) Date: Tue, 11 Sep 2007 12:21:08 +0200 Subject: [LinuxBIOS] Xen and LinuxBIOS In-Reply-To: <15925.194.237.142.21.1189499621.squirrel@www.boonen.name> References: <15925.194.237.142.21.1189499621.squirrel@www.boonen.name> Message-ID: <46E66C14.7090803@yahoo.de> Xenoppix is fully usable even with legacy bios on this mother (-board) --Q Joop Boonen schrieb: > All, > > I'm thinking of buying a GA-M57SLI-S4 mainboard. As AMD-V isn't activated > in the BIOS I probably want to use LinuxBIOS. As i want to use > virtualisation i would like to know if LinuxBIOS also supports Xen i.e. I > use a Xen aware kernel in LinuxBIOS that works. > > I would like to use LinuxBIOS in combination with OpenSuSE. > > Regards, > > Joop Boonen. > > > > From pawn2be.wild at yahoo.de Tue Sep 11 12:37:25 2007 From: pawn2be.wild at yahoo.de (Quux) Date: Tue, 11 Sep 2007 12:37:25 +0200 Subject: [LinuxBIOS] EHCI Debug Port on ICH4/ICH4-M chipset In-Reply-To: <20070911055206.j2jd747vok0ok48k@www.smittys.pointclark.net> References: <200709102249.04606.openembedded@haerwu.biz> <20070911055206.j2jd747vok0ok48k@www.smittys.pointclark.net> Message-ID: <46E66FE5.4060405@yahoo.de> joe at smittys.pointclark.net schrieb: > The ICH4 datasheet also says it has a EHCI debug port. > Why is it not supported in LB? > hardware (displays, data cables, automated profilers or such) are somewhat uncommon for it and the serial port / POST card is already quite helpful. the debug port could transmit much faster of course. so "someone should do it (tm)" (i.e. provide support) --Q From ward at gnu.org Tue Sep 11 15:14:41 2007 From: ward at gnu.org (Ward Vandewege) Date: Tue, 11 Sep 2007 09:14:41 -0400 Subject: [LinuxBIOS] Xen and LinuxBIOS In-Reply-To: <15925.194.237.142.21.1189499621.squirrel@www.boonen.name> References: <15925.194.237.142.21.1189499621.squirrel@www.boonen.name> Message-ID: <20070911131441.GA14078@localdomain> Hi Joop, On Tue, Sep 11, 2007 at 10:33:41AM +0200, Joop Boonen wrote: > I'm thinking of buying a GA-M57SLI-S4 mainboard. As AMD-V isn't activated > in the BIOS I probably want to use LinuxBIOS. You mean virtualization? What makes you think that it is disabled on the m57sli-s4? > As i want to use > virtualisation i would like to know if LinuxBIOS also supports Xen i.e. I > use a Xen aware kernel in LinuxBIOS that works. It does, but you have to either: a) build LinuxBIOS with grub2 (which I have not tested yet, but is on my todo list) b) start a kexec-enabled kernel from filo and then kexec into the Xen kernel (which is how I've got some machines in production). You could boot the kexec-enabled kernel from disk, or you could put it in the rom chip (which would make the machine boot faster). The problem is that filo - the current 'standard' linuxbios bootloader - does not support ELF modules; xen requires that to start up. I have a patch pending to buildrom that makes it really easy to build a linux-as-a-bootloader (LAB) image with a kexec-enabled kernel in the rom chip (you need a 1MB chip; the m57sli comes with a 512KB chip). Hopefully I'll be able to apply it today or tomorrow (I'm a bit short on time right now), and then I'll also update the m57sli howto on the wiki. > I would like to use LinuxBIOS in combination with OpenSuSE. That should not be a problem. Any modern distro should work. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From svn at openbios.org Tue Sep 11 17:58:19 2007 From: svn at openbios.org (svn at openbios.org) Date: Tue, 11 Sep 2007 17:58:19 +0200 Subject: [LinuxBIOS] r2770 - trunk/util/flashrom Message-ID: Author: uwe Date: 2007-09-11 17:58:18 +0200 (Tue, 11 Sep 2007) New Revision: 2770 Modified: trunk/util/flashrom/chipset_enable.c Log: Change out/in combinations to pci_read/write_byte in sis630 chipset enable. Signed-off-by: Alex Beregszaszi Acked-by: Uwe Hermann Modified: trunk/util/flashrom/chipset_enable.c =================================================================== --- trunk/util/flashrom/chipset_enable.c 2007-09-09 20:24:29 UTC (rev 2769) +++ trunk/util/flashrom/chipset_enable.c 2007-09-11 15:58:18 UTC (rev 2770) @@ -46,13 +46,11 @@ char b; /* Enable 0xFFF8000~0xFFFF0000 decoding on SiS 540/630 */ - outl(0x80000840, 0x0cf8); - b = inb(0x0cfc) | 0x0b; - outb(b, 0xcfc); + b = pci_read_byte(dev, 0x40); + pci_write_byte(dev, 0x40, b | 0xb); /* Flash write enable on SiS 540/630 */ - outl(0x80000845, 0x0cf8); - b = inb(0x0cfd) | 0x40; - outb(b, 0xcfd); + b = pci_read_byte(dev, 0x45); + pci_write_byte(dev, 0x45, b | 0x40); /* The same thing on SiS 950 SuperIO side */ outb(0x87, 0x2e); From uwe at hermann-uwe.de Tue Sep 11 17:59:42 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Tue, 11 Sep 2007 17:59:42 +0200 Subject: [LinuxBIOS] [PATCH] Flashrom: sis630 simplification In-Reply-To: <20070911095358.GA9619@coresystems.de> References: <1189262986.26302.129.camel@localhost> <13426df10709081059p547adebcud430e6243753f690@mail.gmail.com> <1189262986.26302.129.camel@localhost> <20070908175631.GA18334@greenwood> <20070908184118.1541.qmail@stuge.se> <20070909201157.GD19841@greenwood> <1189445090.2155.18.camel@exponential.lanl.gov> <20070911095358.GA9619@coresystems.de> Message-ID: <20070911155941.GA27441@greenwood> On Tue, Sep 11, 2007 at 11:53:58AM +0200, Stefan Reinauer wrote: > * Li-Ta Lo [070910 19:24]: > > > I'm not too eager to find out the hard way. This is low-level > > > enough that I think there _might_ be unintended/unnoticed consequences. > > > > > > Anybody with such a chipset willing to test the patch? > > > > It was too long ago for me to remember why I was doing something like > > that. My guess is that the pci_dev passed to the function is the > > northbridge but you have to program the southbridge or the LPC or it > > was not linked with pci_util then. > > Not linking against libpci was indeed the issue that caused this. > I think we should check the code in like that. OK then, r2770. It would still be nice if somebody could test this on hardware, though. 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 marc.jones at amd.com Tue Sep 11 18:22:29 2007 From: marc.jones at amd.com (Marc Jones) Date: Tue, 11 Sep 2007 10:22:29 -0600 Subject: [LinuxBIOS] [Fwd: Re: AMD 690G chipset support in LinuxBIOS v2] In-Reply-To: <46E620E1.7040002@gmail.com> References: <46E61E0D.7030304@AMD.com> <46E620E1.7040002@gmail.com> Message-ID: <46E6C0C5.5020409@amd.com> Corey Osgood wrote: > Marc Jones wrote: >> Meant to send this to the list. >> Marc >> >> >> -------- Original Message -------- >> Subject: Re: [LinuxBIOS] AMD 690G chipset support in LinuxBIOS v2 >> Date: Mon, 10 Sep 2007 21:05:47 -0600 >> From: Marc Jones >> To: Darmawan Salihun >> References: <46893e740709101937j32a4f32bu6dc296a628d36dc6 at mail.gmail.com> >> >> >> >> Darmawan Salihun wrote: >> >>> Hi all, >>> I've grepped through the source code last night but haven't found >>> code for board that uses this chipset. Is there any support coming >>> down the road? I'm planning to buy a new system for BIOS experiments >>> in the next few days. This chipset is a candidate for me. I want a >>> chipset with onboard video and K8 processor. >>> I choose K8 because the datasheet for the memory controller is >>> readily available. I'm open for any suggestion(s). Basically, I just >>> want a system that can run Vista, support multicore processor and can >>> be used for LinuxBIOS experiments (preferably without soldering stuff >>> needed). >>> Anyway, one further question: hot-flashing can be done on SPI >>> chips as well, right? >>> >>> >>> Regards, >>> >>> Darmawan Salihun >>> -------------------------------------------------------------------- >>> -= Human knowledge belongs to the world =- >>> >> Hi Darmawan, >> Currently there is no support in LinuxBIOS for any ATI(now AMD) >> chipsets. We do plan to work on this in the next six months but I don't >> have a specific release date. >> >> == >> Marc Jones >> Senior Firmware Engineer >> (970) 226-9684 Office >> mailto:Marc.Jones at amd.com >> http://www.amd.com/embeddedprocessors >> >> >> Marc > > Great news! Is this only for current and future chipsets, or might we > see some older ones as well? Most interested in the RS480/SB400, btw, > I'd like to mess around with it on my laptop and see what happens. > > Thanks, > Corey > Corey, We will focus on current chipsets for now since that is what our customers need. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From stepan at coresystems.de Tue Sep 11 18:38:48 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 11 Sep 2007 18:38:48 +0200 Subject: [LinuxBIOS] ASUS M2N32-SLI Deluxe Message-ID: <20070911163848.GA19593@coresystems.de> Hi, I am working on the Asus M2N32-SLI Deluxe and I started out with the Gigabyte target as base. I had to disable ht optimization in the CAR code, or the machine would not survive the reset. It gets to device enumeration now, but it seems it keeps looping on the devices on bus 0 until it runs out of heap: LinuxBIOS-2.0.0_m57sli_Fallback Tue Jul 31 11:11:26 EDT 2007 starting... *sysinfo range: [000cf000,000cf730) bsp_apicid=00 core0 started: started ap apicid: 01 SBLink=00 NC node|link=00 begin msr fid, vid 3106121206100202 end msr fid, vid 3106121206100202 mcp55_num:01 ht reset - ignoring Ram1.00 Ram2.00 Unbuffered 400Mhz Interleaved RAM: 0x00200000 KB Ram3 dimm_mask = 00000011 x4_mask = 00000000 x16_mask = 00000000 single_rank_mask = 00000000 ODC = 00113222 Addr Timing= 00202520 Initializing memory: done Setting variable MTRR 2, base: 0MB, range: 2048MB, type WB set DQS timing:RcvrEn:Pass1: 00 CTLRMaxDelay=11 done set DQS timing:DQSPos: 00 done set DQS timing:RcvrEn:Pass2: 00 CTLRMaxDelay=42 done Total DQS Training : tsc [00]=000000003307610e Total DQS Training : tsc [01]=0000000033e8c69a Total DQS Training : tsc [02]=0000000068f5bcda Total DQS Training : tsc [03]=000000006ac2555a Ram4 v_esp=000ceeb8 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 dst=00100000 linxbios_ram.nrv2b length = 0000d704 linxbios_ram.bin length = 00022550 Jumping to LinuxBIOS. LinuxBIOS-2.0.0_m57sli_Fallback Tue Jul 31 11:11:26 EDT 2007 booting... Enumerating buses... APIC_CLUSTER: 0 enabled PCI_DOMAIN: 0000 enabled PCI: 00:18.3 siblings=1 CPU: APIC: 00 enabled CPU: APIC: 01 enabled PCI: pci_scan_bus for bus 00 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] enabled PCI: 00:1e.0 [10de/0369] enabled PCI: 00:1f.0 [10de/0360] enabled PCI: 00:1f.1 [10de/0368] enabled PCI: 00:1f.2 [10de/036a] enabled PCI: 00:1f.3 [10de/036b] enabled PCI: 00:00.0 [10de/036c] enabled PCI: 00:00.0 Hypertransport link capability not foundPCI: pci_scan_bus for bus 00 PCI: 00:00.0 [10de/036c] enabled PCI: 00:00.1 [10de/036d] enabled Disabling static device: PCI: 00:01.0 Disabling static device: PCI: 00:01.1 PCI: 00:02.0 [10de/036e] enabled PCI: 00:03.0 [10de/037f] enabled PCI: 00:03.1 [10de/037f] enabled PCI: 00:03.2 [10de/037f] enabled PCI: 00:04.0 [10de/0370] enabled PCI: 00:04.1 [10de/0371] enabled Disabling static device: PCI: 00:05.0 Disabling static device: PCI: 00:05.1 Disabling static device: PCI: 00:05.2 PCI: 00:06.0 [10de/0372] enabled PCI: 00:07.0 [10de/0372] enabled PCI: 00:08.0 [10de/0376] enabled PCI: 00:09.0 [10de/0374] disabled PCI: 00:0a.0 [10de/0374] enabled PCI: 00:0b.0 [10de/0378] enabled PCI: 00:0c.0 [10de/0375] enabled PCI: 00:0d.0 [10de/0377] enabled Disabling static device: PCI: 00:0e.0 PCI: 00:0f.0 [10de/02f4] enabled PCI: 00:0f.1 [10de/02fa] enabled PCI: 00:0f.2 [10de/02fe] enabled PCI: 00:0f.3 [10de/02f8] enabled PCI: 00:0f.4 [10de/02f9] enabled PCI: 00:0f.5 [10de/02ff] enabled PCI: 00:0f.6 [10de/027f] enabled PCI: 00:0f.7 [10de/027e] enabled PCI: 00:11.0 subbordinate bus PCI Express PCI: 00:11.0 [10de/02fc] enabled PCI: 00:12.0 subbordinate bus PCI Express PCI: 00:12.0 [10de/02fd] enabled PCI: 00:13.0 subbordinate bus PCI Express PCI: 00:13.0 [10de/02fb] enabled 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] enabled PCI: 00:1e.0 [10de/0369] enabled PCI: 00:1f.0 [10de/0360] enabled PCI: 00:1f.1 [10de/0368] enabled PCI: 00:1f.2 [10de/036a] enabled PCI: 00:1f.3 [10de/036b] enabled PCI: 00:00.0 [10de/036c] enabled PCI: 00:00.1 [10de/036d] enabled PCI: 00:02.0 [10de/036e] enabled PCI: 00:03.0 [10de/037f] enabled PCI: 00:03.1 [10de/037f] enabled PCI: 00:03.2 [10de/037f] enabled PCI: 00:04.0 [10de/0370] enabled PCI: 00:04.1 [10de/0371] enabled PCI: 00:06.0 [10de/0372] enabled PCI: 00:07.0 [10de/0372] enabled PCI: 00:08.0 [10de/0376] enabled PCI: 00:09.0 [10de/0374] enabled PCI: 00:0a.0 [10de/0374] enabled PCI: 00:0b.0 [10de/0378] enabled PCI: 00:0c.0 [10de/0375] enabled PCI: 00:0d.0 [10de/0377] enabled PCI: 00:0f.0 [10de/02f4] enabled PCI: 00:0f.1 [10de/02fa] enabled PCI: 00:0f.2 [10de/02fe] enabled PCI: 00:0f.3 [10de/02f8] enabled PCI: 00:0f.4 [10de/02f9] enabled PCI: 00:0f.5 [10de/02ff] enabled PCI: 00:0f.6 [10de/027f] enabled PCI: 00:0f.7 [10de/027e] enabled PCI: 00:11.0 subbordinate bus PCI Express PCI: 00:11.0 [10de/02fc] enabled PCI: 00:12.0 subbordinate bus PCI Express PCI: 00:12.0 [10de/02fd] enabled PCI: 00:13.0 subbordinate bus PCI Express PCI: 00:13.0 [10de/02fb] enabled 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] enabled PCI: 00:1e.0 [10de/0369] enabled PCI: 00:1f.0 [10de/0360] enabled PCI: 00:1f.1 [10de/0368] enabled PCI: 00:1f.2 [10de/036a] enabled PCI: 00:1f.3 [10de/036b] enabled PCI: 00:00.0 [10de/036c] enabled PCI: 00:00.1 [10de/036d] enabled PCI: 00:02.0 [10de/036e] enabled PCI: 00:03.0 [10de/037f] enabled PCI: 00:03.1 [10de/037f] enabled PCI: 00:03.2 [10de/037f] enabled PCI: 00:04.0 [10de/0370] enabled PCI: 00:04.1 [10de/0371] enabled PCI: 00:06.0 [10de/0372] enabled PCI: 00:07.0 [10de/0372] enabled PCI: 00:08.0 [10de/0376] enabled PCI: 00:09.0 [10de/0374] enabled PCI: 00:0a.0 [10de/0374] enabled PCI: 00:0b.0 [10de/0378] enabled PCI: 00:0c.0 [10de/0375] enabled PCI: 00:0d.0 [10de/0377] enabled PCI: 00:0f.0 [10de/02f4] enabled PCI: 00:0f.1 [10de/02fa] enabled PCI: 00:0f.2 [10de/02fe] enabled PCI: 00:0f.3 [10de/02f8] enabled PCI: 00:0f.4 [10de/02f9] enabled PCI: 00:0f.5 [10de/02ff] enabled PCI: 00:0f.6 [10de/027f] enabled PCI: 00:0f.7 [10de/027e] enabled PCI: 00:11.0 subbordinate bus PCI Express PCI: 00:11.0 [10de/02fc] enabled PCI: 00:12.0 subbordinate bus PCI Express PCI: 00:12.0 [10de/02fd] enabled PCI: 00:13.0 subbordinate bus PCI Express PCI: 00:13.0 [10de/02fb] enabled 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] enabled Error! malloc: free_mem_ptr >= free_mem_end_ptr Factory bios comes up with these devices: 00:00.0 0500: 10de:02f4 (rev a2) 00:00.1 0500: 10de:02fa (rev a2) 00:00.2 0500: 10de:02fe (rev a2) 00:00.3 0500: 10de:02f8 (rev a2) 00:00.4 0500: 10de:02f9 (rev a2) 00:00.5 0500: 10de:02ff (rev a2) 00:00.6 0500: 10de:027f (rev a2) 00:00.7 0500: 10de:027e (rev a2) 00:03.0 0604: 10de:02fd (rev a1) 00:04.0 0604: 10de:02fb (rev a1) 00:08.0 0500: 10de:0369 (rev a1) 00:09.0 0601: 10de:0360 (rev a2) 00:09.1 0c05: 10de:0368 (rev a2) 00:09.2 0500: 10de:036a (rev a2) 00:0a.0 0c03: 10de:036c (rev a1) 00:0a.1 0c03: 10de:036d (rev a2) 00:0c.0 0101: 10de:036e (rev a1) 00:0d.0 0101: 10de:037f (rev a2) 00:0d.1 0101: 10de:037f (rev a2) 00:0d.2 0101: 10de:037f (rev a2) 00:0e.0 0604: 10de:0370 (rev a2) 00:0e.1 0403: 10de:0371 (rev a2) 00:10.0 0680: 10de:0373 (rev a2) 00:11.0 0680: 10de:0373 (rev a2) 00:12.0 0604: 10de:0376 (rev a2) 00:14.0 0604: 10de:0374 (rev a2) 00:16.0 0604: 10de:0375 (rev a2) 00:17.0 0604: 10de:0377 (rev a2) 00:18.0 0600: 1022:1100 00:18.1 0600: 1022:1101 00:18.2 0600: 1022:1102 00:18.3 0600: 1022:1103 02:00.0 0300: 10de:0392 (rev a1) 03:0b.0 0c00: 104c:8023 06:00.0 0180: 1095:3132 (rev 01) 00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) 00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2) 00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2) 00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2) 00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2) 00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) 00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2) 00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2) 00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) 00:04.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) 00:08.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a1) 00:09.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2) 00:09.1 SMBus: nVidia Corporation MCP55 SMBus (rev a2) 00:09.2 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a2) 00:0a.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1) 00:0a.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2) 00:0c.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1) 00:0d.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2) 00:0d.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2) 00:0d.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2) 00:0e.0 PCI bridge: nVidia Corporation MCP55 PCI bridge (rev a2) 00:0e.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2) 00:10.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2) 00:11.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2) 00:12.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2) 00:14.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2) 00:16.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2) 00:17.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 02:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7600 GS] (rev a1) 03:0b.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) 06:00.0 Mass storage controller: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller (rev 01) Any ideas what could go wrong? -- 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 info at coresystems.de Tue Sep 11 18:44:46 2007 From: info at coresystems.de (LinuxBIOS information) Date: Tue, 11 Sep 2007 18:44:46 +0200 Subject: [LinuxBIOS] r2770 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2770 to the LinuxBIOS source repository and caused the following changes: Change Log: Change out/in combinations to pci_read/write_byte in sis630 chipset enable. Signed-off-by: Alex Beregszaszi Acked-by: Uwe Hermann Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2770&device=hdama&vendor=arima Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2770&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2770&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2770&device=juki-511p&vendor=iei Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2770&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2770&device=dk8x&vendor=iwill If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From marc.jones at amd.com Tue Sep 11 18:51:41 2007 From: marc.jones at amd.com (Marc Jones) Date: Tue, 11 Sep 2007 10:51:41 -0600 Subject: [LinuxBIOS] ASUS M2N32-SLI Deluxe In-Reply-To: <20070911163848.GA19593@coresystems.de> References: <20070911163848.GA19593@coresystems.de> Message-ID: <46E6C79D.6030304@amd.com> Stefan Reinauer wrote: > Hi, > > I am working on the Asus M2N32-SLI Deluxe and I started out with the > Gigabyte target as base. > > I had to disable ht optimization in the CAR code, or the machine would > not survive the reset. > > It gets to device enumeration now, but it seems it keeps looping on the > devices on bus 0 until it runs out of heap: > > Any ideas what could go wrong? > > Stefan, I have only just begun to look at this code myself but I suspect the problem starts in the HT optimization. I think that the optimization code will setup the pcibus numbers to scan. I don't know why it would loop but it seems like some bad logic check first and last bus. Sorry I don't have more ideas for you right now. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From yinghailu at gmail.com Tue Sep 11 19:12:51 2007 From: yinghailu at gmail.com (yhlu) Date: Tue, 11 Sep 2007 10:12:51 -0700 Subject: [LinuxBIOS] ASUS M2N32-SLI Deluxe In-Reply-To: <20070911163848.GA19593@coresystems.de> References: <20070911163848.GA19593@coresystems.de> Message-ID: <2ea3fae10709111012o1ca4de3cm624404da405c19db@mail.gmail.com> some months ago, i sent out about one patch about it, but wonder if it is checked in...you may dig out from list. or let me find some time to compare the my local tree with public tree. YH From yinghailu at gmail.com Tue Sep 11 19:16:24 2007 From: yinghailu at gmail.com (yhlu) Date: Tue, 11 Sep 2007 10:16:24 -0700 Subject: [LinuxBIOS] quadcore opteron In-Reply-To: <46E605FA.5020102@AMD.com> References: <46E605FA.5020102@AMD.com> Message-ID: <2ea3fae10709111016j60dc79c4s50950d385f20f6cc@mail.gmail.com> On 9/10/07, Marc Jones wrote: > > Barcelona is very similar to the Opteron but does require some new > initialization code. ??? YH From JJia at Fortinet.com Tue Sep 11 19:26:10 2007 From: JJia at Fortinet.com (Jia Jianwei) Date: Tue, 11 Sep 2007 10:26:10 -0700 Subject: [LinuxBIOS] ICH8(82801H) USB problem References: <059301c7f404$becde6c0$3a4610ac@fortinet.com> <20070911095232.GB8677@coresystems.de> Message-ID: <05cf01c7f498$d835cf80$3a4610ac@fortinet.com> It's not exactly LinuxBios source, but It's also used to load linux. I referenced LinuxBios source code and of course contributed some source code to LinuxBios before. The attached is southbridge initialization code. Thanks! Best Regards, Jianwei ----- Original Message ----- From: "Stefan Reinauer" To: "Jia Jianwei" Cc: Sent: Tuesday, September 11, 2007 2:52 AM Subject: Re: [LinuxBIOS] ICH8(82801H) USB problem > * Jia Jianwei [070911 01:46]: > > > > I'm portting BIOS on Q965+ICH8DO, USB port in ICH8 is not working anyway, > > It's always reporting address assign timeout when I plug in a usb device, > > the error message is like this: > > > > hub.c: new USB device 00:1d.0-1, assigned address 4 > > usb_control/bulk_msg: timeout > > usb.c: USB device not accepting new address=4 (error=-110) > > > > > > I checked interrupt, seems interupt increased after USB device plug in. > > Can anyone give me some clues? Thanks in advance! > > If this is LinuxBIOS, please post the source code, so we can help you > find the bug. > > 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/ > > -------------- next part -------------- A non-text attachment was scrubbed... Name: ich8.c Type: application/octet-stream Size: 23454 bytes Desc: not available URL: From stepan at coresystems.de Tue Sep 11 19:48:05 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 11 Sep 2007 19:48:05 +0200 Subject: [LinuxBIOS] ASUS M2N32-SLI Deluxe In-Reply-To: <2ea3fae10709111012o1ca4de3cm624404da405c19db@mail.gmail.com> References: <20070911163848.GA19593@coresystems.de> <2ea3fae10709111012o1ca4de3cm624404da405c19db@mail.gmail.com> Message-ID: <46E6D4D5.3090102@coresystems.de> yhlu wrote: > some months ago, i sent out about one patch about it, but wonder if it > is checked in...you may dig out from list. > > or let me find some time to compare the my local tree with public tree. > > YH > > What was the patch about? I can try to find and merge it... 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 yinghailu at gmail.com Tue Sep 11 19:57:15 2007 From: yinghailu at gmail.com (yhlu) Date: Tue, 11 Sep 2007 10:57:15 -0700 Subject: [LinuxBIOS] ASUS M2N32-SLI Deluxe In-Reply-To: <46E6D4D5.3090102@coresystems.de> References: <20070911163848.GA19593@coresystems.de> <2ea3fae10709111012o1ca4de3cm624404da405c19db@mail.gmail.com> <46E6D4D5.3090102@coresystems.de> Message-ID: <2ea3fae10709111057yecced8bj4728824080552f38@mail.gmail.com> On 9/11/07, Stefan Reinauer wrote: > yhlu wrote: > > some months ago, i sent out about one patch about it, but wonder if it > > is checked in...you may dig out from list. > > > > or let me find some time to compare the my local tree with public tree. > > > > YH > > > > > What was the patch about? I can try to find and merge it... about uinitid setting when c51+mcp51 or c51+mcp55... maybe Ed is on the receiver list too.. or Marc could send you the diff, becase he got my latest tree... YH From corey.osgood at gmail.com Tue Sep 11 20:44:16 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Tue, 11 Sep 2007 14:44:16 -0400 Subject: [LinuxBIOS] EHCI Debug Port on ICH4/ICH4-M chipset In-Reply-To: <46E66FE5.4060405@yahoo.de> References: <200709102249.04606.openembedded@haerwu.biz> <20070911055206.j2jd747vok0ok48k@www.smittys.pointclark.net> <46E66FE5.4060405@yahoo.de> Message-ID: <46E6E200.1000103@gmail.com> Quux wrote: > joe at smittys.pointclark.net schrieb: > >> The ICH4 datasheet also says it has a EHCI debug port. >> Why is it not supported in LB? >> >> > > hardware (displays, data cables, automated profilers or such) are > somewhat uncommon for it and the serial port / POST card is already > quite helpful. > the debug port could transmit much faster of course. so "someone should > do it (tm)" (i.e. provide support) --Q Support for the generic EHCI debug port already exists, IIRC it was necessary for the mcp55 port. The biggest reason we need this is that some boards don't have legacy serial ports any more, they rely on USB and port replicators/docks. -Corey From peter at stuge.se Tue Sep 11 21:04:32 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 11 Sep 2007 21:04:32 +0200 Subject: [LinuxBIOS] AMD 690G chipset support in LinuxBIOS v2 In-Reply-To: <20070911092007.0915d2b7.rasmus@wiman.org> <46893e740709101937j32a4f32bu6dc296a628d36dc6@mail.gmail.com> References: <46893e740709101937j32a4f32bu6dc296a628d36dc6@mail.gmail.com> <20070911092007.0915d2b7.rasmus@wiman.org> <46893e740709101937j32a4f32bu6dc296a628d36dc6@mail.gmail.com> Message-ID: <20070911190432.30652.qmail@stuge.se> On Tue, Sep 11, 2007 at 09:37:04AM +0700, Darmawan Salihun wrote: > Is there any support coming down the road? I haven't seen it mentioned. > I'm planning to buy a new system for BIOS experiments in the next > few days. This chipset is a candidate for me. I want a chipset with > onboard video and K8 processor. I guess you want a Tyan board then. But I think they're mostly server class boards so a bit expensive. > I choose K8 because the datasheet for the memory controller is > readily available. K8 is really well supported by LB. > I'm open for any suggestion(s). Basically, I just want a system > that can run Vista, support multicore processor and can be used for > LinuxBIOS experiments (preferably without soldering stuff needed). Onboard graphics is what gets you into trouble. You'll almost always need to solder today. Not many boards ship with socketed flash, especially not in the desktop segment. > Anyway, one further question: hot-flashing can be done on SPI chips > as well, right? Sure, but they're never socketed from factory. You would have to hack some hardware together. On Tue, Sep 11, 2007 at 09:20:07AM +0200, Rasmus Wiman wrote: > I am thinking along the same lines. My primary candidate is NForce > 430 since MCP55 is already supported. But that could of course mean > absolutely nothing at all. Just because there is working code for > one NVidia chipset it doesn't mean that code will be easy to adapt > th the 430. The current support for NVIDIA was written by Yinghai while at AMD where he had access to all the neccessary data sheets. I'm not sure if he's still got access to good docs from NV? //Peter From peter at stuge.se Tue Sep 11 21:09:58 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 11 Sep 2007 21:09:58 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <20070911054753.7nfsbt4xwgkkcwc4@www.smittys.pointclark.net> References: <46D6AB93.9080607@stockwith.co.uk> <1188756804.46dafd4437693@imp.free.fr> <20070909222428.15040.qmail@stuge.se> <200709101203.37170.jtd@sparc.net> <20070910222006.11349.qmail@stuge.se> <20070911054753.7nfsbt4xwgkkcwc4@www.smittys.pointclark.net> Message-ID: <20070911190958.31508.qmail@stuge.se> On Tue, Sep 11, 2007 at 05:47:53AM -0400, joe at smittys.pointclark.net wrote: > I use Chemtronics Chem-Wik Desoldering Braid. It seems to work > really well. It sucks up all the solder so the pads are left pretty > much bare:-) Yeah - braid is good! Sometimes there can still be a very small amount of solder left though, so that a lot more force is needed to lift the pin - in that case just heating the pad quickly works well. Removing as much solder as possible is good also because the pin doesn't have to be lifted as high from the board to break the joint - which means less risk of breaking the pin in the process. //Peter From peter at stuge.se Tue Sep 11 21:26:00 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 11 Sep 2007 21:26:00 +0200 Subject: [LinuxBIOS] ICH8(82801H) USB problem In-Reply-To: <05cf01c7f498$d835cf80$3a4610ac@fortinet.com> References: <059301c7f404$becde6c0$3a4610ac@fortinet.com> <20070911095232.GB8677@coresystems.de> <05cf01c7f498$d835cf80$3a4610ac@fortinet.com> Message-ID: <20070911192600.1732.qmail@stuge.se> On Tue, Sep 11, 2007 at 10:26:10AM -0700, Jia Jianwei wrote: > > > I'm portting BIOS on Q965+ICH8DO, USB port in ICH8 is not > > > working anyway, It's always reporting address assign timeout > > > when I plug in a usb device, the error message is like this: > > > > > > hub.c: new USB device 00:1d.0-1, assigned address 4 > > > usb_control/bulk_msg: timeout > > > usb.c: USB device not accepting new address=4 (error=-110) > > > > > > I checked interrupt, seems interupt increased after USB device > > > plug in. Can anyone give me some clues? Try enabling really verbose debugging in the Linux USB stack to see what is (not) happening. > > If this is LinuxBIOS, please post the source code, so we can help > > you find the bug. > > It's not exactly LinuxBios source, but It's also used to load > linux. I referenced LinuxBios source code and of course > contributed some source code to LinuxBios before. The attached is > southbridge initialization code. Note that if you are using any LinuxBIOS source code in your software, you are creating a derived work and thus are bound by the GPL to release your complete work also under the GPL. //Peter From rminnich at gmail.com Tue Sep 11 22:37:32 2007 From: rminnich at gmail.com (ron minnich) Date: Tue, 11 Sep 2007 13:37:32 -0700 Subject: [LinuxBIOS] denver in april Message-ID: <13426df10709111337q79b8777evd337110357531cca@mail.gmail.com> I've been asked for the following: "#1, can you use your mailing list to quickly take the temperature of those likely to attend, to see if they are sufficiently interested in a Denver meeting on March 31-April 1 in Denver. ", so, let me know if you think you could attend this. ron From ward at gnu.org Tue Sep 11 22:42:56 2007 From: ward at gnu.org (Ward Vandewege) Date: Tue, 11 Sep 2007 16:42:56 -0400 Subject: [LinuxBIOS] denver in april In-Reply-To: <13426df10709111337q79b8777evd337110357531cca@mail.gmail.com> References: <13426df10709111337q79b8777evd337110357531cca@mail.gmail.com> Message-ID: <20070911204256.GA9218@localdomain> On Tue, Sep 11, 2007 at 01:37:32PM -0700, ron minnich wrote: > I've been asked for the following: "#1, can you use your mailing list > to quickly take the temperature of those likely to attend, to see if > they are sufficiently interested in > a Denver meeting on March 31-April 1 in Denver. ", > > so, let me know if you think you could attend this. Yep, I am interested and hope to be able to attend. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From dhendrix at google.com Tue Sep 11 22:50:16 2007 From: dhendrix at google.com (David Hendricks) Date: Tue, 11 Sep 2007 13:50:16 -0700 Subject: [LinuxBIOS] denver in april In-Reply-To: <13426df10709111337q79b8777evd337110357531cca@mail.gmail.com> References: <13426df10709111337q79b8777evd337110357531cca@mail.gmail.com> Message-ID: Mild to moderate--I've been looking for an excuse to fly out there anyway. Who's organizing? On 9/11/07, ron minnich wrote: > > I've been asked for the following: "#1, can you use your mailing list > to quickly take the temperature of those likely to attend, to see if > they are sufficiently interested in > a Denver meeting on March 31-April 1 in Denver. ", > > so, let me know if you think you could attend this. > > ron > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey.osgood at gmail.com Tue Sep 11 22:50:54 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Tue, 11 Sep 2007 16:50:54 -0400 Subject: [LinuxBIOS] denver in april In-Reply-To: <20070911204256.GA9218@localdomain> References: <13426df10709111337q79b8777evd337110357531cca@mail.gmail.com> <20070911204256.GA9218@localdomain> Message-ID: <46E6FFAE.4050809@gmail.com> Ward Vandewege wrote: > On Tue, Sep 11, 2007 at 01:37:32PM -0700, ron minnich wrote: > >> I've been asked for the following: "#1, can you use your mailing list >> to quickly take the temperature of those likely to attend, to see if >> they are sufficiently interested in >> a Denver meeting on March 31-April 1 in Denver. ", >> >> so, let me know if you think you could attend this. >> > > Yep, I am interested and hope to be able to attend. > > Thanks, > Ward. > > count me in -Corey From dhendrix at google.com Tue Sep 11 22:57:59 2007 From: dhendrix at google.com (David Hendricks) Date: Tue, 11 Sep 2007 13:57:59 -0700 Subject: [LinuxBIOS] quadcore opteron In-Reply-To: <2ea3fae10709111016j60dc79c4s50950d385f20f6cc@mail.gmail.com> References: <46E605FA.5020102@AMD.com> <2ea3fae10709111016j60dc79c4s50950d385f20f6cc@mail.gmail.com> Message-ID: Two words: extra crispy ;-) On 9/11/07, yhlu wrote: > > On 9/10/07, Marc Jones wrote: > > > > Barcelona is very similar to the Opteron but does require some new > > initialization code. > > ??? > > YH > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhbarr at gozelle.com Tue Sep 11 23:18:32 2007 From: dhbarr at gozelle.com (David H. Barr) Date: Tue, 11 Sep 2007 16:18:32 -0500 Subject: [LinuxBIOS] denver in april In-Reply-To: <13426df10709111337q79b8777evd337110357531cca@mail.gmail.com> References: <13426df10709111337q79b8777evd337110357531cca@mail.gmail.com> Message-ID: On 9/11/07, ron minnich wrote: > I've been asked for the following: "#1, can you use your mailing list > to quickly take the temperature of those likely to attend, to see if > they are sufficiently interested in > a Denver meeting on March 31-April 1 in Denver. ", > > so, let me know if you think you could attend this. My temperature is about 98?F or so, and I think I could (and would) attend this. From jens at freimann.org Tue Sep 11 23:29:38 2007 From: jens at freimann.org (Jens Freimann) Date: Tue, 11 Sep 2007 23:29:38 +0200 Subject: [LinuxBIOS] [PATCH] Add more PCI config data to device structure Message-ID: <1189546178.7001.28.camel@jens-laptop> Hi, this is a patch to add more data from the PCI configuration space to the device struct. It is needed for example to create a device tree in Open Firmware from the LB device tree. There is one patch vor v2 and another one for v3. Bye, Jens -------------- next part -------------- A non-text attachment was scrubbed... Name: pciconfig_v2.diff Type: text/x-patch Size: 2323 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pciconfig_v3.diff Type: text/x-patch Size: 1980 bytes Desc: not available URL: From jens at freimann.org Tue Sep 11 23:30:20 2007 From: jens at freimann.org (Jens Freimann) Date: Tue, 11 Sep 2007 23:30:20 +0200 Subject: [LinuxBIOS] [PATCH] Add pointer to device tree to LinuxBIOS table Message-ID: <1189546220.7001.29.camel@jens-laptop> Hi, this patch adds a pointer to the LinuxBIOS table which points to the root device. I use it to access the LB device tree from Open Firmware. There is one patch for v2 and another one for v3. Bye, Jens -------------- next part -------------- A non-text attachment was scrubbed... Name: lbdevtreepointer_v2.diff Type: text/x-patch Size: 1874 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lbdevtreepointer_v3.diff Type: text/x-patch Size: 1656 bytes Desc: not available URL: From echelon at free.fr Wed Sep 12 03:11:19 2007 From: echelon at free.fr (echelon at free.fr) Date: Wed, 12 Sep 2007 03:11:19 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <20070911190958.31508.qmail@stuge.se> References: <46D6AB93.9080607@stockwith.co.uk> <1188756804.46dafd4437693@imp.free.fr> <20070909222428.15040.qmail@stuge.se> <200709101203.37170.jtd@sparc.net> <20070910222006.11349.qmail@stuge.se> <20070911054753.7nfsbt4xwgkkcwc4@www.smittys.pointclark.net> <20070911190958.31508.qmail@stuge.se> Message-ID: <1189559479.46e73cb7476b9@imp.free.fr> Hi all, Finaly a little victory with the SPI version of the GA-M57SLI-S4 board.. It works!!! LinuxBIOS + FILO as payload work (almost) "out of the box" on the spi revision of the card, i.e. I didn't make any changes to the source tree used to generate the rom image. But some issues remain: -1) no support in flashrom for spi chips. I used a home made spi programmer (with a Altera FPGA) to flash the rom image. I "socketised" also the flash chip and the mainboard. -2) I managed to boot a Linux with LB (a pretty old Debian distro with a 2.4 kernel). No VGA display at all! I had to use a serial console to display the LB logs and then to log in into Linux. BTW my graphics adapter was a old PCI graphics card. -3) I tried to install a network card too (PCI also). When booting with the factory bios image (Award) it works well, lspci shows both the graphics adapter and the ethernet one. But when booting with LB, these 2 items don't appear anymore into the lspci scan.. It looks to me that the PCI bridge is not correctly initialized into the SB : am I wrong or not on this issue? That's the first assessement I can make for my work with this motherboard for the moment. Now I will try to add support for SPI flash and ITE8716 superio in flashrom (I have never done that before, it will be hard for me!..). Btw, is someone else working with this board at this moment or am I alone?.. I would like to avoid to do unusefull work.. Finaly another finding I made: - the board comes with a 512 KiB flash chip. I tried to use a 1 MiB flash chip and it works! But I had to duplicate the linuxbios.rom image (cat lb.rom lb.rom > lb2.rom) to generate a bigger image suitable for this bigger flash. That's all folks.. Florentin From peter at stuge.se Wed Sep 12 02:52:17 2007 From: peter at stuge.se (Peter Stuge) Date: Wed, 12 Sep 2007 02:52:17 +0200 Subject: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI) In-Reply-To: <1189559479.46e73cb7476b9@imp.free.fr> References: <46D6AB93.9080607@stockwith.co.uk> <1188756804.46dafd4437693@imp.free.fr> <20070909222428.15040.qmail@stuge.se> <200709101203.37170.jtd@sparc.net> <20070910222006.11349.qmail@stuge.se> <20070911054753.7nfsbt4xwgkkcwc4@www.smittys.pointclark.net> <20070911190958.31508.qmail@stuge.se> <1189559479.46e73cb7476b9@imp.free.fr> Message-ID: <20070912005217.27716.qmail@stuge.se> On Wed, Sep 12, 2007 at 03:11:19AM +0200, echelon at free.fr wrote: > Finaly a little victory with the SPI version of the GA-M57SLI-S4 > board.. > It works!!! Great to hear. Glad you can confirm they didn't do too much to change it. > But some issues remain: > -1) no support in flashrom for spi chips. I used a home made spi > programmer (with a Altera FPGA) to flash the rom image. I > "socketised" also the flash chip and the mainboard. Can you confirm or reject the theory for adding a switch? How did you do the socket? > No VGA display at all! Did you include the VGA BIOS in your LB image and enable VGA in Config.lb? > -3) I tried to install a network card too (PCI also). When > booting with the factory bios image (Award) it works well, lspci > shows both the graphics adapter and the ethernet one. But when > booting with LB, these 2 items don't appear anymore into the lspci > scan.. Does LB find them? Can you show us lspci from factory BIOS and full serial output from the LB boot? > It looks to me that the PCI bridge is not correctly initialized > into the SB : am I wrong or not on this issue? That could be it. Maybe they changed enough to make the board's Config.lb invalid. > Now I will try to add support for SPI flash and ITE8716 superio in > flashrom (I have never done that before, it will be hard for > me!..). Btw, is someone else working with this board at this moment > or am I alone?.. I would like to avoid to do unusefull work.. Carl-Daniel was going to have a look at it when he got back online unless someone else did it first. flashrom has no support at all for the SPI way of flashing so I would just do a massive hack for the first round of SPI support. > Finaly another finding I made: > - the board comes with a 512 KiB flash chip. I tried to use a 1 > MiB flash chip and it works! But I had to duplicate the > linuxbios.rom, image (cat lb.rom lb.rom > lb2.rom) to generate a > bigger image suitable for this bigger flash. Yep - I would expect that to work. Cool. //Peter From outlander_wei at yahoo.com Wed Sep 12 04:02:04 2007 From: outlander_wei at yahoo.com (Richard Wei) Date: Tue, 11 Sep 2007 19:02:04 -0700 (PDT) Subject: [LinuxBIOS] Tyan S2885 interrupt problem... Message-ID: <276505.44148.qm@web33503.mail.mud.yahoo.com> Traped in the interrupt problem for a long time. Need someone's guidance. When I disabled SMP and Power Management support in Linux 2.6.14, I was able to enter the shell without any IRQ ability (IRQ=0) for all PCI devices. Checking for some discussions and found out that most of the successful case has to turn them on, and expect I/O APIC and local APIC to assigned IRQ for PCI devices. Am I on the right track? Or is there other method to assigned IRQ? But everytime init_lapic_sysfs called, the kernel hang~ Did I miss anything? Any suggestion is appreciated~ Richard Wei ========================================================== Environment: MB:Tyan S2885 Only one AMD Opteron CPU is mounted on. LinuxBIOSv2-2751, Linux 2.6.14 ======================================================== log message (I/O APIC Enabled) ======================================================== LinuxBIOS-2.0.0_s2885_Fallback Wed Sep 12 09:39:37 CST 2007 starting... 01 nodes initialized. core0 started: started ap apicid: SBLink=02 NC node|link=00 busn=40 NC node|link=02 ht reset - LinuxBIOS-2.0.0_s2885_Fallback Wed Sep 12 09:39:37 CST 2007 starting... 01 nodes initialized. core0 started: started ap apicid: SBLink=02 NC node|link=00 busn=40 NC node|link=02 Ram1.00 Ram2.00 Ram3 Initializing memory: done Ram4 v_esp=000cfd24 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 = 000093a5 linxbios_ram.bin length = 0001898c Jumping to LinuxBIOS. LinuxBIOS-2.0.0_s2885_Fallback Wed Sep 12 09:39:37 CST 2007 booting... Enumerating buses... APIC_CLUSTER: 0 enabled PCI_DOMAIN: 0000 enabled PCI: 00:18.3 siblings=0 Found Rev E or Rev F later single core CPU: APIC: 00 enabled PCI: pci_scan_bus for bus 00 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] enabled PCI: 00:00.0 [1022/7450] enabled PCI: 00:0a.0 [1022/7450] enabled next_unitid: 000c PCI: 00:00.0 [1022/7460] enabled PCI: 00:0c.0 [1022/7460] enabled next_unitid: 0010 PCI: pci_scan_bus for bus 00 PCI: 00:06.0 [1022/7460] enabled PCI: 00:07.0 [1022/7468] enabled PCI: 00:07.1 [1022/7469] enabled PCI: 00:07.2 [1022/746a] enabled PCI: 00:07.3 [1022/746b] enabled PCI: 00:07.5 [1022/746d] enabled PCI: 00:0a.0 [1022/7450] enabled PCI: 00:0a.1 [1022/7451] enabled PCI: 00:0b.0 [1022/7450] enabled PCI: 00:0b.1 [1022/7451] enabled PCI: pci_scan_bus for bus 01 PCI: 01:00.0 [1022/7464] enabled PCI: 01:00.1 [1022/7464] enabled PCI: 01:0b.0 [1095/3114] enabled PCI: 01:0c.0 [104c/8023] enabled PCI: pci_scan_bus returning with max=001 PNP: 002e.0 enabled PNP: 002e.1 disabled PNP: 002e.2 enabled PNP: 002e.3 enabled PNP: 002e.5 enabled PNP: 002e.6 disabled PNP: 002e.7 disabled PNP: 002e.8 disabled PNP: 002e.9 disabled PNP: 002e.a disabled PNP: 002e.b enabled smbus: PCI: 00:07.3[0]->I2C: 01:50 enabled smbus: PCI: 00:07.3[0]->I2C: 01:51 enabled smbus: PCI: 00:07.3[0]->I2C: 01:52 enabled smbus: PCI: 00:07.3[0]->I2C: 01:53 enabled smbus: PCI: 00:07.3[0]->I2C: 01:54 enabled smbus: PCI: 00:07.3[0]->I2C: 01:55 enabled smbus: PCI: 00:07.3[0]->I2C: 01:56 enabled smbus: PCI: 00:07.3[0]->I2C: 01:57 enabled PCI: pci_scan_bus for bus 02 PCI: 02:09.0 [14e4/16a7] enabled PCI: pci_scan_bus returning with max=002 PCI: 02: 100MHz PCI-X PCI: 02:09.0 AMD8131 PCI-X tuning PCI: pci_scan_bus for bus 03 PCI: pci_scan_bus returning with max=003 PCI: 03: 133MHz PCI-X PCI: pci_scan_bus returning with max=003 PCI: 40:00.0 [1022/7454] enabled PCI: 40:01.0 [1022/7454] enabled next_unitid: 0004 PCI: pci_scan_bus for bus 40 PCI: 40:01.0 [1022/7454] enabled PCI: 40:02.0 [1022/7455] enabled PCI: pci_scan_bus for bus 41 PCI: 41:00.0 [10de/0181] enabled PCI: pci_scan_bus returning with max=041 PCI: pci_scan_bus returning with max=041 PCI: pci_scan_bus returning with max=041 done Allocating resources... Reading resources... PCI: 40:02.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 41 io PCI: 00:06.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 01 prefmem PCI: 00:0a.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 02 io PCI: 00:0a.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 02 prefmem Done reading resources. Setting resources... PCI: 00:18.0 1d8 <- [0x0000003000 - 0x0000002fff] io PCI: 00:18.0 1b8 <- [0x00e0000000 - 0x00f3ffffff] prefmem PCI: 00:18.0 1b0 <- [0x00f8000000 - 0x00f91fffff] mem PCI: 00:18.0 1d2 <- [0x0000001000 - 0x0000002fff] io PCI: 00:18.0 1aa <- [0x00f9500000 - 0x00f94fffff] prefmem PCI: 00:18.0 1a2 <- [0x00f9200000 - 0x00f94fffff] mem PCI: 40:01.0 10 <- [0x00e0000000 - 0x00efffffff] prefmem PCI: 40:01.0 14 <- [0x00f9100000 - 0x00f9100000] mem PCI: 40:02.0 24 <- [0x00f0000000 - 0x00f3ffffff] bus 41 prefmem PCI: 40:02.0 20 <- [0x00f8000000 - 0x00f90fffff] bus 41 mem PCI: 41:00.0 10 <- [0x00f8000000 - 0x00f8ffffff] mem PCI: 41:00.0 14 <- [0x00f0000000 - 0x00f3ffffff] prefmem PCI: 41:00.0 30 <- [0x00f9000000 - 0x00f901ffff] romem PCI: 00:06.0 1c <- [0x0000001000 - 0x0000001fff] bus 01 io PCI: 00:06.0 20 <- [0x00f9200000 - 0x00f92fffff] bus 01 mem PCI: 01:00.0 10 <- [0x00f9204000 - 0x00f9204fff] mem PCI: 01:00.1 10 <- [0x00f9205000 - 0x00f9205fff] mem PCI: 01:0b.0 10 <- [0x0000001010 - 0x0000001017] io PCI: 01:0b.0 14 <- [0x0000001030 - 0x0000001033] io PCI: 01:0b.0 18 <- [0x0000001020 - 0x0000001027] io PCI: 01:0b.0 1c <- [0x0000001040 - 0x0000001043] io PCI: 01:0b.0 20 <- [0x0000001000 - 0x000000100f] io PCI: 01:0b.0 24 <- [0x00f9207000 - 0x00f92073ff] mem PCI: 01:0c.0 10 <- [0x00f9206000 - 0x00f92067ff] mem PCI: 01:0c.0 14 <- [0x00f9200000 - 0x00f9203fff] mem PNP: 002e.0 60 <- [0x00000003f0 - 0x00000003f7] io PNP: 002e.0 70 <- [0x0000000006 - 0x0000000006] irq PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] io PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] irq PNP: 002e.3 60 <- [0x00000002f8 - 0x00000002ff] io PNP: 002e.3 70 <- [0x0000000003 - 0x0000000003] irq PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] io PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] io PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] irq PNP: 002e.5 72 <- [0x000000000c - 0x000000000c] irq PNP: 002e.b 60 <- [0x0000000290 - 0x0000000297] io PNP: 002e.b 70 <- [0x0000000005 - 0x0000000005] irq PCI: 00:07.1 20 <- [0x0000002860 - 0x000000286f] io PCI: 00:07.2 10 <- [0x0000002840 - 0x000000285f] io PCI: 00:07.3 58 <- [0x0000002000 - 0x00000020ff] io PCI: 00:07.5 10 <- [0x0000002400 - 0x00000024ff] io PCI: 00:07.5 14 <- [0x0000002800 - 0x000000283f] io PCI: 00:0a.0 20 <- [0x00f9300000 - 0x00f93fffff] bus 02 mem PCI: 02:09.0 10 <- [0x00f9300000 - 0x00f930ffff] mem64 PCI: 00:0a.1 10 <- [0x00f9400000 - 0x00f9400fff] mem64 PCI: 00:0b.1 10 <- [0x00f9401000 - 0x00f9401fff] mem64 PCI: 00:18.3 94 <- [0x00f4000000 - 0x00f7ffffff] mem Done setting resources. Done allocating resources. Enabling resources... PCI: 00:18.0 cmd <- 140 PCI: 40:01.0 subsystem <- 10f1/2885 PCI: 40:01.0 cmd <- 146 PCI: 40:02.0 bridge ctrl <- 0003 PCI: 40:02.0 cmd <- 146 PCI: 41:00.0 cmd <- 142 PCI: 00:06.0 bridge ctrl <- 0003 PCI: 00:06.0 cmd <- 147 PCI: 01:00.0 subsystem <- 10f1/2885 PCI: 01:00.0 cmd <- 142 PCI: 01:00.1 subsystem <- 10f1/2885 PCI: 01:00.1 cmd <- 142 PCI: 01:0b.0 subsystem <- 10f1/2885 PCI: 01:0b.0 cmd <- 143 PCI: 01:0c.0 cmd <- 142 PCI: 00:07.0 subsystem <- 10f1/2885 PCI: 00:07.0 cmd <- 14f w83627hf hwm smbus enabled PCI: 00:07.1 subsystem <- 10f1/2885 PCI: 00:07.1 cmd <- 141 PCI: 00:07.2 subsystem <- 10f1/2885 PCI: 00:07.2 cmd <- 141 PCI: 00:07.3 subsystem <- 10f1/2885 PCI: 00:07.3 cmd <- 141 PCI: 00:07.5 subsystem <- 10f1/2885 PCI: 00:07.5 cmd <- 141 PCI: 00:0a.0 bridge ctrl <- 0003 PCI: 00:0a.0 cmd <- 146 PCI: 02:09.0 subsystem <- 10f1/2885 PCI: 02:09.0 cmd <- 142 PCI: 00:0a.1 subsystem <- 10f1/2885 PCI: 00:0a.1 cmd <- 146 PCI: 00:0b.1 subsystem <- 10f1/2885 PCI: 00:0b.1 cmd <- 146 PCI: 00:18.1 subsystem <- 10f1/2885 PCI: 00:18.1 cmd <- 140 PCI: 00:18.2 subsystem <- 10f1/2885 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 20f51 CPU: family 0f, model 25, stepping 01 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 DONE variable MTRRs Clear out the extra MTRR's MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled CPU model AMD Opteron(tm) Processor 248 Setting up local apic... apic_id: 0x00 done. Clearing memory 2048K - 524288K: ------- done CPU #0 Initialized All AP CPUs stopped PCI: 00:18.0 init PCI: 40:02.0 init PCI: 00:0a.0 init PCI: 02:09.0 init PCI: 00:06.0 init PCI: 01:0b.0 init PCI: 00:07.0 init amd8111: ioapic bsp_apicid = 00 RTC Init Invalid CMOS LB checksum enabling HPET @0xfed00000 PNP: 002e.0 init PNP: 002e.2 init PNP: 002e.3 init PNP: 002e.5 init PNP: 002e.b init PCI: 00:07.1 init IDE1 IDE0 PCI: 00:07.3 init set power on after power fail PCI: 00:18.1 init PCI: 00:18.2 init PCI: 00:18.3 init NB: Function 3 Misc Control.. done. PCI: 01:0c.0 init PCI: 41:00.0 init Devices initialized Writing IRQ routing tables to 0xf0000...done. Wrote the mp table end at: 00000020 - 000003e0 Moving GDT to 0x500...ok Adjust low_table_end from 0x00000530 to 0x00001000 Adjust rom_table_end from 0x000f0400 to 0x00100000 Wrote linuxbios table at: 00000530 - 00000dbc checksum 6d01 Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3 rom_stream: 0xfffc0000 - 0xfffdffff Found ELF candidate at offset 0 header_offset is 0 Try to load at offset 0x0 New segment addr 0x100000 size 0x23740 offset 0xc0 filesize 0x9594 (cleaned up) New segment addr 0x100000 size 0x23740 offset 0xc0 filesize 0x9594 New segment addr 0x123740 size 0x48 offset 0x9660 filesize 0x48 (cleaned up) New segment addr 0x123740 size 0x48 offset 0x9660 filesize 0x48 Dropping non PT_LOAD segment Dropping non PT_LOAD segment Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000023740 filesz: 0x00 00000000009594 Clearing Segment: addr: 0x0000000000109594 memsz: 0x000000000001a1ac Loading Segment: addr: 0x0000000000123740 memsz: 0x0000000000000048 filesz: 0x00 00000000000048 Jumping to boot code at 0x106568 FILO version 0.5 (root at host.domain.com) Tue Sep 4 11:25:34 CST 2007 collect_sys_info: boot eax = 0xe1fb007 collect_sys_info: boot ebx = 0x1ffda180 collect_sys_info: boot arg = 0x1ffda180 malloc_diag: alloc: 0 bytes (0 blocks), free: 16376 bytes (1 blocks) malloc_diag: alloc: 24 bytes (1 blocks), free: 16352 bytes (1 blocks) collect_elfboot_info: Bootloader: elfboot collect_elfboot_info: Version: 1.3 malloc_diag: alloc: 40 bytes (2 blocks), free: 16336 bytes (1 blocks) collect_linuxbios_info: Searching for LinuxBIOS tables... find_lb_table: Found canidate at: 00000530 find_lb_table: header checksum o.k. find_lb_table: table checksum o.k. find_lb_table: record count o.k. collect_linuxbios_info: Found LinuxBIOS table at: 00000530 convert_memmap: 0x00000000000000 0x00000000001000 16 convert_memmap: 0x00000000001000 0x0000000009f000 1 convert_memmap: 0x000000000c0000 0x00000000030000 1 convert_memmap: 0x000000000f0000 0x00000000010000 16 convert_memmap: 0x00000000100000 0x0000001ff00000 1 collect_sys_info: 0000000000001000-00000000000a0000 collect_sys_info: 00000000000c0000-00000000000f0000 collect_sys_info: 0000000000100000-0000000020000000 collect_sys_info: RAM 512 MB relocate: Current location: 0x100000-0x123787 relocate: Relocating to 0x1ffdc870-0x1ffffff7... ok setup_timers: CPU 2191 MHz Press for default boot, or for boot prompt... timed out boot: hda1:/vmlinuz-2.6.14 root=/dev/VolGroup00/LogVol00 initrd=/initrd-2.6.14.i mg console=tty0 console=ttyS0,115200 enforcing=0 malloc_diag: alloc: 176 bytes (3 blocks), free: 16200 bytes (1 blocks) malloc_diag: alloc: 192 bytes (4 blocks), free: 16184 bytes (1 blocks) file_open: dev=hda1, path=/vmlinuz-2.6.14 ide_software_reset: Waiting for ide0 to become ready for reset... ok ide_software_reset: await 1 ide_software_reset: await 2 init_drive: Testing for hda init_drive: Probing for hda init_drive: LBA mode, sectors=19746720 init_drive: Init device params... ok hda: LBA 10GB: IBM-DTTA-371010 init_drive: Testing for hdb init_drive: Testing for hdb devopen: Partition 1 start 63 length 208782 Mounted ext2fs malloc_diag: alloc: 176 bytes (3 blocks), free: 16200 bytes (1 blocks) elf_load: Not a bootable ELF image malloc_diag: alloc: 192 bytes (4 blocks), free: 16184 bytes (1 blocks) file_open: dev=hda1, path=/vmlinuz-2.6.14 devopen: already open malloc_diag: alloc: 176 bytes (3 blocks), free: 16200 bytes (1 blocks) Found Linux version 2.6.14 (root at localhost.localdomain) #37 SMP Tue Sep 18 20:17 :17 CST 2007 (protocol 0x204) (loadflags 0x1) bzImage. init_linux_params: Setting up paramters at 0x90000 set_memory_size: 0000000000001000 - 00000000000a0000 set_memory_size: 00000000000c0000 - 00000000000f0000 set_memory_size: 0000000000100000 - 0000000020000000 set_memory_size: ramtop=0x20000000 set_memory_size: ext_mem_k=64512, alt_mem_k=523264 parse_command_line: original command line: "root=/dev/VolGroup00/LogVol00 initrd =/initrd-2.6.14.img console=tty0 console=ttyS0,115200 enforcing=0" parse_command_line: kernel command line at 0x91000 malloc_diag: alloc: 208 bytes (4 blocks), free: 16168 bytes (1 blocks) parse_command_line: initrd=/initrd-2.6.14.img parse_command_line: kernel command line (75 bytes): "root=/dev/VolGroup00/LogVol 00 console=tty0 console=ttyS0,115200 enforcing=0" load_linux_kernel: offset=0x2000 addr=0x100000 size=0x1613f1 Loading kernel... ok file_open: dev=, path=/initrd-2.6.14.img load_initrd: start=0x1feec000 end=0x1ffdb9af Loading initrd... ok malloc_diag: alloc: 176 bytes (3 blocks), free: 16200 bytes (1 blocks) start_linux: eip=0x100000 Jumping to entry point... Linux version 2.6.14 (root at localhost.localdomain) (gcc version 3.4.3 20041212 (R ed Hat 3.4.3-9.EL4)) #37 SMP Tue Sep 18 20:17:17 CST 2007 BIOS-provided physical RAM map: BIOS-e820: 0000000000001000 - 00000000000a0000 (usable) BIOS-e820: 0000000000100000 - 0000000020000000 (usable) 0MB HIGHMEM available. 512MB LOWMEM available. found SMP MP-table at 00000010 DMI not present. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: TYAN Product ID: S2885 APIC at: 0xFEE00000 Processor #0 15:5 APIC version 16 I/O APIC #1 Version 17 at 0xFEC00000. I/O APIC #2 Version 17 at 0xF9400000. I/O APIC #3 Version 17 at 0xF9401000. Enabling APIC mode: Flat. Using 3 I/O APICs Processors: 1 Allocating PCI resources starting at 30000000 (gap: 20000000:e0000000) Built 1 zonelists Kernel command line: root=/dev/VolGroup00/LogVol00 console=tty0 console=ttyS0,11 5200 enforcing=0 Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 2192.178 MHz processor. Using tsc for high-res timesource Console: colour dummy device 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 514504k/524288k available (2103k kernel code, 9200k reserved, 633k data, 196k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 4392.77 BogoMIPS (lpj=8785558) Mount-cache hash table entries: 512 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. mtrr: v2.0 (20020519) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. CPU0: AMD Opteron(tm) Processor 248 stepping 01 Total of 1 processors activated (4392.77 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 pin1=2 pin2=0 Brought up 1 CPUs checking if image is initramfs... it is Freeing initrd memory: 958k freed NET: Registered protocol family 16 PCI: Using configuration type 1 Linux Plug and Play Support v0.97 (c) Adam Belay SCSI subsystem initialized usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PCI: Unable to handle 64-bit address space for bridge 0000:00:0a.0 PCI: Unable to handle 64-bit address for device 0000:40:01.0 PCI: Discovered primary peer bus 40 [IRQ] PCI: Using IRQ router default [1022/7468] at 0000:00:07.0 PCI->APIC IRQ transform: 0000:00:07.2[D] -> IRQ 19 PCI->APIC IRQ transform: 0000:00:07.5[B] -> IRQ 17 PCI->APIC IRQ transform: 0000:01:00.0[D] -> IRQ 19 PCI->APIC IRQ transform: 0000:01:00.1[D] -> IRQ 19 PCI->APIC IRQ transform: 0000:01:0b.0[A] -> IRQ 17 PCI->APIC IRQ transform: 0000:01:0c.0[A] -> IRQ 19 PCI->APIC IRQ transform: 0000:02:09.0[A] -> IRQ 24 PCI->APIC IRQ transform: 0000:41:00.0[A] -> IRQ 16 PCI: Bridge: 0000:00:06.0 IO window: 1000-1fff MEM window: f9200000-f92fffff PREFETCH window: 30000000-300fffff PCI: Bridge: 0000:00:0a.0 IO window: disabled. MEM window: f9300000-f93fffff PREFETCH window: 30100000-301fffff PCI: Bridge: 0000:00:0b.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:40:02.0 IO window: disabled. MEM window: f8000000-f90fffff PREFETCH window: f0000000-f3ffffff Unable to handle kernel NULL pointer dereference at virtual address 00000053 printing eip: c01c5c68 *pde = 00000000 Oops: 0000 [#1] SMP Modules linked in: CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010282 (2.6.14) EIP is at kref_get+0x8/0x50 eax: 00000053 ebx: 00000053 ecx: c036dba0 edx: 00000032 esi: dfede000 edi: 00000000 ebp: 00000000 esp: dfedff7c ds: 007b es: 007b ss: 0068 Process swapper (pid: 1, threadinfo=dfede000 task=c14eaa50) Stack: c036dbb4 c01c51d7 c036dbcc c035a0c8 0000003b c01c51d7 00000053 c035a0c8 c01c4f07 0000003b c03d5c3c dfede000 00000000 c03bd071 c035a0c8 c03b0a84 00000000 c033ed08 00000000 dfede000 00000000 00000000 c010039c 00000002 Call Trace: [] kobject_get+0x17/0x20 [] kobject_get+0x17/0x20 [] kobject_add+0x37/0xf0 [] init_lapic_sysfs+0x21/0x40 [] do_initcalls+0x54/0xd0 [] init+0x7c/0x220 [] init+0x0/0x220 [] kernel_thread_helper+0x5/0x10 Code: 8b 5c 24 10 8b 7c 24 18 8b 6c 24 1c 83 c4 20 c3 90 90 90 8b 44 24 04 c7 00 01 00 00 00 c3 90 8d 74 26 00 53 83 ec 10 8b 5c 24 18 <8b> 03 85 c0 74 08 f0 ff 03 83 c4 10 5b c3 c7 44 24 0c 20 00 00 <0>Kernel panic - not syncing: Attempted to kill init! ____________________________________________________________________________________ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz From joe at smittys.pointclark.net Wed Sep 12 09:26:17 2007 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Wed, 12 Sep 2007 03:26:17 -0400 Subject: [LinuxBIOS] i82801DB PCI Bridge locking up Message-ID: <20070912032617.gthkfz5g408k04gs@www.smittys.pointclark.net> Hello, Here is an overview of my problem. When booting, LB freezes when trying to "Enabling resources..." of the PCI Bridge (00:1e.0). I am using the i82801xx code. I think I figured out what is wrong but I don't know why. "Reading resources..." of the device seems to go ok (see below) but when it comes time to "Setting resources..." I don't see the device anywhere (00:1e.0). And then it just locks up at "Enabling resources...". Anyone have any idea why the PCI Bridge is not showing up in "Setting resources..."??? Please help, this is my last obsticle to getting this to boot (i hope). Thanks - Joe ------------------------- 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:00.0 register 10(00000008), read-only ignoring it PCI: 00:1e.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 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: 0000f000 size: 00000000 align: 12 gran: 12 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 link: 0 done PCI: 00:1e.0 compute_allocate_io: base: 0000f000 size: 00000000 align: 12 gran: 12 done PCI: 00:1e.0 1c <- [0x000000f000 - 0x000000efff] bus 01 io PCI: 00:1e.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 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: fff00000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 link: 0 done PCI: 00:1e.0 compute_allocate_prefmem: base: fff00000 size: 00000000 align: 20 gran: 20 done PCI: 00:1e.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 01 prefmem PCI: 00:1e.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 PCI: 00:1e.0 read_resources bus 1 link: 0 PCI: 00:1e.0 read_resources bus 1 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 1 link: 0 PCI: 00:1e.0 read_resources bus 1 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 01 mem PCI: 00:1f.0 read_resources bus 0 link: 0 PCI: 00:1f.0 read_resources bus 0 link: 0 done PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done Root Device read_resources bus 0 link: 0 done PCI: 00:1f.5 10 * [0x00000400 - 0x000004ff] io PCI: 00:1f.6 10 * [0x00000800 - 0x000008ff] io PCI: 00:1f.6 14 * [0x00000c00 - 0x00000c7f] io PCI: 00:1f.5 14 * [0x00000c80 - 0x00000cbf] io PCI: 00:1d.0 20 * [0x00000cc0 - 0x00000cdf] io PCI: 00:1d.1 20 * [0x00000ce0 - 0x00000cff] io PCI: 00:1d.2 20 * [0x00001000 - 0x0000101f] io PCI: 00:1f.3 20 * [0x00001020 - 0x0000103f] io PCI: 00:1f.1 20 * [0x00001040 - 0x0000104f] io PCI: 00:1f.1 10 * [0x00001050 - 0x00001057] io PCI: 00:1f.1 18 * [0x00001060 - 0x00001067] io PCI: 00:1f.1 14 * [0x00001070 - 0x00001073] io PCI: 00:1f.1 1c * [0x00001080 - 0x00001083] io Root Device compute_allocate_io: base: 00001084 size: 00000c84 align: 8 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:1d.7 10 * [0x00000000 - 0x000003ff] mem PCI: 00:1f.1 24 * [0x00001000 - 0x000013ff] mem PCI: 00:1f.5 18 * [0x00002000 - 0x000021ff] mem PCI: 00:1f.5 1c * [0x00003000 - 0x000030ff] mem Root Device compute_allocate_mem: base: 00003100 size: 00003100 align: 10 gran: 0 done Done reading resources. Setting resources... Root Device compute_allocate_io: base: 00001000 size: 00000c84 align: 8 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:1f.5 10 * [0x00001000 - 0x000010ff] io PCI: 00:1f.6 10 * [0x00001400 - 0x000014ff] io PCI: 00:1f.6 14 * [0x00001800 - 0x0000187f] io PCI: 00:1f.5 14 * [0x00001880 - 0x000018bf] io PCI: 00:1d.0 20 * [0x000018c0 - 0x000018df] io PCI: 00:1d.1 20 * [0x000018e0 - 0x000018ff] io PCI: 00:1d.2 20 * [0x00001c00 - 0x00001c1f] io PCI: 00:1f.3 20 * [0x00001c20 - 0x00001c3f] io PCI: 00:1f.1 20 * [0x00001c40 - 0x00001c4f] io PCI: 00:1f.1 10 * [0x00001c50 - 0x00001c57] io PCI: 00:1f.1 18 * [0x00001c60 - 0x00001c67] io PCI: 00:1f.1 14 * [0x00001c70 - 0x00001c73] io PCI: 00:1f.1 1c * [0x00001c80 - 0x00001c83] io Root Device compute_allocate_io: base: 00001c84 size: 00000c84 align: 8 gran: 0 done Root Device compute_allocate_mem: base: febfcc00 size: 00003100 align: 10 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:1d.7 10 * [0xfebfd000 - 0xfebfd3ff] mem PCI: 00:1f.1 24 * [0xfebfe000 - 0xfebfe3ff] mem PCI: 00:1f.5 18 * [0xfebff000 - 0xfebff1ff] mem PCI: 00:1f.5 1c * [0xfec00000 - 0xfec000ff] mem Root Device compute_allocate_mem: base: fec00100 size: 00003500 align: 10 gran: 0 done Root Device assign_resources, bus 0 link: 0 Setting RAM size to 131072 PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 PCI: 00:1d.0 20 <- [0x00000018c0 - 0x00000018df] io PCI: 00:1d.1 20 <- [0x00000018e0 - 0x00000018ff] io PCI: 00:1d.2 20 <- [0x0000001c00 - 0x0000001c1f] io PCI: 00:1d.7 10 <- [0x00febfd000 - 0x00febfd3ff] mem PCI: 00:1f.0 assign_resources, bus 0 link: 0 PNP: 002e.4 60 <- [0x00000003f8 - 0x00000003ff] io PNP: 002e.4 70 <- [0x0000000004 - 0x0000000004] irq PNP: 002e.7 60 <- [0x0000000060 - 0x0000000060] io PNP: 002e.7 62 <- [0x0000000064 - 0x0000000064] io PNP: 002e.7 70 <- [0x0000000001 - 0x0000000001] irq PNP: 002e.7 72 <- [0x000000000c - 0x000000000c] irq PNP: 002e.a 5d <- [0x0000000047 - 0x0000000046] io PNP: 002e.a 5e <- [0x0000000048 - 0x0000000047] io PCI: 00:1f.0 assign_resources, bus 0 link: 0 PCI: 00:1f.1 10 <- [0x0000001c50 - 0x0000001c57] io PCI: 00:1f.1 14 <- [0x0000001c70 - 0x0000001c73] io PCI: 00:1f.1 18 <- [0x0000001c60 - 0x0000001c67] io PCI: 00:1f.1 1c <- [0x0000001c80 - 0x0000001c83] io PCI: 00:1f.1 20 <- [0x0000001c40 - 0x0000001c4f] io PCI: 00:1f.1 24 <- [0x00febfe000 - 0x00febfe3ff] mem PCI: 00:1f.3 20 <- [0x0000001c20 - 0x0000001c3f] io PCI: 00:1f.5 10 <- [0x0000001000 - 0x00000010ff] io PCI: 00:1f.5 14 <- [0x0000001880 - 0x00000018bf] io PCI: 00:1f.5 18 <- [0x00febff000 - 0x00febff1ff] mem PCI: 00:1f.5 1c <- [0x00fec00000 - 0x00fec000ff] mem PCI: 00:1f.6 10 <- [0x0000001400 - 0x00000014ff] io PCI: 00:1f.6 14 <- [0x0000001800 - 0x000000187f] io 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:00.0 cmd <- 146 PCI: 00:1d.0 cmd <- 141 PCI: 00:1d.1 cmd <- 141 PCI: 00:1d.2 cmd <- 141 PCI: 00:1d.7 subsystem <- 00/00 PCI: 00:1d.7 cmd <- 142 PCI: 00:1e.0 bridge ctrl <- 0003 PCI: 00:1e.0 cmd <- 141 ************freezes here**************** ------------------------------- From uwe at hermann-uwe.de Wed Sep 12 14:25:58 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Wed, 12 Sep 2007 14:25:58 +0200 Subject: [LinuxBIOS] i82801DB PCI Bridge locking up In-Reply-To: <20070912032617.gthkfz5g408k04gs@www.smittys.pointclark.net> References: <20070912032617.gthkfz5g408k04gs@www.smittys.pointclark.net> Message-ID: <20070912122558.GA22601@greenwood> On Wed, Sep 12, 2007 at 03:26:17AM -0400, joe at smittys.pointclark.net wrote: > Hello, > Here is an overview of my problem. When booting, LB freezes when > trying to "Enabling resources..." of the PCI Bridge (00:1e.0). I am > using the i82801xx code. I think I figured out what is wrong but I > don't know why. "Reading resources..." of the device seems to go ok > (see below) but when it comes time to "Setting resources..." I don't > see the device anywhere (00:1e.0). And then it just locks up at > "Enabling resources...". > > Anyone have any idea why the PCI Bridge is not showing up in "Setting > resources..."??? Please help, this is my last obsticle to getting this > to boot (i hope). Please post a patch with all your changes against current svn so we can help with debugging. 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 Wed Sep 12 15:47:10 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Wed, 12 Sep 2007 15:47:10 +0200 Subject: [LinuxBIOS] AMD 690G chipset support in LinuxBIOS v2 In-Reply-To: <20070911190432.30652.qmail@stuge.se> References: <46893e740709101937j32a4f32bu6dc296a628d36dc6@mail.gmail.com> <20070911092007.0915d2b7.rasmus@wiman.org> <46893e740709101937j32a4f32bu6dc296a628d36dc6@mail.gmail.com> <20070911190432.30652.qmail@stuge.se> Message-ID: <20070912134710.GB22601@greenwood> On Tue, Sep 11, 2007 at 09:04:32PM +0200, Peter Stuge wrote: > On Tue, Sep 11, 2007 at 09:37:04AM +0700, Darmawan Salihun wrote: > > Is there any support coming down the road? > > I haven't seen it mentioned. See Marc's post, they're working on it (which is great!) > > I'm planning to buy a new system for BIOS experiments in the next > > few days. This chipset is a candidate for me. I want a chipset with > > onboard video and K8 processor. > > I guess you want a Tyan board then. But I think they're mostly server > class boards so a bit expensive. Other alternatives, which are not quite there yet, but good candidates for the future: ASUS A8N-E ASUS A8NE-FM/S ASUS M2N32-SLI Deluxe maybe others And if you're willing to invest some more work to add support for a completely new board, check this list for good candidates: http://linuxbios.org/Desktops > > I'm open for any suggestion(s). Basically, I just want a system > > that can run Vista, support multicore processor and can be used for > > LinuxBIOS experiments (preferably without soldering stuff needed). > > You'll almost always > need to solder today. Not many boards ship with socketed flash, > especially not in the desktop segment. Nah, I wouldn't say that. Check http://linuxbios.org/Desktops, almost all boards listed there seem to have a socketed BIOS (judging from PCB photos I found on the web). > On Tue, Sep 11, 2007 at 09:20:07AM +0200, Rasmus Wiman wrote: > > I am thinking along the same lines. My primary candidate is NForce > > 430 since MCP55 is already supported. But that could of course mean > > absolutely nothing at all. Just because there is working code for > > one NVidia chipset it doesn't mean that code will be easy to adapt > > th the 430. > > The current support for NVIDIA was written by Yinghai while at AMD > where he had access to all the neccessary data sheets. I'm not sure > if he's still got access to good docs from NV? Dunno either, but my guess is that _without_ those docs you cannot easily adapt the MCP55 (or CK804) code to another NVIDIA chipset. But feel free to correct me if it's easier than I think... 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 jordan.crouse at amd.com Wed Sep 12 16:49:20 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 12 Sep 2007 08:49:20 -0600 Subject: [LinuxBIOS] buildrom: doquilt.sh In-Reply-To: <20070905220839.GA23344@localdomain> References: <20070905220839.GA23344@localdomain> Message-ID: <20070912144920.GA4913@cosmic.amd.com> On 05/09/07 18:08 -0400, Ward Vandewege wrote: > Hi there, > > This is the first in a series of patches for buildrom to add support for the > Gigabyte m57sli board. I've been distracted by several small fires. These have all be acked - can somebody check them in for me? Thanks! :) Jordan From ward at gnu.org Wed Sep 12 17:04:19 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 11:04:19 -0400 Subject: [LinuxBIOS] buildrom: doquilt.sh In-Reply-To: <20070912144920.GA4913@cosmic.amd.com> References: <20070905220839.GA23344@localdomain> <20070912144920.GA4913@cosmic.amd.com> Message-ID: <20070912150419.GA15994@localdomain> On Wed, Sep 12, 2007 at 08:49:20AM -0600, Jordan Crouse wrote: > On 05/09/07 18:08 -0400, Ward Vandewege wrote: > > Hi there, > > > > This is the first in a series of patches for buildrom to add support for the > > Gigabyte m57sli board. > > I've been distracted by several small fires. These have all be acked - can > somebody check them in for me? Thanks! :) Sure, I'll do it today; also have been a bit busy. I'm going to prepare one more patch first to pull the tiny patches directly from the repository rather than including them in the buildrom sources. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From ward at gnu.org Wed Sep 12 18:21:09 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 12:21:09 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: add packages/kernel/patches/tiny_m57sli In-Reply-To: <13426df10709081134r209f0c33vc893a46e39c39458@mail.gmail.com> References: <20070906142443.GC29891@localdomain> <13426df10709081028m3fcaefc1k1a9113d26fa8e0d1@mail.gmail.com> <2ea3fae10709081131m7c275f9fha9f7b18e1c65b0f4@mail.gmail.com> <13426df10709081134r209f0c33vc893a46e39c39458@mail.gmail.com> Message-ID: <20070912162109.GA16629@localdomain> On Sat, Sep 08, 2007 at 11:34:01AM -0700, ron minnich wrote: > On 9/8/07, yhlu wrote: > > On 9/8/07, ron minnich wrote: > > > On 9/6/07, Ward Vandewege wrote: > > > > These patches are released under the GPLv2, so we can just include them in > > > > our buildrom tree. Do we need a license header for each file? > > > > > > > > > This comes from tiny, right? I think since it is a patch we are ok? > > > > we should put the URL in buildrom to download that quilt patchset from > > elinux.org like download linux tar ball... > > good point, ward, is that doable? It is; here are the updated patches, if there are no objections I'm going to commit later today. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: m57sli-kernel.mk.patch Type: text/x-diff Size: 1083 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: download-tiny.patch Type: text/x-diff Size: 1127 bytes Desc: not available URL: From yinghailu at gmail.com Wed Sep 12 18:33:49 2007 From: yinghailu at gmail.com (yhlu) Date: Wed, 12 Sep 2007 09:33:49 -0700 Subject: [LinuxBIOS] Tyan S2885 interrupt problem... In-Reply-To: <276505.44148.qm@web33503.mail.mud.yahoo.com> References: <276505.44148.qm@web33503.mail.mud.yahoo.com> Message-ID: <2ea3fae10709120933r5adec756v4a79cd1591c223ac@mail.gmail.com> please use 64 bit kernel... YH From stepan at coresystems.de Wed Sep 12 18:37:46 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 12 Sep 2007 18:37:46 +0200 Subject: [LinuxBIOS] ASUS M2N32-SLI Deluxe In-Reply-To: <2ea3fae10709111057yecced8bj4728824080552f38@mail.gmail.com> References: <20070911163848.GA19593@coresystems.de> <2ea3fae10709111012o1ca4de3cm624404da405c19db@mail.gmail.com> <46E6D4D5.3090102@coresystems.de> <2ea3fae10709111057yecced8bj4728824080552f38@mail.gmail.com> Message-ID: <20070912163746.GA5878@coresystems.de> * yhlu [070911 19:57]: > about uinitid setting when c51+mcp51 or c51+mcp55... > maybe Ed is on the receiver list too.. > > or Marc could send you the diff, becase he got my latest tree... This seems to be it: http://linuxbios.org/pipermail/linuxbios/2007-January/018045.html I tested it and it gets me quite a bit further. -- 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 Wed Sep 12 18:39:06 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 12 Sep 2007 18:39:06 +0200 Subject: [LinuxBIOS] r18 - buildrom-devel/bin Message-ID: Author: ward Date: 2007-09-12 18:39:06 +0200 (Wed, 12 Sep 2007) New Revision: 18 Modified: buildrom-devel/bin/doquilt.sh Log: Make doquilt.sh a bit smarter about dealing with quilt patch trees. Signed-off-by: Ward Vandewege Acked-by: Jordan Crouse Modified: buildrom-devel/bin/doquilt.sh =================================================================== --- buildrom-devel/bin/doquilt.sh 2007-08-29 16:54:43 UTC (rev 17) +++ buildrom-devel/bin/doquilt.sh 2007-09-12 16:39:06 UTC (rev 18) @@ -22,6 +22,13 @@ exit 0 fi +# Sometimes the patch order matches. In that case, we can pass the entire patch subdirectory +# to this script as the second argument, and we'll copy it into $DIR/patches/ +if [ -d $1 ]; then + cp -pr $1/* $DIR/patches/ + shift +fi + while [ $# -gt 0 ]; do echo `basename $1` >> $DIR/patches/series cp $1 $DIR/patches From ward at gnu.org Wed Sep 12 18:39:34 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 12:39:34 -0400 Subject: [LinuxBIOS] buildrom: doquilt.sh In-Reply-To: <20070906023435.GA23823@cosmic.amd.com> References: <20070905220839.GA23344@localdomain> <20070906023435.GA23823@cosmic.amd.com> Message-ID: <20070912163934.GA17001@localdomain> On Wed, Sep 05, 2007 at 08:34:35PM -0600, Jordan Crouse wrote: > Acked-by: Jordan Crouse r18 Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From svn at openbios.org Wed Sep 12 18:41:58 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 12 Sep 2007 18:41:58 +0200 Subject: [LinuxBIOS] r19 - buildrom-devel/config/payloads Message-ID: Author: ward Date: 2007-09-12 18:41:58 +0200 (Wed, 12 Sep 2007) New Revision: 19 Modified: buildrom-devel/config/payloads/lab.conf Log: Don't limit RAM to 119MB for LAB, which was leftover from the early OLPC days. Also add console output to tty0. Signed-off-by: Ward Vandewege Acked-by: Jordan Crouse Modified: buildrom-devel/config/payloads/lab.conf =================================================================== --- buildrom-devel/config/payloads/lab.conf 2007-09-12 16:39:06 UTC (rev 18) +++ buildrom-devel/config/payloads/lab.conf 2007-09-12 16:41:58 UTC (rev 19) @@ -7,7 +7,7 @@ ### Payload specific configuration # Specify the default command line for the image -COMMAND_LINE=console=ttyS0,115200 mem=119m rdinit=/linuxrc +COMMAND_LINE=console=tty0 console=ttyS0,115200 rdinit=/linuxrc # This is the version string printed during boot. From ward at gnu.org Wed Sep 12 18:42:35 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 12:42:35 -0400 Subject: [LinuxBIOS] buildrom: config/payloads/lab.conf In-Reply-To: <20070906023524.GB23823@cosmic.amd.com> References: <20070905221238.GA23411@localdomain> <20070906023524.GB23823@cosmic.amd.com> Message-ID: <20070912164235.GB17001@localdomain> On Wed, Sep 05, 2007 at 08:35:24PM -0600, Jordan Crouse wrote: > > Don't limit RAM to 119MB for LAB. Not sure why this was necessary in the first place. > > Ahhh - the good ol' days of OLPC - when just booting the kernel was new > and magical. > > > Signed-off-by: Ward Vandewege > > Acked-by: Jordan Crouse r19 Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From svn at openbios.org Wed Sep 12 18:48:42 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 12 Sep 2007 18:48:42 +0200 Subject: [LinuxBIOS] r20 - buildrom-devel Message-ID: Author: ward Date: 2007-09-12 18:48:42 +0200 (Wed, 12 Sep 2007) New Revision: 20 Modified: buildrom-devel/README Log: Fixed typos (trivial). Signed-off-by: Ward Vandewege Acked-by: Ward Vandewege Modified: buildrom-devel/README =================================================================== --- buildrom-devel/README 2007-09-12 16:41:58 UTC (rev 19) +++ buildrom-devel/README 2007-09-12 16:48:42 UTC (rev 20) @@ -8,8 +8,8 @@ This is a simple makefile system that designed to build a ROM image for LinuxBIOS based systems. This system allows one to choose one of several different payloads for a variety of platforms. The intention of buildROM -is to build everythign together with one step, rather then the 6 or 8 -individual steps that it would hae taken previously. +is to build everything together with one step, rather then the 6 or 8 +individual steps that it would have taken previously. Payloads From ward at gnu.org Wed Sep 12 18:49:16 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 12:49:16 -0400 Subject: [LinuxBIOS] buildrom: README In-Reply-To: <20070906023546.GC23823@cosmic.amd.com> References: <20070905221531.GA23467@localdomain> <20070906023546.GC23823@cosmic.amd.com> Message-ID: <20070912164916.GC17001@localdomain> On Wed, Sep 05, 2007 at 08:35:46PM -0600, Jordan Crouse wrote: > > Fixed typo. > > > > Signed-off-by: Ward Vandewege > > Acked by: Jordan Crouse r20 Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From svn at openbios.org Wed Sep 12 18:55:33 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 12 Sep 2007 18:55:33 +0200 Subject: [LinuxBIOS] r21 - buildrom-devel/bin Message-ID: Author: ward Date: 2007-09-12 18:55:33 +0200 (Wed, 12 Sep 2007) New Revision: 21 Modified: buildrom-devel/bin/mklibs.py Log: This is a workaround for a bug in the mklibs.py script. Jordan clarified: "It seems that there is some sort of obfustication going on in the ctype.h header file that somehow filters down to pain in uclibc/busybox. This workaround is as good as any - if anything, it costs us a few bytes in an extra possibly not needed function, but that's not so bad." Signed-off-by: Ward Vandewege Acked-by: Jordan Crouse Modified: buildrom-devel/bin/mklibs.py =================================================================== --- buildrom-devel/bin/mklibs.py 2007-09-12 16:48:42 UTC (rev 20) +++ buildrom-devel/bin/mklibs.py 2007-09-12 16:55:33 UTC (rev 21) @@ -472,6 +472,10 @@ # to be the only one and including it on alpha as well # doesn't hurt. I guess all archs can live with this. needed_symbols.add(("sys_siglist", 1)) +# For some reason this symbol is needed by busybox but not included in the +# stripped libc... +# Ward Vandewege, 2007-08-30 +needed_symbols.add(("__ctype_toupper", 1)) while True: debug(DEBUG_NORMAL, "library reduction pass", `passnr`) From ward at gnu.org Wed Sep 12 18:55:57 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 12:55:57 -0400 Subject: [LinuxBIOS] buildrom: bin/mklibs.py In-Reply-To: <20070906024501.GD23823@cosmic.amd.com> References: <20070905222224.GB23467@localdomain> <20070906024501.GD23823@cosmic.amd.com> Message-ID: <20070912165557.GD17001@localdomain> On Wed, Sep 05, 2007 at 08:45:01PM -0600, Jordan Crouse wrote: > On 05/09/07 18:22 -0400, Ward Vandewege wrote: > > OK, so this one is a workaround. I'm not sure what the proper fix would be. > > > > I'd be grateful for comments on how to solve this in a better way. The > > mklibs.py script is stripping one symbol too much (__ctype_toupper) from the > > uclibc libc, which breaks busybox. This might be toolchain dependent - I've > > done my testing on Gnewsense Deltad (aka Ubuntu Dapper Drake) with GCC 4.1.0. > > sigh - we've seen issues with ctype functions before, and I'm just not really > clear on the best way to handle them. It seems that there is some sort of > obfustication going on in the ctype.h header file that somehow filters > down to pain in uclibc/busybox. This work around is as good as any - if > anything, it costs us a few bytes in an extra possibly not needed function, > but thats not so bad. > > Acked-by: Jordan Crouse r21 Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From svn at openbios.org Wed Sep 12 20:47:06 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 12 Sep 2007 20:47:06 +0200 Subject: [LinuxBIOS] r22 - buildrom-devel/packages/filo/patches Message-ID: Author: ward Date: 2007-09-12 20:47:06 +0200 (Wed, 12 Sep 2007) New Revision: 22 Added: buildrom-devel/packages/filo/patches/sata-spinup-delay.patch Log: The sata spinup patch. Signed-off-by: Ward Vandewege Acked-by: Jordan Crouse Added: buildrom-devel/packages/filo/patches/sata-spinup-delay.patch =================================================================== --- buildrom-devel/packages/filo/patches/sata-spinup-delay.patch (rev 0) +++ buildrom-devel/packages/filo/patches/sata-spinup-delay.patch 2007-09-12 18:47:06 UTC (rev 22) @@ -0,0 +1,12 @@ +Index: main/filo.c +=================================================================== +--- svn/main/filo.c (revision 34) ++++ svn/main/filo.c (working copy) +@@ -60,6 +60,7 @@ + + /* Initialize */ + init(); ++ delay (5); + grub_main(); + return 0; + } From svn at openbios.org Wed Sep 12 20:48:54 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 12 Sep 2007 20:48:54 +0200 Subject: [LinuxBIOS] r23 - buildrom-devel/packages/filo Message-ID: Author: ward Date: 2007-09-12 20:48:54 +0200 (Wed, 12 Sep 2007) New Revision: 23 Modified: buildrom-devel/packages/filo/filo.mk Log: Add the sata spinup delay patch. Signed-off-by: Ward Vandewege Acked-by: Jordan Crouse Modified: buildrom-devel/packages/filo/filo.mk =================================================================== --- buildrom-devel/packages/filo/filo.mk 2007-09-12 18:47:06 UTC (rev 22) +++ buildrom-devel/packages/filo/filo.mk 2007-09-12 18:48:54 UTC (rev 23) @@ -8,6 +8,11 @@ FILO_PATCHES=$(PACKAGE_DIR)/filo/patches/make.patch +ifeq ($(CONFIG_PLATFORM_M57SLI),y) + FILO_PATCHES += $(PACKAGE_DIR)/filo/patches/sata-spinup-delay.patch +endif + + ifeq ($(CONFIG_VERBOSE),y) FILO_FETCH_LOG=/dev/stdout FILO_BUILD_LOG=/dev/stdout From svn at openbios.org Wed Sep 12 20:50:24 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 12 Sep 2007 20:50:24 +0200 Subject: [LinuxBIOS] r24 - buildrom-devel/packages/filo/conf Message-ID: Author: ward Date: 2007-09-12 20:50:24 +0200 (Wed, 12 Sep 2007) New Revision: 24 Added: buildrom-devel/packages/filo/conf/m57sli-Config Log: The filo config file for the m57sli. Signed-off-by: Ward Vandewege Acked-by: Jordan Crouse Added: buildrom-devel/packages/filo/conf/m57sli-Config =================================================================== --- buildrom-devel/packages/filo/conf/m57sli-Config (rev 0) +++ buildrom-devel/packages/filo/conf/m57sli-Config 2007-09-12 18:50:24 UTC (rev 24) @@ -0,0 +1,50 @@ +# Use grub instead of autoboot? +USE_GRUB = 1 +# Grub menu.lst path +MENULST_FILE = "hde1:/boot/grub/menu.lst" +# Driver for hard disk, CompactFlash, and CD-ROM on IDE bus +IDE_DISK = 1 +# Add a short delay when polling status registers +# (required on some broken SATA controllers) +IDE_DISK_POLL_DELAY = 1 +# Driver for USB Storage +USB_DISK = 1 +# VGA text console +VGA_CONSOLE = 1 +PC_KEYBOARD = 1 +# Enable the serial console +SERIAL_CONSOLE = 1 +# Serial console; real external serial port +SERIAL_IOBASE = 0x3f8 +SERIAL_SPEED = 115200 +# Filesystems +FSYS_EXT2FS = 1 +FSYS_ISO9660 = 1 +# Support for boot disk image in bootable CD-ROM (El Torito) +ELTORITO = 1 +# PCI support +SUPPORT_PCI = 1 +# Enable this to scan PCI busses above bus 0 +# AMD64 based boards do need this. +PCI_BRUTE_SCAN = 1 +# Loader for standard Linux kernel image, a.k.a. /vmlinuz +LINUX_LOADER = 1 + +# Debugging +#DEBUG_ALL = 1 +#DEBUG_ELFBOOT = 1 +#DEBUG_ELFNOTE = 1 +#DEBUG_LINUXBIOS = 1 +#DEBUG_MALLOC = 1 +#DEBUG_MULTIBOOT = 1 +#DEBUG_SEGMENT = 1 +#DEBUG_SYS_INFO = 1 +#DEBUG_TIMER = 1 +#DEBUG_BLOCKDEV = 1 +#DEBUG_PCI = 1 +#DEBUG_VIA_SOUND = 1 +#DEBUG_LINUXLOAD = 1 +#DEBUG_IDE = 1 +#DEBUG_USB = 1 +#DEBUG_ELTORITO = 1 + From ward at gnu.org Wed Sep 12 20:51:08 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 14:51:08 -0400 Subject: [LinuxBIOS] buildrom: filo patches for m57sli In-Reply-To: <20070906024554.GE23823@cosmic.amd.com> References: <20070905223308.GC23467@localdomain> <20070906024554.GE23823@cosmic.amd.com> Message-ID: <20070912185108.GE17001@localdomain> On Wed, Sep 05, 2007 at 08:45:54PM -0600, Jordan Crouse wrote: > On 05/09/07 18:33 -0400, Ward Vandewege wrote: > > This adds buildrom m57sli support for the filo bootloader. > > > > Signed-off-by: Ward Vandewege > Acked-by: Jordan CRouse r22, r23, r24. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From svn at openbios.org Wed Sep 12 20:53:43 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 12 Sep 2007 20:53:43 +0200 Subject: [LinuxBIOS] r25 - buildrom-devel/packages/linuxbios/patches Message-ID: Author: ward Date: 2007-09-12 20:53:43 +0200 (Wed, 12 Sep 2007) New Revision: 25 Added: buildrom-devel/packages/linuxbios/patches/m57sli-filo-Config.lb.patch Log: The m57sli-s4 LinuxBIOS Config.lb file for filo payload. Signed-off-by: Ward Vandewege Acked-by: Jordan Crouse Added: buildrom-devel/packages/linuxbios/patches/m57sli-filo-Config.lb.patch =================================================================== --- buildrom-devel/packages/linuxbios/patches/m57sli-filo-Config.lb.patch (rev 0) +++ buildrom-devel/packages/linuxbios/patches/m57sli-filo-Config.lb.patch 2007-09-12 18:53:43 UTC (rev 25) @@ -0,0 +1,97 @@ +Index: Config.lb +=================================================================== +--- LinuxBIOSv2/targets/gigabyte/m57sli/Config.lb-orig 2007-08-14 14:49:13.000000000 -0400 ++++ LinuxBIOSv2/targets/gigabyte/m57sli/Config.lb 2007-08-21 17:56:34.000000000 -0400 +@@ -22,83 +22,30 @@ + target m57sli + mainboard gigabyte/m57sli + +-# serengeti_leopard + romimage "normal" +-# 48K for SCSI FW +-# option ROM_SIZE = 475136 +-# 48K for SCSI FW and 48K for ATI ROM +-# option ROM_SIZE = 425984 +-# 64K for Etherboot +-# option ROM_SIZE = 458752 +-# 44k for atixx.rom +-# option ROM_SIZE = 479232 +- option USE_FAILOVER_IMAGE=0 ++ option USE_FAILOVER_IMAGE=0 + option USE_FALLBACK_IMAGE=0 +-# option ROM_IMAGE_SIZE=0x13800 +-# option ROM_IMAGE_SIZE=0x18800 + option ROM_IMAGE_SIZE=0x20000 +-# option ROM_IMAGE_SIZE=0x15800 + option XIP_ROM_SIZE=0x40000 + option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" +-# payload ../../../payloads/tg3--ide_disk.zelf +-# payload ../../../payloads/filo.elf +-# payload ../../../payloads/filo_mem.elf +-# payload ../../../payloads/filo.zelf +-# payload ../../../payloads/tg3--filo_hda2.zelf +-# payload ../../../payloads/tg3.zelf +-# payload ../../../../payloads/tg3_vga.zelf +-# payload ../../../../payloads/tg3--filo_hda2_vga.zelf +-# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf +-# payload ../../../../payloads/forcedeth--filo_hda2_vga.zelf +- payload ../../../../payloads/forcedeth--filo_hda2_vga_5_4_2_mcp55.zelf +-# payload ../../../payloads/tg3_com2.zelf +-# payload ../../../payloads/e1000--filo.zelf +-# payload ../../../payloads/tg3--e1000--filo.zelf +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf ++ payload ../payload.elf + end + + romimage "fallback" +- option USE_FAILOVER_IMAGE=0 ++ option USE_FAILOVER_IMAGE=0 + option USE_FALLBACK_IMAGE=1 +-# option ROM_IMAGE_SIZE=0x13800 +-# option ROM_IMAGE_SIZE=0x19800 + option ROM_IMAGE_SIZE=0x20000 +-# option ROM_IMAGE_SIZE=0x15800 + option XIP_ROM_SIZE=0x40000 + option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" +-# payload ../../../payloads/tg3--ide_disk.zelf +-# payload ../../../payloads/filo.elf +-# payload ../../../payloads/filo_mem.elf +-# payload ../../../payloads/filo.zelf +-# payload ../../../payloads/tg3--filo_hda2.zelf +-# payload ../../../payloads/tg3.zelf +-# payload ../../../../payloads/tg3_vga.zelf +-# payload ../../../../payloads/memtest +-# payload ../../../../payloads/e1000_vga.zelf +-# payload ../../../../payloads/tg3--filo_hda2_vga.zelf +-# payload ../../../../payloads/filo_hda.zelf +-# payload ../../../../payloads/adlo.elf +-# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf +-# payload ../../../../payloads/forcedeth_mcp55_filo_hda2.zelf +- payload ../../../../payloads/forcedeth--filo_hda2_vga_5_4_2_mcp55.zelf +-# payload ../../../../payloads/forcedeth--filo_hda2_vga.zelf +-# payload ../../../payloads/tg3_com2.zelf +-# payload ../../../payloads/e1000--filo.zelf +-# payload ../../../payloads/tg3--e1000--filo.zelf +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf ++ payload ../payload.elf + end + + romimage "failover" +- option USE_FAILOVER_IMAGE=1 +- option USE_FALLBACK_IMAGE=0 +- option ROM_IMAGE_SIZE=FAILOVER_SIZE +- option XIP_ROM_SIZE=FAILOVER_SIZE +- option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Failover" ++ option USE_FAILOVER_IMAGE=1 ++ option USE_FALLBACK_IMAGE=0 ++ option ROM_IMAGE_SIZE=FAILOVER_SIZE ++ option XIP_ROM_SIZE=FAILOVER_SIZE ++ option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Failover" + end + +-#buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" + buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" "failover" From svn at openbios.org Wed Sep 12 21:10:26 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 12 Sep 2007 21:10:26 +0200 Subject: [LinuxBIOS] r26 - buildrom-devel/packages/linuxbios/patches Message-ID: Author: ward Date: 2007-09-12 21:10:26 +0200 (Wed, 12 Sep 2007) New Revision: 26 Added: buildrom-devel/packages/linuxbios/patches/m57sli-kernel-and-lab-Config.lb.patch Log: The m57sli-s4 LinuxBIOS Config.lb file for LAB/kernel payload. Signed-off-by: Ward Vandewege Acked-by: Jordan CRouse Added: buildrom-devel/packages/linuxbios/patches/m57sli-kernel-and-lab-Config.lb.patch =================================================================== --- buildrom-devel/packages/linuxbios/patches/m57sli-kernel-and-lab-Config.lb.patch (rev 0) +++ buildrom-devel/packages/linuxbios/patches/m57sli-kernel-and-lab-Config.lb.patch 2007-09-12 19:10:26 UTC (rev 26) @@ -0,0 +1,101 @@ +--- LinuxBIOSv2/targets/gigabyte/m57sli/Config.lb-orig 2007-08-14 14:49:13.000000000 -0400 ++++ LinuxBIOSv2/targets/gigabyte/m57sli/Config.lb 2007-08-21 17:56:34.000000000 -0400 +@@ -19,86 +19,32 @@ + ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + ## + ++# Sample config file for ++ + target m57sli + mainboard gigabyte/m57sli + +-# serengeti_leopard +-romimage "normal" +-# 48K for SCSI FW +-# option ROM_SIZE = 475136 +-# 48K for SCSI FW and 48K for ATI ROM +-# option ROM_SIZE = 425984 +-# 64K for Etherboot +-# option ROM_SIZE = 458752 +-# 44k for atixx.rom +-# option ROM_SIZE = 479232 +- option USE_FAILOVER_IMAGE=0 +- option USE_FALLBACK_IMAGE=0 +-# option ROM_IMAGE_SIZE=0x13800 +-# option ROM_IMAGE_SIZE=0x18800 +- option ROM_IMAGE_SIZE=0x20000 +-# option ROM_IMAGE_SIZE=0x15800 +- option XIP_ROM_SIZE=0x40000 +- option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" +-# payload ../../../payloads/tg3--ide_disk.zelf +-# payload ../../../payloads/filo.elf +-# payload ../../../payloads/filo_mem.elf +-# payload ../../../payloads/filo.zelf +-# payload ../../../payloads/tg3--filo_hda2.zelf +-# payload ../../../payloads/tg3.zelf +-# payload ../../../../payloads/tg3_vga.zelf +-# payload ../../../../payloads/tg3--filo_hda2_vga.zelf +-# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf +-# payload ../../../../payloads/forcedeth--filo_hda2_vga.zelf +- payload ../../../../payloads/forcedeth--filo_hda2_vga_5_4_2_mcp55.zelf +-# payload ../../../payloads/tg3_com2.zelf +-# payload ../../../payloads/e1000--filo.zelf +-# payload ../../../payloads/tg3--e1000--filo.zelf +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf +-end ++option ROM_SIZE=0x100000 ++option FALLBACK_SIZE=(ROM_SIZE-0x1000) + + romimage "fallback" +- option USE_FAILOVER_IMAGE=0 ++ option USE_FAILOVER_IMAGE=0 + option USE_FALLBACK_IMAGE=1 +-# option ROM_IMAGE_SIZE=0x13800 +-# option ROM_IMAGE_SIZE=0x19800 +- option ROM_IMAGE_SIZE=0x20000 +-# option ROM_IMAGE_SIZE=0x15800 ++ option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 ++ option CONFIG_PRECOMPRESSED_PAYLOAD=1 ++ option ROM_IMAGE_SIZE=0x17000 + option XIP_ROM_SIZE=0x40000 + option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" +-# payload ../../../payloads/tg3--ide_disk.zelf +-# payload ../../../payloads/filo.elf +-# payload ../../../payloads/filo_mem.elf +-# payload ../../../payloads/filo.zelf +-# payload ../../../payloads/tg3--filo_hda2.zelf +-# payload ../../../payloads/tg3.zelf +-# payload ../../../../payloads/tg3_vga.zelf +-# payload ../../../../payloads/memtest +-# payload ../../../../payloads/e1000_vga.zelf +-# payload ../../../../payloads/tg3--filo_hda2_vga.zelf +-# payload ../../../../payloads/filo_hda.zelf +-# payload ../../../../payloads/adlo.elf +-# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.zelf +-# payload ../../../../payloads/forcedeth_mcp55_filo_hda2.zelf +- payload ../../../../payloads/forcedeth--filo_hda2_vga_5_4_2_mcp55.zelf +-# payload ../../../../payloads/forcedeth--filo_hda2_vga.zelf +-# payload ../../../payloads/tg3_com2.zelf +-# payload ../../../payloads/e1000--filo.zelf +-# payload ../../../payloads/tg3--e1000--filo.zelf +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_5.3.zelf +-# payload ../../../payloads/tg3--eepro100--e1000--filo_hda2_com2.zelf ++ payload ../payload.elf + end + + romimage "failover" +- option USE_FAILOVER_IMAGE=1 ++ option USE_FAILOVER_IMAGE=1 + option USE_FALLBACK_IMAGE=0 + option ROM_IMAGE_SIZE=FAILOVER_SIZE + option XIP_ROM_SIZE=FAILOVER_SIZE + option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Failover" + end + +-#buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" +-buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" "failover" ++ ++buildrom ./linuxbios.rom ROM_SIZE "fallback" "failover" From ward at gnu.org Wed Sep 12 21:10:55 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 15:10:55 -0400 Subject: [LinuxBIOS] buildrom: LinuxBIOS payload Config.lb files In-Reply-To: <20070906024625.GF23823@cosmic.amd.com> References: <20070905223921.GD23467@localdomain> <20070906024625.GF23823@cosmic.amd.com> Message-ID: <20070912191055.GF17001@localdomain> On Wed, Sep 05, 2007 at 08:46:25PM -0600, Jordan Crouse wrote: > Acked by: Jordan CRouse > > On 05/09/07 18:39 -0400, Ward Vandewege wrote: > > Two new patch files for LAB/kernel and FILO payload respectively. r25 and r26. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From rminnich at gmail.com Wed Sep 12 21:12:29 2007 From: rminnich at gmail.com (ron minnich) Date: Wed, 12 Sep 2007 12:12:29 -0700 Subject: [LinuxBIOS] buildrom: LinuxBIOS payload Config.lb files In-Reply-To: <20070912191055.GF17001@localdomain> References: <20070905223921.GD23467@localdomain> <20070906024625.GF23823@cosmic.amd.com> <20070912191055.GF17001@localdomain> Message-ID: <13426df10709121212g34bb7bd1x2d044e21e50ea90e@mail.gmail.com> Ward, can we get kernel and all in 1 MB at this point? thanks ron From svn at openbios.org Wed Sep 12 21:12:53 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 12 Sep 2007 21:12:53 +0200 Subject: [LinuxBIOS] r27 - buildrom-devel/packages/linuxbios Message-ID: Author: ward Date: 2007-09-12 21:12:53 +0200 (Wed, 12 Sep 2007) New Revision: 27 Added: buildrom-devel/packages/linuxbios/m57sli-linuxbios.mk Log: Add the makefile for the m57sli LinuxBIOS build. Signed-off-by: Ward Vandewege Acked-by: Jordan Crouse Added: buildrom-devel/packages/linuxbios/m57sli-linuxbios.mk =================================================================== --- buildrom-devel/packages/linuxbios/m57sli-linuxbios.mk (rev 0) +++ buildrom-devel/packages/linuxbios/m57sli-linuxbios.mk 2007-09-12 19:12:53 UTC (rev 27) @@ -0,0 +1,44 @@ +# This is the Generic LinuxBIOS target + +ifeq ($(CONFIG_PLATFORM),y) +ifeq ($(LINUXBIOS_TAG),) +$(error You need to specify a version to pull in your platform config) +endif +endif + +LINUXBIOS_PATCHES= + +ifeq ($(CONFIG_PAYLOAD_FILO),y) + LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/m57sli-filo-Config.lb.patch +endif + +ifeq ($(CONFIG_PAYLOAD_KERNEL),y) + LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/m57sli-kernel-and-lab-Config.lb.patch +endif + +ifeq ($(CONFIG_PAYLOAD_LAB),y) + LINUXBIOS_PATCHES += $(PACKAGE_DIR)/linuxbios/patches/m57sli-kernel-and-lab-Config.lb.patch +endif + + +LINUXBIOS_BASE_DIR=svn +LINUXBIOS_URL=svn://openbios.org/repos/trunk/LinuxBIOSv2 +LINUXBIOS_TARBALL=linuxbios-svn-$(LINUXBIOS_TAG).tar.gz +LINUXBIOS_PAYLOAD_TARGET=$(LINUXBIOS_BUILD_DIR)/payload.elf +TARGET_ROM = $(LINUXBIOS_VENDOR)-$(LINUXBIOS_BOARD).rom + +include $(PACKAGE_DIR)/linuxbios/linuxbios.inc + +$(SOURCE_DIR)/$(LINUXBIOS_TARBALL): + @ echo "Fetching the LinuxBIOS code..." + @ mkdir -p $(SOURCE_DIR)/linuxbios + @ $(BIN_DIR)/fetchsvn.sh $(LINUXBIOS_URL) $(SOURCE_DIR)/linuxbios \ + $(LINUXBIOS_TAG) $(SOURCE_DIR)/$(LINUXBIOS_TARBALL) \ + > $(LINUXBIOS_FETCH_LOG) 2>&1 + +$(OUTPUT_DIR)/$(TARGET_ROM): $(LINUXBIOS_OUTPUT) + @ cat $(LINUXBIOS_OUTPUT) > $@ + +linuxbios: $(OUTPUT_DIR)/$(TARGET_ROM) +linuxbios-clean: generic-linuxbios-clean +linuxbios-distclean: generic-linuxbios-distclean From ward at gnu.org Wed Sep 12 21:13:20 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 15:13:20 -0400 Subject: [LinuxBIOS] buildrom: packages/linuxbios/m57sli-linuxbios.mk In-Reply-To: <20070906025024.GH23823@cosmic.amd.com> References: <20070905224404.GF23467@localdomain> <20070906025024.GH23823@cosmic.amd.com> Message-ID: <20070912191320.GG17001@localdomain> On Wed, Sep 05, 2007 at 08:50:24PM -0600, Jordan Crouse wrote: > On 05/09/07 18:44 -0400, Ward Vandewege wrote: > > > > > > -- > > Ward Vandewege > > Free Software Foundation - Senior System Administrator > > > > > Add the makefile for the m57sli LinuxBIOS build. > > > > Signed-off-by: Ward Vandewege > > Acked-by: Jordan Crouse r27 Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From svn at openbios.org Wed Sep 12 21:17:14 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 12 Sep 2007 21:17:14 +0200 Subject: [LinuxBIOS] r28 - buildrom-devel/packages/kernel/conf Message-ID: Author: ward Date: 2007-09-12 21:17:14 +0200 (Wed, 12 Sep 2007) New Revision: 28 Added: buildrom-devel/packages/kernel/conf/defconfig-m57sli Log: The stripped down m57sli-s4 kernel config. Printk is disabled which makes the kernel a lot smaller but makes debugging more difficult. To debug, disable module support and enable printk support, which will still make the kernel fit in a 1MB rom for LAB. Signed-off-by: Ward Vandewege Acked-by: Ronald G. Minnich Added: buildrom-devel/packages/kernel/conf/defconfig-m57sli =================================================================== --- buildrom-devel/packages/kernel/conf/defconfig-m57sli (rev 0) +++ buildrom-devel/packages/kernel/conf/defconfig-m57sli 2007-09-12 19:17:14 UTC (rev 28) @@ -0,0 +1,1208 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.22.2 +# Wed Sep 5 17:08:35 2007 +# +CONFIG_X86_32=y +CONFIG_GENERIC_TIME=y +CONFIG_CLOCKSOURCE_WATCHDOG=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_SEMAPHORE_SLEEPERS=y +CONFIG_X86=y +CONFIG_MMU=y +CONFIG_ZONE_DMA=y +CONFIG_QUICKLIST=y +CONFIG_GENERIC_ISA_DMA=y +CONFIG_GENERIC_IOMAP=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_DMI=y +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" + +# +# Code maturity level options +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_LOCK_KERNEL=y +CONFIG_INIT_ENV_ARG_LIMIT=32 + +# +# General setup +# +CONFIG_LOCALVERSION="" +# CONFIG_LOCALVERSION_AUTO is not set +# CONFIG_SWAP is not set +# CONFIG_SYSVIPC is not set +# CONFIG_POSIX_MQUEUE is not set +# CONFIG_BSD_PROCESS_ACCT is not set +# CONFIG_TASKSTATS is not set +# CONFIG_UTS_NS is not set +# CONFIG_AUDIT is not set +# CONFIG_IKCONFIG is not set +CONFIG_LOG_BUF_SHIFT=17 +# CONFIG_SYSFS_DEPRECATED is not set +# CONFIG_RELAY is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE="" +# CONFIG_SYSENTER is not set +# CONFIG_AIO is not set +# CONFIG_XATTR is not set +# CONFIG_FILE_LOCKING is not set +# CONFIG_ETHTOOL is not set +# CONFIG_INETPEER is not set +# CONFIG_NET_DEV_MULTICAST is not set +# CONFIG_MEASURE_INLINES is not set +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +# CONFIG_UID16 is not set +# CONFIG_SYSCTL_SYSCALL is not set +# CONFIG_KALLSYMS is not set +CONFIG_HOTPLUG=y +# CONFIG_PRINTK_FUNC is not set +# CONFIG_BUG is not set +# CONFIG_ELF_CORE is not set +CONFIG_PANIC=y +CONFIG_FULL_PANIC=y +# CONFIG_BASE_FULL is not set +CONFIG_NET_SMALL=y +CONFIG_FUTEX=y +CONFIG_ANON_INODES=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_TIMERFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +# CONFIG_CRC32_TABLES is not set +# CONFIG_VM_EVENT_COUNTERS is not set +# CONFIG_SLAB is not set +# CONFIG_SLUB is not set +CONFIG_SLOB=y +CONFIG_CC_FUNIT_AT_A_TIME=y +CONFIG_LINUXTINY_DO_UNINLINE=y +CONFIG_BINFMT_SCRIPT=y +CONFIG_MAX_SWAPFILES_SHIFT=0 +CONFIG_NR_LDISCS=2 +CONFIG_MAX_USER_RT_PRIO=5 +CONFIG_RT_MUTEXES=y +CONFIG_CRC32_CALC=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=1 + +# +# Loadable module support +# +# CONFIG_MODULES is not set + +# +# Block layer +# +CONFIG_BLOCK=y +# CONFIG_LBD is not set +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +# CONFIG_IOSCHED_DEADLINE is not set +# CONFIG_IOSCHED_CFQ is not set +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="anticipatory" + +# +# Processor type and features +# +# CONFIG_TICK_ONESHOT is not set +# CONFIG_NO_HZ is not set +# CONFIG_HIGH_RES_TIMERS is not set +# CONFIG_SMP is not set +CONFIG_X86_PC=y +# CONFIG_X86_ELAN is not set +# CONFIG_X86_VOYAGER is not set +# CONFIG_X86_NUMAQ is not set +# CONFIG_X86_SUMMIT is not set +# CONFIG_X86_BIGSMP is not set +# CONFIG_X86_VISWS is not set +# CONFIG_X86_GENERICARCH is not set +# CONFIG_X86_ES7000 is not set +# CONFIG_PARAVIRT is not set +CONFIG_M386=y +# CONFIG_M486 is not set +# CONFIG_M586 is not set +# CONFIG_M586TSC is not set +# CONFIG_M586MMX is not set +# CONFIG_M686 is not set +# CONFIG_MPENTIUMII is not set +# CONFIG_MPENTIUMIII is not set +# CONFIG_MPENTIUMM is not set +# CONFIG_MCORE2 is not set +# CONFIG_MPENTIUM4 is not set +# CONFIG_MK6 is not set +# CONFIG_MK7 is not set +# CONFIG_MK8 is not set +# CONFIG_MCRUSOE is not set +# CONFIG_MEFFICEON is not set +# CONFIG_MWINCHIPC6 is not set +# CONFIG_MWINCHIP2 is not set +# CONFIG_MWINCHIP3D is not set +# CONFIG_MGEODEGX1 is not set +# CONFIG_MGEODE_LX is not set +# CONFIG_MCYRIXIII is not set +# CONFIG_MVIAC3_2 is not set +# CONFIG_MVIAC7 is not set +# CONFIG_X86_GENERIC is not set +CONFIG_X86_L1_CACHE_SHIFT=4 +CONFIG_RWSEM_GENERIC_SPINLOCK=y +# CONFIG_ARCH_HAS_ILOG2_U32 is not set +# CONFIG_ARCH_HAS_ILOG2_U64 is not set +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_X86_PPRO_FENCE=y +CONFIG_X86_F00F_BUG=y +CONFIG_X86_MINIMUM_CPU_MODEL=0 +CONFIG_HPET_TIMER=y +# CONFIG_PREEMPT_NONE is not set +# CONFIG_PREEMPT_VOLUNTARY is not set +CONFIG_PREEMPT=y +CONFIG_PREEMPT_BKL=y +CONFIG_X86_UP_APIC=y +CONFIG_X86_UP_IOAPIC=y +CONFIG_X86_LOCAL_APIC=y +CONFIG_X86_IO_APIC=y +# CONFIG_X86_MCE is not set +# CONFIG_VM86 is not set +# CONFIG_TOSHIBA is not set +# CONFIG_I8K is not set +# CONFIG_X86_REBOOTFIXUPS is not set +# CONFIG_MICROCODE is not set +# CONFIG_X86_MSR is not set +# CONFIG_X86_CPUID is not set + +# +# Firmware Drivers +# +# CONFIG_EDD is not set +# CONFIG_DELL_RBU is not set +# CONFIG_DCDBAS is not set +CONFIG_NOHIGHMEM=y +# CONFIG_HIGHMEM4G is not set +# CONFIG_HIGHMEM64G is not set +CONFIG_VMSPLIT_3G=y +# CONFIG_VMSPLIT_3G_OPT is not set +# CONFIG_VMSPLIT_2G is not set +# CONFIG_VMSPLIT_2G_OPT is not set +# CONFIG_VMSPLIT_1G is not set +CONFIG_PAGE_OFFSET=0xC0000000 +CONFIG_ARCH_FLATMEM_ENABLE=y +CONFIG_ARCH_SPARSEMEM_ENABLE=y +CONFIG_ARCH_SELECT_MEMORY_MODEL=y +CONFIG_ARCH_POPULATES_NODE_MAP=y +CONFIG_SELECT_MEMORY_MODEL=y +CONFIG_FLATMEM_MANUAL=y +# CONFIG_DISCONTIGMEM_MANUAL is not set +# CONFIG_SPARSEMEM_MANUAL is not set +CONFIG_FLATMEM=y +CONFIG_FLAT_NODE_MEM_MAP=y +CONFIG_SPARSEMEM_STATIC=y +CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_RESOURCES_64BIT is not set +CONFIG_ZONE_DMA_FLAG=1 +CONFIG_NR_QUICK=1 +# CONFIG_MATH_EMULATION is not set +# CONFIG_MTRR is not set +# CONFIG_SECCOMP is not set +# CONFIG_HZ_100 is not set +CONFIG_HZ_250=y +# CONFIG_HZ_300 is not set +# CONFIG_HZ_1000 is not set +CONFIG_HZ=250 +CONFIG_KEXEC=y +CONFIG_PHYSICAL_START=0x100000 +# CONFIG_RELOCATABLE is not set +CONFIG_PHYSICAL_ALIGN=0x100000 +CONFIG_COMPAT_VDSO=y + +# +# Power management options (ACPI, APM) +# +# CONFIG_PM is not set + +# +# CPU Frequency scaling +# +# CONFIG_CPU_FREQ is not set + +# +# Bus options (PCI, PCMCIA, EISA, MCA, ISA) +# +CONFIG_PCI=y +# CONFIG_PCI_GOBIOS is not set +# CONFIG_PCI_GOMMCONFIG is not set +# CONFIG_PCI_GODIRECT is not set +CONFIG_PCI_GOANY=y +CONFIG_PCI_BIOS=y +CONFIG_PCI_DIRECT=y +# CONFIG_PCIEPORTBUS is not set +CONFIG_ARCH_SUPPORTS_MSI=y +# CONFIG_PCI_MSI is not set +CONFIG_HT_IRQ=y +CONFIG_ISA_DMA_API=y +# CONFIG_ISA is not set +# CONFIG_MCA is not set +# CONFIG_SCx200 is not set + +# +# PCCARD (PCMCIA/CardBus) support +# +# CONFIG_PCCARD is not set +# CONFIG_HOTPLUG_PCI is not set + +# +# Executable file formats +# +CONFIG_BINFMT_ELF=y +# CONFIG_BINFMT_AOUT is not set +# CONFIG_BINFMT_MISC is not set + +# +# Networking +# +CONFIG_NET=y + +# +# Networking options +# +# CONFIG_PACKET is not set +CONFIG_UNIX=y +# CONFIG_NET_KEY is not set +CONFIG_INET=y +# CONFIG_IP_MULTICAST is not set +# CONFIG_IP_ADVANCED_ROUTER is not set +CONFIG_IP_FIB_HASH=y +# CONFIG_IP_PNP is not set +# CONFIG_NET_IPIP is not set +# CONFIG_NET_IPGRE is not set +# CONFIG_ARPD is not set +CONFIG_SYN_COOKIES=y +# CONFIG_INET_AH is not set +# CONFIG_INET_ESP is not set +# CONFIG_INET_IPCOMP is not set +# CONFIG_INET_XFRM_TUNNEL is not set +# CONFIG_INET_TUNNEL is not set +# CONFIG_INET_XFRM_MODE_TRANSPORT is not set +# CONFIG_INET_XFRM_MODE_TUNNEL is not set +# CONFIG_INET_XFRM_MODE_BEET is not set +# CONFIG_INET_DIAG is not set +# CONFIG_TCP_CONG_ADVANCED is not set +CONFIG_TCP_CONG_CUBIC=y +CONFIG_DEFAULT_TCP_CONG="cubic" +# CONFIG_TCP_MD5SIG is not set +# CONFIG_IPV6 is not set +# CONFIG_INET6_XFRM_TUNNEL is not set +# CONFIG_INET6_TUNNEL is not set +# CONFIG_NETWORK_SECMARK is not set +# CONFIG_NETFILTER is not set +# CONFIG_IP_DCCP is not set +# CONFIG_IP_SCTP is not set +# CONFIG_TIPC is not set +# CONFIG_ATM is not set +# CONFIG_BRIDGE is not set +# CONFIG_VLAN_8021Q is not set +# CONFIG_DECNET is not set +# CONFIG_LLC2 is not set +# CONFIG_IPX is not set +# CONFIG_ATALK is not set +# CONFIG_X25 is not set +# CONFIG_LAPB is not set +# CONFIG_ECONET is not set +# CONFIG_WAN_ROUTER is not set + +# +# QoS and/or fair queueing +# +# CONFIG_NET_SCHED is not set + +# +# Network testing +# +# CONFIG_NET_PKTGEN is not set +# CONFIG_HAMRADIO is not set +# CONFIG_IRDA is not set +# CONFIG_BT is not set +# CONFIG_AF_RXRPC is not set + +# +# Wireless +# +# CONFIG_CFG80211 is not set +# CONFIG_WIRELESS_EXT is not set +# CONFIG_MAC80211 is not set +# CONFIG_IEEE80211 is not set +# CONFIG_RFKILL is not set + +# +# Device Drivers +# + +# +# Generic Driver Options +# +CONFIG_STANDALONE=y +CONFIG_PREVENT_FIRMWARE_BUILD=y +# CONFIG_FW_LOADER is not set +# CONFIG_SYS_HYPERVISOR is not set + +# +# Connector - unified userspace <-> kernelspace linker +# +# CONFIG_CONNECTOR is not set +# CONFIG_MTD is not set + +# +# Parallel port support +# +# CONFIG_PARPORT is not set + +# +# Plug and Play support +# +# CONFIG_PNPACPI is not set + +# +# Block devices +# +# CONFIG_BLK_DEV_FD is not set +# CONFIG_BLK_CPQ_DA is not set +# CONFIG_BLK_CPQ_CISS_DA is not set +# CONFIG_BLK_DEV_DAC960 is not set +# CONFIG_BLK_DEV_UMEM is not set +# CONFIG_BLK_DEV_COW_COMMON is not set +CONFIG_BLK_DEV_LOOP=y +# CONFIG_BLK_DEV_CRYPTOLOOP is not set +# CONFIG_BLK_DEV_NBD is not set +# CONFIG_BLK_DEV_SX8 is not set +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_COUNT=16 +CONFIG_BLK_DEV_RAM_SIZE=65536 +CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024 +# CONFIG_CDROM_PKTCDVD is not set +# CONFIG_ATA_OVER_ETH is not set + +# +# Misc devices +# +# CONFIG_IBM_ASM is not set +# CONFIG_PHANTOM is not set +# CONFIG_SGI_IOC4 is not set +# CONFIG_TIFM_CORE is not set +CONFIG_IDE=y +CONFIG_IDE_MAX_HWIFS=4 +CONFIG_BLK_DEV_IDE=y + +# +# Please see Documentation/ide.txt for help/info on IDE drives +# +# CONFIG_BLK_DEV_IDE_SATA is not set +# CONFIG_BLK_DEV_HD_IDE is not set +# CONFIG_BLK_DEV_IDEDISK is not set +# CONFIG_IDEDISK_MULTI_MODE is not set +CONFIG_BLK_DEV_IDECD=y +# CONFIG_BLK_DEV_IDETAPE is not set +# CONFIG_BLK_DEV_IDEFLOPPY is not set +# CONFIG_BLK_DEV_IDESCSI is not set +# CONFIG_IDE_TASK_IOCTL is not set +# CONFIG_IDE_PROC_FS is not set + +# +# IDE chipset support/bugfixes +# +CONFIG_IDE_GENERIC=y +# CONFIG_BLK_DEV_CMD640 is not set +CONFIG_BLK_DEV_IDEPCI=y +CONFIG_IDEPCI_SHARE_IRQ=y +CONFIG_IDEPCI_PCIBUS_ORDER=y +# CONFIG_BLK_DEV_OFFBOARD is not set +CONFIG_BLK_DEV_GENERIC=y +# CONFIG_BLK_DEV_OPTI621 is not set +# CONFIG_BLK_DEV_RZ1000 is not set +CONFIG_BLK_DEV_IDEDMA_PCI=y +# CONFIG_BLK_DEV_IDEDMA_FORCED is not set +# CONFIG_IDEDMA_ONLYDISK is not set +# CONFIG_BLK_DEV_AEC62XX is not set +# CONFIG_BLK_DEV_ALI15X3 is not set +CONFIG_BLK_DEV_AMD74XX=y +# CONFIG_BLK_DEV_ATIIXP is not set +# CONFIG_BLK_DEV_CMD64X is not set +# CONFIG_BLK_DEV_TRIFLEX is not set +# CONFIG_BLK_DEV_CY82C693 is not set +# CONFIG_BLK_DEV_CS5520 is not set +# CONFIG_BLK_DEV_CS5530 is not set +# CONFIG_BLK_DEV_CS5535 is not set +# CONFIG_BLK_DEV_HPT34X is not set +# CONFIG_BLK_DEV_HPT366 is not set +# CONFIG_BLK_DEV_JMICRON is not set +# CONFIG_BLK_DEV_SC1200 is not set +# CONFIG_BLK_DEV_PIIX is not set +# CONFIG_BLK_DEV_IT8213 is not set +# CONFIG_BLK_DEV_IT821X is not set +# CONFIG_BLK_DEV_NS87415 is not set +# CONFIG_BLK_DEV_PDC202XX_OLD is not set +# CONFIG_BLK_DEV_PDC202XX_NEW is not set +# CONFIG_BLK_DEV_SVWKS is not set +# CONFIG_BLK_DEV_SIIMAGE is not set +# CONFIG_BLK_DEV_SIS5513 is not set +# CONFIG_BLK_DEV_SLC90E66 is not set +# CONFIG_BLK_DEV_TRM290 is not set +# CONFIG_BLK_DEV_VIA82CXXX is not set +# CONFIG_BLK_DEV_TC86C001 is not set +# CONFIG_IDE_ARM is not set +CONFIG_BLK_DEV_IDEDMA=y +# CONFIG_IDEDMA_IVB is not set +# CONFIG_BLK_DEV_HD is not set + +# +# SCSI device support +# +# CONFIG_RAID_ATTRS is not set +CONFIG_SCSI=y +# CONFIG_SCSI_TGT is not set +# CONFIG_SCSI_NETLINK is not set +# CONFIG_SCSI_PROC_FS is not set + +# +# SCSI support type (disk, tape, CD-ROM) +# +CONFIG_BLK_DEV_SD=y +# CONFIG_CHR_DEV_ST is not set +# CONFIG_CHR_DEV_OSST is not set +# CONFIG_BLK_DEV_SR is not set +# CONFIG_CHR_DEV_SG is not set +# CONFIG_CHR_DEV_SCH is not set + +# +# Some SCSI devices (e.g. CD jukebox) support multiple LUNs +# +# CONFIG_SCSI_MULTI_LUN is not set +# CONFIG_SCSI_CONSTANTS is not set +# CONFIG_SCSI_LOGGING is not set +# CONFIG_SCSI_SCAN_ASYNC is not set + +# +# SCSI Transports +# +# CONFIG_SCSI_SPI_ATTRS is not set +# CONFIG_SCSI_FC_ATTRS is not set +# CONFIG_SCSI_ISCSI_ATTRS is not set +# CONFIG_SCSI_SAS_ATTRS is not set +# CONFIG_SCSI_SAS_LIBSAS is not set + +# +# SCSI low-level drivers +# +# CONFIG_ISCSI_TCP is not set +# CONFIG_BLK_DEV_3W_XXXX_RAID is not set +# CONFIG_SCSI_3W_9XXX is not set +# CONFIG_SCSI_ACARD is not set +# CONFIG_SCSI_AACRAID is not set +# CONFIG_SCSI_AIC7XXX is not set +# CONFIG_SCSI_AIC7XXX_OLD is not set +# CONFIG_SCSI_AIC79XX is not set +# CONFIG_SCSI_AIC94XX is not set +# CONFIG_SCSI_DPT_I2O is not set +# CONFIG_SCSI_ADVANSYS is not set +# CONFIG_SCSI_ARCMSR is not set +# CONFIG_MEGARAID_NEWGEN is not set +# CONFIG_MEGARAID_LEGACY is not set +# CONFIG_MEGARAID_SAS is not set +# CONFIG_SCSI_HPTIOP is not set +# CONFIG_SCSI_BUSLOGIC is not set +# CONFIG_SCSI_DMX3191D is not set +# CONFIG_SCSI_EATA is not set +# CONFIG_SCSI_FUTURE_DOMAIN is not set +# CONFIG_SCSI_GDTH is not set +# CONFIG_SCSI_IPS is not set +# CONFIG_SCSI_INITIO is not set +# CONFIG_SCSI_INIA100 is not set +# CONFIG_SCSI_STEX is not set +# CONFIG_SCSI_SYM53C8XX_2 is not set +# CONFIG_SCSI_IPR is not set +# CONFIG_SCSI_QLOGIC_1280 is not set +# CONFIG_SCSI_QLA_FC is not set +# CONFIG_SCSI_QLA_ISCSI is not set +# CONFIG_SCSI_LPFC is not set +# CONFIG_SCSI_DC395x is not set +# CONFIG_SCSI_DC390T is not set +# CONFIG_SCSI_NSP32 is not set +# CONFIG_SCSI_DEBUG is not set +# CONFIG_SCSI_SRP is not set +CONFIG_ATA=y +# CONFIG_ATA_NONSTANDARD is not set +# CONFIG_SATA_AHCI is not set +# CONFIG_SATA_SVW is not set +# CONFIG_ATA_PIIX is not set +# CONFIG_SATA_MV is not set +CONFIG_SATA_NV=y +# CONFIG_PDC_ADMA is not set +# CONFIG_SATA_QSTOR is not set +# CONFIG_SATA_PROMISE is not set +# CONFIG_SATA_SX4 is not set +# CONFIG_SATA_SIL is not set +# CONFIG_SATA_SIL24 is not set +# CONFIG_SATA_SIS is not set +# CONFIG_SATA_ULI is not set +# CONFIG_SATA_VIA is not set +# CONFIG_SATA_VITESSE is not set +# CONFIG_SATA_INIC162X is not set +# CONFIG_PATA_ALI is not set +# CONFIG_PATA_AMD is not set +# CONFIG_PATA_ARTOP is not set +# CONFIG_PATA_ATIIXP is not set +# CONFIG_PATA_CMD640_PCI is not set +# CONFIG_PATA_CMD64X is not set +# CONFIG_PATA_CS5520 is not set +# CONFIG_PATA_CS5530 is not set +# CONFIG_PATA_CS5535 is not set +# CONFIG_PATA_CYPRESS is not set +# CONFIG_PATA_EFAR is not set +# CONFIG_ATA_GENERIC is not set +# CONFIG_PATA_HPT366 is not set +# CONFIG_PATA_HPT37X is not set +# CONFIG_PATA_HPT3X2N is not set +# CONFIG_PATA_HPT3X3 is not set +# CONFIG_PATA_IT821X is not set +# CONFIG_PATA_IT8213 is not set +# CONFIG_PATA_JMICRON is not set +# CONFIG_PATA_TRIFLEX is not set +# CONFIG_PATA_MARVELL is not set +# CONFIG_PATA_MPIIX is not set +# CONFIG_PATA_OLDPIIX is not set +# CONFIG_PATA_NETCELL is not set +# CONFIG_PATA_NS87410 is not set +# CONFIG_PATA_OPTI is not set +# CONFIG_PATA_OPTIDMA is not set +# CONFIG_PATA_PDC_OLD is not set +# CONFIG_PATA_RADISYS is not set +# CONFIG_PATA_RZ1000 is not set +# CONFIG_PATA_SC1200 is not set +# CONFIG_PATA_SERVERWORKS is not set +# CONFIG_PATA_PDC2027X is not set +# CONFIG_PATA_SIL680 is not set +# CONFIG_PATA_SIS is not set +# CONFIG_PATA_VIA is not set +# CONFIG_PATA_WINBOND is not set +# CONFIG_PATA_PLATFORM is not set + +# +# Multi-device support (RAID and LVM) +# +# CONFIG_MD is not set + +# +# Fusion MPT device support +# +# CONFIG_FUSION is not set +# CONFIG_FUSION_SPI is not set +# CONFIG_FUSION_FC is not set +# CONFIG_FUSION_SAS is not set + +# +# IEEE 1394 (FireWire) support +# +# CONFIG_FIREWIRE is not set +# CONFIG_IEEE1394 is not set + +# +# I2O device support +# +# CONFIG_I2O is not set +# CONFIG_MACINTOSH_DRIVERS is not set + +# +# Network device support +# +CONFIG_NETDEVICES=y +CONFIG_DUMMY=y +# CONFIG_BONDING is not set +# CONFIG_EQUALIZER is not set +# CONFIG_TUN is not set +# CONFIG_ARCNET is not set +# CONFIG_PHYLIB is not set + +# +# Ethernet (10 or 100Mbit) +# +CONFIG_NET_ETHERNET=y +CONFIG_MII=y +# CONFIG_HAPPYMEAL is not set +# CONFIG_SUNGEM is not set +# CONFIG_CASSINI is not set +# CONFIG_NET_VENDOR_3COM is not set + +# +# Tulip family network device support +# +# CONFIG_NET_TULIP is not set +# CONFIG_HP100 is not set +CONFIG_NET_PCI=y +# CONFIG_PCNET32 is not set +# CONFIG_AMD8111_ETH is not set +# CONFIG_ADAPTEC_STARFIRE is not set +# CONFIG_B44 is not set +CONFIG_FORCEDETH=y +# CONFIG_FORCEDETH_NAPI is not set +# CONFIG_DGRS is not set +# CONFIG_EEPRO100 is not set +# CONFIG_E100 is not set +# CONFIG_FEALNX is not set +# CONFIG_NATSEMI is not set +# CONFIG_NE2K_PCI is not set +# CONFIG_8139CP is not set +# CONFIG_8139TOO is not set +# CONFIG_SIS900 is not set +# CONFIG_EPIC100 is not set +# CONFIG_SUNDANCE is not set +# CONFIG_TLAN is not set +# CONFIG_VIA_RHINE is not set +# CONFIG_SC92031 is not set +# CONFIG_NETDEV_1000 is not set +# CONFIG_NETDEV_10000 is not set +# CONFIG_TR is not set + +# +# Wireless LAN +# +# CONFIG_WLAN_PRE80211 is not set +# CONFIG_WLAN_80211 is not set +# CONFIG_WAN is not set +# CONFIG_FDDI is not set +# CONFIG_HIPPI is not set +# CONFIG_PPP is not set +# CONFIG_SLIP is not set +# CONFIG_NET_FC is not set +# CONFIG_SHAPER is not set +# CONFIG_NETCONSOLE is not set +# CONFIG_NETPOLL is not set +# CONFIG_NET_POLL_CONTROLLER is not set + +# +# ISDN subsystem +# +# CONFIG_ISDN is not set + +# +# Telephony Support +# +# CONFIG_PHONE is not set + +# +# Input device support +# +CONFIG_INPUT=y +# CONFIG_INPUT_FF_MEMLESS is not set +# CONFIG_INPUT_POLLDEV is not set + +# +# Userland interfaces +# +CONFIG_INPUT_MOUSEDEV=y +# CONFIG_INPUT_MOUSEDEV_PSAUX is not set +CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 +CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 +# CONFIG_INPUT_JOYDEV is not set +# CONFIG_INPUT_TSDEV is not set +# CONFIG_INPUT_EVDEV is not set +# CONFIG_INPUT_EVBUG is not set + +# +# Input Device Drivers +# +CONFIG_INPUT_KEYBOARD=y +CONFIG_KEYBOARD_ATKBD=y +# CONFIG_KEYBOARD_SUNKBD is not set +# CONFIG_KEYBOARD_LKKBD is not set +# CONFIG_KEYBOARD_XTKBD is not set +# CONFIG_KEYBOARD_NEWTON is not set +# CONFIG_KEYBOARD_STOWAWAY is not set +# CONFIG_INPUT_MOUSE is not set +# CONFIG_INPUT_JOYSTICK is not set +# CONFIG_INPUT_TABLET is not set +# CONFIG_INPUT_TOUCHSCREEN is not set +# CONFIG_INPUT_MISC is not set + +# +# Hardware I/O ports +# +CONFIG_SERIO=y +CONFIG_SERIO_I8042=y +CONFIG_SERIO_SERPORT=y +# CONFIG_SERIO_CT82C710 is not set +# CONFIG_SERIO_PCIPS2 is not set +CONFIG_SERIO_LIBPS2=y +# CONFIG_SERIO_RAW is not set +# CONFIG_GAMEPORT is not set + +# +# Character devices +# +CONFIG_VT=y +CONFIG_VT_CONSOLE=y +CONFIG_HW_CONSOLE=y +# CONFIG_VT_HW_CONSOLE_BINDING is not set +# CONFIG_SERIAL_NONSTANDARD is not set + +# +# Serial drivers +# +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_PCI=y +CONFIG_SERIAL_8250_NR_UARTS=48 +CONFIG_SERIAL_8250_RUNTIME_UARTS=4 +# CONFIG_SERIAL_8250_EXTENDED is not set + +# +# Non-8250 serial port support +# +CONFIG_SERIAL_CORE=y +CONFIG_SERIAL_CORE_CONSOLE=y +# CONFIG_SERIAL_JSM is not set +CONFIG_UNIX98_PTYS=y +CONFIG_LEGACY_PTYS=y +CONFIG_LEGACY_PTY_COUNT=256 + +# +# IPMI +# +# CONFIG_IPMI_HANDLER is not set +# CONFIG_WATCHDOG is not set +# CONFIG_HW_RANDOM is not set +# CONFIG_NVRAM is not set +# CONFIG_RTC is not set +# CONFIG_GEN_RTC is not set +# CONFIG_R3964 is not set +# CONFIG_APPLICOM is not set +# CONFIG_SONYPI is not set +# CONFIG_AGP is not set +# CONFIG_DRM is not set +# CONFIG_MWAVE is not set +# CONFIG_PC8736x_GPIO is not set +# CONFIG_NSC_GPIO is not set +# CONFIG_CS5535_GPIO is not set +# CONFIG_RAW_DRIVER is not set +# CONFIG_HANGCHECK_TIMER is not set + +# +# TPM devices +# +# CONFIG_TCG_TPM is not set +# CONFIG_TELCLOCK is not set +CONFIG_DEVPORT=y +CONFIG_I2C=y +CONFIG_I2C_BOARDINFO=y +# CONFIG_I2C_CHARDEV is not set + +# +# I2C Algorithms +# +CONFIG_I2C_ALGOBIT=y +# CONFIG_I2C_ALGOPCF is not set +CONFIG_I2C_ALGOPCA=y + +# +# I2C Hardware Bus support +# +# CONFIG_I2C_ALI1535 is not set +# CONFIG_I2C_ALI1563 is not set +# CONFIG_I2C_ALI15X3 is not set +# CONFIG_I2C_AMD756 is not set +# CONFIG_I2C_AMD8111 is not set +# CONFIG_I2C_I801 is not set +# CONFIG_I2C_I810 is not set +# CONFIG_I2C_PIIX4 is not set +# CONFIG_I2C_NFORCE2 is not set +# CONFIG_I2C_OCORES is not set +# CONFIG_I2C_PARPORT_LIGHT is not set +# CONFIG_I2C_PROSAVAGE is not set +# CONFIG_I2C_SAVAGE4 is not set +# CONFIG_I2C_SIMTEC is not set +# CONFIG_SCx200_ACB is not set +# CONFIG_I2C_SIS5595 is not set +# CONFIG_I2C_SIS630 is not set +# CONFIG_I2C_SIS96X is not set +# CONFIG_I2C_VIA is not set +# CONFIG_I2C_VIAPRO is not set +# CONFIG_I2C_VOODOO3 is not set + +# +# Miscellaneous I2C Chip support +# +# CONFIG_SENSORS_DS1337 is not set +# CONFIG_SENSORS_DS1374 is not set +# CONFIG_SENSORS_EEPROM is not set +# CONFIG_SENSORS_PCF8574 is not set +# CONFIG_SENSORS_PCA9539 is not set +# CONFIG_SENSORS_PCF8591 is not set +# CONFIG_SENSORS_MAX6875 is not set +# CONFIG_I2C_DEBUG_CORE is not set +# CONFIG_I2C_DEBUG_ALGO is not set +# CONFIG_I2C_DEBUG_BUS is not set +# CONFIG_I2C_DEBUG_CHIP is not set + +# +# SPI support +# +# CONFIG_SPI is not set +# CONFIG_SPI_MASTER is not set + +# +# Dallas's 1-wire bus +# +# CONFIG_W1 is not set +# CONFIG_HWMON is not set + +# +# Multifunction device drivers +# +# CONFIG_MFD_SM501 is not set + +# +# Multimedia devices +# +# CONFIG_VIDEO_DEV is not set +# CONFIG_DVB_CORE is not set +# CONFIG_DAB is not set + +# +# Graphics support +# +# CONFIG_BACKLIGHT_LCD_SUPPORT is not set + +# +# Display device support +# +# CONFIG_DISPLAY_SUPPORT is not set +# CONFIG_VGASTATE is not set +# CONFIG_FB is not set + +# +# Console display driver support +# +CONFIG_VGA_CONSOLE=y +# CONFIG_VGACON_SOFT_SCROLLBACK is not set +# CONFIG_VIDEO_SELECT is not set +CONFIG_DUMMY_CONSOLE=y + +# +# Sound +# +# CONFIG_SOUND is not set + +# +# HID Devices +# +CONFIG_HID=y +# CONFIG_HID_DEBUG is not set + +# +# USB support +# +CONFIG_USB_ARCH_HAS_HCD=y +CONFIG_USB_ARCH_HAS_OHCI=y +CONFIG_USB_ARCH_HAS_EHCI=y +# CONFIG_USB is not set + +# +# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' +# + +# +# USB Gadget Support +# +# CONFIG_USB_GADGET is not set +# CONFIG_MMC is not set + +# +# LED devices +# +# CONFIG_NEW_LEDS is not set + +# +# LED drivers +# + +# +# LED Triggers +# + +# +# InfiniBand support +# +# CONFIG_INFINIBAND is not set + +# +# EDAC - error detection and reporting (RAS) (EXPERIMENTAL) +# +# CONFIG_EDAC is not set + +# +# Real Time Clock +# +# CONFIG_RTC_CLASS is not set + +# +# DMA Engine support +# +# CONFIG_DMA_ENGINE is not set + +# +# DMA Clients +# + +# +# DMA Devices +# + +# +# Virtualization +# +# CONFIG_KVM is not set + +# +# File systems +# +CONFIG_EXT2_FS=y +# CONFIG_EXT2_FS_XIP is not set +# CONFIG_EXT3_FS is not set +# CONFIG_EXT4DEV_FS is not set +# CONFIG_REISERFS_FS is not set +# CONFIG_JFS_FS is not set +# CONFIG_FS_POSIX_ACL is not set +# CONFIG_XFS_FS is not set +# CONFIG_GFS2_FS is not set +# CONFIG_OCFS2_FS is not set +# CONFIG_MINIX_FS is not set +# CONFIG_ROMFS_FS is not set +# CONFIG_INOTIFY is not set +# CONFIG_QUOTA is not set +CONFIG_DNOTIFY=y +# CONFIG_AUTOFS_FS is not set +# CONFIG_AUTOFS4_FS is not set +# CONFIG_FUSE_FS is not set + +# +# CD-ROM/DVD Filesystems +# +CONFIG_ISO9660_FS=y +CONFIG_JOLIET=y +# CONFIG_ZISOFS is not set +# CONFIG_UDF_FS is not set + +# +# DOS/FAT/NT Filesystems +# +CONFIG_FAT_FS=y +CONFIG_MSDOS_FS=y +CONFIG_VFAT_FS=y +CONFIG_FAT_DEFAULT_CODEPAGE=437 +CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" +# CONFIG_NTFS_FS is not set + +# +# Pseudo filesystems +# +CONFIG_PROC_FS=y +CONFIG_PROC_KCORE=y +CONFIG_PROC_SYSCTL=y +CONFIG_SYSFS=y +CONFIG_TMPFS=y +# CONFIG_TMPFS_POSIX_ACL is not set +# CONFIG_HUGETLBFS is not set +# CONFIG_HUGETLB_PAGE is not set +CONFIG_RAMFS=y +# CONFIG_CONFIGFS_FS is not set + +# +# Miscellaneous filesystems +# +# CONFIG_ADFS_FS is not set +# CONFIG_AFFS_FS is not set +# CONFIG_ECRYPT_FS is not set +# CONFIG_HFS_FS is not set +# CONFIG_HFSPLUS_FS is not set +# CONFIG_BEFS_FS is not set +# CONFIG_BFS_FS is not set +# CONFIG_EFS_FS is not set +# CONFIG_CRAMFS is not set +# CONFIG_VXFS_FS is not set +# CONFIG_HPFS_FS is not set +# CONFIG_QNX4FS_FS is not set +# CONFIG_SYSV_FS is not set +# CONFIG_UFS_FS is not set + +# +# Network File Systems +# +# CONFIG_NFSD is not set +# CONFIG_SMB_FS is not set +# CONFIG_CIFS is not set +# CONFIG_NCP_FS is not set +# CONFIG_CODA_FS is not set +# CONFIG_AFS_FS is not set +# CONFIG_9P_FS is not set + +# +# Partition Types +# +# CONFIG_PARTITION_ADVANCED is not set +CONFIG_MSDOS_PARTITION=y + +# +# Native Language Support +# +CONFIG_NLS=y +CONFIG_NLS_DEFAULT="cp437" +CONFIG_NLS_CODEPAGE_437=y +# CONFIG_NLS_CODEPAGE_737 is not set +# CONFIG_NLS_CODEPAGE_775 is not set +# CONFIG_NLS_CODEPAGE_850 is not set +# CONFIG_NLS_CODEPAGE_852 is not set +# CONFIG_NLS_CODEPAGE_855 is not set +# CONFIG_NLS_CODEPAGE_857 is not set +# CONFIG_NLS_CODEPAGE_860 is not set +# CONFIG_NLS_CODEPAGE_861 is not set +# CONFIG_NLS_CODEPAGE_862 is not set +# CONFIG_NLS_CODEPAGE_863 is not set +# CONFIG_NLS_CODEPAGE_864 is not set +# CONFIG_NLS_CODEPAGE_865 is not set +# CONFIG_NLS_CODEPAGE_866 is not set +# CONFIG_NLS_CODEPAGE_869 is not set +# CONFIG_NLS_CODEPAGE_936 is not set +# CONFIG_NLS_CODEPAGE_950 is not set +# CONFIG_NLS_CODEPAGE_932 is not set +# CONFIG_NLS_CODEPAGE_949 is not set +# CONFIG_NLS_CODEPAGE_874 is not set +# CONFIG_NLS_ISO8859_8 is not set +# CONFIG_NLS_CODEPAGE_1250 is not set +# CONFIG_NLS_CODEPAGE_1251 is not set +CONFIG_NLS_ASCII=y +# CONFIG_NLS_ISO8859_1 is not set +# CONFIG_NLS_ISO8859_2 is not set +# CONFIG_NLS_ISO8859_3 is not set +# CONFIG_NLS_ISO8859_4 is not set +# CONFIG_NLS_ISO8859_5 is not set +# CONFIG_NLS_ISO8859_6 is not set +# CONFIG_NLS_ISO8859_7 is not set +# CONFIG_NLS_ISO8859_9 is not set +# CONFIG_NLS_ISO8859_13 is not set +# CONFIG_NLS_ISO8859_14 is not set +# CONFIG_NLS_ISO8859_15 is not set +# CONFIG_NLS_KOI8_R is not set +# CONFIG_NLS_KOI8_U is not set +# CONFIG_NLS_UTF8 is not set + +# +# Distributed Lock Manager +# +# CONFIG_DLM is not set + +# +# Instrumentation Support +# +# CONFIG_PROFILING is not set + +# +# Kernel hacking +# +CONFIG_TRACE_IRQFLAGS_SUPPORT=y +# CONFIG_ENABLE_MUST_CHECK is not set +# CONFIG_MAGIC_SYSRQ is not set +# CONFIG_UNUSED_SYMBOLS is not set +# CONFIG_DEBUG_FS is not set +# CONFIG_HEADERS_CHECK is not set +# CONFIG_DEBUG_KERNEL is not set +CONFIG_EARLY_PRINTK=y +CONFIG_X86_FIND_SMP_CONFIG=y +CONFIG_X86_MPPARSE=y +CONFIG_DOUBLEFAULT=y + +# +# Security options +# +CONFIG_KEYS=y +# CONFIG_KEYS_DEBUG_PROC_KEYS is not set +# CONFIG_SECURITY is not set + +# +# Cryptographic options +# +CONFIG_CRYPTO=y +CONFIG_CRYPTO_ALGAPI=y +CONFIG_CRYPTO_BLKCIPHER=y +CONFIG_CRYPTO_MANAGER=y +# CONFIG_CRYPTO_HMAC is not set +# CONFIG_CRYPTO_XCBC is not set +# CONFIG_CRYPTO_NULL is not set +# CONFIG_CRYPTO_MD4 is not set +CONFIG_CRYPTO_MD5=y +CONFIG_CRYPTO_SHA1=y +CONFIG_CRYPTO_SHA256=y +# CONFIG_CRYPTO_SHA512 is not set +# CONFIG_CRYPTO_WP512 is not set +# CONFIG_CRYPTO_TGR192 is not set +# CONFIG_CRYPTO_GF128MUL is not set +# CONFIG_CRYPTO_ECB is not set +CONFIG_CRYPTO_CBC=y +# CONFIG_CRYPTO_PCBC is not set +# CONFIG_CRYPTO_LRW is not set +# CONFIG_CRYPTO_CRYPTD is not set +CONFIG_CRYPTO_DES=y +# CONFIG_CRYPTO_FCRYPT is not set +# CONFIG_CRYPTO_BLOWFISH is not set +# CONFIG_CRYPTO_TWOFISH is not set +# CONFIG_CRYPTO_TWOFISH_586 is not set +# CONFIG_CRYPTO_SERPENT is not set +# CONFIG_CRYPTO_AES is not set +# CONFIG_CRYPTO_AES_586 is not set +CONFIG_CRYPTO_CAST5=y +# CONFIG_CRYPTO_CAST6 is not set +# CONFIG_CRYPTO_TEA is not set +# CONFIG_CRYPTO_ARC4 is not set +# CONFIG_CRYPTO_KHAZAD is not set +# CONFIG_CRYPTO_ANUBIS is not set +# CONFIG_CRYPTO_DEFLATE is not set +# CONFIG_CRYPTO_MICHAEL_MIC is not set +# CONFIG_CRYPTO_CRC32C is not set +# CONFIG_CRYPTO_CAMELLIA is not set + +# +# Hardware crypto devices +# +# CONFIG_CRYPTO_DEV_PADLOCK is not set +# CONFIG_CRYPTO_DEV_GEODE is not set + +# +# Library routines +# +CONFIG_BITREVERSE=y +CONFIG_CRC_CCITT=y +CONFIG_CRC16=y +# CONFIG_CRC_ITU_T is not set +CONFIG_CRC32=y +CONFIG_LIBCRC32C=y +CONFIG_PLIST=y +CONFIG_HAS_IOMEM=y +CONFIG_HAS_IOPORT=y +CONFIG_HAS_DMA=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_X86_BIOS_REBOOT=y +CONFIG_KTIME_SCALAR=y From ward at gnu.org Wed Sep 12 21:17:43 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 15:17:43 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: m57sli linux kernel config + makefile In-Reply-To: <13426df10709081026k35f67563w2fd99f24c35e90e8@mail.gmail.com> References: <20070906142507.GD29891@localdomain> <13426df10709081026k35f67563w2fd99f24c35e90e8@mail.gmail.com> Message-ID: <20070912191743.GH17001@localdomain> On Sat, Sep 08, 2007 at 10:26:41AM -0700, ron minnich wrote: > Acked-by: Ronald G. Minnich > > Ward you can commit right? r28 Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From svn at openbios.org Wed Sep 12 21:19:38 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 12 Sep 2007 21:19:38 +0200 Subject: [LinuxBIOS] r29 - in buildrom-devel/skeleton: . bin Message-ID: Author: ward Date: 2007-09-12 21:19:38 +0200 (Wed, 12 Sep 2007) New Revision: 29 Modified: buildrom-devel/skeleton/bin/boot.functions buildrom-devel/skeleton/device.txt buildrom-devel/skeleton/linuxrc Log: Change the skeleton files to give us a simple busybox + kexec boot (statically built kexec on disk). Signed-off-by: Ward Vandewege Acked-by: Ronald G. Minnich Modified: buildrom-devel/skeleton/bin/boot.functions =================================================================== --- buildrom-devel/skeleton/bin/boot.functions 2007-09-12 19:17:14 UTC (rev 28) +++ buildrom-devel/skeleton/bin/boot.functions 2007-09-12 19:19:38 UTC (rev 29) @@ -4,17 +4,11 @@ # Note - these are being kept for compatablity purposes # The best solution is to use olpc-boot.sh -CMDLINE="root=/dev/sda1 console=ttyS0,115200 console=tty0 rootdelay=10 rw" -KERNEL="/bzImage" -INITRD="" +CMDLINE="root=/dev/sda1 ro console=tty0 console=ttyS0,115200" +KERNEL="/boot/vmlinuz" +INITRD="/boot/initrd.img" VT="1" -# Any of the above can be over-ridden by /boot.conf - -if [ -f /boot.conf ]; then - . /boot.conf -fi - message() { echo $1 > /dev/tty$VT echo $1 @@ -26,25 +20,14 @@ # Switch to the mounted directory to make life easier for the script cd $DIR - if [ -x ./boot/olpc-boot.sh ]; then - . ./boot/olpc-boot.sh - message "Unable to execute the olpc-boot.sh script" - return - fi + # Any of the above can be over-ridden by /boot.conf - if [ -x ./olpc-boot.sh ]; then - . ./olpc-boot.sh - message "Unable to execute the olpc-boot.sh script" - return + if [ -f $DIR/etc/boot.conf ]; then + . $DIR/etc/boot.conf fi - # For backwards compatablity - try to find the kernel + $DIR/sbin/kexec -l $DIR/$KERNEL --command-line="$CMDLINE" + $DIR/sbin/kexec -e - if [ ! -f $DIR$KERNEL ]; then - message "ERROR: $DIR$KERNEL doesn't exist." - return - fi - - /sbin/kbl-kexec $DIR$KERNEL "$CMDLINE" $INITRD - message "ERROR: can't run kbl-kexec $DIR$KERNEL $CMDLINE $INITRD" + message "ERROR: can't run kexec $DIR$KERNEL $CMDLINE $INITRD" } Modified: buildrom-devel/skeleton/device.txt =================================================================== --- buildrom-devel/skeleton/device.txt 2007-09-12 19:17:14 UTC (rev 28) +++ buildrom-devel/skeleton/device.txt 2007-09-12 19:19:38 UTC (rev 29) @@ -6,5 +6,12 @@ console c 640 0 0 5 1 sda b 660 0 0 8 0 sda1 b 660 0 0 8 1 +sda2 b 660 0 0 8 2 +sda3 b 660 0 0 8 3 +sda4 b 660 0 0 8 4 +sda5 b 660 0 0 8 5 +sda6 b 660 0 0 8 6 +sda7 b 660 0 0 8 7 +sda8 b 660 0 0 8 8 mem c 640 0 0 1 1 fb0 c 640 0 0 29 0 Modified: buildrom-devel/skeleton/linuxrc =================================================================== --- buildrom-devel/skeleton/linuxrc 2007-09-12 19:17:14 UTC (rev 28) +++ buildrom-devel/skeleton/linuxrc 2007-09-12 19:19:38 UTC (rev 29) @@ -1,62 +1,28 @@ #!/bin/sh -# We need boot functions for message() +/sbin/makedevs /dev < device.txt > /output.makedevs.txt 2>&1 + . /bin/boot.functions boot_default() { - sh /bin/boot-nand - sh /bin/boot-usb + sh /bin/boot-hdd } -# Make the null device by hand, since we use it in the makedevs step. - -mknod /dev/null c 1 3 - mkdir /proc mount -t proc proc /proc # For debug purposes mount -t usbfs usbfs /proc/bus/usb -# Makedevs returns seemingly nasty error messages, even though the -# files are still created (we're missing something in the minimal kernel -# that causes chown to return ENOSYS). -# End result - we ignore the error messages - -/sbin/makedevs /dev < device.txt > /dev/null 2>&1 - # Show the version -cat /buildrom-version cat /buildrom-version > /dev/tty$VT -# FIXME - bad! - -message "Starting bootmenu." +message "Trying to boot from hdd." cd /bin -./bootmenu +./boot-hdd RET=$? cd / -# Bootmenu now returns 0 if the timeout happened (meaning, -# we want to boot the default - which in this case is nand -# then USB key. $RET > 0 means to select the menu item - -# NOTE: Should 3 be boot_default, or boot-usb only? - -if [ $RET -eq 0 ]; then - message "NOTICE: Booting default" - boot_default -elif [ $RET -eq 1 ]; then - message "ERROR: Wired mode isn't supported right now." -elif [ $RET -eq 2 ]; then - message "ERROR: Wireless mode isn't supported right now." -elif [ $RET -eq 3 ]; then - sh /bin/boot-usb -elif [ $RET -eq -1 ]; then - message "ERROR: The bootmenu was not successful." -fi - message "NOTICE: Starting the shell..." - openvt $VT /bin/ash exec /bin/ash From ward at gnu.org Wed Sep 12 21:26:24 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 15:26:24 -0400 Subject: [LinuxBIOS] buildrom: LinuxBIOS payload Config.lb files In-Reply-To: <13426df10709121212g34bb7bd1x2d044e21e50ea90e@mail.gmail.com> References: <20070905223921.GD23467@localdomain> <20070906024625.GF23823@cosmic.amd.com> <20070912191055.GF17001@localdomain> <13426df10709121212g34bb7bd1x2d044e21e50ea90e@mail.gmail.com> Message-ID: <20070912192624.GI17001@localdomain> On Wed, Sep 12, 2007 at 12:12:29PM -0700, ron minnich wrote: > Ward, can we get kernel and all in 1 MB at this point? Yes - busybox + 2.6.22.2 with tiny patches and most non-essential stuff disabled. No kexec binary or boot menu. There currently is almost 84K to spare. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From ward at gnu.org Wed Sep 12 21:27:16 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 15:27:16 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: initramfs skeleton In-Reply-To: <13426df10709081025w2b9d0cd4oc85d47a88f93428d@mail.gmail.com> References: <20070906142519.GE29891@localdomain> <13426df10709081025w2b9d0cd4oc85d47a88f93428d@mail.gmail.com> Message-ID: <20070912192716.GJ17001@localdomain> On Sat, Sep 08, 2007 at 10:25:41AM -0700, ron minnich wrote: > Acked-by: Ronald G. Minnich > > On 9/6/07, Ward Vandewege wrote: > > Update the initramfs skeleton to be less olpc specific. This skeleton needs > > more generalization, but that's for later. r29 Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From rminnich at gmail.com Wed Sep 12 21:31:28 2007 From: rminnich at gmail.com (ron minnich) Date: Wed, 12 Sep 2007 12:31:28 -0700 Subject: [LinuxBIOS] buildrom: LinuxBIOS payload Config.lb files In-Reply-To: <20070912192624.GI17001@localdomain> References: <20070905223921.GD23467@localdomain> <20070906024625.GF23823@cosmic.amd.com> <20070912191055.GF17001@localdomain> <13426df10709121212g34bb7bd1x2d044e21e50ea90e@mail.gmail.com> <20070912192624.GI17001@localdomain> Message-ID: <13426df10709121231h769f015ct9224f865750dfdb4@mail.gmail.com> On 9/12/07, Ward Vandewege wrote: > On Wed, Sep 12, 2007 at 12:12:29PM -0700, ron minnich wrote: > > Ward, can we get kernel and all in 1 MB at this point? > > Yes - busybox + 2.6.22.2 with tiny patches and most non-essential stuff > disabled. No kexec binary or boot menu. well! Good news. can you send me your .config? ron From danieldelahoyde at gmail.com Wed Sep 12 21:35:59 2007 From: danieldelahoyde at gmail.com (Daniel Delahoyde) Date: Wed, 12 Sep 2007 20:35:59 +0100 Subject: [LinuxBIOS] ABIT AA8 Duramax Message-ID: <1189625759.5884.3.camel@dan-desktop> Hi Linux BIOS team, could you please let me know if the ABIT AA8 DuraMax motherboard with the following lspci output will work with Linux Bios: 00:00.0 Host bridge: Intel Corporation 82925X/XE Memory Controller Hub (rev 04) 00:01.0 PCI bridge: Intel Corporation 82925X/XE PCI Express Root Port (rev 04) 00:1b.0 Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3) 00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC Interface Bridge (rev 03) 00:1f.2 IDE interface: Intel Corporation 82801FR/FRW (ICH6R/ICH6RW) SATA Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03) 01:00.0 VGA compatible controller: nVidia Corporation Unknown device 016a (rev a1) 02:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) 02:02.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) Thanks, Daniel From alex at rtfs.hu Wed Sep 12 21:37:15 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Wed, 12 Sep 2007 21:37:15 +0200 Subject: [LinuxBIOS] [PATCH] pci_rom.c checksum extension rom In-Reply-To: <1189162475.26302.55.camel@localhost> References: <1188904675.17055.2.camel@localhost> <20070905022911.GA31013@coresystems.de> <1189162475.26302.55.camel@localhost> Message-ID: <1189625835.19904.6.camel@localhost> Hi, On Fri, 2007-09-07 at 12:54 +0200, Alex Beregszaszi wrote: > Hi, > > On Wed, 2007-09-05 at 04:29 +0200, Stefan Reinauer wrote: > > * Alex Beregszaszi [070904 13:17]: > > > Hi, > > > > > > the attached patch adds code to checksum the pci extension rom and stop > > > if the stored and calculated checksum differ. > > > > Is this checksum reliably correct? I am hesitating to add new > > restrictions that might break otherwise working cards. > > You are right, attached is a correct method. There is no fixed checksum > byte, instead the whole should sum to zero. Any comments on this? -- Alex From ward at gnu.org Wed Sep 12 21:37:49 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 15:37:49 -0400 Subject: [LinuxBIOS] buildrom: LinuxBIOS payload Config.lb files In-Reply-To: <13426df10709121231h769f015ct9224f865750dfdb4@mail.gmail.com> References: <20070905223921.GD23467@localdomain> <20070906024625.GF23823@cosmic.amd.com> <20070912191055.GF17001@localdomain> <13426df10709121212g34bb7bd1x2d044e21e50ea90e@mail.gmail.com> <20070912192624.GI17001@localdomain> <13426df10709121231h769f015ct9224f865750dfdb4@mail.gmail.com> Message-ID: <20070912193749.GA18233@localdomain> On Wed, Sep 12, 2007 at 12:31:28PM -0700, ron minnich wrote: > On 9/12/07, Ward Vandewege wrote: > > On Wed, Sep 12, 2007 at 12:12:29PM -0700, ron minnich wrote: > > > Ward, can we get kernel and all in 1 MB at this point? > > > > Yes - busybox + 2.6.22.2 with tiny patches and most non-essential stuff > > disabled. No kexec binary or boot menu. > > well! Good news. can you send me your .config? I just checked it in; you can find it here in the buildrom svn tree: packages/kernel/conf/defconfig-m57sli This is fairly specific to the m57sli-s4; make sure to change your sata/disk and nic driver if necessary, at the very least. Also printk is disabled which saves a lot of space, but makes debugging rather annoying. If you disable module support you can enable printk and still have 25K to spare. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From alex at rtfs.hu Wed Sep 12 21:37:56 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Wed, 12 Sep 2007 21:37:56 +0200 Subject: [LinuxBIOS] [PATCH] Support other than 0xC000 ROMs in VM86 In-Reply-To: <1189009010.17055.107.camel@localhost> References: <1188925040.17055.40.camel@localhost> <20070905014527.GB10233@coresystems.de> <1189009010.17055.107.camel@localhost> Message-ID: <1189625876.19904.8.camel@localhost> Hi, On Wed, 2007-09-05 at 18:16 +0200, Alex Beregszaszi wrote: > On Wed, 2007-09-05 at 03:45 +0200, Stefan Reinauer wrote: > > > > Also it changes the function to inline assembly and passes the arguments > > > through that. > > > > > > This patch includes the changes from my previous patch "[PATCH] vgabios: > > > use same interface for biosemu.c and vm86.c", but should be committed > > > incrementally. > > > > Can you please rediff against the current svn and send this patch again? > > Sure, attached. I hope this is not forgotten. -- Alex From ward at gnu.org Wed Sep 12 21:38:56 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 15:38:56 -0400 Subject: [LinuxBIOS] [rminnich@gmail.com: Re: [ward@gnu.org: Re: [PATCH] buildrom: add packages/kernel/patches/tiny_m57sli]] Message-ID: <20070912193856.GB18233@localdomain> For the record. Thanks, Ward. ----- Forwarded message from ron minnich ----- DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=g1R2QGgyxGV69Ij4FECJsC+aShFj2m/QlQD1YQGFUhI=; b=IXe9CW3ZWq1SxuvdonCRJkcZS2rNbzFY2exf3kUPXbaVLXJHewJoPqJhcC4nJEv11+wySG93ekeOzm5L3r9Ew1hElDgUEX7SnUHszrQa6gysKu/OovTv6QeCR5mrb3PyDa1WIR0W+uC502zuGSUEt/RW4jixj/iCabS6bRvgVdk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rWE2HF7hu4j48qxLaz/rcKosQJa2V/Mj4YeRgsu/CPGxIIGiol43Pz33MA0XgXAEEVKVb/XVlka4EvpdojWYfRmNik2YYG+2m1r1lalpcVbcRfmNueoW7vvYcZzx8wD8cKoA42L5FK84Kva6sGHQpAn6mL4uQtS+/eS+Fvbhj+c= Date: Wed, 12 Sep 2007 12:33:30 -0700 From: ron minnich To: Ward Vandewege Subject: Re: [ward at gnu.org: Re: [LinuxBIOS] [PATCH] buildrom: add packages/kernel/patches/tiny_m57sli] Content-Disposition: inline X-Detected-Kernel: Linux 2.6 (newer, 2) X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) Acked-by: Ronald G. Minnich !DSPAM:46e83f1b65821804284693! ----- End forwarded message ----- -- Ward Vandewege Free Software Foundation - Senior System Administrator From alex at rtfs.hu Wed Sep 12 21:41:11 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Wed, 12 Sep 2007 21:41:11 +0200 Subject: [LinuxBIOS] [PATCH] LAR verison field In-Reply-To: <13426df10709081039l5247cb5ai6b12860deaace799@mail.gmail.com> References: <1189040359.26302.7.camel@localhost> <13426df10709081039l5247cb5ai6b12860deaace799@mail.gmail.com> Message-ID: <1189626071.19904.12.camel@localhost> Hi, On Sat, 2007-09-08 at 10:39 -0700, ron minnich wrote: > hi, we rejected this idea, right? I am trying to catch up on un-acked patches. What about adding then a version string (to a fixed position) in stage1? For user-space tools to handle multiple versions. -- Alex From alex at rtfs.hu Wed Sep 12 21:42:31 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Wed, 12 Sep 2007 21:42:31 +0200 Subject: [LinuxBIOS] [RFC] Multiple payload support in v3 In-Reply-To: <13426df10709081038j2dcd6ccfob27bf04536ba5f5a@mail.gmail.com> References: <1189046215.26302.26.camel@localhost> <13426df10709081038j2dcd6ccfob27bf04536ba5f5a@mail.gmail.com> Message-ID: <1189626151.19904.15.camel@localhost> Hi, On Sat, 2007-09-08 at 10:38 -0700, ron minnich wrote: > This is a slight change. Did you verify this with a kernel payload? No. I tested it with GRUB2, FILO and lbmenu. And as I said this is not yet intended for inclusion, just for the record to have an updated version of Uwe's posted patch. -- Alex From alex at rtfs.hu Wed Sep 12 21:43:02 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Wed, 12 Sep 2007 21:43:02 +0200 Subject: [LinuxBIOS] [PATCH] LAR: linearly count segment numbers In-Reply-To: <13426df10709081031k26eeb9a2s238f6ee45cee70c6@mail.gmail.com> References: <1189045829.26302.20.camel@localhost> <13426df10709081031k26eeb9a2s238f6ee45cee70c6@mail.gmail.com> Message-ID: <1189626182.19904.17.camel@localhost> Hi, On Sat, 2007-09-08 at 10:31 -0700, ron minnich wrote: > Acked-by: Ronald G. Minnich Can someone please commit this? -- Alex From alex at rtfs.hu Wed Sep 12 21:43:20 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Wed, 12 Sep 2007 21:43:20 +0200 Subject: [LinuxBIOS] [PATCH] LAR checksums In-Reply-To: <1189041821.26302.13.camel@localhost> References: <1189041821.26302.13.camel@localhost> Message-ID: <1189626200.19904.19.camel@localhost> Hi, On Thu, 2007-09-06 at 03:23 +0200, Alex Beregszaszi wrote: > Hi, > > checksum-fix.diff fixes a checksum calculation bug in the lar utility, > where it would checksum less bytes then desired. > > lar-check-sum.diff implements checksum checking in the runtime lar code. > > I implemented the check inside the filename check, thus it wont be > executed on unneeded entries. As my assumption was that I cant modify > the memory, the code is skipping bytes between 20-24 of the header > (checksum field) to generate a correct sum. > > This is bad, as the numbers shall be updated at every lar structure > change. This is good, as we are not writing to memory. Any comments to this? -- Alex From alex at rtfs.hu Wed Sep 12 21:44:15 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Wed, 12 Sep 2007 21:44:15 +0200 Subject: [LinuxBIOS] [PATCH] [V3] LAR: merge common parts of copy/run_file In-Reply-To: <1189094037.26302.37.camel@localhost> References: <1189094037.26302.37.camel@localhost> Message-ID: <1189626255.19904.21.camel@localhost> Hi, On Thu, 2007-09-06 at 17:53 +0200, Alex Beregszaszi wrote: > Hi, > > attached patch creates a file-local process_file() function which has > the common pats of copy_file and run_file. Just a reminder: any comments on this? :) -- Alex From corey.osgood at gmail.com Wed Sep 12 21:45:27 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Wed, 12 Sep 2007 15:45:27 -0400 Subject: [LinuxBIOS] ABIT AA8 Duramax In-Reply-To: <1189625759.5884.3.camel@dan-desktop> References: <1189625759.5884.3.camel@dan-desktop> Message-ID: <46E841D7.8080208@gmail.com> Daniel Delahoyde wrote: > Hi Linux BIOS team, > > could you please let me know if the ABIT AA8 DuraMax motherboard with > the following lspci output will work with Linux Bios: > > 00:00.0 Host bridge: Intel Corporation 82925X/XE Memory Controller Hub > (rev 04) > 00:01.0 PCI bridge: Intel Corporation 82925X/XE PCI Express Root Port > (rev 04) > 00:1b.0 Audio device: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) High Definition Audio Controller (rev 03) > 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB UHCI #1 (rev 03) > 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB UHCI #2 (rev 03) > 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB UHCI #3 (rev 03) > 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB UHCI #4 (rev 03) > 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB2 EHCI Controller (rev 03) > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3) > 00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC > Interface Bridge (rev 03) > 00:1f.2 IDE interface: Intel Corporation 82801FR/FRW (ICH6R/ICH6RW) SATA > Controller (rev 03) > 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) > SMBus Controller (rev 03) > 01:00.0 VGA compatible controller: nVidia Corporation Unknown device > 016a (rev a1) > 02:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 > Gigabit Ethernet (rev 10) > 02:02.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 > IEEE-1394a-2000 Controller (PHY/Link) > > Thanks, > > Daniel > > > > No, the intel 925 chipset is not yet supported. -Corey From svn at openbios.org Wed Sep 12 21:50:00 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 12 Sep 2007 21:50:00 +0200 Subject: [LinuxBIOS] r30 - buildrom-devel/packages/kernel Message-ID: Author: ward Date: 2007-09-12 21:50:00 +0200 (Wed, 12 Sep 2007) New Revision: 30 Added: buildrom-devel/packages/kernel/m57sli-kernel.mk Modified: buildrom-devel/packages/kernel/kernel.inc Log: 1. Add support to automatically download the Linux Tiny patches from http://elinux.org/Linux_Tiny 2. Add the makefile for the m57sli kernel. Signed-off-by: Ward Vandewege Acked-by: Ronald G. Minnich Modified: buildrom-devel/packages/kernel/kernel.inc =================================================================== --- buildrom-devel/packages/kernel/kernel.inc 2007-09-12 19:19:38 UTC (rev 29) +++ buildrom-devel/packages/kernel/kernel.inc 2007-09-12 19:50:00 UTC (rev 30) @@ -21,9 +21,20 @@ @ mkdir -p $(KERNEL_DIR) @ echo "Unpacking kernel..." @ tar -C $(KERNEL_DIR) -jxf $(SOURCE_DIR)/$(KERNEL_SOURCE) - @ touch $@ + @ touch $@ +$(KERNEL_STAMP_DIR)/.unpacked-tiny: $(SOURCE_DIR)/$(TINY_SOURCE) + @ mkdir -p $(KERNEL_DIR) + @ mkdir -p $(KERNEL_DIR)/tiny + @ echo "Unpacking tiny patches..." + @ tar -C $(KERNEL_DIR)/tiny -xzf $(SOURCE_DIR)/$(TINY_SOURCE) + @ touch $@ + +ifneq ($(TINY_SOURCE),) +$(KERNEL_STAMP_DIR)/.patched: $(KERNEL_STAMP_DIR)/.unpacked $(KERNEL_STAMP_DIR)/.unpacked-tiny +else $(KERNEL_STAMP_DIR)/.patched: $(KERNEL_STAMP_DIR)/.unpacked +endif @ echo "Patching kernel..." @ $(BIN_DIR)/doquilt.sh $(KERNEL_SRC_DIR) $(KERNEL_PATCHES) @ touch $@ Added: buildrom-devel/packages/kernel/m57sli-kernel.mk =================================================================== --- buildrom-devel/packages/kernel/m57sli-kernel.mk (rev 0) +++ buildrom-devel/packages/kernel/m57sli-kernel.mk 2007-09-12 19:50:00 UTC (rev 30) @@ -0,0 +1,25 @@ +# Build file for the Gigabyte M57SLI-S4 LAB kernel + +KERNEL_URL=http://kernel.org/pub/linux/kernel/v2.6/ +KERNEL_SOURCE=linux-$(KERNEL_VERSION).tar.bz2 +KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/defconfig-m57sli + +TINY_URL=http://elinux.org/images/0/0e/ +TINY_SOURCE=Tiny-quilt-2.6.22.1-1.tar.gz +TINY_DIR=$(KERNEL_DIR)/tiny/patches + +KERNEL_PATCHES += $(TINY_DIR) + +$(SOURCE_DIR)/$(KERNEL_SOURCE): + @ mkdir -p $(SOURCE_DIR) + @ wget -P $(SOURCE_DIR) $(KERNEL_URL)/$(KERNEL_SOURCE) + +$(SOURCE_DIR)/$(TINY_SOURCE): + @ mkdir -p $(SOURCE_DIR) + @ wget -P $(SOURCE_DIR) $(TINY_URL)/$(TINY_SOURCE) + +include $(PACKAGE_DIR)/kernel/kernel.inc + +kernel: generic-kernel +kernel-clean: generic-kernel-clean +kernel-distclean: generic-kernel-distclean From ward at gnu.org Wed Sep 12 21:54:02 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 15:54:02 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: add packages/kernel/patches/tiny_m57sli In-Reply-To: <20070912162109.GA16629@localdomain> References: <20070906142443.GC29891@localdomain> <13426df10709081028m3fcaefc1k1a9113d26fa8e0d1@mail.gmail.com> <2ea3fae10709081131m7c275f9fha9f7b18e1c65b0f4@mail.gmail.com> <13426df10709081134r209f0c33vc893a46e39c39458@mail.gmail.com> <20070912162109.GA16629@localdomain> Message-ID: <20070912195402.GC18233@localdomain> On Wed, Sep 12, 2007 at 12:21:09PM -0400, Ward Vandewege wrote: > On Sat, Sep 08, 2007 at 11:34:01AM -0700, ron minnich wrote: > > On 9/8/07, yhlu wrote: > > > On 9/8/07, ron minnich wrote: > > > > On 9/6/07, Ward Vandewege wrote: > > > > > These patches are released under the GPLv2, so we can just include them in > > > > > our buildrom tree. Do we need a license header for each file? > > > > > > > > > > > > This comes from tiny, right? I think since it is a patch we are ok? > > > > > > we should put the URL in buildrom to download that quilt patchset from > > > elinux.org like download linux tar ball... > > > > good point, ward, is that doable? > > It is; here are the updated patches, if there are no objections I'm going to > commit later today. Ron ack'ed this (http://www.linuxbios.org/pipermail/linuxbios/2007-September/024533.html); r30. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From alex at rtfs.hu Wed Sep 12 22:02:10 2007 From: alex at rtfs.hu (Alex Beregszaszi) Date: Wed, 12 Sep 2007 22:02:10 +0200 Subject: [LinuxBIOS] License header missing in util/flashrom/layout.c Message-ID: <1189627330.19904.24.camel@localhost> Hi, the subject says it all. The missing header in udelay.c was added a few days ago, this should not be missed. -- Alex From ward at gnu.org Wed Sep 12 22:04:06 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 16:04:06 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: auto disable lzma compression for non-supported payloads Message-ID: <20070912200406.GA18638@localdomain> -- Ward Vandewege Free Software Foundation - Senior System Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: auto-disabled-lzma-per-payload.patch Type: text/x-diff Size: 1442 bytes Desc: not available URL: From ward at gnu.org Wed Sep 12 22:06:57 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 16:06:57 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: add m57sli-s4 config option Message-ID: <20070912200657.GA18670@localdomain> -- Ward Vandewege Free Software Foundation - Senior System Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: add-m57sli-config-option.patch Type: text/x-diff Size: 944 bytes Desc: not available URL: From jordan.crouse at amd.com Wed Sep 12 22:13:14 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 12 Sep 2007 14:13:14 -0600 Subject: [LinuxBIOS] buildrom: add m57sli-s4 config option In-Reply-To: <20070912200657.GA18670@localdomain> References: <20070912200657.GA18670@localdomain> Message-ID: <20070912201314.GG4913@cosmic.amd.com> Acked-by: Jordan Crouse On 12/09/07 16:06 -0400, Ward Vandewege wrote: > -- > Ward Vandewege > Free Software Foundation - Senior System Administrator > > Add configuration option for the m57sli board in the kconfig menus. > > Signed-off-by: Ward Vandewege > > Index: config/platforms/Config.in > =================================================================== > --- config/platforms/Config.in (revision 17) > +++ config/platforms/Config.in (working copy) > @@ -26,5 +26,9 @@ > bool "AMD DB800" > select PLATFORM > > +config PLATFORM_M57SLI > + bool "Gigabyte M57SLI" > + select PLATFORM > + > endchoice > endmenu > Index: config/platforms/platforms.conf > =================================================================== > --- config/platforms/platforms.conf (revision 17) > +++ config/platforms/platforms.conf (working copy) > @@ -11,5 +11,6 @@ > PLATFORM-$(CONFIG_PLATFORM_MSM800SEV) = msm800sev.conf > PLATFORM-$(CONFIG_PLATFORM_DB800) = db800.conf > PLATFORM-$(CONFIG_PLATFORM_DBE61) = dbe61.conf > +PLATFORM-$(CONFIG_PLATFORM_M57SLI) = m57sli.conf > > include $(CONFIG_DIR)/platforms/$(PLATFORM-y) > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From ward at gnu.org Wed Sep 12 22:16:01 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 16:16:01 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: (revised) auto disable lzma compression for non-supported payloads In-Reply-To: <20070912200406.GA18638@localdomain> References: <20070912200406.GA18638@localdomain> Message-ID: <20070912201601.GA18771@localdomain> That last patch was silly, this is the proper way to disable lzma. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: auto-disabled-lzma-per-payload.patch Type: text/x-diff Size: 845 bytes Desc: not available URL: From jordan.crouse at amd.com Wed Sep 12 22:22:11 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 12 Sep 2007 14:22:11 -0600 Subject: [LinuxBIOS] buildrom: (revised) auto disable lzma compression for non-supported payloads In-Reply-To: <20070912201601.GA18771@localdomain> References: <20070912200406.GA18638@localdomain> <20070912201601.GA18771@localdomain> Message-ID: <20070912202211.GI4913@cosmic.amd.com> On 12/09/07 16:16 -0400, Ward Vandewege wrote: > > That last patch was silly, this is the proper way to disable lzma. Acked-by: Jordan Crouse > Thanks, > Ward. > > -- > Ward Vandewege > Free Software Foundation - Senior System Administrator > > Automatically disable LZMA compression for FILO, as it breaks that payload. > > Signed-off-by: Ward Vandewege > > Index: Config.in > =================================================================== > --- Config.in (revision 17) > +++ Config.in (working copy) > @@ -10,7 +10,7 @@ > bool "See the build output on stdout" > default n > help > - See the entire build output on stdout. Otherwise, it will > + See the entire build output on stdout. Otherwise, it will > be saved off in a series of logs > > config ADVANCED > @@ -24,10 +24,11 @@ > config USE_LZMA > bool "Enable LZMA compression" > depends !PAYLOAD_OFW > + depends !PAYLOAD_FILO > default y > help > - Allow LZMA compression for the payload. This doesn't work > - for OFW. > + Allow LZMA compression for the payload. This doesn't work > + for FILO or OFW. > > > config LB_USE_BUILD > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From svn at openbios.org Wed Sep 12 22:25:06 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 12 Sep 2007 22:25:06 +0200 Subject: [LinuxBIOS] r31 - buildrom-devel Message-ID: Author: ward Date: 2007-09-12 22:25:06 +0200 (Wed, 12 Sep 2007) New Revision: 31 Modified: buildrom-devel/Config.in Log: Automatically disable LZMA compression for FILO, as it breaks that payload. Signed-off-by: Ward Vandewege Acked-by: Jordan Crouse Modified: buildrom-devel/Config.in =================================================================== --- buildrom-devel/Config.in 2007-09-12 19:50:00 UTC (rev 30) +++ buildrom-devel/Config.in 2007-09-12 20:25:06 UTC (rev 31) @@ -10,7 +10,7 @@ bool "See the build output on stdout" default n help - See the entire build output on stdout. Otherwise, it will + See the entire build output on stdout. Otherwise, it will be saved off in a series of logs config ADVANCED @@ -24,10 +24,11 @@ config USE_LZMA bool "Enable LZMA compression" depends !PAYLOAD_OFW + depends !PAYLOAD_FILO default y help - Allow LZMA compression for the payload. This doesn't work - for OFW. + Allow LZMA compression for the payload. This doesn't work + for FILO or OFW. config LB_USE_BUILD From ward at gnu.org Wed Sep 12 22:25:28 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 16:25:28 -0400 Subject: [LinuxBIOS] buildrom: add m57sli-s4 config option In-Reply-To: <20070912201314.GG4913@cosmic.amd.com> References: <20070912200657.GA18670@localdomain> <20070912201314.GG4913@cosmic.amd.com> Message-ID: <20070912202528.GA18860@localdomain> On Wed, Sep 12, 2007 at 02:13:14PM -0600, Jordan Crouse wrote: > Acked-by: Jordan Crouse r31 Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From svn at openbios.org Wed Sep 12 22:28:23 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 12 Sep 2007 22:28:23 +0200 Subject: [LinuxBIOS] r32 - buildrom-devel/config/platforms Message-ID: Author: ward Date: 2007-09-12 22:28:23 +0200 (Wed, 12 Sep 2007) New Revision: 32 Modified: buildrom-devel/config/platforms/Config.in buildrom-devel/config/platforms/platforms.conf Log: Add configuration option for the m57sli board in the kconfig menus. Signed-off-by: Ward Vandewege Acked-by: Jordan Crouse Modified: buildrom-devel/config/platforms/Config.in =================================================================== --- buildrom-devel/config/platforms/Config.in 2007-09-12 20:25:06 UTC (rev 31) +++ buildrom-devel/config/platforms/Config.in 2007-09-12 20:28:23 UTC (rev 32) @@ -26,5 +26,9 @@ bool "AMD DB800" select PLATFORM +config PLATFORM_M57SLI + bool "Gigabyte M57SLI" + select PLATFORM + endchoice endmenu Modified: buildrom-devel/config/platforms/platforms.conf =================================================================== --- buildrom-devel/config/platforms/platforms.conf 2007-09-12 20:25:06 UTC (rev 31) +++ buildrom-devel/config/platforms/platforms.conf 2007-09-12 20:28:23 UTC (rev 32) @@ -11,5 +11,6 @@ PLATFORM-$(CONFIG_PLATFORM_MSM800SEV) = msm800sev.conf PLATFORM-$(CONFIG_PLATFORM_DB800) = db800.conf PLATFORM-$(CONFIG_PLATFORM_DBE61) = dbe61.conf +PLATFORM-$(CONFIG_PLATFORM_M57SLI) = m57sli.conf include $(CONFIG_DIR)/platforms/$(PLATFORM-y) From ward at gnu.org Wed Sep 12 22:29:09 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 16:29:09 -0400 Subject: [LinuxBIOS] buildrom: add m57sli-s4 config option In-Reply-To: <20070912201314.GG4913@cosmic.amd.com> References: <20070912200657.GA18670@localdomain> <20070912201314.GG4913@cosmic.amd.com> Message-ID: <20070912202909.GB18860@localdomain> On Wed, Sep 12, 2007 at 02:13:14PM -0600, Jordan Crouse wrote: > Acked-by: Jordan Crouse > > On 12/09/07 16:06 -0400, Ward Vandewege wrote: > > -- > > Ward Vandewege > > Free Software Foundation - Senior System Administrator > > > > > Add configuration option for the m57sli board in the kconfig menus. > > > > Signed-off-by: Ward Vandewege Sorry, this is r32 not r31. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From ward at gnu.org Wed Sep 12 22:29:34 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 16:29:34 -0400 Subject: [LinuxBIOS] buildrom: (revised) auto disable lzma compression for non-supported payloads In-Reply-To: <20070912202211.GI4913@cosmic.amd.com> References: <20070912200406.GA18638@localdomain> <20070912201601.GA18771@localdomain> <20070912202211.GI4913@cosmic.amd.com> Message-ID: <20070912202934.GC18860@localdomain> On Wed, Sep 12, 2007 at 02:22:11PM -0600, Jordan Crouse wrote: > On 12/09/07 16:16 -0400, Ward Vandewege wrote: > > > > That last patch was silly, this is the proper way to disable lzma. > > Acked-by: Jordan Crouse And this is r31. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From svn at openbios.org Wed Sep 12 22:31:41 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 12 Sep 2007 22:31:41 +0200 Subject: [LinuxBIOS] r33 - buildrom-devel/packages/linuxbios Message-ID: Author: ward Date: 2007-09-12 22:31:41 +0200 (Wed, 12 Sep 2007) New Revision: 33 Modified: buildrom-devel/packages/linuxbios/m57sli-linuxbios.mk Log: Trivial: change download location from openbios.org to linuxbios.org. Signed-off-by: Ward Vandewege Acked-by: Ward Vandewege Modified: buildrom-devel/packages/linuxbios/m57sli-linuxbios.mk =================================================================== --- buildrom-devel/packages/linuxbios/m57sli-linuxbios.mk 2007-09-12 20:28:23 UTC (rev 32) +++ buildrom-devel/packages/linuxbios/m57sli-linuxbios.mk 2007-09-12 20:31:41 UTC (rev 33) @@ -22,7 +22,7 @@ LINUXBIOS_BASE_DIR=svn -LINUXBIOS_URL=svn://openbios.org/repos/trunk/LinuxBIOSv2 +LINUXBIOS_URL=svn://linuxbios.org/repos/trunk/LinuxBIOSv2 LINUXBIOS_TARBALL=linuxbios-svn-$(LINUXBIOS_TAG).tar.gz LINUXBIOS_PAYLOAD_TARGET=$(LINUXBIOS_BUILD_DIR)/payload.elf TARGET_ROM = $(LINUXBIOS_VENDOR)-$(LINUXBIOS_BOARD).rom From ward at gnu.org Wed Sep 12 22:34:44 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 16:34:44 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: packages/linuxbios/m57sli-linuxbios.mk (revised) In-Reply-To: <20070908192447.GD18334@greenwood> References: <20070906033848.GB26150@localdomain> <20070908192447.GD18334@greenwood> Message-ID: <20070912203444.GD18860@localdomain> On Sat, Sep 08, 2007 at 09:24:47PM +0200, Uwe Hermann wrote: > > +LINUXBIOS_BASE_DIR=svn > > +LINUXBIOS_URL=svn://openbios.org/repos/trunk/LinuxBIOSv2 > > Minor issue, but why not use linuxbios.org here? Fair enough; I just copied it from one of the other targets. Fixed in r33 (self-acked since it's a trivial change). Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From ward at gnu.org Wed Sep 12 22:57:10 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 16:57:10 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: add config/platforms/m57sli.conf Message-ID: <20070912205710.GA19075@localdomain> -- Ward Vandewege Free Software Foundation - Senior System Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: m57sli.conf.patch Type: text/x-diff Size: 1128 bytes Desc: not available URL: From jordan.crouse at amd.com Wed Sep 12 23:02:23 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 12 Sep 2007 15:02:23 -0600 Subject: [LinuxBIOS] buildrom: add config/platforms/m57sli.conf In-Reply-To: <20070912205710.GA19075@localdomain> References: <20070912205710.GA19075@localdomain> Message-ID: <20070912210223.GL4913@cosmic.amd.com> On 12/09/07 16:57 -0400, Ward Vandewege wrote: > -- > Ward Vandewege > Free Software Foundation - Senior System Administrator > Add the platform config file for the m57sli. This is the final patch of this > set, which completes FILO/LAB payload support for the Gigabyte M57SLI-S4 > motherboard. > > Signed-off-by: Ward Vandewege Acked-by: Jordan Crouse > Index: config/platforms/m57sli.conf > =================================================================== > --- config/platforms/m57sli.conf (revision 0) > +++ config/platforms/m57sli.conf (revision 0) > @@ -0,0 +1,38 @@ > +# Support for the Gigabyte M57SLI-S4 board > + > +#### Platform configuration > + > +CC=gcc > +STRIP=strip > +AS=as > + > +TARGET_ARCH=i686 > +CFLAGS_platform = -m32 > + > +# Targets > + > +KERNEL_MK=$(PACKAGE_DIR)/kernel/m57sli-kernel.mk > +LINUXBIOS_MK=$(PACKAGE_DIR)/linuxbios/m57sli-linuxbios.mk > + > +# kernel configuration (for LAB) > + > +KERNEL_VERSION=2.6.22.2 > +KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/m57sli-defconfig > +UCLIBC_ARCH=i386 > + > +# Etherboot configuration > +ETHERBOOT_ARCH=i386 > + > +# LinuxBIOS configuration > + > +LINUXBIOS_VENDOR=gigabyte > +LINUXBIOS_BOARD=m57sli > +LINUXBIOS_CONFIG=Config.lb > +LINUXBIOS_TDIR=m57sli > +LINUXBIOS_TAG=2742 > +LINUXBIOS_ROM_NAME=linuxbios.rom > + > +# FILO configuration > + > +FILO_CONFIG=m57sli-Config > + > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From svn at openbios.org Wed Sep 12 23:04:42 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 12 Sep 2007 23:04:42 +0200 Subject: [LinuxBIOS] r34 - buildrom-devel/config/platforms Message-ID: Author: ward Date: 2007-09-12 23:04:42 +0200 (Wed, 12 Sep 2007) New Revision: 34 Added: buildrom-devel/config/platforms/m57sli.conf Log: Add the platform config file for the m57sli. This is the final patch of this set, which completes FILO/LAB payload support for the Gigabyte M57SLI-S4 motherboard. Signed-off-by: Ward Vandewege Acked-by: Jordan Crouse Added: buildrom-devel/config/platforms/m57sli.conf =================================================================== --- buildrom-devel/config/platforms/m57sli.conf (rev 0) +++ buildrom-devel/config/platforms/m57sli.conf 2007-09-12 21:04:42 UTC (rev 34) @@ -0,0 +1,38 @@ +# Support for the Gigabyte M57SLI-S4 board + +#### Platform configuration + +CC=gcc +STRIP=strip +AS=as + +TARGET_ARCH=i686 +CFLAGS_platform = -m32 + +# Targets + +KERNEL_MK=$(PACKAGE_DIR)/kernel/m57sli-kernel.mk +LINUXBIOS_MK=$(PACKAGE_DIR)/linuxbios/m57sli-linuxbios.mk + +# kernel configuration (for LAB) + +KERNEL_VERSION=2.6.22.2 +KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/m57sli-defconfig +UCLIBC_ARCH=i386 + +# Etherboot configuration +ETHERBOOT_ARCH=i386 + +# LinuxBIOS configuration + +LINUXBIOS_VENDOR=gigabyte +LINUXBIOS_BOARD=m57sli +LINUXBIOS_CONFIG=Config.lb +LINUXBIOS_TDIR=m57sli +LINUXBIOS_TAG=2742 +LINUXBIOS_ROM_NAME=linuxbios.rom + +# FILO configuration + +FILO_CONFIG=m57sli-Config + From ward at gnu.org Wed Sep 12 23:05:04 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 17:05:04 -0400 Subject: [LinuxBIOS] buildrom: add config/platforms/m57sli.conf In-Reply-To: <20070912210223.GL4913@cosmic.amd.com> References: <20070912205710.GA19075@localdomain> <20070912210223.GL4913@cosmic.amd.com> Message-ID: <20070912210504.GA19222@localdomain> On Wed, Sep 12, 2007 at 03:02:23PM -0600, Jordan Crouse wrote: > On 12/09/07 16:57 -0400, Ward Vandewege wrote: > > -- > > Ward Vandewege > > Free Software Foundation - Senior System Administrator > > > Add the platform config file for the m57sli. This is the final patch of this > > set, which completes FILO/LAB payload support for the Gigabyte M57SLI-S4 > > motherboard. > > > > Signed-off-by: Ward Vandewege > Acked-by: Jordan Crouse And that's r34. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From uwe at hermann-uwe.de Wed Sep 12 23:37:54 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Wed, 12 Sep 2007 23:37:54 +0200 Subject: [LinuxBIOS] [PATCH] buildrom: make menuconfig support Message-ID: <20070912213753.GF22601@greenwood> See patch. 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: buildrom_menuconfig.patch Type: text/x-diff Size: 1590 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 jordan.crouse at amd.com Wed Sep 12 23:40:50 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 12 Sep 2007 15:40:50 -0600 Subject: [LinuxBIOS] buildrom: make menuconfig support In-Reply-To: <20070912213753.GF22601@greenwood> References: <20070912213753.GF22601@greenwood> Message-ID: <20070912214050.GM4913@cosmic.amd.com> On 12/09/07 23:37 +0200, Uwe Hermann wrote: > See patch. > > > Uwe. > -- > http://www.hermann-uwe.de | http://www.holsham-traders.de > http://www.crazy-hacks.org | http://www.unmaintained-free-software.org > Add support for 'make menuconfig' in buildrom. Until now, > only 'make oldconfig' would work. > > Signed-off-by: Uwe Hermann Acked-by: Jordan Crouse Thanks Uwe! > Index: scripts/kconfig/lxdialog/Makefile > =================================================================== > --- scripts/kconfig/lxdialog/Makefile (Revision 34) > +++ scripts/kconfig/lxdialog/Makefile (Arbeitskopie) > @@ -1,11 +1,13 @@ > # Makefile to build lxdialog package > # > > +CONFIG_SHELL := sh > + > check-lxdialog := ./check-lxdialog.sh > > HOSTCC ?= gcc > > -# Use reursively expanded variables so we do not call gcc unless > +# Use recursively expanded variables so we do not call gcc unless > # we really need to do so. (Do not call gcc as part of make mrproper) > HOST_EXTRACFLAGS = $(shell $(CONFIG_SHELL) $(check-lxdialog) -ccflags) > HOST_LOADLIBES = $(shell $(CONFIG_SHELL) $(check-lxdialog) -ldflags $(HOSTCC)) > @@ -22,5 +24,9 @@ > lxdialog-objs := checklist.o menubox.o textbox.o yesno.o inputbox.o \ > util.o lxdialog.o msgbox.o > > -lxdialog: $(lxdialog-objs) > - $(CC) -o lxdialog $(lxdialog-objs) > +lxdialog: dochecklxdialog $(lxdialog-objs) > + $(CC) $(HOST_LOADLIBES) -o lxdialog $(lxdialog-objs) > + > +%.o: %.c > + $(Q)$(HOSTCC) $(HOST_EXTRACFLAGS) $^ -c -o $@ > + > Index: Makefile > =================================================================== > --- Makefile (Revision 34) > +++ Makefile (Arbeitskopie) > @@ -94,4 +94,10 @@ > > defconfig: $(KCONFIG_DIR)/conf > @$(KCONFIG_DIR)/conf -d $(BASE_DIR)/Config.in > + > +menuconfig: > + @make -C $(KCONFIG_DIR)/lxdialog lxdialog > + @make -C $(KCONFIG_DIR) mconf > + @$(KCONFIG_DIR)/mconf $(BASE_DIR)/Config.in > + > endif > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From ward at gnu.org Wed Sep 12 23:59:04 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 17:59:04 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: add missing bin/boot-hdd file to initramfs skeleton Message-ID: <20070912215904.GA19590@localdomain> I simply forgot to add this file to my patch set. -- Ward Vandewege Free Software Foundation - Senior System Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: add-boot-hdd.patch Type: text/x-diff Size: 695 bytes Desc: not available URL: From ward at gnu.org Thu Sep 13 00:04:29 2007 From: ward at gnu.org (Ward Vandewege) Date: Wed, 12 Sep 2007 18:04:29 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: make menuconfig support In-Reply-To: <20070912213753.GF22601@greenwood> References: <20070912213753.GF22601@greenwood> Message-ID: <20070912220429.GA19636@localdomain> On Wed, Sep 12, 2007 at 11:37:54PM +0200, Uwe Hermann wrote: > See patch. > > > Uwe. > -- > http://www.hermann-uwe.de | http://www.holsham-traders.de > http://www.crazy-hacks.org | http://www.unmaintained-free-software.org > Add support for 'make menuconfig' in buildrom. Until now, > only 'make oldconfig' would work. > > Signed-off-by: Uwe Hermann Acked-by: Ward Vandewege -- Ward Vandewege Free Software Foundation - Senior System Administrator From svn at openbios.org Thu Sep 13 00:11:33 2007 From: svn at openbios.org (svn at openbios.org) Date: Thu, 13 Sep 2007 00:11:33 +0200 Subject: [LinuxBIOS] r2771 - in trunk/LinuxBIOSv2: src/mainboard/msi src/mainboard/msi/ms6178 targets/msi targets/msi/ms6178 Message-ID: Author: uwe Date: 2007-09-13 00:11:33 +0200 (Thu, 13 Sep 2007) New Revision: 2771 Added: trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/ trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/Config.lb trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/Options.lb trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/auto.c trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/chip.h trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/mainboard.c trunk/LinuxBIOSv2/targets/msi/ms6178/ trunk/LinuxBIOSv2/targets/msi/ms6178/Config.lb Log: Add initial support for the Intel 810 based board MSI MS-6178. Signed-off-by: Uwe Hermann Acked-by: Corey Osgood Added: trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/Config.lb (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/Config.lb 2007-09-12 22:11:33 UTC (rev 2771) @@ -0,0 +1,133 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2007 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 +## + +if USE_FALLBACK_IMAGE + default ROM_SECTION_SIZE = FALLBACK_SIZE + default ROM_SECTION_OFFSET = (ROM_SIZE - FALLBACK_SIZE) +else + default ROM_SECTION_SIZE = (ROM_SIZE - FALLBACK_SIZE) + default ROM_SECTION_OFFSET = 0 +end +default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) +default PAYLOAD_SIZE = (ROM_SECTION_SIZE - ROM_IMAGE_SIZE) +default _ROMBASE = (CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE) +default XIP_ROM_SIZE = 65536 +default XIP_ROM_BASE = (_ROMBASE + ROM_IMAGE_SIZE - XIP_ROM_SIZE) +arch i386 end +driver mainboard.o +if HAVE_PIRQ_TABLE object irq_tables.o end +# object reset.o +makerule ./failover.E + depends "$(MAINBOARD)/../../../lib/failover.c ./romcc" + action "./romcc -E -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/../../../lib/failover.c -o $@" +end +makerule ./failover.inc + depends "$(MAINBOARD)/../../../lib/failover.c ./romcc" + action "./romcc -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/../../../lib/failover.c -o $@" +end +makerule ./auto.E + # depends "$(MAINBOARD)/auto.c option_table.h ./romcc" + depends "$(MAINBOARD)/auto.c ./romcc" + action "./romcc -E -mcpu=p2 -O -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/auto.c -o $@" +end +makerule ./auto.inc + # depends "$(MAINBOARD)/auto.c option_table.h ./romcc" + depends "$(MAINBOARD)/auto.c ./romcc" + action "./romcc -mcpu=p2 -O -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/auto.c -o $@" +end +mainboardinit cpu/x86/16bit/entry16.inc +mainboardinit cpu/x86/32bit/entry32.inc +ldscript /cpu/x86/16bit/entry16.lds +ldscript /cpu/x86/32bit/entry32.lds +if USE_FALLBACK_IMAGE + mainboardinit cpu/x86/16bit/reset16.inc + ldscript /cpu/x86/16bit/reset16.lds +else + mainboardinit cpu/x86/32bit/reset32.inc + ldscript /cpu/x86/32bit/reset32.lds +end +mainboardinit arch/i386/lib/cpu_reset.inc +mainboardinit arch/i386/lib/id.inc +ldscript /arch/i386/lib/id.lds +if USE_FALLBACK_IMAGE + ldscript /arch/i386/lib/failover.lds + mainboardinit ./failover.inc +end +mainboardinit cpu/x86/fpu/enable_fpu.inc +mainboardinit cpu/x86/mmx/enable_mmx.inc +mainboardinit ./auto.inc +mainboardinit cpu/x86/mmx/disable_mmx.inc +dir /pc80 +config chip.h + +chip northbridge/intel/i82810 # Northbridge + device pci_domain 0 on + device pci 0.0 on end # Host bridge + device pci 1.0 off # Onboard video + # chip drivers/pci/onboard + # device pci 1.0 on end + # register "rom_address" = "0xfff80000" + # end + end + chip southbridge/intel/i82801xx # Southbridge + device pci 1e.0 on # PCI bridge + # chip drivers/pci/onboard + # device pci 1.0 on end + # register "rom_address" = "0xfff80000" + # end + end + device pci 1f.0 on # ISA bridge + chip superio/winbond/w83627hf + device pnp 2e.8 on # Floppy + # io 0x60 = 0x3f0 + io 0x60 = 0x3f2 + irq 0x70 = 6 + drq 0x74 = 2 + end + device pnp 2e.9 on # Com1 + io 0x60 = 0x3f8 + irq 0x70 = 4 + end + device pnp 2e.a on # Parallel port + io 0x60 = 0x378 + irq 0x70 = 7 + drq 0x74 = 3 + end + device pnp 2e.b on # PS/2 keyboard/mouse + io 0x60 = 0x60 + io 0x62 = 0x64 + irq 0x70 = 1 # Keyboard interrupt + irq 0x72 = 12 # Mouse interrupt + end + device pnp 2e.c on end # Game port + device pnp 2e.d on end # MIDI / MPU401 + end + end + device pci 1f.1 on end # IDE + device pci 1f.2 on end # USB + device pci 1f.3 on end # SMBus + device pci 1f.5 on end # AC'97 audio + device pci 1f.6 off end # AC'97 modem + end + end + chip cpu/intel/socket_PGA370 # CPU + end +end + Added: trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/Options.lb (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/Options.lb 2007-09-12 22:11:33 UTC (rev 2771) @@ -0,0 +1,95 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2007 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 +## + +uses HAVE_MP_TABLE +uses HAVE_PIRQ_TABLE +uses USE_FALLBACK_IMAGE +uses HAVE_FALLBACK_BOOT +uses HAVE_HARD_RESET +uses HAVE_OPTION_TABLE +uses USE_OPTION_TABLE +uses CONFIG_ROM_PAYLOAD +uses IRQ_SLOT_COUNT +uses MAINBOARD +uses MAINBOARD_VENDOR +uses MAINBOARD_PART_NUMBER +uses LINUXBIOS_EXTRA_VERSION +uses ARCH +uses FALLBACK_SIZE +uses STACK_SIZE +uses HEAP_SIZE +uses ROM_SIZE +uses ROM_SECTION_SIZE +uses ROM_IMAGE_SIZE +uses ROM_SECTION_SIZE +uses ROM_SECTION_OFFSET +uses CONFIG_ROM_PAYLOAD_START +uses CONFIG_COMPRESSED_PAYLOAD_LZMA +uses PAYLOAD_SIZE +uses _ROMBASE +uses _RAMBASE +uses XIP_ROM_SIZE +uses XIP_ROM_BASE +uses HAVE_MP_TABLE +uses CROSS_COMPILE +uses CC +uses HOSTCC +uses OBJCOPY +uses DEFAULT_CONSOLE_LOGLEVEL +uses MAXIMUM_CONSOLE_LOGLEVEL +uses CONFIG_CONSOLE_SERIAL8250 +uses TTYS0_BAUD +uses TTYS0_BASE +uses TTYS0_LCS +uses CONFIG_UDELAY_TSC +uses CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 +uses CONFIG_CONSOLE_VGA +uses CONFIG_PCI_ROM_RUN + +default HAVE_FALLBACK_BOOT = 1 +default HAVE_MP_TABLE = 0 +default HAVE_HARD_RESET = 0 +default HAVE_PIRQ_TABLE = 0 # FIXME +default IRQ_SLOT_COUNT = 4 # FIXME +default HAVE_OPTION_TABLE = 0 +#default USE_OPTION_TABLE = !USE_FALLBACK_IMAGE +default USE_OPTION_TABLE = 0 +default ROM_IMAGE_SIZE = 64 * 1024 +default FALLBACK_SIZE = 128 * 1024 +default STACK_SIZE = 0x2000 +default HEAP_SIZE = 0x4000 +default _RAMBASE = 0x00004000 +default CONFIG_ROM_PAYLOAD = 1 +default CROSS_COMPILE = "" +default CC = "$(CROSS_COMPILE)gcc -m32" +default HOSTCC = "gcc" +default CONFIG_CONSOLE_SERIAL8250 = 1 +default TTYS0_BAUD = 115200 +default TTYS0_BASE = 0x3f8 +default TTYS0_LCS = 0x3 +default DEFAULT_CONSOLE_LOGLEVEL = 9 +default MAXIMUM_CONSOLE_LOGLEVEL = 9 +default CONFIG_UDELAY_TSC = 1 +default CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 = 1 +default CONFIG_CONSOLE_VGA = 1 +default CONFIG_PCI_ROM_RUN = 1 + +end + Added: trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/auto.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/auto.c (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/auto.c 2007-09-12 22:11:33 UTC (rev 2771) @@ -0,0 +1,70 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2007 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 + */ + +#define ASSEMBLY 1 + +#include +#include +#include +#include +#include +#include +#include "pc80/serial.c" +#include "arch/i386/lib/console.c" +#include "ram/ramtest.c" +#include "superio/winbond/w83627hf/w83627hf_early_serial.c" +#include "northbridge/intel/i82810/raminit.h" +#include "cpu/x86/mtrr/earlymtrr.c" +#include "cpu/x86/bist.h" +#include "southbridge/intel/i82801xx/i82801xx_early_smbus.c" +#include "pc80/udelay_io.c" +#include "northbridge/intel/i82810/raminit.c" +#include "sdram/generic_sdram.c" + +#define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1) + +static void main(unsigned long bist) +{ + static const struct mem_controller memctrl[] = { + { + .d0 = PCI_DEV(0, 0, 0), + .channel0 = {0x50, 0x51}, + } + }; + + if (bist == 0) + early_mtrr_init(); + + enable_smbus(); + + /* FIXME */ + outb(0x87, 0x2e); + outb(0x87, 0x2e); + pnp_write_config(SERIAL_DEV, 0x24, 0x84 | (1 << 6)); + w83627hf_enable_serial(SERIAL_DEV, TTYS0_BASE); + outb(0x87, 0xaa); + + uart_init(); + console_init(); + report_bist_failure(bist); + /* dump_spd_registers(&memctrl[0]); */ + sdram_initialize(sizeof(memctrl) / sizeof(memctrl[0]), memctrl); + /* ram_check(0, 640 * 1024); */ +} Added: trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/chip.h (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/chip.h 2007-09-12 22:11:33 UTC (rev 2771) @@ -0,0 +1,25 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2007 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 + */ + +extern struct chip_operations mainboard_msi_ms6178_ops; + +struct mainboard_msi_ms6178_config { + int nothing; +}; Added: trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/mainboard.c (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/mainboard.c 2007-09-12 22:11:33 UTC (rev 2771) @@ -0,0 +1,26 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2007 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 "chip.h" + +struct chip_operations mainboard_msi_ms6178_ops = { + CHIP_NAME("MSI MS-6178 Mainboard") +}; Added: trunk/LinuxBIOSv2/targets/msi/ms6178/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/msi/ms6178/Config.lb (rev 0) +++ trunk/LinuxBIOSv2/targets/msi/ms6178/Config.lb 2007-09-12 22:11:33 UTC (rev 2771) @@ -0,0 +1,39 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2007 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 +## + +target ms6178 +mainboard msi/ms6178 + +option ROM_SIZE = 512 * 1024 +# option ROM_SIZE = (512 * 1024) - (32 * 1024) + +romimage "normal" + option USE_FALLBACK_IMAGE = 0 + option LINUXBIOS_EXTRA_VERSION = ".0Normal" + payload /tmp/filo.elf +end + +romimage "fallback" + option USE_FALLBACK_IMAGE = 1 + option LINUXBIOS_EXTRA_VERSION = ".0Fallback" + payload /tmp/filo.elf +end + +buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" From uwe at hermann-uwe.de Thu Sep 13 00:13:39 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 13 Sep 2007 00:13:39 +0200 Subject: [LinuxBIOS] [PATCH] Initial support for the MSI MS-6178 (i810-based) In-Reply-To: <46D78E6D.9080201@gmail.com> References: <20070830194234.GA7091@greenwood> <46D78E6D.9080201@gmail.com> Message-ID: <20070912221339.GG22601@greenwood> On Thu, Aug 30, 2007 at 11:43:41PM -0400, Corey Osgood wrote: > > here's an initial patch for the MSI MS-6178 mainboard. > > > > Looks like a good start (see comments below) > > Acked-by: Corey Osgood Thanks, committed for now in r2771, but it'll need some fixes; will send extra patches for that. 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 rasmus at wiman.org Thu Sep 13 00:21:32 2007 From: rasmus at wiman.org (Rasmus Wiman) Date: Thu, 13 Sep 2007 00:21:32 +0200 Subject: [LinuxBIOS] AMD 690G chipset support in LinuxBIOS v2 In-Reply-To: <20070912134710.GB22601@greenwood> References: <46893e740709101937j32a4f32bu6dc296a628d36dc6@mail.gmail.com> <20070911092007.0915d2b7.rasmus@wiman.org> <46893e740709101937j32a4f32bu6dc296a628d36dc6@mail.gmail.com> <20070911190432.30652.qmail@stuge.se> <20070912134710.GB22601@greenwood> Message-ID: <20070913002132.c843035e.rasmus@wiman.org> Uwe Hermann wrote: > On Tue, Sep 11, 2007 at 09:04:32PM +0200, Peter Stuge wrote: > > On Tue, Sep 11, 2007 at 09:37:04AM +0700, Darmawan Salihun wrote: > > > Is there any support coming down the road? > > > > I haven't seen it mentioned. > > See Marc's post, they're working on it (which is great!) I didn't read that one, but now I have started checking out the AMD 690 options too. I thought the NV6100 were the cheapset k8 MB:s here in Sweden, but now I just saw a Gigabyte GA-MA69VM-S2 ATX board for 373 kronor, and a MSI K9AGM2-L micro ATX for 464. There might be even cheaper ones, I did not do a thorough search. I might get myself the MSI board when I can afford it. I suppose I can't do much LB developing myself until Marc has a go on it, but what the hell. Most of my computers are old and slow anyway and I need a box to play with Solaris. /Rasmus From uwe at hermann-uwe.de Thu Sep 13 00:25:55 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 13 Sep 2007 00:25:55 +0200 Subject: [LinuxBIOS] [PATCH] Build fix for MSI MS-6178 Message-ID: <20070912222555.GH22601@greenwood> See patch. In addition to _this_ patch, my failover.c patch (no ACKs yet) needs to be committed, too, to really fix the build. 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: v2_msi_ms6178_buildfix.patch Type: text/x-diff Size: 1326 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 svn at openbios.org Thu Sep 13 00:27:10 2007 From: svn at openbios.org (svn at openbios.org) Date: Thu, 13 Sep 2007 00:27:10 +0200 Subject: [LinuxBIOS] r35 - in buildrom-devel: . scripts/kconfig/lxdialog Message-ID: Author: uwe Date: 2007-09-13 00:27:10 +0200 (Thu, 13 Sep 2007) New Revision: 35 Modified: buildrom-devel/Makefile buildrom-devel/scripts/kconfig/lxdialog/Makefile Log: Add support for 'make menuconfig' in buildrom. Until now, only 'make oldconfig' would work. Signed-off-by: Uwe Hermann Acked-by: Jordan Crouse Acked-by: Ward Vandewege Modified: buildrom-devel/Makefile =================================================================== --- buildrom-devel/Makefile 2007-09-12 21:04:42 UTC (rev 34) +++ buildrom-devel/Makefile 2007-09-12 22:27:10 UTC (rev 35) @@ -94,4 +94,10 @@ defconfig: $(KCONFIG_DIR)/conf @$(KCONFIG_DIR)/conf -d $(BASE_DIR)/Config.in + +menuconfig: + @make -C $(KCONFIG_DIR)/lxdialog lxdialog + @make -C $(KCONFIG_DIR) mconf + @$(KCONFIG_DIR)/mconf $(BASE_DIR)/Config.in + endif Modified: buildrom-devel/scripts/kconfig/lxdialog/Makefile =================================================================== --- buildrom-devel/scripts/kconfig/lxdialog/Makefile 2007-09-12 21:04:42 UTC (rev 34) +++ buildrom-devel/scripts/kconfig/lxdialog/Makefile 2007-09-12 22:27:10 UTC (rev 35) @@ -1,11 +1,13 @@ # Makefile to build lxdialog package # +CONFIG_SHELL := sh + check-lxdialog := ./check-lxdialog.sh HOSTCC ?= gcc -# Use reursively expanded variables so we do not call gcc unless +# Use recursively expanded variables so we do not call gcc unless # we really need to do so. (Do not call gcc as part of make mrproper) HOST_EXTRACFLAGS = $(shell $(CONFIG_SHELL) $(check-lxdialog) -ccflags) HOST_LOADLIBES = $(shell $(CONFIG_SHELL) $(check-lxdialog) -ldflags $(HOSTCC)) @@ -22,5 +24,9 @@ lxdialog-objs := checklist.o menubox.o textbox.o yesno.o inputbox.o \ util.o lxdialog.o msgbox.o -lxdialog: $(lxdialog-objs) - $(CC) -o lxdialog $(lxdialog-objs) +lxdialog: dochecklxdialog $(lxdialog-objs) + $(CC) $(HOST_LOADLIBES) -o lxdialog $(lxdialog-objs) + +%.o: %.c + $(Q)$(HOSTCC) $(HOST_EXTRACFLAGS) $^ -c -o $@ + From uwe at hermann-uwe.de Thu Sep 13 00:28:11 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 13 Sep 2007 00:28:11 +0200 Subject: [LinuxBIOS] [PATCH] buildrom: make menuconfig support In-Reply-To: <20070912220429.GA19636@localdomain> References: <20070912213753.GF22601@greenwood> <20070912220429.GA19636@localdomain> Message-ID: <20070912222811.GI22601@greenwood> On Wed, Sep 12, 2007 at 06:04:29PM -0400, Ward Vandewege wrote: > > Add support for 'make menuconfig' in buildrom. Until now, > > only 'make oldconfig' would work. > > > > Signed-off-by: Uwe Hermann > Acked-by: Jordan Crouse > Acked-by: Ward Vandewege Thanks, r35. 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 tsylla at gmail.com Thu Sep 13 00:43:37 2007 From: tsylla at gmail.com (Tom Sylla) Date: Wed, 12 Sep 2007 18:43:37 -0400 Subject: [LinuxBIOS] [PATCH] buildrom: make menuconfig support In-Reply-To: <20070912213753.GF22601@greenwood> References: <20070912213753.GF22601@greenwood> Message-ID: <57947bf80709121543j6ac3d340w7eb526c55e9e7576@mail.gmail.com> Hm, what about at least a tiny update to README that says that menuconfig is available? (it currently says to use oldconfig) On 9/12/07, Uwe Hermann wrote: > See patch. > > > 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) > > iD8DBQFG6FwxXdVoV3jWIbQRAhWvAJ90GkxvCNZyIUXG+udXVsgVPxDaXgCgiub5 > RAzlHgsXp3pu91Pl/7Ah2AI= > =K+Zb > -----END PGP SIGNATURE----- > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > > From info at coresystems.de Thu Sep 13 00:58:33 2007 From: info at coresystems.de (LinuxBIOS information) Date: Thu, 13 Sep 2007 00:58:33 +0200 Subject: [LinuxBIOS] r2771 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2771 to the LinuxBIOS source repository and caused the following changes: Change Log: Add initial support for the Intel 810 based board MSI MS-6178. Signed-off-by: Uwe Hermann Acked-by: Corey Osgood Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2771&device=hdama&vendor=arima Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2771&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2771&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2771&device=juki-511p&vendor=iei Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2771&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2771&device=dk8x&vendor=iwill Configuration of msi:ms6178 is still broken If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From svn at openbios.org Thu Sep 13 03:20:20 2007 From: svn at openbios.org (svn at openbios.org) Date: Thu, 13 Sep 2007 03:20:20 +0200 Subject: [LinuxBIOS] r36 - buildrom-devel/skeleton/bin Message-ID: Author: uwe Date: 2007-09-13 03:20:19 +0200 (Thu, 13 Sep 2007) New Revision: 36 Added: buildrom-devel/skeleton/bin/boot-hdd Log: Add missing boot-hdd file to the initramfs skeleton. Required for LAB. Signed-off-by: Ward Vandewege Acked-by: Uwe Hermann Added: buildrom-devel/skeleton/bin/boot-hdd =================================================================== --- buildrom-devel/skeleton/bin/boot-hdd (rev 0) +++ buildrom-devel/skeleton/bin/boot-hdd 2007-09-13 01:20:19 UTC (rev 36) @@ -0,0 +1,17 @@ +#!/bin/sh + +. /bin/boot.functions + +DIR=/hdd/ + +mkdir $DIR +mount -oro /dev/sda1 $DIR + +if [ $? -eq 0 ]; then + doboot $DIR + message "ERROR: Couldn't boot from the hdd." + exit 1 +fi + +message "ERROR: Couldn't mount the hdd." +exit 1 Property changes on: buildrom-devel/skeleton/bin/boot-hdd ___________________________________________________________________ Name: svn:executable + * From uwe at hermann-uwe.de Thu Sep 13 03:22:04 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 13 Sep 2007 03:22:04 +0200 Subject: [LinuxBIOS] [PATCH] buildrom: add missing bin/boot-hdd file to initramfs skeleton In-Reply-To: <20070912215904.GA19590@localdomain> References: <20070912215904.GA19590@localdomain> Message-ID: <20070913012202.GK22601@greenwood> On Wed, Sep 12, 2007 at 05:59:04PM -0400, Ward Vandewege wrote: > Add missing boot-hdd file to the initramfs skeleton. Required for LAB. > > Signed-off-by: Ward Vandewege Tested and works. r36. 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 Sep 13 03:27:18 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 13 Sep 2007 03:27:18 +0200 Subject: [LinuxBIOS] [PATCH] Add more PCI config data to device structure In-Reply-To: <1189546178.7001.28.camel@jens-laptop> References: <1189546178.7001.28.camel@jens-laptop> Message-ID: <20070913012718.GL22601@greenwood> On Tue, Sep 11, 2007 at 11:29:38PM +0200, Jens Freimann wrote: > this is a patch to add more data from the PCI configuration space to the > device struct. It is needed for example to create a device tree in Open > Firmware from the LB device tree. > > There is one patch vor v2 and another one for v3. > > Bye, > Jens > Add more information to the device structure, so an Open Firmware > device tree can be created from data in struct device. > > Signed-off-by: Jens Freimann > > Index: src/devices/pci_device.c > =================================================================== > --- src/devices/pci_device.c (revision 2770) > +++ src/devices/pci_device.c (working copy) > @@ -972,7 +972,34 @@ > /* Read the rest of the pci configuration information */ > hdr_type = pci_read_config8(dev, PCI_HEADER_TYPE); > class = pci_read_config32(dev, PCI_CLASS_REVISION); > - > + > + u16 status = pci_read_config16(dev, PCI_STATUS); > + dev->status = status; > + > + u8 revision = pci_read_config8(dev, PCI_REVISION_ID); > + dev->revision = revision; > + > + u8 cache_line = pci_read_config8(dev, PCI_CACHE_LINE_SIZE); > + dev->cache_line = cache_line; > + > + u8 irq_line = pci_read_config8(dev, PCI_INTERRUPT_LINE); > + dev->irq_line = irq_line; > + > + u8 irq_pin = pci_read_config8(dev, PCI_INTERRUPT_PIN); > + dev->irq_pin = irq_pin; > + > + u8 min_gnt = pci_read_config8(dev, PCI_MIN_GNT); > + dev->min_gnt = min_gnt; > + > + u8 max_lat = pci_read_config8(dev, PCI_MAX_LAT); > + dev->max_lat = max_lat; > + > + u16 subsystem_vendor = pci_read_config16(dev, PCI_SUBSYSTEM_VENDOR_ID); > + dev->subsystem_vendor = subsystem_vendor; > + > + u16 subsystem_device = pci_read_config16(dev, PCI_SUBSYSTEM_ID); > + dev->subsystem_device = subsystem_device; Is there a reaons why this wouldn't work? dev->status = pci_read_config16(dev, PCI_STATUS); dev->revision = pci_read_config8(dev, PCI_REVISION_ID); dev->cache_line = pci_read_config8(dev, PCI_CACHE_LINE_SIZE); dev->irq_line = pci_read_config8(dev, PCI_INTERRUPT_LINE); dev->irq_pin = pci_read_config8(dev, PCI_INTERRUPT_PIN); dev->min_gnt = pci_read_config8(dev, PCI_MIN_GNT); dev->max_lat = pci_read_config8(dev, PCI_MAX_LAT); dev->subsystem_vendor = pci_read_config16(dev, PCI_SUBSYSTEM_VENDOR_ID); dev->subsystem_device = pci_read_config16(dev, PCI_SUBSYSTEM_ID); (much shorter) > + > /* Store the interesting information in the device structure */ > dev->vendor = id & 0xffff; > dev->device = (id >> 16) & 0xffff; > Index: src/include/device/device.h > =================================================================== > --- src/include/device/device.h (revision 2770) > +++ src/include/device/device.h (working copy) > @@ -68,9 +68,19 @@ > device_t sibling; /* next device on this bus */ > device_t next; /* chain of all devices */ > > + char dtsname[64]; > struct device_path path; > unsigned vendor; > unsigned device; > + u16 status; > + u8 revision; > + u8 cache_line; > + u8 irq_line; > + u8 irq_pin; > + u8 min_gnt; > + u8 max_lat; > + u16 subsystem_vendor; > + u16 subsystem_device; Use TABs for indentation as per coding guidelines, please. The patch looks good to me otherwise, but someone with more OFW knowledge should probably look over it, 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 uwe at hermann-uwe.de Thu Sep 13 03:32:53 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 13 Sep 2007 03:32:53 +0200 Subject: [LinuxBIOS] [PATCH] Add pointer to device tree to LinuxBIOS table In-Reply-To: <1189546220.7001.29.camel@jens-laptop> References: <1189546220.7001.29.camel@jens-laptop> Message-ID: <20070913013253.GM22601@greenwood> On Tue, Sep 11, 2007 at 11:30:20PM +0200, Jens Freimann wrote: > Add a pointer to the root device to the LinuxBIOS table. Used for > example to access the device list from Open Firmware. > > Signed-off-by: Jens Freimann > > Index: src/include/boot/linuxbios_tables.h > =================================================================== > --- src/include/boot/linuxbios_tables.h (Revision 2770) > +++ src/include/boot/linuxbios_tables.h (Arbeitskopie) > @@ -106,6 +106,12 @@ > struct lb_memory_range map[0]; > }; > > +struct lb_devtree { > + uint32_t tag; > + uint32_t size; > + uint32_t dev_root_ptr; /* pointer to root device */ > +}; Fix the coding style please (TABs, not spaces, for indentation). > #define LB_TAG_HWRPB 0x0002 > struct lb_hwrpb { > uint32_t tag; > Index: src/arch/i386/boot/linuxbios_table.c > =================================================================== > --- src/arch/i386/boot/linuxbios_table.c (Revision 2770) > +++ src/arch/i386/boot/linuxbios_table.c (Arbeitskopie) > @@ -348,6 +348,27 @@ > return mem; > } > > +/** > + * Add entire device tree to LinuxBIOS table > + * > + * @param head Pointer to lbtable header > + */ > +struct lb_devtree *lb_devtree(struct lb_header *head) > +{ > + struct lb_devtree *lbdev = NULL; > + struct device *dev = NULL; > + > + lbdev = (struct lb_devtree *)lb_new_record(head); > + lbdev->tag = 0xE; What is 0xe? Should probably be some #define with a descriptive name for better readability? > + char buf[64]; Why? It's never used in the patch(?) > /* Record our various random string information */ > lb_strings(head); > > + /* Record the LinuxBIOS device tree */ > + lb_devtree(head); > + > /* Remember where my valid memory ranges are */ > return lb_table_fini(head); Someone should double-check that this doesn't break any existing tools (lxbios?) or expectations in the code. Do we consider this as "public API" of some sort or doesn't it matter at all if it changes? 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 Sep 13 03:36:16 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 13 Sep 2007 03:36:16 +0200 Subject: [LinuxBIOS] [PATCH] AMD CS5530 rewrite Message-ID: <20070913013616.GN22601@greenwood> Hi, I posted this several weeks ago (and it got an ACK), but I never comitted it; I'm reposting again just in case, as I did some improvements on the code. This is verified to build and work on real hardware (ASI MB-5BLMP). It's quite likely that this is needed to fix one or two other targets (one in the repo and one still in development). 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: v2_cs5530_rewrite2.patch Type: text/x-diff Size: 15436 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 corey.osgood at gmail.com Thu Sep 13 05:17:23 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Wed, 12 Sep 2007 23:17:23 -0400 Subject: [LinuxBIOS] [PATCH] Build fix for MSI MS-6178 In-Reply-To: <20070912222555.GH22601@greenwood> References: <20070912222555.GH22601@greenwood> Message-ID: <46E8ABC3.9090903@gmail.com> Uwe Hermann wrote: > See patch. > > In addition to _this_ patch, my failover.c patch (no ACKs yet) needs to > be committed, too, to really fix the build. > > > Uwe. > Both patches (I don't want to dig for the failover.c patch but I'm familiar with it): Acked-by: Corey Osgood 1 comment below ;) > ------------------------------------------------------------------------ > > Fix the build for the MSI MS-6178 target (wrong location of the common > failover.c file). > > Signed-off-by: Uwe Hermann > > Index: src/mainboard/msi/ms6178/Config.lb > =================================================================== > --- src/mainboard/msi/ms6178/Config.lb (Revision 2771) > +++ src/mainboard/msi/ms6178/Config.lb (Arbeitskopie) > @@ -35,12 +35,12 @@ > if HAVE_PIRQ_TABLE object irq_tables.o end > # object reset.o > makerule ./failover.E > - depends "$(MAINBOARD)/../../../lib/failover.c ./romcc" > - action "./romcc -E -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/../../../lib/failover.c -o $@" > + depends "$(MAINBOARD)/../../../arch/i386/lib/failover.c ./romcc" > Is there really no simpler way of stating this line? > + action "./romcc -E -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/../../../arch/i386/lib/failover.c -o $@" > end > makerule ./failover.inc > - depends "$(MAINBOARD)/../../../lib/failover.c ./romcc" > - action "./romcc -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/../../../lib/failover.c -o $@" > + depends "$(MAINBOARD)/../../../arch/i386/lib/failover.c ./romcc" > + action "./romcc -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/../../../arch/i386/lib/failover.c -o $@" > end > makerule ./auto.E > # depends "$(MAINBOARD)/auto.c option_table.h ./romcc" > From Libo.Feng at amd.com Thu Sep 13 05:37:32 2007 From: Libo.Feng at amd.com (Feng, Libo) Date: Thu, 13 Sep 2007 11:37:32 +0800 Subject: [LinuxBIOS] A question of LPC Message-ID: BIOS FLASH is attached on LPC. But the data in BIOS should eventually appear in the data bus of processor. How do the data in BIOS get to the data bus of processor? In the MSI ms9185, processor is connected with BCM 5780 via hyper transport, the BCM 5780 is then connected with BCM 5785 via hyper transport, and LPC is attached to BCM 5785. However, when the first instruction is fetched from BIOS, HT is not well initialized yet. How the data get to the data bus of processor? Best Regards ??? Feng Libo @ AMD Ext: 20906 Mobile Phone: 13683249071 Office Phone: 0086-010-62801406 -------------- next part -------------- An HTML attachment was scrubbed... URL: From darmawan.salihun at gmail.com Thu Sep 13 06:20:56 2007 From: darmawan.salihun at gmail.com (Darmawan Salihun) Date: Thu, 13 Sep 2007 11:20:56 +0700 Subject: [LinuxBIOS] A question of LPC In-Reply-To: References: Message-ID: <46893e740709122120i597175ffj6c016552e59af62d@mail.gmail.com> Hi, On 9/13/07, Feng, Libo wrote: > > > BIOS FLASH is attached on LPC. But the data in BIOS should eventually > appear in the data bus of processor. How do the data in BIOS get to the data > bus of processor? In the MSI ms9185, processor is connected with BCM 5780 > via hyper transport, the BCM 5780 is then connected with BCM 5785 via hyper > transport, and LPC is attached to BCM 5785. However, when the first > instruction is fetched from BIOS, HT is not well initialized yet. How the > data get to the data bus of processor? > > Best Regards > > ??? Feng Libo @ AMD Ext: 20906 > Mobile Phone: 13683249071 > Office Phone: 0086-010-62801406 > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > I think HT has default values for link width and speed, right? That way, data can still be sent to the processor. I'm not too sure about newer version of HT specs, because it was HT version 1.0 spec that I read back then. CMIIW Regards, Darmawan Salihun -------------------------------------------------------------------- -= Human knowledge belongs to the world =- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Libo.Feng at amd.com Thu Sep 13 06:29:22 2007 From: Libo.Feng at amd.com (Feng, Libo) Date: Thu, 13 Sep 2007 12:29:22 +0800 Subject: [LinuxBIOS] A question of LPC In-Reply-To: <46893e740709122120i597175ffj6c016552e59af62d@mail.gmail.com> References: <46893e740709122120i597175ffj6c016552e59af62d@mail.gmail.com> Message-ID: Hi, Yes, HT has default settings when power on. But another question is: if data is transferred through this route, there must be a serial-to-parallel module in either BCM 5780 or processor. Because the data bus of processor is wider than HT link. But I can' t find the module. Best Regards ??? Feng Libo @ AMD Ext: 20906 Mobile Phone: 13683249071 Office Phone: 0086-010-62801406 ________________________________ From: Darmawan Salihun [mailto:darmawan.salihun at gmail.com] Sent: Thursday, September 13, 2007 12:21 PM To: Feng, Libo; linuxbios Subject: Re: [LinuxBIOS] A question of LPC Hi, On 9/13/07, Feng, Libo wrote: BIOS FLASH is attached on LPC. But the data in BIOS should eventually appear in the data bus of processor. How do the data in BIOS get to the data bus of processor? In the MSI ms9185, processor is connected with BCM 5780 via hyper transport, the BCM 5780 is then connected with BCM 5785 via hyper transport, and LPC is attached to BCM 5785. However, when the first instruction is fetched from BIOS, HT is not well initialized yet. How the data get to the data bus of processor? Best Regards ??? Feng Libo @ AMD Ext: 20906 Mobile Phone: 13683249071 Office Phone: 0086-010-62801406 -- linuxbios mailing list linuxbios at linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios I think HT has default values for link width and speed, right? That way, data can still be sent to the processor. I'm not too sure about newer version of HT specs, because it was HT version 1.0 spec that I read back then. CMIIW Regards, Darmawan Salihun -------------------------------------------------------------------- -= Human knowledge belongs to the world =- -------------- next part -------------- An HTML attachment was scrubbed... URL: From emblinux at yahoo.com Thu Sep 13 07:30:27 2007 From: emblinux at yahoo.com (embedded linux) Date: Wed, 12 Sep 2007 22:30:27 -0700 (PDT) Subject: [LinuxBIOS] linuxbios on decTOP Message-ID: <721087.36289.qm@web45516.mail.sp1.yahoo.com> DecTOP (AMD PIC) is selling for $99 or (4 for $297) http://www.dataevolution.com/dectop%20info%202.htm Since this is similar to OLPC hardware, I assume this is supported? Anyone has any experience with this hardware? Please forgive me this dicussion has happened before. Thanks, Krane --------------------------------- Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, and more! -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at smittys.pointclark.net Thu Sep 13 08:40:16 2007 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Thu, 13 Sep 2007 02:40:16 -0400 Subject: [LinuxBIOS] i82801DB PCI Bridge locking up In-Reply-To: <20070912122558.GA22601@greenwood> References: <20070912032617.gthkfz5g408k04gs@www.smittys.pointclark.net> <20070912122558.GA22601@greenwood> Message-ID: <20070913024016.fajh2qt7c4wk848w@www.smittys.pointclark.net> Quoting Uwe Hermann : > On Wed, Sep 12, 2007 at 03:26:17AM -0400, joe at smittys.pointclark.net wrote: >> Hello, >> Here is an overview of my problem. When booting, LB freezes when >> trying to "Enabling resources..." of the PCI Bridge (00:1e.0). I am >> using the i82801xx code. I think I figured out what is wrong but I >> don't know why. "Reading resources..." of the device seems to go ok >> (see below) but when it comes time to "Setting resources..." I don't >> see the device anywhere (00:1e.0). And then it just locks up at >> "Enabling resources...". >> >> Anyone have any idea why the PCI Bridge is not showing up in "Setting >> resources..."??? Please help, this is my last obsticle to getting this >> to boot (i hope). > > Please post a patch with all your changes against current svn so we can > help with debugging. > I will as soon as I get a chance to create a patch. I think I may know where the issue lies but not sure how to fix it. First according to the pci_dev_set_resources() or pci_set_resource() function in pci_device.c if the resource is already stored or if resources is substractive it just returns, so I am assuming it is ok that I don't see it in "Setting resources...". Is that correct?? If so couldn't the report_resource_stored() function be added to these to output something?? Next, I think the bios is hanging on the enable_childrens_resources(dev); part of the pci_bus_enable_resources() function. I have no idea why but I will do some more testing in the morning. I have a feeling It may have to do with the onboard i82801DB nic (this is down from the PCI Bridge and would fall under the enable_childrens_resources?) that is not being detected for some reason. I noticed on one of the other Intel motherboard Config.Lb's that they indicated a pci rom for it. I wonder if my nic needs the pci rom to get it going, and this would solve the problem? Thanks - Joe From k_arlstrom at hotmail.com Wed Sep 12 22:14:47 2007 From: k_arlstrom at hotmail.com (Jonas K) Date: Wed, 12 Sep 2007 20:14:47 +0000 Subject: [LinuxBIOS] MSI k9n platinum Message-ID: HI! Im interested in the idea of a "upgraded", free bios, I just bought a new motherboard (msi k9n platinum) and started looking on your page and found that some guy started working on it allmost a year back (http://www.openbios.org/pipermail/linuxbios/2006-December/017580.html) but there is no sign of a finished work yet.. Did he abandon the idea or what happened ? Is someone working on a k9n motherboard right now? //Jonas _________________________________________________________________ Ladda upp bilder p? ditt Space s? kan dina v?nner se n?r du uppdaterar genom Messenger! http://spaces.live.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From uwe at hermann-uwe.de Thu Sep 13 10:25:42 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 13 Sep 2007 10:25:42 +0200 Subject: [LinuxBIOS] linuxbios on decTOP In-Reply-To: <721087.36289.qm@web45516.mail.sp1.yahoo.com> References: <721087.36289.qm@web45516.mail.sp1.yahoo.com> Message-ID: <20070913082542.GA9216@greenwood> Hi, On Wed, Sep 12, 2007 at 10:30:27PM -0700, embedded linux wrote: > > DecTOP (AMD PIC) is selling for $99 or (4 for $297) > http://www.dataevolution.com/dectop%20info%202.htm > > Since this is similar to OLPC hardware, I assume this is supported? Anyone has any experience with this hardware? No experience here, and it's not supported out of the box. However, as the chipset (GX2 northbridge and CS5535 southbridge, I think) is already supported, it shouldn't be too much work. I see one problem, namely that the ROM/BIOS chip is soldered on to the board (and not in a socket), according to http://www.enicomms.com/decTOP/DSCF1154.JPG This will require some soldering (desolder the chip, solder on a socket), so that you are able to insert a backup ROM chip in case of problems with flashing (and for testing during development). If you want to give this a try, please send us more information, lspci -nnn, lspci -vvv, lspnp -v (note: 'lspnp'. not lspci this time). 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 svn at openbios.org Thu Sep 13 10:38:24 2007 From: svn at openbios.org (svn at openbios.org) Date: Thu, 13 Sep 2007 10:38:24 +0200 Subject: [LinuxBIOS] r2772 - in trunk/LinuxBIOSv2/src: arch/i386/lib mainboard/msi/ms6178 Message-ID: Author: uwe Date: 2007-09-13 10:38:24 +0200 (Thu, 13 Sep 2007) New Revision: 2772 Added: trunk/LinuxBIOSv2/src/arch/i386/lib/failover.c Modified: trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/Config.lb Log: Add a common/global failover.c file which can be used by all (or at least most) mainboards. This should put and end to copy-paste'ing the same file again and again for every mainboard. Fix the build for the MSI MS-6178 target (wrong location of the common failover.c file). Signed-off-by: Uwe Hermann Acked-by: Corey Osgood Added: trunk/LinuxBIOSv2/src/arch/i386/lib/failover.c =================================================================== --- trunk/LinuxBIOSv2/src/arch/i386/lib/failover.c (rev 0) +++ trunk/LinuxBIOSv2/src/arch/i386/lib/failover.c 2007-09-13 08:38:24 UTC (rev 2772) @@ -0,0 +1,49 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2007 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 + */ + +#define ASSEMBLY 1 + +#include +#include "arch/romcc_io.h" +#include "pc80/mc146818rtc_early.c" + +/** + * Check whether the normal or the fallback image should be booted + * (by reading the proper flag from CMOS), and boot it. + * + * @param bist The input BIST value. + * @return The BIST value. + */ +static unsigned long main(unsigned long bist) +{ + if (do_normal_boot()) + goto normal_image; + else + goto fallback_image; + +normal_image: + __asm__ __volatile__("jmp __normal_image" : : "a" (bist) : ); + +cpu_reset: + __asm__ __volatile__("jmp __cpu_reset" : : "a" (bist) : ); + +fallback_image: + return bist; +} Modified: trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/Config.lb 2007-09-12 22:11:33 UTC (rev 2771) +++ trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/Config.lb 2007-09-13 08:38:24 UTC (rev 2772) @@ -35,12 +35,12 @@ if HAVE_PIRQ_TABLE object irq_tables.o end # object reset.o makerule ./failover.E - depends "$(MAINBOARD)/../../../lib/failover.c ./romcc" - action "./romcc -E -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/../../../lib/failover.c -o $@" + depends "$(MAINBOARD)/../../../arch/i386/lib/failover.c ./romcc" + action "./romcc -E -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/../../../arch/i386/lib/failover.c -o $@" end makerule ./failover.inc - depends "$(MAINBOARD)/../../../lib/failover.c ./romcc" - action "./romcc -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/../../../lib/failover.c -o $@" + depends "$(MAINBOARD)/../../../arch/i386/lib/failover.c ./romcc" + action "./romcc -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/../../../arch/i386/lib/failover.c -o $@" end makerule ./auto.E # depends "$(MAINBOARD)/auto.c option_table.h ./romcc" From uwe at hermann-uwe.de Thu Sep 13 10:40:12 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 13 Sep 2007 10:40:12 +0200 Subject: [LinuxBIOS] [PATCH] Build fix for MSI MS-6178 In-Reply-To: <46E8ABC3.9090903@gmail.com> References: <20070912222555.GH22601@greenwood> <46E8ABC3.9090903@gmail.com> Message-ID: <20070913084012.GB9216@greenwood> On Wed, Sep 12, 2007 at 11:17:23PM -0400, Corey Osgood wrote: > Both patches (I don't want to dig for the failover.c patch but I'm > familiar with it): > Acked-by: Corey Osgood Thanks, r2772. > > Index: src/mainboard/msi/ms6178/Config.lb > > =================================================================== > > --- src/mainboard/msi/ms6178/Config.lb (Revision 2771) > > +++ src/mainboard/msi/ms6178/Config.lb (Arbeitskopie) > > @@ -35,12 +35,12 @@ > > if HAVE_PIRQ_TABLE object irq_tables.o end > > # object reset.o > > makerule ./failover.E > > - depends "$(MAINBOARD)/../../../lib/failover.c ./romcc" > > - action "./romcc -E -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/../../../lib/failover.c -o $@" > > + depends "$(MAINBOARD)/../../../arch/i386/lib/failover.c ./romcc" > > > > Is there really no simpler way of stating this line? I don't know any. Maybe I'm missing some variable which points to the top-level src/ directory? 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 adrian at lisas.de Thu Sep 13 10:51:53 2007 From: adrian at lisas.de (Adrian Reber) Date: Thu, 13 Sep 2007 10:51:53 +0200 Subject: [LinuxBIOS] r2772 - in trunk/LinuxBIOSv2/src: arch/i386/lib mainboard/msi/ms6178 In-Reply-To: <20070913083857.A05F640156@rhlx01.hs-esslingen.de> References: <20070913083857.A05F640156@rhlx01.hs-esslingen.de> Message-ID: <20070913085153.GA5890@lisas.de> On Thu, Sep 13, 2007 at 10:38:24AM +0200, svn at openbios.org wrote: > + * 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 ASSEMBLY 1 I am not really sure how this is used... But gcc defines, at least since 2.95, __ASSEMBLER__ if compiling an assembler file. So it is not really necessary if you have for example an include file which should do certain parts only if included in assembler code. Adrian From info at coresystems.de Thu Sep 13 11:25:09 2007 From: info at coresystems.de (LinuxBIOS information) Date: Thu, 13 Sep 2007 11:25:09 +0200 Subject: [LinuxBIOS] r2772 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2772 to the LinuxBIOS source repository and caused the following changes: Change Log: Add a common/global failover.c file which can be used by all (or at least most) mainboards. This should put and end to copy-paste'ing the same file again and again for every mainboard. Fix the build for the MSI MS-6178 target (wrong location of the common failover.c file). Signed-off-by: Uwe Hermann Acked-by: Corey Osgood Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2772&device=hdama&vendor=arima Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2772&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2772&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2772&device=juki-511p&vendor=iei Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2772&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2772&device=dk8x&vendor=iwill Configuration of msi:ms6178 is still broken If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From svn at openbios.org Thu Sep 13 11:55:44 2007 From: svn at openbios.org (svn at openbios.org) Date: Thu, 13 Sep 2007 11:55:44 +0200 Subject: [LinuxBIOS] r2773 - trunk/LinuxBIOSv2/src/mainboard/msi/ms6178 Message-ID: Author: uwe Date: 2007-09-13 11:55:44 +0200 (Thu, 13 Sep 2007) New Revision: 2773 Modified: trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/Options.lb Log: Fix abuild run of the MSI MS-6178 (trivial). Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Modified: trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/Options.lb 2007-09-13 08:38:24 UTC (rev 2772) +++ trunk/LinuxBIOSv2/src/mainboard/msi/ms6178/Options.lb 2007-09-13 09:55:44 UTC (rev 2773) @@ -63,6 +63,7 @@ uses CONFIG_CONSOLE_VGA uses CONFIG_PCI_ROM_RUN +default ROM_SIZE = 512 * 1024 default HAVE_FALLBACK_BOOT = 1 default HAVE_MP_TABLE = 0 default HAVE_HARD_RESET = 0 From info at coresystems.de Thu Sep 13 12:42:50 2007 From: info at coresystems.de (LinuxBIOS information) Date: Thu, 13 Sep 2007 12:42:50 +0200 Subject: [LinuxBIOS] r2773 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2773 to the LinuxBIOS source repository and caused the following changes: Change Log: Fix abuild run of the MSI MS-6178 (trivial). Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2773&device=hdama&vendor=arima Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2773&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2773&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2773&device=juki-511p&vendor=iei Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2773&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2773&device=dk8x&vendor=iwill Configuration of msi:ms6178 has been fixed If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From peter at stuge.se Thu Sep 13 14:11:28 2007 From: peter at stuge.se (Peter Stuge) Date: Thu, 13 Sep 2007 14:11:28 +0200 Subject: [LinuxBIOS] AMD 690G chipset support in LinuxBIOS v2 In-Reply-To: <20070913002132.c843035e.rasmus@wiman.org> References: <46893e740709101937j32a4f32bu6dc296a628d36dc6@mail.gmail.com> <20070911092007.0915d2b7.rasmus@wiman.org> <46893e740709101937j32a4f32bu6dc296a628d36dc6@mail.gmail.com> <20070911190432.30652.qmail@stuge.se> <20070912134710.GB22601@greenwood> <20070913002132.c843035e.rasmus@wiman.org> Message-ID: <20070913121128.1436.qmail@stuge.se> On Thu, Sep 13, 2007 at 12:21:32AM +0200, Rasmus Wiman wrote: > I just saw a Gigabyte GA-MA69VM-S2 ATX board for 373 kronor, and a > MSI K9AGM2-L micro ATX for 464. Where? //Peter From peter at stuge.se Thu Sep 13 14:24:16 2007 From: peter at stuge.se (Peter Stuge) Date: Thu, 13 Sep 2007 14:24:16 +0200 Subject: [LinuxBIOS] i82801DB PCI Bridge locking up In-Reply-To: <20070913024016.fajh2qt7c4wk848w@www.smittys.pointclark.net> References: <20070912032617.gthkfz5g408k04gs@www.smittys.pointclark.net> <20070912122558.GA22601@greenwood> <20070913024016.fajh2qt7c4wk848w@www.smittys.pointclark.net> Message-ID: <20070913122416.3608.qmail@stuge.se> On Thu, Sep 13, 2007 at 02:40:16AM -0400, joe at smittys.pointclark.net wrote: > I wonder if my nic needs the pci rom to get it going, and this > would solve the problem? The ROM would be used much later in the init process, so no, it's not likely to help. :\ //Peter From peter at stuge.se Thu Sep 13 14:26:24 2007 From: peter at stuge.se (Peter Stuge) Date: Thu, 13 Sep 2007 14:26:24 +0200 Subject: [LinuxBIOS] MSI k9n platinum In-Reply-To: References: Message-ID: <20070913122624.3954.qmail@stuge.se> Hi, On Wed, Sep 12, 2007 at 08:14:47PM +0000, Jonas K wrote: > Is someone working on a k9n motherboard right now? Not that we know of. //Peter From uwe at hermann-uwe.de Thu Sep 13 14:51:57 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 13 Sep 2007 14:51:57 +0200 Subject: [LinuxBIOS] MSI k9n platinum In-Reply-To: <20070913122624.3954.qmail@stuge.se> References: <20070913122624.3954.qmail@stuge.se> Message-ID: <20070913125155.GC9216@greenwood> On Thu, Sep 13, 2007 at 02:26:24PM +0200, Peter Stuge wrote: > On Wed, Sep 12, 2007 at 08:14:47PM +0000, Jonas K wrote: > > Is someone working on a k9n motherboard right now? > > Not that we know of. Not currently working on it, but I have a K9N Neo here, I just don't know when I'll find the time to give it a try. 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 joe at smittys.pointclark.net Thu Sep 13 15:19:01 2007 From: joe at smittys.pointclark.net (joe at smittys.pointclark.net) Date: Thu, 13 Sep 2007 09:19:01 -0400 Subject: [LinuxBIOS] i82801DB PCI Bridge locking up In-Reply-To: <20070913122416.3608.qmail@stuge.se> References: <20070912032617.gthkfz5g408k04gs@www.smittys.pointclark.net> <20070912122558.GA22601@greenwood> <20070913024016.fajh2qt7c4wk848w@www.smittys.pointclark.net> <20070913122416.3608.qmail@stuge.se> Message-ID: <20070913091901.dvy6umcw4k8so0g8@www.smittys.pointclark.net> Quoting Peter Stuge : > On Thu, Sep 13, 2007 at 02:40:16AM -0400, joe at smittys.pointclark.net wrote: >> I wonder if my nic needs the pci rom to get it going, and this >> would solve the problem? > > The ROM would be used much later in the init process, so no, it's not > likely to help. :\ > > After a few tests I found the problem. It is locking up on this line: pci_write_config16(dev, PCI_COMMAND, command); It is trying to write to the CMD(0x04) register of the PCI Bridge. Looks like it is trying to write 0x0141. Setting the SERR# Enable (SERR_EN), Parity Error Response (PER), and I/O Space Enable (IOSE). I have no idea why this would cause a lock up??? I doesn't on any of the other devices?? Could someone take a look at the i82801DB datasheet and tell me if I am missing something?? Sometimes two (or more) heads are better than one. Thanks - Joe From svn at openbios.org Thu Sep 13 15:47:02 2007 From: svn at openbios.org (svn at openbios.org) Date: Thu, 13 Sep 2007 15:47:02 +0200 Subject: [LinuxBIOS] r2774 - trunk/LinuxBIOSv2/src/northbridge/amd/amdk8 Message-ID: Author: stepan Date: 2007-09-13 15:47:02 +0200 (Thu, 13 Sep 2007) New Revision: 2774 Modified: trunk/LinuxBIOSv2/src/northbridge/amd/amdk8/get_sblk_pci1234.c Log: I still don't understand a word, but I tried to improve the documentation. (trivial) Please fix this if you can. Signed-off-by: Stefan Reinauer Acked-by: Stefan Reinauer Modified: trunk/LinuxBIOSv2/src/northbridge/amd/amdk8/get_sblk_pci1234.c =================================================================== --- trunk/LinuxBIOSv2/src/northbridge/amd/amdk8/get_sblk_pci1234.c 2007-09-13 09:55:44 UTC (rev 2773) +++ trunk/LinuxBIOSv2/src/northbridge/amd/amdk8/get_sblk_pci1234.c 2007-09-13 13:47:02 UTC (rev 2774) @@ -29,10 +29,12 @@ its successor. Use of the Materials by the Government constitutes acknowledgement of AMD's proprietary rights in them. ============================================================================*/ -// 2005.9 serengeti support -// by yhlu -// 2005.9 yhlu modify that to more dynamic for AMD Opteron Based MB +/* Copyright 2007 coresystems GmbH */ +// 2005.9 yhlu serengeti support +// 2005.9 yhlu modify that to more dynamic for AMD Opteron Based MB +// 2007.9 stepan improve code documentation + #include #include #include @@ -79,88 +81,121 @@ #endif -/* why we need pci1234 array - final result for pci1234 will be - pci1234[0] will record sblink and bus range - pci1234[i] will record ht chain i. - it will keep the sequence when some ht io card is not installed. +/** + * Why we need the pci1234[] array + * + * It will keep the sequence of HT devices in the HT link registers even when a + * given HT I/O card is not installed. + * + * The final result for pci1234[] will be + * + * pci1234[0] will record the south bridge link and bus range + * pci1234[i] will record HT chain i. + * + * For example, on the Tyan S2885 linxbios_ram will put the AMD8151 chain (HT + * link 0) into the register 0xE0, and the AMD8131/8111 HT chain into the + * register 0xE4. + * + * So we need to make sure that the south bridge link will always be on + * pci1234[0]. + * + * Imagine a scenario with multiple HT I/O cards, where you don't install HT I/O 1, + * but you only install HT I/O 2 and HT I/O 3. The HT I/Os will end up in registers + * 0xE4 and 0xE8. + * + * But we want to leave pci1234[1] to HT I/O 1 (even though it is disabled), + * and let HT I/O 2 and HT I/O 3 still use pci1234[2] and pci1234[3]. + * + * So we keep the sequence. You need to preset the pci1234[1], pci1234[2], + * pci1234[3] for this purpose. + * + * For this example you need to set + * + * unsigned pci1234[] = { + * 0x0000ff0, + * 0x0000f10, // HT IO 1 card always on node 1 + * 0x0000f20, // HT IO 2 card always on node 2 + * 0x0000f30 // HT IO 3 card always on node 3 + * }; + * + * For 2P + htio(n1) + htio(n0_1) + htio(n1_1), 2P + htio(n1) + 2P + htio(n2) + htio(n3): + * You need an array pci1234[6]: + * + * unsigned pci1234[] = { + * 0x0000ff0, + * 0x0000010, // HT IO 1 card always on node 1 + * 0x0000f00, // HT IO 2 card always on node 0 + * 0x0000110, // HT IO 3 card always on node 1 + * 0x0000f20, // HT IO 4 card always on node 2 + * 0x0000f30 // HT IO 5 card always on node 3 + * }; + * + * + * For 4p+htio(n1)+htio(n2)+htio(n3),4p+htio(n1)+4p+htio(n6)+htio(n7): + * You need an array pci1234[6]: + * + * unsigned pci1234[] = { + * 0x0000ff0, + * 0x0000f10, // HT IO 1 card always on node 1 + * 0x0000f20, // HT IO 2 card always on node 2 + * 0x0000f30, // HT IO 3 card always on node 3 + * 0x0000f60, // HT IO 4 card always on node 6 + * 0x0000f70 // HT IO 5 card always on node 7 + * }; + * + * + * For 2p + htio(n1) + htio(n0_1) + htio(n1_1), 2P + htio(n1) + 2P + + * htio(n2) + htio(n3), 2P + htio(n1) + 4P + htio(n4) + htio(n5), + * you need an array pci1234[8]: + * + * unsigned pci1234[] = { + * 0x0000ff0, + * 0x0000010, // HT IO 1 card always on node 1 + * 0x0000f00, // HT IO 2 card always on node 0 + * 0x0000110, // HT IO 3 card always on node 1 + * 0x0000f20, // HT IO 4 card always on node 2 + * 0x0000f30 // HT IO 5 card always on node 3 + * 0x0000f40, // HT IO 6 card always on node 4 + * 0x0000f50 // HT IO 7 card always on node 5 + * }; + * + * + * For 4P + htio(n1) + htio(n2) + htio(n3), 4p + htio(n1) + 2p + htio(n4) + + * htio(n5), 4p + htio(n1) + 4p + htio(n6) + htio(n7), + * you need an array pci1234[8]: + * + * unsigned pci1234[] = { + * 0x0000ff0, + * 0x0000f10, // HT IO 1 card always on node 1 + * 0x0000f20, // HT IO 2 card always on node 2 + * 0x0000f30, // HT IO 3 card always on node 3 + * 0x0000f40, // HT IO 4 card always on node 4 + * 0x0000f50 // HT IO 5 card always on node 5 + * 0x0000f60, // HT IO 6 card always on node 6 + * 0x0000f70 // HT IO 7 card always on node 7 + * }; + * + * + * So the maximum posible value of HC_POSSIBLE_NUM is 8. (FIXME Why?) + * + * 1n: 3 + * 2n: 2x2 - 1 + * 4n: 1x4 - 2 + * 6n: 2 + * 8n: 2 + * Total: 12 + * + * Just put all the possible HT Node/link to the list tp pci1234[] in + * src/mainboard//get_bus_conf.c + * + * Also don't forget to increase the ACPI_SSDTX_NUM etc (FIXME what else) if + * you have too many SSDTs + * + * What about co-processor in socket 1 on a 2 way system? Or socket 2 and + * socket 3 on a 4 way system? Treat that as an HC, too! + * + */ - for Tyan S2885 the linxbios_ram will put 8151 chain (link 0) to 0xE0 reg, and 8131/8111 on 0xe4 reg, So we need to make sure the sb link - will always on pci1234[0] - for multi ht-io cards, if you don't install htio1, and only installed htio2, htio3, the htio will be on 0xe4, and 0xe8. - but we want to leave pci1234[1] to htio1 (even it is disabled) , and let htio2 and htio3 still use pci1234[2] and pci1234[3] - So we keep the sequence. ---- you need to preset the pci1234[1], pci1234[2], pci1234[3] for this purpose - for example you need set - unsigned pci1234[] = { - 0x0000ff0, - 0x0000f10, // HT IO 1 card always on node 1 - 0x0000f20, // HT IO 2 card always on node 2 - 0x0000f30 // HT IO 3 card always on node 3 - }; - - for 2p+htio(n1)+htio(n0_1)+htio(n1_1),2p+htio(n1)+2p+htio(n2)+htio(n3) : need pci1234[6] - unsigned pci1234[] = { - 0x0000ff0, - 0x0000010, // HT IO 1 card always on node 1 - 0x0000f00, // HT IO 2 card always on node 0 - 0x0000110, // HT IO 3 card always on node 1 - 0x0000f20, // HT IO 4 card always on node 2 - 0x0000f30 // HT IO 5 card always on node 3 - }; - - for 4p+htio(n1)+htio(n2)+htio(n3),4p+htio(n1)+4p+htio(n6)+htio(n7) : need pci1234[6] - unsigned pci1234[] = { - 0x0000ff0, - 0x0000f10, // HT IO 1 card always on node 1 - 0x0000f20, // HT IO 2 card always on node 2 - 0x0000f30, // HT IO 3 card always on node 3 - 0x0000f60, // HT IO 4 card always on node 6 - 0x0000f70 // HT IO 5 card always on node 7 - }; - - - for 2p+htio(n1)+htio(n0_1)+htio(n1_1), 2p+htio(n1)+2p+htio(n2)+htio(n3), 2p+htio(n1)+4p+htio(n4)+htio(n5), need pci1234[8] - unsigned pci1234[] = { - 0x0000ff0, - 0x0000010, // HT IO 1 card always on node 1 - 0x0000f00, // HT IO 2 card always on node 0 - 0x0000110, // HT IO 3 card always on node 1 - 0x0000f20, // HT IO 4 card always on node 2 - 0x0000f30 // HT IO 5 card always on node 3 - 0x0000f40, // HT IO 6 card always on node 4 - 0x0000f50 // HT IO 7 card always on node 5 - }; - - - for 4p+htio(n1)+htio(n2)+htio(n3), 4p+htio(n1)+2p+htio(n4)+htio(n5), 4p+htio(n1)+4p+htio(n6)+htio(n7), need pci1234[8] - unsigned pci1234[] = { - 0x0000ff0, - 0x0000f10, // HT IO 1 card always on node 1 - 0x0000f20, // HT IO 2 card always on node 2 - 0x0000f30, // HT IO 3 card always on node 3 - 0x0000f40, // HT IO 4 card always on node 4 - 0x0000f50 // HT IO 5 card always on node 5 - 0x0000f60, // HT IO 6 card always on node 6 - 0x0000f70 // HT IO 7 card always on node 7 - }; - - - So Max HC_POSSIBLE_NUM is 8 - - 1n: 3 - 2n: 2x2 - 1 - 4n: 1x4 - 2 - 6n: 2 - 8n: 2 - Total: 12 - - just put all the possible ht node/link to the list tp pci1234[] in get_bus_conf.c on MB dir - - Also don't forget to increase the ACPI_SSDTX_NUM etc if you have too much SSDT - - How about co-processor on socket 1 on 2 way system. or socket 2, and socket3 on 4 way system....? treat that as one hc too! - -*/ void get_sblk_pci1234(void) { @@ -178,27 +213,37 @@ sysconf.pci1234[0] = dword; sysconf.hcid[0] = 0; - /*about hardcode numbering for HT_IO support - set the node_id and link_id that could have ht chain in the one array, - then check if is enabled.... then update final value - */ - //here we need to set hcdn - //1. hypertransport.c need to record hcdn_reg together with 0xe0, 0xe4, 0xe8, 0xec when are set - //2. so at the same time we need update hsdn with hcdn_reg here + /* About hardcoded numbering for HT_IO support + * + * Set the node_id and link_id that could have a HT chain in the one + * array, (FIXME: which one?) then check if is enabled. Then update + * final value + */ + /* Here we need to set hcdn + * + * 1. hypertransport.c needs to record hcdn_reg together with 0xe0, + * 0xe4, 0xe8, 0xec when are set (FIXME: when WHAT is set?) + * + * 2. So at the same time we need update hcdn with hcdn_reg here. FIXME: Why? + */ + dev = dev_find_slot(0, PCI_DEVFN(0x18, 1)); + for(j=0;j<4;j++) { uint32_t dwordx; - dwordx = pci_read_config32(dev, 0xe0+j*4); - dwordx &=0xffff0ff1; //keep bus num, node_id, link_num, enable bits - if((dwordx & 0xff1) == dword) { //SBLINK + dwordx = pci_read_config32(dev, 0xe0 + j*4); + dwordx &=0xffff0ff1; /* keep bus num, node_id, link_num, enable bits */ + if((dwordx & 0xff1) == dword) { /* SBLINK */ sysconf.pci1234[0] = dwordx; sysconf.hcdn[0] = sysconf.hcdn_reg[j]; continue; } + if((dwordx & 1) == 1) { - // We need to find out the number of HC - // for exact match + /* We need to find out the number of HC + * for exact match + */ for(i=1;i References: <20070912032617.gthkfz5g408k04gs@www.smittys.pointclark.net> <20070912122558.GA22601@greenwood> <20070913024016.fajh2qt7c4wk848w@www.smittys.pointclark.net> <20070913122416.3608.qmail@stuge.se> <20070913091901.dvy6umcw4k8so0g8@www.smittys.pointclark.net> Message-ID: <57947bf80709130710q26c5eaa7l2c5cf796e46938f2@mail.gmail.com> Can you check the SERR and PERR status in the bridge before the enable? (they are in offset 1f of config space) If you clear them first, does it help? We have a platform with a different southbridge where we find that to be the case (clearing the status bits first makes it not hang) On 9/13/07, joe at smittys.pointclark.net wrote: > Quoting Peter Stuge : > > > On Thu, Sep 13, 2007 at 02:40:16AM -0400, joe at smittys.pointclark.net wrote: > >> I wonder if my nic needs the pci rom to get it going, and this > >> would solve the problem? > > > > The ROM would be used much later in the init process, so no, it's not > > likely to help. :\ > > > > > After a few tests I found the problem. It is locking up on this line: > > pci_write_config16(dev, PCI_COMMAND, command); > > It is trying to write to the CMD(0x04) register of the PCI Bridge. > Looks like it is trying to write 0x0141. Setting the SERR# Enable > (SERR_EN), Parity Error Response (PER), and I/O Space Enable (IOSE). > > I have no idea why this would cause a lock up??? I doesn't on any of > the other devices?? Could someone take a look at the i82801DB > datasheet and tell me if I am missing something?? Sometimes two (or > more) heads are better than one. > > > Thanks - Joe > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > From info at coresystems.de Thu Sep 13 16:34:28 2007 From: info at coresystems.de (LinuxBIOS information) Date: Thu, 13 Sep 2007 16:34:28 +0200 Subject: [LinuxBIOS] r2774 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "stepan" checked in revision 2774 to the LinuxBIOS source repository and caused the following changes: Change Log: I still don't understand a word, but I tried to improve the documentation. (trivial) Please fix this if you can. Signed-off-by: Stefan Reinauer Acked-by: Stefan Reinauer Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2774&device=hdama&vendor=arima Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2774&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2774&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2774&device=juki-511p&vendor=iei Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2774&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2774&device=dk8x&vendor=iwill 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 should be backed out. Best regards, LinuxBIOS automatic build system From jordan.crouse at amd.com Thu Sep 13 17:00:18 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Thu, 13 Sep 2007 09:00:18 -0600 Subject: [LinuxBIOS] linuxbios on decTOP In-Reply-To: <20070913082542.GA9216@greenwood> References: <721087.36289.qm@web45516.mail.sp1.yahoo.com> <20070913082542.GA9216@greenwood> Message-ID: <20070913150018.GQ4913@cosmic.amd.com> On 13/09/07 10:25 +0200, Uwe Hermann wrote: > Hi, > > On Wed, Sep 12, 2007 at 10:30:27PM -0700, embedded linux wrote: > > > > DecTOP (AMD PIC) is selling for $99 or (4 for $297) > > http://www.dataevolution.com/dectop%20info%202.htm > > > > Since this is similar to OLPC hardware, I assume this is supported? Anyone has any experience with this hardware? > > No experience here, and it's not supported out of the box. However, as > the chipset (GX2 northbridge and CS5535 southbridge, I think) is > already supported, it shouldn't be too much work. > > I see one problem, namely that the ROM/BIOS chip is soldered on > to the board (and not in a socket), according to > http://www.enicomms.com/decTOP/DSCF1154.JPG > > This will require some soldering (desolder the chip, solder on a > socket), so that you are able to insert a backup ROM chip in case of > problems with flashing (and for testing during development). > > If you want to give this a try, please send us more information, > lspci -nnn, lspci -vvv, lspnp -v (note: 'lspnp'. not lspci this time). It is a GX2 with a 5535. You will have to desolder the ROM, but IIRC, its pretty easy to get a socket on the PCB. The one big problem is that there isn't a serial port, so you'll be stuck without any sort of output until the kernel framebuffer comes up. There's a clever hardware hack to get around that by intercepting the DDC lines on the VGA, though, if you are really interested (of course, you'll need to set up the serial port accordingly in the LB code). Other then that, I don't recall any huge gotchas, mainboard wise. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From peter at stuge.se Thu Sep 13 17:31:39 2007 From: peter at stuge.se (Peter Stuge) Date: Thu, 13 Sep 2007 17:31:39 +0200 Subject: [LinuxBIOS] linuxbios on decTOP In-Reply-To: <20070913150018.GQ4913@cosmic.amd.com> References: <721087.36289.qm@web45516.mail.sp1.yahoo.com> <20070913082542.GA9216@greenwood> <20070913150018.GQ4913@cosmic.amd.com> Message-ID: <20070913153139.3101.qmail@stuge.se> On Thu, Sep 13, 2007 at 09:00:18AM -0600, Jordan Crouse wrote: > There's a clever hardware hack to get around that by intercepting > the DDC lines on the VGA, though, if you are really interested Oh - so that's part of the 5535? I thought it was linutop only. Do you happen to know if it's safe to draw the power needed for the level conversion from some other pin on the VGA connector? //Peter From rasmus at wiman.org Thu Sep 13 19:02:29 2007 From: rasmus at wiman.org (Rasmus Wiman) Date: Thu, 13 Sep 2007 19:02:29 +0200 Subject: [LinuxBIOS] AMD 690G chipset support in LinuxBIOS v2 In-Reply-To: <20070913121128.1436.qmail@stuge.se> References: <46893e740709101937j32a4f32bu6dc296a628d36dc6@mail.gmail.com> <20070911092007.0915d2b7.rasmus@wiman.org> <46893e740709101937j32a4f32bu6dc296a628d36dc6@mail.gmail.com> <20070911190432.30652.qmail@stuge.se> <20070912134710.GB22601@greenwood> <20070913002132.c843035e.rasmus@wiman.org> <20070913121128.1436.qmail@stuge.se> Message-ID: <20070913190230.f4e60124.rasmus@wiman.org> Peter Stuge wrote: > On Thu, Sep 13, 2007 at 12:21:32AM +0200, Rasmus Wiman wrote: > > I just saw a Gigabyte GA-MA69VM-S2 ATX board for 373 kronor, and a > > MSI K9AGM2-L micro ATX for 464. > > Where? http://www.levitech.se I the page says they don't have the cards in stock, but they are in the price list. Also, by the way, since I didn't notice until today, someone else could also have missed this: http://www.x.org/docs/AMD/ Who knows, it could be useful to someone here. /Rasmus From jens at freimann.org Thu Sep 13 21:58:19 2007 From: jens at freimann.org (Jens Freimann) Date: Thu, 13 Sep 2007 21:58:19 +0200 Subject: [LinuxBIOS] [PATCH] Add more PCI config data to device structure In-Reply-To: <20070913012718.GL22601@greenwood> References: <1189546178.7001.28.camel@jens-laptop> <20070913012718.GL22601@greenwood> Message-ID: <1189713499.7685.41.camel@jens-laptop> Hi, attached is a fixed version of my patch. So far only for v3, because I ran into another problem with v2 that needs to be fixed first. Am Donnerstag, den 13.09.2007, 03:27 +0200 schrieb Uwe Hermann: > > Index: src/devices/pci_device.c > > =================================================================== > > --- src/devices/pci_device.c (revision 2770) > > +++ src/devices/pci_device.c (working copy) > > @@ -972,7 +972,34 @@ > > /* Read the rest of the pci configuration information */ > > hdr_type = pci_read_config8(dev, PCI_HEADER_TYPE); > > class = pci_read_config32(dev, PCI_CLASS_REVISION); > > - > > + > > + u16 status = pci_read_config16(dev, PCI_STATUS); > > + dev->status = status; > > + > Is there a reaons why this wouldn't work? > > dev->status = pci_read_config16(dev, PCI_STATUS); > (much shorter) No, there used to be a reason for this, but not anymore. Changed it to the shorter version. > > /* Store the interesting information in the device structure */ > > dev->vendor = id & 0xffff; > > dev->device = (id >> 16) & 0xffff; > > Index: src/include/device/device.h > > =================================================================== > > --- src/include/device/device.h (revision 2770) > > +++ src/include/device/device.h (working copy) > > @@ -68,9 +68,19 @@ > > device_t sibling; /* next device on this bus */ > > device_t next; /* chain of all devices */ > > > > + char dtsname[64]; > > struct device_path path; > > unsigned vendor; > > unsigned device; > > + u16 status; > Use TABs for indentation as per coding guidelines, please. Done. > The patch looks good to me otherwise, but someone with more OFW > knowledge should probably look over it, too. I think Stefan already looked at it. (?) Jens -------------- next part -------------- A non-text attachment was scrubbed... Name: pciconfig_v3.diff Type: text/x-patch Size: 1814 bytes Desc: not available URL: From jens at freimann.org Thu Sep 13 21:58:30 2007 From: jens at freimann.org (Jens Freimann) Date: Thu, 13 Sep 2007 21:58:30 +0200 Subject: [LinuxBIOS] [PATCH] Add pointer to device tree to LinuxBIOS table In-Reply-To: <20070913013253.GM22601@greenwood> References: <1189546220.7001.29.camel@jens-laptop> <20070913013253.GM22601@greenwood> Message-ID: <1189713510.7685.42.camel@jens-laptop> Hi, attached is the fixed version of my patch. So far only for v3, because I ran into another problem with v2 that needs to be fixed first. Am Donnerstag, den 13.09.2007, 03:32 +0200 schrieb Uwe Hermann: > On Tue, Sep 11, 2007 at 11:30:20PM +0200, Jens Freimann wrote: > > Add a pointer to the root device to the LinuxBIOS table. Used for > > example to access the device list from Open Firmware. > > > > Signed-off-by: Jens Freimann > > > > Index: src/include/boot/linuxbios_tables.h > > =================================================================== > > --- src/include/boot/linuxbios_tables.h (Revision 2770) > > +++ src/include/boot/linuxbios_tables.h (Arbeitskopie) > > @@ -106,6 +106,12 @@ > > struct lb_memory_range map[0]; > > }; > > > > +struct lb_devtree { > > + uint32_t tag; > > + uint32_t size; > > + uint32_t dev_root_ptr; /* pointer to root device */ > > +}; > > Fix the coding style please (TABs, not spaces, for indentation). Done. > > #define LB_TAG_HWRPB 0x0002 > > struct lb_hwrpb { > > uint32_t tag; > > Index: src/arch/i386/boot/linuxbios_table.c > > =================================================================== > > --- src/arch/i386/boot/linuxbios_table.c (Revision 2770) > > +++ src/arch/i386/boot/linuxbios_table.c (Arbeitskopie) > > @@ -348,6 +348,27 @@ > > return mem; > > } > > > > +/** > > + * Add entire device tree to LinuxBIOS table > > + * > > + * @param head Pointer to lbtable header > > + */ > > +struct lb_devtree *lb_devtree(struct lb_header *head) > > +{ > > + struct lb_devtree *lbdev = NULL; > > + struct device *dev = NULL; > > + > > + lbdev = (struct lb_devtree *)lb_new_record(head); > > + lbdev->tag = 0xE; > > What is 0xe? Should probably be some #define with a descriptive name > for better readability? Done. > > + char buf[64]; Removed, because it was unused. > > /* Record our various random string information */ > > lb_strings(head); > > > > + /* Record the LinuxBIOS device tree */ > > + lb_devtree(head); > > + > > /* Remember where my valid memory ranges are */ > > return lb_table_fini(head); > > Someone should double-check that this doesn't break any existing tools > (lxbios?) or expectations in the code. Do we consider this as "public API" > of some sort or doesn't it matter at all if it changes? I tried lxbios. To me it seems to work fine. Of course when dumping the lbtable it prints "UNKNOWN" for the newly introduced LB_DEVTREE_PTR (0xE) tag. Jens -------------- next part -------------- A non-text attachment was scrubbed... Name: lbdevtreepointer_v3.diff Type: text/x-patch Size: 1701 bytes Desc: not available URL: From jordan.crouse at amd.com Thu Sep 13 23:07:27 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Thu, 13 Sep 2007 15:07:27 -0600 Subject: [LinuxBIOS] linuxbios on decTOP In-Reply-To: <20070913153139.3101.qmail@stuge.se> References: <721087.36289.qm@web45516.mail.sp1.yahoo.com> <20070913082542.GA9216@greenwood> <20070913150018.GQ4913@cosmic.amd.com> <20070913153139.3101.qmail@stuge.se> Message-ID: <20070913210727.GA7483@cosmic.amd.com> On 13/09/07 17:31 +0200, Peter Stuge wrote: > On Thu, Sep 13, 2007 at 09:00:18AM -0600, Jordan Crouse wrote: > > There's a clever hardware hack to get around that by intercepting > > the DDC lines on the VGA, though, if you are really interested > > Oh - so that's part of the 5535? I thought it was linutop only. > > Do you happen to know if it's safe to draw the power needed for > the level conversion from some other pin on the VGA connector? I think it is, but I'm not a hardware engineer, nor do I play one on TV. > > //Peter > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > > -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From rminnich at gmail.com Thu Sep 13 23:19:38 2007 From: rminnich at gmail.com (ron minnich) Date: Thu, 13 Sep 2007 14:19:38 -0700 Subject: [LinuxBIOS] [PATCH] AMD CS5530 rewrite In-Reply-To: <20070913013616.GN22601@greenwood> References: <20070913013616.GN22601@greenwood> Message-ID: <13426df10709131419y8306cadgab154e7396a97560@mail.gmail.com> I like it. I wonder if you want doxygen comments, but that is up to you. This is great. Acked-by: Ronald G. Minnich From uwe at hermann-uwe.de Fri Sep 14 02:06:43 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 14 Sep 2007 02:06:43 +0200 Subject: [LinuxBIOS] [RFC] Initial attempt at supporting MSI K9N Neo (MS-7260) Message-ID: <20070914000643.GA2656@greenwood> Hi, here's my first try with the K9N. It took me a while to figure out how to make serial work (the Super I/O is at 0x4e on this board, and you need a small hack to switch to 24MHz, see patch), but that part works fine now. It does not survive the RAM init, yet, I get "No memory for this cpu" errors. Somethings's wrong with RAM/SPD detection, but I didn't yet have time to debug. I'm posting this in case anybody wants to play a bit with this target... The boot log and my current diff against the GA-M57SLI-S4 code is attached. Notes: - The BIOS is socketed (thank god!) and is a 512KB PLCC chip (Pm49FL004). - Flashrom does _not_ work on this board, though (board-specific init required). - I'm using two DIMMs, the BIOS says "DRAM clocking is 667 MHz, Dual-Channel" There a 2 green, and 2 orange slots for RAM, my DIMMs are both in the orange ones (and work fine using the proprietary BIOS). Some more info on the board and CPU: $ lspci -nn 00:00.0 RAM memory [0500]: nVidia Corporation MCP55 Memory Controller [10de:0369] (rev a1) 00:01.0 ISA bridge [0601]: nVidia Corporation MCP55 LPC Bridge [10de:0363] (rev a2) 00:01.1 SMBus [0c05]: nVidia Corporation MCP55 SMBus [10de:0368] (rev a2) 00:01.2 RAM memory [0500]: nVidia Corporation MCP55 Memory Controller [10de:036a] (rev a2) 00:02.0 USB Controller [0c03]: nVidia Corporation MCP55 USB Controller [10de:036c] (rev a1) 00:02.1 USB Controller [0c03]: nVidia Corporation MCP55 USB Controller [10de:036d] (rev a2) 00:04.0 IDE interface [0101]: nVidia Corporation MCP55 IDE [10de:036e] (rev a1) 00:05.0 IDE interface [0101]: nVidia Corporation MCP55 SATA Controller [10de:037f] (rev a2) 00:05.1 IDE interface [0101]: nVidia Corporation MCP55 SATA Controller [10de:037f] (rev a2) 00:06.0 PCI bridge [0604]: nVidia Corporation MCP55 PCI bridge [10de:0370] (rev a2) 00:06.1 Audio device [0403]: nVidia Corporation MCP55 High Definition Audio [10de:0371] (rev a2) 00:08.0 Bridge [0680]: nVidia Corporation MCP55 Ethernet [10de:0373] (rev a2) 00:0b.0 PCI bridge [0604]: nVidia Corporation MCP55 PCI Express bridge [10de:0374] (rev a2) 00:0c.0 PCI bridge [0604]: nVidia Corporation MCP55 PCI Express bridge [10de:0374] (rev a2) 00:0d.0 PCI bridge [0604]: nVidia Corporation MCP55 PCI Express bridge [10de:0378] (rev a2) 00:0e.0 PCI bridge [0604]: nVidia Corporation MCP55 PCI Express bridge [10de:0375] (rev a2) 00:0f.0 PCI bridge [0604]: nVidia Corporation MCP55 PCI Express bridge [10de:0377] (rev a2) 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101] 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102] 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103] 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc 3D Rage II+ 215GTB [Mach64 GTB] [1002:4755] (rev 9a) $ lspci -vvv 00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a1) Subsystem: Micro-Star International Co., Ltd. Unknown device 7260 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [b8] Subsystem: Gammagraphx, Inc. Unknown device 0000 Capabilities: [8c] HyperTransport: MSI Mapping 00:06.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2) Subsystem: Micro-Star International Co., Ltd. Unknown device 7260 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [40] Subsystem: nVidia Corporation Unknown device 0000 Capabilities: [48] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+ Address: 00000000fee00000 Data: 4049 Capabilities: [60] HyperTransport: MSI Mapping Capabilities: [80] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <512ns, L1 <4us Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 4 Link: Latency L0s <512ns, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x4 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise- Slot: Number 0, PowerLimit 0.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Off, PwrInd On, Power- Root: Correctable- Non-Fatal- Fatal- PME- 00:0c.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [40] Subsystem: nVidia Corporation Unknown device 0000 Capabilities: [48] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+ Address: 00000000fee00000 Data: 4051 Capabilities: [60] HyperTransport: MSI Mapping Capabilities: [80] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <512ns, L1 <4us Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 3 Link: Latency L0s <512ns, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x4 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise- Slot: Number 0, PowerLimit 0.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Off, PwrInd On, Power- Root: Correctable- Non-Fatal- Fatal- PME- 00:0d.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [40] Subsystem: nVidia Corporation Unknown device 0000 Capabilities: [48] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+ Address: 00000000fee00000 Data: 4059 Capabilities: [60] HyperTransport: MSI Mapping Capabilities: [80] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <512ns, L1 <4us Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 2 Link: Latency L0s <512ns, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x4 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise- Slot: Number 0, PowerLimit 0.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Off, PwrInd On, Power- Root: Correctable- Non-Fatal- Fatal- PME- 00:0e.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [40] Subsystem: nVidia Corporation Unknown device 0000 Capabilities: [48] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+ Address: 00000000fee00000 Data: 4061 Capabilities: [60] HyperTransport: MSI Mapping Capabilities: [80] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <512ns, L1 <4us Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 1 Link: Latency L0s <512ns, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x8 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise- Slot: Number 0, PowerLimit 0.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Off, PwrInd On, Power- Root: Correctable- Non-Fatal- Fatal- PME- 00:0f.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [40] Subsystem: nVidia Corporation Unknown device 0000 Capabilities: [48] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+ Address: 00000000fee00000 Data: 4069 Capabilities: [60] HyperTransport: MSI Mapping Capabilities: [80] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <512ns, L1 <4us Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s L1, Port 0 Link: Latency L0s <512ns, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x16 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise- Slot: Number 0, PowerLimit 0.000000 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Off, PwrInd On, Power- Root: Correctable- Non-Fatal- Fatal- PME- 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR-