From yinghai.lu at amd.com Wed Nov 1 03:25:28 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 31 Oct 2006 18:25:28 -0800 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage Message-ID: <5986589C150B2F49A46483AC44C7BCA412D7AE@ssvlexmb2.amd.com> Please check patch attached. It could be applied to mkelfImage cleanly. Make mkelfImage to take vmlinux in elf64 for amd64 Actually the vmlinux on amd64 is elf64, so parse it and set it back to elf32. Signed-off-by: Yinghai Lu -------------- next part -------------- A non-text attachment was scrubbed... Name: mkelfImage_amd64.patch Type: application/octet-stream Size: 9141 bytes Desc: mkelfImage_amd64.patch URL: From greg.lindahl at qlogic.com Wed Nov 1 03:35:54 2006 From: greg.lindahl at qlogic.com (Greg Lindahl) Date: Tue, 31 Oct 2006 18:35:54 -0800 Subject: [LinuxBIOS] Improvements to "Supported Motherboards" wiki page. In-Reply-To: <20061031182241.GA14150@greenwood> References: <20061020210845.GA13614@greenwood> <20061025175032.GB8535@greenwood> <20061031162901.GH2037@greenwood> <45477FD0.6020704@gmail.com> <13426df10610310914w71ab6de6ob44114f0d8230d86@mail.gmail.com> <20061031182241.GA14150@greenwood> Message-ID: <20061101023554.GE5151@greglaptop.skyriver> Dumb question: IBM is currently shipping the e326m, not the e326, is this supported? I don't know how different it is. I don't have one, we're x-series bigots :-) -- greg From hawke at hawkesnest.net Wed Nov 1 04:01:18 2006 From: hawke at hawkesnest.net (Alex Mauer) Date: Tue, 31 Oct 2006 21:01:18 -0600 Subject: [LinuxBIOS] Improvements to "Supported Motherboards" wiki page. In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA412D768@ssvlexmb2.amd.com> <20061025231841.GB22616@coresystems.de> <20061026111748.GE6907@greenwood> Message-ID: Alex Mauer wrote: > Uwe Hermann wrote: > >> and with the Epia? Any known problems or should everything work? > I noticed on that page that the bottom section, "Motherboards supported in LinuxBIOSv1" lists the EPIA as "LBv2: Yes". If that is meant to indicate that it works in LBv2 it should probably be changed; if it is meant to indicate only that it exists in LBv2, then never mind. -Alex Mauer "hawke" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From rminnich at gmail.com Wed Nov 1 04:36:03 2006 From: rminnich at gmail.com (ron minnich) Date: Tue, 31 Oct 2006 20:36:03 -0700 Subject: [LinuxBIOS] Improvements to "Supported Motherboards" wiki page. In-Reply-To: <20061101023554.GE5151@greglaptop.skyriver> References: <20061020210845.GA13614@greenwood> <20061025175032.GB8535@greenwood> <20061031162901.GH2037@greenwood> <45477FD0.6020704@gmail.com> <13426df10610310914w71ab6de6ob44114f0d8230d86@mail.gmail.com> <20061031182241.GA14150@greenwood> <20061101023554.GE5151@greglaptop.skyriver> Message-ID: <13426df10610311936i8d9b55awbe77af76ef09f807@mail.gmail.com> On 10/31/06, Greg Lindahl wrote: > > Dumb question: IBM is currently shipping the e326m, not the e326, is > this supported? hard to say without testing it :-( get ibm to send us one :-) ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From svn at openbios.org Wed Nov 1 13:52:51 2006 From: svn at openbios.org (svn at openbios.org) Date: Wed, 01 Nov 2006 12:52:51 -0000 Subject: [LinuxBIOS] r2482 - in trunk/LinuxBIOSv2: documentation/RFC src/superio/ite/it8661f src/superio/ite/it8671f src/superio/ite/it8673f src/superio/ite/it8705f src/superio/ite/it8712f src/superio/ite/it8716f src/superio/ite/it8718f Message-ID: Author: uwe Date: 2006-11-01 13:52:49 +0100 (Wed, 01 Nov 2006) New Revision: 2482 Modified: trunk/LinuxBIOSv2/documentation/RFC/chip.tex trunk/LinuxBIOSv2/src/superio/ite/it8661f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8661f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8671f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8671f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8673f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8673f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8705f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8705f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8712f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8712f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8716f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8716f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8718f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8718f/superio.c Log: Rename some variables from *ITE* to *ite* for consistency reasons (refs #4). Signed-off-by: Uwe Hermann Acked-by: Stefan Reinauer Modified: trunk/LinuxBIOSv2/documentation/RFC/chip.tex =================================================================== --- trunk/LinuxBIOSv2/documentation/RFC/chip.tex 2006-10-28 16:03:37 UTC (rev 2481) +++ trunk/LinuxBIOSv2/documentation/RFC/chip.tex 2006-11-01 12:52:49 UTC (rev 2482) @@ -28,7 +28,7 @@ chip [path=] [""] \end{verbatim} The name is in the standard LinuxBIOS form of type/vendor/name, e.g. -"southbridge/intel/piix4e" or "superio/ITE/it8671f". The class of the +"southbridge/intel/piix4e" or "superio/ite/it8671f". The class of the chip is derived from the first pathname component of the name, and the chip configuration is derived from the following components. @@ -50,9 +50,9 @@ For each chip, there are two structures. The structures contain control information for the chip, and register initialization information. The names of the structures are derived by ``flattening'' the chip name, -as in the current linuxbios. For example, superio/ITE/xyz uses -two structs, one called superio_ITE_xyz_control and one called -superio_ITE_xyz_init. The control struct is initialized from the +as in the current linuxbios. For example, superio/ite/xyz uses +two structs, one called superio_ite_xyz_control and one called +superio_ite_xyz_init. The control struct is initialized from the chip name and path information, and has a pointer to the config struct. The config struct is initialized from the quote string Modified: trunk/LinuxBIOSv2/src/superio/ite/it8661f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8661f/chip.h 2006-10-28 16:03:37 UTC (rev 2481) +++ trunk/LinuxBIOSv2/src/superio/ite/it8661f/chip.h 2006-11-01 12:52:49 UTC (rev 2482) @@ -24,9 +24,9 @@ /* #include */ #include -extern struct chip_operations superio_ITE_it8661f_ops; +extern struct chip_operations superio_ite_it8661f_ops; -struct superio_ITE_it8661f_config { +struct superio_ite_it8661f_config { struct uart8250 com1, com2; /* struct pc_keyboard keyboard; */ }; Modified: trunk/LinuxBIOSv2/src/superio/ite/it8661f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8661f/superio.c 2006-10-28 16:03:37 UTC (rev 2481) +++ trunk/LinuxBIOSv2/src/superio/ite/it8661f/superio.c 2006-11-01 12:52:49 UTC (rev 2482) @@ -25,7 +25,7 @@ static void init(device_t dev) { - struct superio_ITE_it8661f_config *conf; + struct superio_ite_it8661f_config *conf; struct resource *res0, *res1; if (!dev->enabled) { @@ -72,7 +72,7 @@ sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]), pnp_dev_info); } -struct chip_operations superio_ITE_it8661f_ops = { +struct chip_operations superio_ite_it8661f_ops = { CHIP_NAME("ITE it8661f") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/ite/it8671f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8671f/chip.h 2006-10-28 16:03:37 UTC (rev 2481) +++ trunk/LinuxBIOSv2/src/superio/ite/it8671f/chip.h 2006-11-01 12:52:49 UTC (rev 2482) @@ -22,9 +22,9 @@ #include #include -extern struct chip_operations superio_ITE_it8671f_ops; +extern struct chip_operations superio_ite_it8671f_ops; -struct superio_ITE_it8671f_config { +struct superio_ite_it8671f_config { struct uart8250 com1, com2; struct pc_keyboard keyboard; }; Modified: trunk/LinuxBIOSv2/src/superio/ite/it8671f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8671f/superio.c 2006-10-28 16:03:37 UTC (rev 2481) +++ trunk/LinuxBIOSv2/src/superio/ite/it8671f/superio.c 2006-11-01 12:52:49 UTC (rev 2482) @@ -23,7 +23,7 @@ static void init(device_t dev) { - struct superio_ITE_it8671f_config *conf; + struct superio_ite_it8671f_config *conf; struct resource *res0, *res1; if (!dev->enabled) { @@ -76,7 +76,7 @@ sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]), pnp_dev_info); } -struct chip_operations superio_ITE_it8671f_ops = { +struct chip_operations superio_ite_it8671f_ops = { CHIP_NAME("ITE it8671f") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/ite/it8673f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8673f/chip.h 2006-10-28 16:03:37 UTC (rev 2481) +++ trunk/LinuxBIOSv2/src/superio/ite/it8673f/chip.h 2006-11-01 12:52:49 UTC (rev 2482) @@ -22,9 +22,9 @@ #include #include -extern struct chip_operations superio_ITE_it8673f_ops; +extern struct chip_operations superio_ite_it8673f_ops; -struct superio_ITE_it8673f_config { +struct superio_ite_it8673f_config { struct uart8250 com1, com2; struct pc_keyboard keyboard; }; Modified: trunk/LinuxBIOSv2/src/superio/ite/it8673f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8673f/superio.c 2006-10-28 16:03:37 UTC (rev 2481) +++ trunk/LinuxBIOSv2/src/superio/ite/it8673f/superio.c 2006-11-01 12:52:49 UTC (rev 2482) @@ -23,7 +23,7 @@ static void init(device_t dev) { - struct superio_ITE_it8673f_config *conf; + struct superio_ite_it8673f_config *conf; struct resource *res0, *res1; if (!dev->enabled) { @@ -78,7 +78,7 @@ sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]), pnp_dev_info); } -struct chip_operations superio_ITE_it8673f_ops = { +struct chip_operations superio_ite_it8673f_ops = { CHIP_NAME("ITE it8673f") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/ite/it8705f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8705f/chip.h 2006-10-28 16:03:37 UTC (rev 2481) +++ trunk/LinuxBIOSv2/src/superio/ite/it8705f/chip.h 2006-11-01 12:52:49 UTC (rev 2482) @@ -23,9 +23,9 @@ #include -extern struct chip_operations superio_ITE_it8705f_ops; +extern struct chip_operations superio_ite_it8705f_ops; -struct superio_ITE_it8705f_config { +struct superio_ite_it8705f_config { struct uart8250 com1, com2; }; Modified: trunk/LinuxBIOSv2/src/superio/ite/it8705f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8705f/superio.c 2006-10-28 16:03:37 UTC (rev 2481) +++ trunk/LinuxBIOSv2/src/superio/ite/it8705f/superio.c 2006-11-01 12:52:49 UTC (rev 2482) @@ -24,7 +24,7 @@ static void init(device_t dev) { - struct superio_ITE_it8705f_config *conf; + struct superio_ite_it8705f_config *conf; struct resource *res0, *res1; if (!dev->enabled) { @@ -79,7 +79,7 @@ sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]), pnp_dev_info); } -struct chip_operations superio_ITE_it8705f_ops = { +struct chip_operations superio_ite_it8705f_ops = { CHIP_NAME("ITE it8705f") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/ite/it8712f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8712f/chip.h 2006-10-28 16:03:37 UTC (rev 2481) +++ trunk/LinuxBIOSv2/src/superio/ite/it8712f/chip.h 2006-11-01 12:52:49 UTC (rev 2482) @@ -22,9 +22,9 @@ #include #include -extern struct chip_operations superio_ITE_it8712f_ops; +extern struct chip_operations superio_ite_it8712f_ops; -struct superio_ITE_it8712f_config { +struct superio_ite_it8712f_config { struct uart8250 com1, com2; struct pc_keyboard keyboard; }; Modified: trunk/LinuxBIOSv2/src/superio/ite/it8712f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8712f/superio.c 2006-10-28 16:03:37 UTC (rev 2481) +++ trunk/LinuxBIOSv2/src/superio/ite/it8712f/superio.c 2006-11-01 12:52:49 UTC (rev 2482) @@ -23,7 +23,7 @@ static void init(device_t dev) { - struct superio_ITE_it8712f_config *conf; + struct superio_ite_it8712f_config *conf; struct resource *res0, *res1; if (!dev->enabled) { @@ -84,7 +84,7 @@ sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]), pnp_dev_info); } -struct chip_operations superio_ITE_it8712f_ops = { +struct chip_operations superio_ite_it8712f_ops = { CHIP_NAME("ITE it8712f") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/ite/it8716f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8716f/chip.h 2006-10-28 16:03:37 UTC (rev 2481) +++ trunk/LinuxBIOSv2/src/superio/ite/it8716f/chip.h 2006-11-01 12:52:49 UTC (rev 2482) @@ -22,9 +22,9 @@ #include #include -extern struct chip_operations superio_ITE_it8716f_ops; +extern struct chip_operations superio_ite_it8716f_ops; -struct superio_ITE_it8716f_config { +struct superio_ite_it8716f_config { struct uart8250 com1, com2; struct pc_keyboard keyboard; }; Modified: trunk/LinuxBIOSv2/src/superio/ite/it8716f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8716f/superio.c 2006-10-28 16:03:37 UTC (rev 2481) +++ trunk/LinuxBIOSv2/src/superio/ite/it8716f/superio.c 2006-11-01 12:52:49 UTC (rev 2482) @@ -23,7 +23,7 @@ static void init(device_t dev) { - struct superio_ITE_it8716f_config *conf; + struct superio_ite_it8716f_config *conf; struct resource *res0, *res1; if (!dev->enabled) { @@ -84,7 +84,7 @@ sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]), pnp_dev_info); } -struct chip_operations superio_ITE_it8716f_ops = { +struct chip_operations superio_ite_it8716f_ops = { CHIP_NAME("ITE it8716f") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/ite/it8718f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8718f/chip.h 2006-10-28 16:03:37 UTC (rev 2481) +++ trunk/LinuxBIOSv2/src/superio/ite/it8718f/chip.h 2006-11-01 12:52:49 UTC (rev 2482) @@ -22,9 +22,9 @@ #include #include -extern struct chip_operations superio_ITE_it8718f_ops; +extern struct chip_operations superio_ite_it8718f_ops; -struct superio_ITE_it8718f_config { +struct superio_ite_it8718f_config { struct uart8250 com1, com2; struct pc_keyboard keyboard; }; Modified: trunk/LinuxBIOSv2/src/superio/ite/it8718f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8718f/superio.c 2006-10-28 16:03:37 UTC (rev 2481) +++ trunk/LinuxBIOSv2/src/superio/ite/it8718f/superio.c 2006-11-01 12:52:49 UTC (rev 2482) @@ -23,7 +23,7 @@ static void init(device_t dev) { - struct superio_ITE_it8718f_config *conf; + struct superio_ite_it8718f_config *conf; struct resource *res0, *res1; if (!dev->enabled) { @@ -80,7 +80,7 @@ sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]), pnp_dev_info); } -struct chip_operations superio_ITE_it8718f_ops = { +struct chip_operations superio_ite_it8718f_ops = { CHIP_NAME("ITE it8718f") .enable_dev = enable_dev, }; From stepan at coresystems.de Wed Nov 1 14:29:53 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 1 Nov 2006 14:29:53 +0100 Subject: [LinuxBIOS] Improvements to "Supported Motherboards" wiki page. In-Reply-To: <20061031182322.GB14150@greenwood> References: <20061020210845.GA13614@greenwood> <20061025175032.GB8535@greenwood> <20061031162901.GH2037@greenwood> <13426df10610310854i2aa4e128yaab276dae38c994a@mail.gmail.com> <20061031182322.GB14150@greenwood> Message-ID: <20061101132953.GB1210@coresystems.de> * Uwe Hermann [061031 19:23]: > On Tue, Oct 31, 2006 at 09:54:50AM -0700, ron minnich wrote: > > >> Technologic TS5300 > > > > sorta working. Works last time I checked. > > OK, I'll make this read "OK" and be yellow. make it green. it works fine here without issues. > > >Totalimpact Briq > > > > dead company > > That doesn't necessarily mean anything. Does it actually work? It did at some point in the past. Greg? -- 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 Nov 1 15:01:51 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 1 Nov 2006 15:01:51 +0100 Subject: [LinuxBIOS] Tyan s2892 the OLPC way In-Reply-To: <20061031155926.GA2037@greenwood> References: <13426df10610310710oa5f286ehd65d2a6024c137f9@mail.gmail.com> <01M903SVCGK28YQEKP@EMAIL1.BYU.EDU> <20061031155926.GA2037@greenwood> Message-ID: <20061101140151.GC1210@coresystems.de> * Uwe Hermann [061031 16:59]: > Hi Myles, > > can I remove the patches from the wiki, instead linking to the > respective files in the mailing list archive? > http://www.linuxbios.org/pipermail/linuxbios/ > > No need to duplicate the information in the wiki if it's already in the > archives... Yes please! Patches should be kept in the tracker (tracker.linuxbios.org), or on the mailing list, until everyone is using the tracker. 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 Wed Nov 1 15:07:01 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 1 Nov 2006 15:07:01 +0100 Subject: [LinuxBIOS] [PATCH] Cosmetic fixes to license headers in src/superio/ite. In-Reply-To: <20061031061321.GA9860@greenwood> References: <20061031061321.GA9860@greenwood> Message-ID: <20061101140701.GF1210@coresystems.de> * Uwe Hermann [061031 07:13]: > Adapt GPL license headers to match the current conventions. > > Signed-off-by: Uwe Hermann > > --- > > I also added the header to all *.lb files. Not tested with abuild, but > this shouldn't really break anything. 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 svn at openbios.org Wed Nov 1 15:21:33 2006 From: svn at openbios.org (svn at openbios.org) Date: Wed, 01 Nov 2006 14:21:33 -0000 Subject: [LinuxBIOS] r2483 - in trunk/LinuxBIOSv2: src/mainboard targets Message-ID: Author: stepan Date: 2006-11-01 15:21:31 +0100 (Wed, 01 Nov 2006) New Revision: 2483 Removed: trunk/LinuxBIOSv2/src/mainboard/advantech/ trunk/LinuxBIOSv2/targets/advantech/ Log: drop unsupported unfinished mainboard Advantech SOM GX DB533-C Signed-off-by: Richard Smith Acked-by: Stefan Reinauer From stepan at coresystems.de Wed Nov 1 15:22:16 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 1 Nov 2006 15:22:16 +0100 Subject: [LinuxBIOS] Improvements to "Supported Motherboards" wiki page. In-Reply-To: <45477FD0.6020704@gmail.com> References: <20061020210845.GA13614@greenwood> <20061025175032.GB8535@greenwood> <20061031162901.GH2037@greenwood> <45477FD0.6020704@gmail.com> Message-ID: <20061101142216.GA6713@coresystems.de> * Richard Smith [061031 17:54]: > You can essentially drop this one. I started on it to work on the OLPC > (is a geode) but found out it had a cs5535 rather than a cs5536. It > would be marked RED. I dropped it on your behalf. Should we delete the cs5535 component as well? -- 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 Nov 1 15:26:58 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 1 Nov 2006 15:26:58 +0100 Subject: [LinuxBIOS] Supported motherboards: List all boards in the tree? In-Reply-To: <20061031182241.GA14150@greenwood> References: <20061020210845.GA13614@greenwood> <20061025175032.GB8535@greenwood> <20061031162901.GH2037@greenwood> <45477FD0.6020704@gmail.com> <13426df10610310914w71ab6de6ob44114f0d8230d86@mail.gmail.com> <20061031182241.GA14150@greenwood> Message-ID: <20061101142658.GB6713@coresystems.de> * Uwe Hermann [061031 19:22]: > On Tue, Oct 31, 2006 at 10:14:39AM -0700, ron minnich wrote: > > If we're dropping it let's drop it. All these red lines give a misleading > > impression. > > I agree _if_ the board never worked at all and there's no chance that > someone will work on it over the next 1-2 years or so. > > But I would _not_ remove it (from svn) if it already worked at some > point (or parts of it). It did not. And it's still in the revision history. > Currently the wiki lists everything that has a directory in > src/mainboard. Maybe we should list only those boards which actually > work, at least partially... abuild tests for $LBROOT/src/mainboard/${VENDOR}/${MAINBOARD}/BROKEN and ignores boards with that line Maybe it should read $LBROOT/src/mainboard/${VENDOR}/${MAINBOARD}/UNSUPPORTED and be a basis whether this should appear in the web list or not. Also,... would it make sense to generate the web page from the repository, by adding a boardinfo.xml file in each board subdirectory with the information? This information could be used to create a multitude of pages,.. for example the qa.linuxbios.org things as well... 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 Nov 1 15:31:07 2006 From: svn at openbios.org (svn at openbios.org) Date: Wed, 01 Nov 2006 14:31:07 -0000 Subject: [LinuxBIOS] r2484 - in trunk/LinuxBIOSv2/src/superio/ite: it8661f it8671f it8673f it8705f it8712f it8716f it8718f Message-ID: Author: uwe Date: 2006-11-01 15:31:00 +0100 (Wed, 01 Nov 2006) New Revision: 2484 Modified: trunk/LinuxBIOSv2/src/superio/ite/it8661f/Config.lb trunk/LinuxBIOSv2/src/superio/ite/it8661f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f.h trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8661f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8671f/Config.lb trunk/LinuxBIOSv2/src/superio/ite/it8671f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f.h trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8671f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8673f/Config.lb trunk/LinuxBIOSv2/src/superio/ite/it8673f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f.h trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8673f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8705f/Config.lb trunk/LinuxBIOSv2/src/superio/ite/it8705f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f.h trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8705f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8712f/Config.lb trunk/LinuxBIOSv2/src/superio/ite/it8712f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f.h trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8712f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8716f/Config.lb trunk/LinuxBIOSv2/src/superio/ite/it8716f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f.h trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8716f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8718f/Config.lb trunk/LinuxBIOSv2/src/superio/ite/it8718f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f.h trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8718f/superio.c Log: Adapt GPL license headers to match the current conventions. Signed-off-by: Uwe Hermann Acked-by: Stefan Reinauer Modified: trunk/LinuxBIOSv2/src/superio/ite/it8661f/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8661f/Config.lb 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8661f/Config.lb 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,2 +1,22 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2006 Uwe Hermann +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; either version 2 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## + config chip.h object superio.o Modified: trunk/LinuxBIOSv2/src/superio/ite/it8661f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8661f/chip.h 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8661f/chip.h 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f.h 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f.h 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f_early_serial.c 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f_early_serial.c 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8661f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8661f/superio.c 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8661f/superio.c 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8671f/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8671f/Config.lb 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8671f/Config.lb 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,2 +1,22 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2006 Uwe Hermann +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; either version 2 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## + config chip.h object superio.o Modified: trunk/LinuxBIOSv2/src/superio/ite/it8671f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8671f/chip.h 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8671f/chip.h 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f.h 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f.h 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f_early_serial.c 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f_early_serial.c 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8671f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8671f/superio.c 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8671f/superio.c 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8673f/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8673f/Config.lb 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8673f/Config.lb 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,2 +1,22 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2006 Uwe Hermann +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; either version 2 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## + config chip.h object superio.o Modified: trunk/LinuxBIOSv2/src/superio/ite/it8673f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8673f/chip.h 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8673f/chip.h 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f.h 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f.h 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f_early_serial.c 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f_early_serial.c 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8673f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8673f/superio.c 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8673f/superio.c 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8705f/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8705f/Config.lb 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8705f/Config.lb 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,2 +1,22 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2006 Uwe Hermann +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; either version 2 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## + config chip.h object superio.o Modified: trunk/LinuxBIOSv2/src/superio/ite/it8705f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8705f/chip.h 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8705f/chip.h 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f.h 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f.h 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8705f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8705f/superio.c 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8705f/superio.c 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8712f/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8712f/Config.lb 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8712f/Config.lb 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,2 +1,22 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2006 Uwe Hermann +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; either version 2 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## + config chip.h object superio.o Modified: trunk/LinuxBIOSv2/src/superio/ite/it8712f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8712f/chip.h 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8712f/chip.h 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f.h 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f.h 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8712f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8712f/superio.c 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8712f/superio.c 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8716f/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8716f/Config.lb 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8716f/Config.lb 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,2 +1,22 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2006 Uwe Hermann +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; either version 2 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## + config chip.h object superio.o Modified: trunk/LinuxBIOSv2/src/superio/ite/it8716f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8716f/chip.h 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8716f/chip.h 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f.h 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f.h 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8716f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8716f/superio.c 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8716f/superio.c 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8718f/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8718f/Config.lb 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8718f/Config.lb 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,2 +1,22 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2006 Uwe Hermann +## +## This program is free software; you can redistribute it and/or modify +## it under the terms of the GNU General Public License as published by +## the Free Software Foundation; either version 2 of the License, or +## (at your option) any later version. +## +## This program is distributed in the hope that it will be useful, +## but WITHOUT ANY WARRANTY; without even the implied warranty of +## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +## GNU General Public License for more details. +## +## You should have received a copy of the GNU General Public License +## along with this program; if not, write to the Free Software +## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA +## + config chip.h object superio.o Modified: trunk/LinuxBIOSv2/src/superio/ite/it8718f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8718f/chip.h 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8718f/chip.h 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f.h 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f.h 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f_early_serial.c 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f_early_serial.c 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify Modified: trunk/LinuxBIOSv2/src/superio/ite/it8718f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8718f/superio.c 2006-11-01 14:21:31 UTC (rev 2483) +++ trunk/LinuxBIOSv2/src/superio/ite/it8718f/superio.c 2006-11-01 14:31:00 UTC (rev 2484) @@ -1,4 +1,6 @@ /* + * This file is part of the LinuxBIOS project. + * * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify From uwe at hermann-uwe.de Wed Nov 1 15:32:16 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Wed, 1 Nov 2006 15:32:16 +0100 Subject: [LinuxBIOS] [patch]MSI ms9185 Linuxbios In-Reply-To: References: Message-ID: <20061101143216.GA1145@greenwood> Add support for the MSI MS-9185 mainboard (code contributed by bxshi from MSI). Signed-off-by: bxshi Acked-by: Uwe Hermann --- The patch still didn't apply for some reason. Here's an updated patch which * applies cleanly to svn * removes the superfluous 'svn:executable' stuff from the patch * fixes a few minor cosmetic issues in the headers (whitespace mostly) * is tested with ./buildtarget (not abuild, though) by me; it compiles, but I cannot test more as I don't have the hardware As soon as the "Fix to vga emulator" issue is resolved, I think this can be committed. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- Index: src/southbridge/broadcom/bcm5785/bcm5785_sata.c =================================================================== --- src/southbridge/broadcom/bcm5785/bcm5785_sata.c (Revision 2481) +++ src/southbridge/broadcom/bcm5785/bcm5785_sata.c (Arbeitskopie) @@ -21,6 +21,8 @@ uint8_t *base; uint8_t *mmio; struct resource *res; + unsigned int mmio_base; + volatile unsigned int *mmio_reg; int i; if(!(dev->path.u.pci.devfn & 7)) { // only set it in Func0 @@ -30,6 +32,21 @@ res = find_resource(dev, 0x24); base = res->base; + + mmio_base = base; + mmio_base &= 0xfffffffc; + mmio_reg = (unsigned int *)( mmio_base + 0x10f0 ); + * mmio_reg = 0x40000001; + mmio_reg = ( unsigned int *)( mmio_base + 0x8c ); + * mmio_reg = 0x00ff2007; + mdelay( 10 ); + * mmio_reg = 0x78592009; + mdelay( 10 ); + * mmio_reg = 0x00082004; + mdelay( 10 ); + * mmio_reg = 0x00002004; + mdelay( 10 ); + //init PHY printk_debug("init PHY...\n"); Index: src/mainboard/msi/ms9185/Config.lb =================================================================== --- src/mainboard/msi/ms9185/Config.lb (Revision 0) +++ src/mainboard/msi/ms9185/Config.lb (Revision 0) @@ -0,0 +1,299 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2006 AMD +## Written by Yinghai Lu for AMD. +## +## Copyright (C) 2006 MSI +## Written by bxshi for MSI. +## +## 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. +## +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 PAYLOAD_SIZE = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE ) +default CONFIG_ROM_STREAM_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) + +## +## Compute where this copy of linuxBIOS will start in the boot rom +## +default _ROMBASE = ( CONFIG_ROM_STREAM_START + PAYLOAD_SIZE ) + +## +## 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 ) + +arch i386 end + +## +## Build the objects we have code for in this directory. +## + +driver mainboard.o + +#dir /drivers/si/3114 + +#needed by irq_tables and mptable and acpi_tables +object get_bus_conf.o + +if HAVE_MP_TABLE + object mptable.o +end + +if HAVE_PIRQ_TABLE + object irq_tables.o +end + +if USE_DCACHE_RAM + + if CONFIG_USE_INIT + # compile cache_as_ram.c to auto.o + makerule ./cache_as_ram_auto.o + 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 -o $@" + end + + else + #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 +end +## +## Build our 16 bit and 32 bit linuxBIOS entry code +## + +if USE_FALLBACK_IMAGE + mainboardinit cpu/x86/16bit/entry16.inc + ldscript /cpu/x86/16bit/entry16.lds +end + +mainboardinit cpu/x86/32bit/entry32.inc +if USE_DCACHE_RAM + if CONFIG_USE_INIT + ldscript /cpu/x86/32bit/entry32.lds + end + + if CONFIG_USE_INIT + ldscript /cpu/amd/car/cache_as_ram.lds + end +end + +## +## 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 + +## +## Include an id string (For safe flashing) +## +mainboardinit arch/i386/lib/id.inc +ldscript /arch/i386/lib/id.lds + +if USE_DCACHE_RAM + ## + ## Setup Cache-As-Ram + ## + mainboardinit cpu/amd/car/cache_as_ram.inc +end + +### +### 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 + if USE_DCACHE_RAM + ldscript /arch/i386/lib/failover.lds + end +end + +### +### O.k. We aren't just an intermediary anymore! +### + +## +## Setup RAM +## +if USE_DCACHE_RAM + + if CONFIG_USE_INIT + initobject cache_as_ram_auto.o + else + mainboardinit ./cache_as_ram_auto.inc + end + +end + +## +## Include the secondary Configuration files +## +if CONFIG_CHIP_NAME + config chip.h +end + +# sample config for amd/serengeti_cheetah +chip northbridge/amd/amdk8/root_complex + device apic_cluster 0 on + chip cpu/amd/socket_F + device apic 0 on end + end + end + device pci_domain 0 on + chip northbridge/amd/amdk8 + device pci 18.0 on end + device pci 18.0 on end + device pci 18.0 on # northbridge + # devices on link 0 + chip southbridge/broadcom/bcm5780 # HT2000 + device pci 0.0 on end # PXB 1 0x0130 + device pci 1.0 on # PXB 2 0x0130 + device pci 4.0 on end # GB E 0x1668 vid = 0x14e4 + device pci 4.1 on end # GB E 0x1669 vid = 0x14e4 + end + device pci 2.0 on end # PCI E 1 #0x0132 + device pci 3.0 on end # PCI E 2 + device pci 4.0 on end # PCI E 3 + device pci 5.0 on end # PCI E 4 + end + chip southbridge/broadcom/bcm5785 # HT1000 + device pci 0.0 on # HT PXB 0x0036 + device pci d.0 on end # PPBX 0x0104 + device pci e.0 on end # SATA 0x024a + device pci e.1 on end # SATA 0x024a bx_a001 + device pci e.2 on end # SATA 0x024a bx_a001 + device pci e.3 on end # SATA 0x024a bx_a001 + end + device pci 1.0 on # Legacy pci main 0x0205 + end + device pci 1.1 on end # IDE 0x0214 + device pci 1.2 on # LPC 0x0234 + chip superio/nsc/pc87417 + device pnp 2e.0 off # Floppy + io 0x60 = 0x3f0 + irq 0x70 = 6 + drq 0x74 = 2 + end + device pnp 2e.1 off # Parallel Port + io 0x60 = 0x378 + irq 0x70 = 7 + end + device pnp 2e.2 off # Com 2 + io 0x60 = 0x2f8 + irq 0x70 = 3 + end + device pnp 2e.3 on # Com 1 + io 0x60 = 0x3f8 + irq 0x70 = 4 + end + device pnp 2e.4 off end # SWC + device pnp 2e.5 off end # Mouse + device pnp 2e.6 on # Keyboard + io 0x60 = 0x60 + io 0x62 = 0x64 + irq 0x70 = 1 + end + device pnp 2e.7 off end # GPIO + device pnp 2e.f off end # XBUS + device pnp 2e.10 on #RTC + io 0x60 = 0x70 + io 0x62 = 0x72 + end + end + end + device pci 1.3 on end # WDTimer 0x0238 + device pci 1.4 on end # XIOAPIC0 0x0235 + device pci 1.5 on end # XIOAPIC1 + device pci 1.6 on end # XIOAPIC2 + device pci 2.0 on end # USB 0x0223 + device pci 2.1 on end # USB + device pci 2.2 on end # USB + #when HT_CHAIN_END_UNITID_BASE (0,1) < HT_CHAIN_UNITID_BASE (6,,,,), + chip drivers/pci/onboard + device pci 3.0 on end # it is in bcm5785_0 bus, but the device id can not be changed even unitid is changed, fake one to get the rom_address + # if HT_CHAIN_END_UNITID_BASE=0, it is 4, if HT_CHAIN_END_UNITID_BASE=1, it is 3 + register "rom_address" = "0xfff80000" + end + #bx_a013+ start + #chip drivers/pci/onboard #SATA2 + # device pci 5.0 on end + # device pci 5.1 on end + # device pci 5.2 on end + # device pci 5.3 on end + #end + #bx_a013+ end + + end + #when HT_CHAIN_END_UNITID_BASE > HT_CHAIN_UNITID_BASE (6, ,,,,) +# chip drivers/pci/onboard +# device pci 0.0 on end # fake, will be disabled +# end +# chip drivers/pci/onboard +# device pci 4.0 on end # it is in bcm5785_0 bus, but the device id can not be changed even unitid is changed +# register "rom_address" = "0xfff80000" +# end + + end # device pci 18.0 + device pci 18.1 on end + device pci 18.2 on end + device pci 18.3 on end + end # amdk8 + end #pci_domain +# chip drivers/generic/debug +# device pnp 0.0 off end # chip name +# device pnp 0.1 on end # pci_regs_all +# device pnp 0.2 off end # mem +# device pnp 0.3 off end # cpuid +# device pnp 0.4 off end # smbus_regs_all +# device pnp 0.5 off end # dual core msr +# device pnp 0.6 off end # cache size +# device pnp 0.7 off end # tsc +# end + +end + + Index: src/mainboard/msi/ms9185/mptable.c =================================================================== --- src/mainboard/msi/ms9185/mptable.c (Revision 0) +++ src/mainboard/msi/ms9185/mptable.c (Revision 0) @@ -0,0 +1,205 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2001 Eric W.Biederman + * + * Copyright (C) 2006 AMD + * Written by Yinghai Lu for AMD. + * + * Copyright (C) 2006 MSI + * Written by bxshi for MSI. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +#include +#include +#if CONFIG_LOGICAL_CPUS==1 +#include +#endif + +#include + +#include "mb_sysconf.h" + +extern void get_bus_conf(void); + +void *smp_write_config_table(void *v) +{ + static const char sig[4] = "PCMP"; + static const char oem[3] = "MSI"; + static const char productid[6] = "MS9185 "; + struct mp_config_table *mc; + + unsigned char bus_num; + int i; + struct mb_sysconf_t *m; + + mc = (void *)(((char *)v) + SMP_FLOATING_TABLE_LEN); + memset(mc, 0, sizeof(*mc)); + + memcpy(mc->mpc_signature, sig, sizeof(sig)); + mc->mpc_length = sizeof(*mc); /* initially just the header */ + mc->mpc_spec = 0x04; + mc->mpc_checksum = 0; /* not yet computed */ + memcpy(mc->mpc_oem, oem, sizeof(oem)); + memcpy(mc->mpc_productid, productid, sizeof(productid)); + mc->mpc_oemptr = 0; + mc->mpc_oemsize = 0; + mc->mpc_entry_count = 0; /* No entries yet... */ + mc->mpc_lapic = LAPIC_ADDR; + mc->mpe_length = 0; + mc->mpe_checksum = 0; + mc->reserved = 0; + + smp_write_processors(mc); + + get_bus_conf(); + m = sysconf.mb; + +/*Bus: Bus ID Type*/ + /* define bus and isa numbers */ + for(bus_num = 0; bus_num < m->bus_isa; bus_num++) { + smp_write_bus(mc, bus_num, "PCI "); + } + smp_write_bus(mc, m->bus_isa, "ISA "); + +/*I/O APICs: APIC ID Version State Address*/ + { + device_t dev = 0; + int i; + struct resource *res; + for(i=0; i<3; i++) { + dev = dev_find_device(0x1166, 0x0235, dev); + if (dev) { + res = find_resource(dev, PCI_BASE_ADDRESS_0); + if (res) { + smp_write_ioapic(mc, m->apicid_bcm5785[i], 0x11, res->base); + } + } + } + + } + +/*I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# */ + smp_write_intsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x0, m->apicid_bcm5785[0], 0x0); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x1, m->apicid_bcm5785[0], 0x1); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x0, m->apicid_bcm5785[0], 0x2); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x3, m->apicid_bcm5785[0], 0x3); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x4, m->apicid_bcm5785[0], 0x4); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x5, m->apicid_bcm5785[0], 0x5); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x6, m->apicid_bcm5785[0], 0x6); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x7, m->apicid_bcm5785[0], 0x7); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x8, m->apicid_bcm5785[0], 0x8); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x9, m->apicid_bcm5785[0], 0x9); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0xc, m->apicid_bcm5785[0], 0xc); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0xd, m->apicid_bcm5785[0], 0xd); + +//IDE + outb(0x02, 0xc00); outb(0x0e, 0xc01); + + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_bcm5785_0, ((1+sysconf.sbdn)<<2)|1, m->apicid_bcm5785[0], 0xe); // IDE + +//SATA + outb(0x07, 0xc00); outb(0x0f, 0xc01); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_bcm5785_1, (0x0e<<2)|0, m->apicid_bcm5785[0], 0xf); + +//USB + outb(0x01, 0xc00); outb(0x0a, 0xc01); + for(i=0;i<3;i++) { + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_bcm5785_0, ((2+sysconf.sbdn)<<2)|i, m->apicid_bcm5785[0], 0xa); // + } + + + + /* enable int */ + /* why here? must get the BAR and PCI command bit 1 set before enable it ....*/ + { + device_t dev; + dev = dev_find_device(0x1166, 0x0205, 0); + if(dev) { + uint32_t dword; + dword = pci_read_config32(dev, 0x6c); + dword |= (1<<4); // enable interrupts + pci_write_config32(dev, 0x6c, dword); + } + } + +//First pci-x slot (on bcm5785) under bus_bcm5785_1:d.0 + // AIC 8130 Galileo Technology... + for(i=0;i<4;i++) { + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_bcm5785_1_1, (6<<2)|i, m->apicid_bcm5785[1], 2 + (1+i)%4); // + } + + +//pci slot (on bcm5785) + for(i=0;i<4;i++) { + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_bcm5785_0, (5<<2)|i, m->apicid_bcm5785[1], 8+i%4); // + } + + +//onboard ati + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_bcm5785_0, (4<<2)|0, m->apicid_bcm5785[1], 0x1); + +//PCI-X on bcm5780 + for(i=0;i<4;i++) { + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_bcm5780[1], (4<<2)|i, m->apicid_bcm5785[1], 2 + (0+i)%4); // + } + +//onboard Broadcom + for(i=0;i<2;i++) { + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_bcm5780[2], (4<<2)|i, m->apicid_bcm5785[1], 0xa + (0+i)%4); // + } + + +// First PCI-E x8 + for(i=0;i<4;i++) { + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_bcm5780[5], (0<<2)|i, m->apicid_bcm5785[1], 0xe); // + } + + +// Second PCI-E x8 + for(i=0;i<4;i++) { + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_bcm5780[3], (0<<2)|i, m->apicid_bcm5785[1], 0xc); // + } + +// Third PCI-E x1 + for(i=0;i<4;i++) { + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_bcm5780[4], (0<<2)|i, m->apicid_bcm5785[1], 0xd); // + } + +/*Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN#*/ + smp_write_intsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x0, MP_APIC_ALL, 0x0); + smp_write_intsrc(mc, mp_NMI, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x0, MP_APIC_ALL, 0x1); + /* There is no extension information... */ + + /* Compute the checksums */ + mc->mpe_checksum = smp_compute_checksum(smp_next_mpc_entry(mc), mc->mpe_length); + mc->mpc_checksum = smp_compute_checksum(mc, mc->mpc_length); + printk_debug("Wrote the mp table end at: %p - %p\n", + mc, smp_next_mpe_entry(mc)); + return smp_next_mpe_entry(mc); +} + +unsigned long write_smp_table(unsigned long addr) +{ + void *v; + v = smp_write_floating_table(addr); + return (unsigned long)smp_write_config_table(v); +} Index: src/mainboard/msi/ms9185/irq_tables.c =================================================================== --- src/mainboard/msi/ms9185/irq_tables.c (Revision 0) +++ src/mainboard/msi/ms9185/irq_tables.c (Revision 0) @@ -0,0 +1,126 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 AMD + * Written by Yinghai Lu for AMD. + * + * Copyright (C) 2006 MSI + * Written by bxshi for MSI. + * + * 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 + */ + +/* This file was generated by getpir.c, do not modify! + (but if you do, please run checkpir on it to verify) + Contains the IRQ Routing Table dumped directly from your memory , wich BIOS sets up + + Documentation at : http://www.microsoft.com/hwdev/busbios/PCIIRQ.HTM +*/ +#include +#include +#include +#include +#include +#include + +#include "mb_sysconf.h" + + +static void write_pirq_info(struct irq_info *pirq_info, uint8_t bus, uint8_t devfn, uint8_t link0, uint16_t bitmap0, + uint8_t link1, uint16_t bitmap1, uint8_t link2, uint16_t bitmap2,uint8_t link3, uint16_t bitmap3, + uint8_t slot, uint8_t rfu) +{ + pirq_info->bus = bus; + pirq_info->devfn = devfn; + + pirq_info->irq[0].link = link0; + pirq_info->irq[0].bitmap = bitmap0; + pirq_info->irq[1].link = link1; + pirq_info->irq[1].bitmap = bitmap1; + pirq_info->irq[2].link = link2; + pirq_info->irq[2].bitmap = bitmap2; + pirq_info->irq[3].link = link3; + pirq_info->irq[3].bitmap = bitmap3; + + pirq_info->slot = slot; + pirq_info->rfu = rfu; +} + +extern void get_bus_conf(void); + +unsigned long write_pirq_routing_table(unsigned long addr) +{ + + struct irq_routing_table *pirq; + struct irq_info *pirq_info; + unsigned slot_num; + uint8_t *v; + + uint8_t sum=0; + int i; + + struct mb_sysconf_t *m; + + get_bus_conf(); + + m = sysconf.mb; + + /* Align the table to be 16 byte aligned. */ + addr += 15; + addr &= ~15; + + /* This table must be betweeen 0xf0000 & 0x100000 */ + printk_info("Writing IRQ routing tables to 0x%x...", addr); + + pirq = (void *)(addr); + v = (uint8_t *)(addr); + + pirq->signature = PIRQ_SIGNATURE; + pirq->version = PIRQ_VERSION; + + pirq->rtr_bus = m->bus_bcm5785_0; + pirq->rtr_devfn = (sysconf.sbdn<<3)|0; + + pirq->exclusive_irqs = 0; + + pirq->rtr_vendor = 0x1166; + pirq->rtr_device = 0x0036; + + pirq->miniport_data = 0; + + memset(pirq->rfu, 0, sizeof(pirq->rfu)); + + pirq_info = (void *) ( &pirq->checksum + 1); + slot_num = 0; +//pci bridge + write_pirq_info(pirq_info, m->bus_bcm5785_0, (sysconf.sbdn<<3)|0, 0x1, 0xdef8, 0x2, 0xdef8, 0x3, 0xdef8, 0x4, 0xdef8, 0, 0); + pirq_info++; slot_num++; + + pirq->size = 32 + 16 * slot_num; + + for (i = 0; i < pirq->size; i++) + sum += v[i]; + + sum = pirq->checksum - sum; + + if (sum != pirq->checksum) { + pirq->checksum = sum; + } + + printk_info("done.\n"); + + return (unsigned long) pirq_info; + +} Index: src/mainboard/msi/ms9185/resourcemap.c =================================================================== --- src/mainboard/msi/ms9185/resourcemap.c (Revision 0) +++ src/mainboard/msi/ms9185/resourcemap.c (Revision 0) @@ -0,0 +1,291 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2003 Stefan Reinauer + * + * Copyright (C) 2006 AMD + * Written by Yinghai Lu for AMD. + * + * Copyright (C) 2006 MSI + * Written by bxshi for MSI. + * + * 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 + */ + +/* + * ms9185 needs a different resource map + * + */ + +static void setup_ms9185_resource_map(void) +{ + static const unsigned int register_values[] = { + /* Careful set limit registers before base registers which contain the enables */ + /* DRAM Limit i Registers + * F1:0x44 i = 0 + * F1:0x4C i = 1 + * F1:0x54 i = 2 + * F1:0x5C i = 3 + * F1:0x64 i = 4 + * F1:0x6C i = 5 + * F1:0x74 i = 6 + * F1:0x7C i = 7 + * [ 2: 0] Destination Node ID + * 000 = Node 0 + * 001 = Node 1 + * 010 = Node 2 + * 011 = Node 3 + * 100 = Node 4 + * 101 = Node 5 + * 110 = Node 6 + * 111 = Node 7 + * [ 7: 3] Reserved + * [10: 8] Interleave select + * specifies the values of A[14:12] to use with interleave enable. + * [15:11] Reserved + * [31:16] DRAM Limit Address i Bits 39-24 + * This field defines the upper address bits of a 40 bit address + * that define the end of the DRAM region. + */ + PCI_ADDR(0, 0x18, 1, 0x44), 0x0000f8f8, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x4C), 0x0000f8f8, 0x00000001, + PCI_ADDR(0, 0x18, 1, 0x54), 0x0000f8f8, 0x00000002, + PCI_ADDR(0, 0x18, 1, 0x5C), 0x0000f8f8, 0x00000003, + PCI_ADDR(0, 0x18, 1, 0x64), 0x0000f8f8, 0x00000004, + PCI_ADDR(0, 0x18, 1, 0x6C), 0x0000f8f8, 0x00000005, + PCI_ADDR(0, 0x18, 1, 0x74), 0x0000f8f8, 0x00000006, + PCI_ADDR(0, 0x18, 1, 0x7C), 0x0000f8f8, 0x00000007, + /* DRAM Base i Registers + * F1:0x40 i = 0 + * F1:0x48 i = 1 + * F1:0x50 i = 2 + * F1:0x58 i = 3 + * F1:0x60 i = 4 + * F1:0x68 i = 5 + * F1:0x70 i = 6 + * F1:0x78 i = 7 + * [ 0: 0] Read Enable + * 0 = Reads Disabled + * 1 = Reads Enabled + * [ 1: 1] Write Enable + * 0 = Writes Disabled + * 1 = Writes Enabled + * [ 7: 2] Reserved + * [10: 8] Interleave Enable + * 000 = No interleave + * 001 = Interleave on A[12] (2 nodes) + * 010 = reserved + * 011 = Interleave on A[12] and A[14] (4 nodes) + * 100 = reserved + * 101 = reserved + * 110 = reserved + * 111 = Interleve on A[12] and A[13] and A[14] (8 nodes) + * [15:11] Reserved + * [13:16] DRAM Base Address i Bits 39-24 + * This field defines the upper address bits of a 40-bit address + * that define the start of the DRAM region. + */ + PCI_ADDR(0, 0x18, 1, 0x40), 0x0000f8fc, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x48), 0x0000f8fc, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x50), 0x0000f8fc, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x58), 0x0000f8fc, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x60), 0x0000f8fc, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x68), 0x0000f8fc, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x70), 0x0000f8fc, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x78), 0x0000f8fc, 0x00000000, + + /* Memory-Mapped I/O Limit i Registers + * F1:0x84 i = 0 + * F1:0x8C i = 1 + * F1:0x94 i = 2 + * F1:0x9C i = 3 + * F1:0xA4 i = 4 + * F1:0xAC i = 5 + * F1:0xB4 i = 6 + * F1:0xBC i = 7 + * [ 2: 0] Destination Node ID + * 000 = Node 0 + * 001 = Node 1 + * 010 = Node 2 + * 011 = Node 3 + * 100 = Node 4 + * 101 = Node 5 + * 110 = Node 6 + * 111 = Node 7 + * [ 3: 3] Reserved + * [ 5: 4] Destination Link ID + * 00 = Link 0 + * 01 = Link 1 + * 10 = Link 2 + * 11 = Reserved + * [ 6: 6] Reserved + * [ 7: 7] Non-Posted + * 0 = CPU writes may be posted + * 1 = CPU writes must be non-posted + * [31: 8] Memory-Mapped I/O Limit Address i (39-16) + * This field defines the upp adddress bits of a 40-bit address that + * defines the end of a memory-mapped I/O region n + */ + PCI_ADDR(0, 0x18, 1, 0x84), 0x00000048, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x8C), 0x00000048, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x94), 0x00000048, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x9C), 0x00000048, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xA4), 0x00000048, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xAC), 0x00000048, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xB4), 0x00000048, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xBC), 0x00000048, 0x00ffff20, + + /* Memory-Mapped I/O Base i Registers + * F1:0x80 i = 0 + * F1:0x88 i = 1 + * F1:0x90 i = 2 + * F1:0x98 i = 3 + * F1:0xA0 i = 4 + * F1:0xA8 i = 5 + * F1:0xB0 i = 6 + * F1:0xB8 i = 7 + * [ 0: 0] Read Enable + * 0 = Reads disabled + * 1 = Reads Enabled + * [ 1: 1] Write Enable + * 0 = Writes disabled + * 1 = Writes Enabled + * [ 2: 2] Cpu Disable + * 0 = Cpu can use this I/O range + * 1 = Cpu requests do not use this I/O range + * [ 3: 3] Lock + * 0 = base/limit registers i are read/write + * 1 = base/limit registers i are read-only + * [ 7: 4] Reserved + * [31: 8] Memory-Mapped I/O Base Address i (39-16) + * This field defines the upper address bits of a 40bit address + * that defines the start of memory-mapped I/O region i + */ + PCI_ADDR(0, 0x18, 1, 0x80), 0x000000f0, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x88), 0x000000f0, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x90), 0x000000f0, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x98), 0x000000f0, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xA0), 0x000000f0, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xA8), 0x000000f0, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xB0), 0x000000f0, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xB8), 0x000000f0, 0x00fc0003, + + /* PCI I/O Limit i Registers + * F1:0xC4 i = 0 + * F1:0xCC i = 1 + * F1:0xD4 i = 2 + * F1:0xDC i = 3 + * [ 2: 0] Destination Node ID + * 000 = Node 0 + * 001 = Node 1 + * 010 = Node 2 + * 011 = Node 3 + * 100 = Node 4 + * 101 = Node 5 + * 110 = Node 6 + * 111 = Node 7 + * [ 3: 3] Reserved + * [ 5: 4] Destination Link ID + * 00 = Link 0 + * 01 = Link 1 + * 10 = Link 2 + * 11 = reserved + * [11: 6] Reserved + * [24:12] PCI I/O Limit Address i + * This field defines the end of PCI I/O region n + * [31:25] Reserved + */ + PCI_ADDR(0, 0x18, 1, 0xC4), 0xFE000FC8, 0x01fff020, + PCI_ADDR(0, 0x18, 1, 0xCC), 0xFE000FC8, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xD4), 0xFE000FC8, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xDC), 0xFE000FC8, 0x00000000, + + /* PCI I/O Base i Registers + * F1:0xC0 i = 0 + * F1:0xC8 i = 1 + * F1:0xD0 i = 2 + * F1:0xD8 i = 3 + * [ 0: 0] Read Enable + * 0 = Reads Disabled + * 1 = Reads Enabled + * [ 1: 1] Write Enable + * 0 = Writes Disabled + * 1 = Writes Enabled + * [ 3: 2] Reserved + * [ 4: 4] VGA Enable + * 0 = VGA matches Disabled + * 1 = matches all address < 64K and where A[9:0] is in the + * range 3B0-3BB or 3C0-3DF independen of the base & limit registers + * [ 5: 5] ISA Enable + * 0 = ISA matches Disabled + * 1 = Blocks address < 64K and in the last 768 bytes of eack 1K block + * from matching agains this base/limit pair + * [11: 6] Reserved + * [24:12] PCI I/O Base i + * This field defines the start of PCI I/O region n + * [31:25] Reserved + */ + PCI_ADDR(0, 0x18, 1, 0xC0), 0xFE000FCC, 0x00000003, + PCI_ADDR(0, 0x18, 1, 0xC8), 0xFE000FCC, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xD0), 0xFE000FCC, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xD8), 0xFE000FCC, 0x00000000, + + /* Config Base and Limit i Registers + * F1:0xE0 i = 0 + * F1:0xE4 i = 1 + * F1:0xE8 i = 2 + * F1:0xEC i = 3 + * [ 0: 0] Read Enable + * 0 = Reads Disabled + * 1 = Reads Enabled + * [ 1: 1] Write Enable + * 0 = Writes Disabled + * 1 = Writes Enabled + * [ 2: 2] Device Number Compare Enable + * 0 = The ranges are based on bus number + * 1 = The ranges are ranges of devices on bus 0 + * [ 3: 3] Reserved + * [ 6: 4] Destination Node + * 000 = Node 0 + * 001 = Node 1 + * 010 = Node 2 + * 011 = Node 3 + * 100 = Node 4 + * 101 = Node 5 + * 110 = Node 6 + * 111 = Node 7 + * [ 7: 7] Reserved + * [ 9: 8] Destination Link + * 00 = Link 0 + * 01 = Link 1 + * 10 = Link 2 + * 11 - Reserved + * [15:10] Reserved + * [23:16] Bus Number Base i + * This field defines the lowest bus number in configuration region i + * [31:24] Bus Number Limit i + * This field defines the highest bus number in configuration regin i + */ + PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0xff000203, + PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xE8), 0x0000FC88, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xEC), 0x0000FC88, 0x00000000, + }; + + int max; + max = sizeof(register_values)/sizeof(register_values[0]); + setup_resource_map(register_values, max); +} + Index: src/mainboard/msi/ms9185/Options.lb =================================================================== --- src/mainboard/msi/ms9185/Options.lb (Revision 0) +++ src/mainboard/msi/ms9185/Options.lb (Revision 0) @@ -0,0 +1,332 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2006 AMD +## Written by Yinghai Lu for AMD. +## +## Copyright (C) 2006 MSI +## Written by bxshi for MSI. +## +## 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 HAVE_ACPI_TABLES +uses ACPI_SSDTX_NUM +uses USE_FALLBACK_IMAGE +uses HAVE_FALLBACK_BOOT +uses HAVE_HARD_RESET +uses IRQ_SLOT_COUNT +uses HAVE_OPTION_TABLE +uses CONFIG_MAX_CPUS +uses CONFIG_MAX_PHYSICAL_CPUS +uses CONFIG_LOGICAL_CPUS +uses CONFIG_IOAPIC +uses CONFIG_SMP +uses FALLBACK_SIZE +uses ROM_SIZE +uses ROM_SECTION_SIZE +uses ROM_IMAGE_SIZE +uses ROM_SECTION_SIZE +uses ROM_SECTION_OFFSET +uses CONFIG_ROM_STREAM +uses CONFIG_ROM_STREAM_START +uses PAYLOAD_SIZE +uses _ROMBASE +uses XIP_ROM_SIZE +uses XIP_ROM_BASE +uses STACK_SIZE +uses HEAP_SIZE +uses USE_OPTION_TABLE +uses LB_CKS_RANGE_START +uses LB_CKS_RANGE_END +uses LB_CKS_LOC +uses MAINBOARD_PART_NUMBER +uses MAINBOARD_VENDOR +uses MAINBOARD +uses MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID +uses MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID +uses LINUXBIOS_EXTRA_VERSION +uses _RAMBASE +uses TTYS0_BAUD +uses TTYS0_BASE +uses TTYS0_LCS +uses DEFAULT_CONSOLE_LOGLEVEL +uses MAXIMUM_CONSOLE_LOGLEVEL +uses MAINBOARD_POWER_ON_AFTER_POWER_FAIL +uses CONFIG_CONSOLE_SERIAL8250 +uses HAVE_INIT_TIMER +uses CONFIG_GDB_STUB +uses CONFIG_GDB_STUB +uses CROSS_COMPILE +uses CC +uses HOSTCC +uses OBJCOPY +uses CONFIG_CHIP_NAME +uses CONFIG_CONSOLE_VGA +uses CONFIG_PCI_ROM_RUN +uses HW_MEM_HOLE_SIZEK +uses HW_MEM_HOLE_SIZE_AUTO_INC +uses K8_HT_FREQ_1G_SUPPORT + +uses HT_CHAIN_UNITID_BASE +uses HT_CHAIN_END_UNITID_BASE +uses SB_HT_CHAIN_ON_BUS0 +uses SB_HT_CHAIN_UNITID_OFFSET_ONLY + +uses USE_DCACHE_RAM +uses DCACHE_RAM_BASE +uses DCACHE_RAM_SIZE +uses DCACHE_RAM_GLOBAL_VAR_SIZE +uses CONFIG_USE_INIT + +uses SERIAL_CPU_INIT + +uses ENABLE_APIC_EXT_ID +uses APIC_ID_OFFSET +uses LIFT_BSP_APIC_ID + +uses CONFIG_PCI_64BIT_PREF_MEM + +uses CONFIG_LB_MEM_TOPK + + +### +### Build options +### + +## +## ROM_SIZE is the size of boot ROM that this board will use. +## +default ROM_SIZE=524288 + +## +## FALLBACK_SIZE is the amount of the ROM the complete fallback image will use +## +#default FALLBACK_SIZE=131072 +#256K +default FALLBACK_SIZE=0x40000 + +#more 1M for pgtbl +default CONFIG_LB_MEM_TOPK=2048 + +## +## Build code for the fallback boot +## +default HAVE_FALLBACK_BOOT=1 + +## +## Build code to reset the motherboard from linuxBIOS +## +default HAVE_HARD_RESET=1 + +## +## Build code to export a programmable irq routing table +## +default HAVE_PIRQ_TABLE=1 +default IRQ_SLOT_COUNT=11 + +## +## Build code to export an x86 MP table +## Useful for specifying IRQ routing values +## +default HAVE_MP_TABLE=1 + +## ACPI tables will be included +#default HAVE_ACPI_TABLES=1 +## extra SSDT num +#default ACPI_SSDTX_NUM=1 + +## +## Build code to export a CMOS option table +## +default HAVE_OPTION_TABLE=1 + +## +## Move the default LinuxBIOS cmos range off of AMD RTC registers +## +default LB_CKS_RANGE_START=49 +default LB_CKS_RANGE_END=122 +default LB_CKS_LOC=123 + +## +## Build code for SMP support +## Only worry about 2 micro processors +## +default CONFIG_SMP=1 +default CONFIG_MAX_CPUS=4 +default CONFIG_MAX_PHYSICAL_CPUS=2 +default CONFIG_LOGICAL_CPUS=1 + +default SERIAL_CPU_INIT=0 + +default ENABLE_APIC_EXT_ID=0 +default APIC_ID_OFFSET=0x8 +default LIFT_BSP_APIC_ID=1 + +#CHIP_NAME ? +default CONFIG_CHIP_NAME=1 + +#memory hole size, 0 mean disable, others will enable the hole, at that case if it is small than mmio_basek, it will use mmio_basek instead. +#2G +#default HW_MEM_HOLE_SIZEK=0x200000 +#1G +default HW_MEM_HOLE_SIZEK=0x100000 +#512M +#default HW_MEM_HOLE_SIZEK=0x80000 + +#make auto increase hole size to avoid hole_startk equal to basek so as to make some kernel happy +#default HW_MEM_HOLE_SIZE_AUTO_INC=1 + +#Opteron K8 1G HT Support +default K8_HT_FREQ_1G_SUPPORT=1 + +#VGA Console +default CONFIG_CONSOLE_VGA=1 +default CONFIG_PCI_ROM_RUN=1 + +#HT Unit ID offset, default is 1, the typical one +default HT_CHAIN_UNITID_BASE=0x06 + +#real SB Unit ID, default is 0x20, mean dont touch it at last +default HT_CHAIN_END_UNITID_BASE=0x01 + +#make the SB HT chain on bus 0, default is not (0) +default SB_HT_CHAIN_ON_BUS0=2 + +#only offset for SB chain?, default is yes(1) +#default SB_HT_CHAIN_UNITID_OFFSET_ONLY=0 + +#allow capable device use that above 4G +#default CONFIG_PCI_64BIT_PREF_MEM=1 + +## +## enable CACHE_AS_RAM specifics +## +default USE_DCACHE_RAM=1 +default DCACHE_RAM_BASE=0xcc000 +default DCACHE_RAM_SIZE=0x04000 +default DCACHE_RAM_GLOBAL_VAR_SIZE=0x01000 +default CONFIG_USE_INIT=0 + +## +## Build code to setup a generic IOAPIC +## +default CONFIG_IOAPIC=1 + +## +## Clean up the motherboard id strings +## +default MAINBOARD_PART_NUMBER="MS9185" +default MAINBOARD_VENDOR="MSI" +default MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID=0x1022 +default MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID=0x2b80 + +### +### LinuxBIOS layout values +### + +## ROM_IMAGE_SIZE is the amount of space to allow linuxBIOS to occupy. +default ROM_IMAGE_SIZE = 65536 + +## +## Use a small 8K stack +## +default STACK_SIZE=0x2000 + +## +## Use a small 32K heap +## +default HEAP_SIZE=0x8000 + +## +## Only use the option table in a normal image +## +default USE_OPTION_TABLE = !USE_FALLBACK_IMAGE + +## +## LinuxBIOS C code runs at this location in RAM +## +default _RAMBASE=0x00100000 + +## +## Load the payload from the ROM +## +default CONFIG_ROM_STREAM = 1 + +### +### Defaults of options that you may want to override in the target config file +### + +## +## The default compiler +## +default CC="$(CROSS_COMPILE)gcc -m32" +default HOSTCC="gcc" + +## +## Disable the gdb stub by default +## +default CONFIG_GDB_STUB=0 + +## +## 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 + +## +## Select power on after power fail setting +default MAINBOARD_POWER_ON_AFTER_POWER_FAIL="MAINBOARD_POWER_ON" + +### End Options.lb +end Index: src/mainboard/msi/ms9185/mb_sysconf.h =================================================================== --- src/mainboard/msi/ms9185/mb_sysconf.h (Revision 0) +++ src/mainboard/msi/ms9185/mb_sysconf.h (Revision 0) @@ -0,0 +1,40 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 AMD + * Written by Yinghai Lu for AMD. + * + * Copyright (C) 2006 MSI + * Written by bxshi for MSI. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#ifndef MB_SYSCONF_H +#define MB_SYSCONF_H + +struct mb_sysconf_t { + unsigned char bus_isa; + unsigned char bus_bcm5780[7]; + unsigned char bus_bcm5785_0; + unsigned char bus_bcm5785_1; + unsigned char bus_bcm5785_1_1; + unsigned apicid_bcm5785[3]; + + unsigned sbdn2; +}; + +#endif + Index: src/mainboard/msi/ms9185/chip.h =================================================================== --- src/mainboard/msi/ms9185/chip.h (Revision 0) +++ src/mainboard/msi/ms9185/chip.h (Revision 0) @@ -0,0 +1,28 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 MSI + * Written by bxshi for MSI. + * + * 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_ms9185_ops; + +struct mainboard_msi_ms9185_config { +// int fixup_scsi; +// int fixup_vga; +}; + Index: src/mainboard/msi/ms9185/cmos.layout =================================================================== --- src/mainboard/msi/ms9185/cmos.layout (Revision 0) +++ src/mainboard/msi/ms9185/cmos.layout (Revision 0) @@ -0,0 +1,98 @@ +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 +395 1 e 1 hw_scrubber +396 1 e 1 interleave_chip_selects +397 2 e 8 max_mem_clock +399 1 e 2 dual_core +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 +440 4 e 9 slow_cpu +444 1 e 1 nmi +445 1 e 1 iommu +728 256 h 0 user_data +984 16 h 0 check_sum +# Reserve the extended AMD configuration registers +1000 24 r 0 reserved_memory + + + +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 +8 0 400Mhz +8 1 333Mhz +8 2 266Mhz +8 3 200Mhz +9 0 off +9 1 87.5% +9 2 75.0% +9 3 62.5% +9 4 50.0% +9 5 37.5% +9 6 25.0% +9 7 12.5% + +checksums + +checksum 392 983 984 + + Index: src/mainboard/msi/ms9185/mainboard.c =================================================================== --- src/mainboard/msi/ms9185/mainboard.c (Revision 0) +++ src/mainboard/msi/ms9185/mainboard.c (Revision 0) @@ -0,0 +1,33 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 MSI + * Written by bxshi for MSI. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +#include +#include "chip.h" + +#if CONFIG_CHIP_NAME == 1 +struct chip_operations mainboard_msi_ms9185_ops = { + CHIP_NAME("MSI MS-9185 mainboard") +}; +#endif Index: src/mainboard/msi/ms9185/get_bus_conf.c =================================================================== --- src/mainboard/msi/ms9185/get_bus_conf.c (Revision 0) +++ src/mainboard/msi/ms9185/get_bus_conf.c (Revision 0) @@ -0,0 +1,144 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 AMD + * Written by Yinghai Lu for AMD. + * + * Copyright (C) 2006 MSI + * Written by bxshi for MSI. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ +#include +#include +#include +#include +#include +#if CONFIG_LOGICAL_CPUS==1 +#include +#endif + +#include + +#include "mb_sysconf.h" + +// Global variables for MB layouts and these will be shared by irqtable mptable and acpi_tables +struct mb_sysconf_t mb_sysconf; + +static unsigned pci1234x[] = +{ //Here you only need to set value in pci1234 for HT-IO that could be installed or not + //You may need to preset pci1234 for HTIO board, please refer to src/northbridge/amd/amdk8/get_sblk_pci1234.c for detail + 0x0000ff0, + 0x0000ff0, +// 0x0000ff0, +// 0x0000ff0, +// 0x0000ff0, +// 0x0000ff0, +// 0x0000ff0, +// 0x0000ff0 +}; +static unsigned hcdnx[] = +{ //HT Chain device num, actually it is unit id base of every ht device in chain, assume every chain only have 4 ht device at most + 0x20202020, + 0x20202020, +// 0x20202020, +// 0x20202020, +// 0x20202020, +// 0x20202020, +// 0x20202020, +// 0x20202020, +}; + +extern void get_sblk_pci1234(void); + +static unsigned get_bus_conf_done = 0; + +void get_bus_conf(void) +{ + + unsigned apicid_base; + + device_t dev; + int i; + struct mb_sysconf_t *m; + + if(get_bus_conf_done==1) return; //do it only once + + get_bus_conf_done = 1; + + sysconf.mb = &mb_sysconf; + + m = sysconf.mb; + + sysconf.hc_possible_num = sizeof(pci1234x)/sizeof(pci1234x[0]); + + for(i=0;i> 8) & 0xff; + m->sbdn2 = sysconf.hcdn[0] & 0xff; // bcm5780 + + m->bus_bcm5785_0 = (sysconf.pci1234[0] >> 16) & 0xff; + m->bus_bcm5780[0] = m->bus_bcm5785_0; + + /* bcm5785 */ + dev = dev_find_slot(m->bus_bcm5785_0, PCI_DEVFN(sysconf.sbdn,0)); + if (dev) { + m->bus_bcm5785_1 = pci_read_config8(dev, PCI_SECONDARY_BUS); + dev = dev_find_slot(m->bus_bcm5785_1, PCI_DEVFN(0xd,0)); + if(dev) { + m->bus_bcm5785_1_1 = pci_read_config8(dev, PCI_SECONDARY_BUS); +#if HT_CHAIN_END_UNITID_BASE >= HT_CHAIN_UNITID_BASE + m->bus_isa = pci_read_config8(dev, PCI_SUBORDINATE_BUS); + m->bus_isa++; + printk_debug("bus_isa=%d\n",m->bus_isa); +#endif + } + } + else { + printk_debug("ERROR - could not find PCI %02x:%02x.0, using defaults\n", m->bus_bcm5785_0, sysconf.sbdn); + } + + /* bcm5780 */ + for(i = 1; i < 7; i++) { + dev = dev_find_slot(m->bus_bcm5780[0], PCI_DEVFN(m->sbdn2 + i - 1,0)); + if(dev) { + m->bus_bcm5780[i] = pci_read_config8(dev, PCI_SECONDARY_BUS); +#if HT_CHAIN_END_UNITID_BASE < HT_CHAIN_UNITID_BASE + m->bus_isa = pci_read_config8(dev, PCI_SUBORDINATE_BUS); + m->bus_isa++; + printk_debug("bus_isa=%d\n",m->bus_isa); +#endif + + } + else { + printk_debug("ERROR - could not find PCI %02x:%02x.0, using defaults\n", m->bus_bcm5780[0], m->sbdn2+i-1); + } + } + + +/*I/O APICs: APIC ID Version State Address*/ +#if CONFIG_LOGICAL_CPUS==1 + apicid_base = get_apicid_base(3); +#else + apicid_base = CONFIG_MAX_PHYSICAL_CPUS; +#endif + for(i=0;i<3;i++) + m->apicid_bcm5785[i] = apicid_base+i; +} Index: src/mainboard/msi/ms9185/cache_as_ram_auto.c =================================================================== --- src/mainboard/msi/ms9185/cache_as_ram_auto.c (Revision 0) +++ src/mainboard/msi/ms9185/cache_as_ram_auto.c (Revision 0) @@ -0,0 +1,375 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 Tyan + * Copyright (C) 2006 AMD + * Written by Yinghai Lu for Tyan and AMD. + * + * Copyright (C) 2006 MSI + * Written by bxshi for MSI. + * + * 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 +#define __ROMCC__ + +#define RAMINIT_SYSINFO 1 +#define CACHE_AS_RAM_ADDRESS_DEBUG 0 + +#define SET_NB_CFG_54 1 + +//used by raminit +#define QRANK_DIMM_SUPPORT 1 + +//used by incoherent_ht +//#define K8_SCAN_PCI_BUS 1 +//#define K8_ALLOCATE_IO_RANGE 1 + + +//used by init_cpus and fidvid +#define K8_SET_FIDVID 1 +//if we want to wait for core1 done before DQS training, set it to 0 +#define K8_SET_FIDVID_CORE0_ONLY 1 + +#define DEBUG_SMBUS 1 + +#include +#include +#include +#include +#include +#include +#include +#include "option_table.h" +#include "pc80/mc146818rtc_early.c" +#include "pc80/serial.c" +#include "arch/i386/lib/console.c" + +#if 0 +static void post_code(uint8_t value) { +#if 1 + int i; + for(i=0;i<0x80000;i++) { + outb(value, 0x80); + } +#endif +} +#endif + +#include +#include "southbridge/broadcom/bcm5785/bcm5785_early_smbus.c" +#include "northbridge/amd/amdk8/raminit.h" +#include "cpu/amd/model_fxx/apic_timer.c" +#include "lib/delay.c" + +#if CONFIG_USE_INIT == 0 + #include "lib/memcpy.c" +#endif + + +#include "cpu/x86/lapic/boot_cpu.c" +#include "northbridge/amd/amdk8/reset_test.c" +#include "northbridge/amd/amdk8/debug.c" +#include "superio/nsc/pc87417/pc87417_early_serial.c" +#include "cpu/amd/mtrr/amd_earlymtrr.c" +#include "cpu/x86/bist.h" + +#include "northbridge/amd/amdk8/setup_resource_map.c" + +#define SERIAL_DEV PNP_DEV(0x2e, PC87417_SP1) +#define RTC_DEV PNP_DEV(0x2e, PC87417_RTC) +#include "southbridge/broadcom/bcm5785/bcm5785_early_setup.c" +static void memreset_setup(void) +{ +} + +static void memreset(int controllers, const struct mem_controller *ctrl) +{ +} + +static inline void activate_spd_rom(const struct mem_controller *ctrl) +{ +#define SMBUS_SWITCH1 0x70 +#define SMBUS_SWITCH2 0x72 + unsigned device = (ctrl->channel0[0]) >> 8; + smbus_send_byte(SMBUS_SWITCH1, device & 0x0f); + smbus_send_byte(SMBUS_SWITCH2, (device >> 4) & 0x0f ); +} + +#if 0 +static inline void change_i2c_mux(unsigned device) +{ +#define SMBUS_SWITCH1 0x70 +#define SMBUS_SWITCH2 0x72 + smbus_send_byte(SMBUS_SWITCH1, device & 0x0f); + smbus_send_byte(SMBUS_SWITCH2, (device >> 4) & 0x0f ); +} +#endif + + + +static inline int spd_read_byte(unsigned device, unsigned address) +{ + return smbus_read_byte(device, address); +} + +#include "northbridge/amd/amdk8/amdk8_f.h" +#include "northbridge/amd/amdk8/coherent_ht.c" + +#include "northbridge/amd/amdk8/incoherent_ht.c" + +#include "northbridge/amd/amdk8/raminit_f.c" + +#include "sdram/generic_sdram.c" + + /* msi does not want the default */ +#include "resourcemap.c" + +#include "cpu/amd/dualcore/dualcore.c" + +#define RC0 (0x10<<8) +#define RC1 (0x01<<8) + +#define DIMM0 0x50 +#define DIMM1 0x51 +#define DIMM2 0x52 +#define DIMM3 0x53 +#define DIMM4 0x54 +#define DIMM5 0x55 +#define DIMM6 0x56 +#define DIMM7 0x57 + + +#include "cpu/amd/car/copy_and_run.c" +#include "cpu/amd/car/post_cache_as_ram.c" + +#include "cpu/amd/model_fxx/init_cpus.c" + +#include "cpu/amd/model_fxx/fidvid.c" + +#if USE_FALLBACK_IMAGE == 1 + +#include "northbridge/amd/amdk8/early_ht.c" + +void failover_process(unsigned long bist, unsigned long cpu_init_detectedx) +{ + + /* Is this a cpu only reset? Is this a secondary cpu? */ + if ((cpu_init_detectedx) || (!boot_cpu())) { + if (last_boot_normal()) { // RTC already inited + goto normal_image; + } else { + goto fallback_image; + } + } + /* Nothing special needs to be done to find bus 0 */ + /* Allow the HT devices to be found */ + + enumerate_ht_chain(); + + bcm5785_enable_rom(); + + bcm5785_enable_lpc(); + + //enable RTC + pc87417_enable_dev(RTC_DEV); + + /* Is this a deliberate reset by the bios */ +// post_code(0x22); + if (bios_reset_detected() && last_boot_normal()) { + goto normal_image; + } + /* This is the primary cpu how should I boot? */ + else if (do_normal_boot()) { + goto normal_image; + } + else { + goto fallback_image; + } + normal_image: +// post_code(0x23); + __asm__ volatile ("jmp __normal_image" + : /* outputs */ + : "a" (bist), "b" (cpu_init_detectedx) /* inputs */ + ); + + fallback_image: +// post_code(0x25); + ; + +} +#endif + +void real_main(unsigned long bist, unsigned long cpu_init_detectedx); + +void cache_as_ram_main(unsigned long bist, unsigned long cpu_init_detectedx) +{ + +#if USE_FALLBACK_IMAGE == 1 + failover_process(bist, cpu_init_detectedx); +#endif + real_main(bist, cpu_init_detectedx); + +} + +void real_main(unsigned long bist, unsigned long cpu_init_detectedx) +{ + static const uint16_t spd_addr[] = { + //first node + RC0|DIMM0, RC0|DIMM2, RC0|DIMM4, RC0|DIMM6, + RC0|DIMM1, RC0|DIMM3, RC0|DIMM5, RC0|DIMM7, +#if CONFIG_MAX_PHYSICAL_CPUS > 1 + //second node + RC1|DIMM0, RC1|DIMM2, RC1|DIMM4, RC1|DIMM6, + RC1|DIMM1, RC1|DIMM3, RC1|DIMM5, RC1|DIMM7, +#endif + + }; + + struct sys_info *sysinfo = (DCACHE_RAM_BASE + DCACHE_RAM_SIZE - DCACHE_RAM_GLOBAL_VAR_SIZE); + + int needs_reset; + unsigned bsp_apicid = 0; + + if (bist == 0) { + bsp_apicid = init_cpus(cpu_init_detectedx, sysinfo); + } + +// post_code(0x32); + + pc87417_enable_serial(SERIAL_DEV, TTYS0_BASE); + uart_init(); + console_init(); + +// dump_mem(DCACHE_RAM_BASE+DCACHE_RAM_SIZE-0x200, DCACHE_RAM_BASE+DCACHE_RAM_SIZE); + + /* Halt if there was a built in self test failure */ + report_bist_failure(bist); + + print_debug("*sysinfo range: ["); print_debug_hex32(sysinfo); print_debug(","); print_debug_hex32((unsigned long)sysinfo+sizeof(struct sys_info)); print_debug(")\r\n"); + + setup_ms9185_resource_map(); +#if 0 + dump_pci_device(PCI_DEV(0, 0x18, 0)); + dump_pci_device(PCI_DEV(0, 0x19, 0)); +#endif + + print_debug("bsp_apicid="); print_debug_hex8(bsp_apicid); print_debug("\r\n"); + + setup_coherent_ht_domain(); + + wait_all_core0_started(); +#if CONFIG_LOGICAL_CPUS==1 + // It is said that we should start core1 after all core0 launched + /* becase optimize_link_coherent_ht is moved out from setup_coherent_ht_domain, + * So here need to make sure last core0 is started, esp for two way system, + * (there may be apic id conflicts in that case) + */ + start_other_cores(); +//bx_a010- wait_all_other_cores_started(bsp_apicid); +#endif + + /* it will set up chains and store link pair for optimization later */ + ht_setup_chains_x(sysinfo); // it will init sblnk and sbbusn, nodes, sbdn + + bcm5785_early_setup(); + + +#if 0 + //it your CPU min fid is 1G, you can change HT to 1G and FID to max one time. + needs_reset = optimize_link_coherent_ht(); + needs_reset |= optimize_link_incoherent_ht(sysinfo); +#endif + +#if K8_SET_FIDVID == 1 + + { + msr_t msr; + msr=rdmsr(0xc0010042); + print_debug("begin msr fid, vid "); print_debug_hex32( msr.hi ); print_debug_hex32(msr.lo); print_debug("\r\n"); + + } + + enable_fid_change(); + + enable_fid_change_on_sb(sysinfo->sbbusn, sysinfo->sbdn); + + init_fidvid_bsp(bsp_apicid); + + // show final fid and vid + { + msr_t msr; + msr=rdmsr(0xc0010042); + print_debug("end msr fid, vid "); print_debug_hex32( msr.hi ); print_debug_hex32(msr.lo); print_debug("\r\n"); + + } +#endif + +#if 1 + needs_reset = optimize_link_coherent_ht(); + needs_reset |= optimize_link_incoherent_ht(sysinfo); + + // fidvid change will issue one LDTSTOP and the HT change will be effective too + if (needs_reset) { + print_info("ht reset -\r\n"); + soft_reset(); + } +#endif + allow_all_aps_stop(bsp_apicid); + + //It's the time to set ctrl in sysinfo now; + fill_mem_ctrl(sysinfo->nodes, sysinfo->ctrl, spd_addr); + + enable_smbus(); + +#if 0 + int i; + for(i=0;i<2;i++) { + activate_spd_rom(sysinfo->ctrl+i); + dump_smbus_registers(); + } +#endif + +#if 0 + int i; + for(i=1;i<256;i<<=1) { + change_i2c_mux(i); + dump_smbus_registers(); + } +#endif + + memreset_setup(); + + //do we need apci timer, tsc...., only debug need it for better output + /* all ap stopped? */ +// init_timer(); // Need to use TMICT to synconize FID/VID + + sdram_initialize(sysinfo->nodes, sysinfo->ctrl, sysinfo); + +#if 0 + print_pci_devices(); +#endif + +#if 0 +// dump_pci_devices(); + dump_pci_device_index_wait(PCI_DEV(0, 0x18, 2), 0x98); + dump_pci_device_index_wait(PCI_DEV(0, 0x19, 2), 0x98); +#endif + + post_cache_as_ram(); + + +} Index: targets/msi/ms9185/Config.lb =================================================================== --- targets/msi/ms9185/Config.lb (Revision 0) +++ targets/msi/ms9185/Config.lb (Revision 0) @@ -0,0 +1,94 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2006 MSI +## Written by bxshi for MSI. +## +## 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 +## + +# Sample config file for +# the msi ms9185 +# This will make a target directory of ./ms9185 + +target ms9185 +mainboard msi/ms9185 + +# ms9185 +romimage "normal" +# 36k for ATI option rom + option ROM_SIZE = 512*1024-36*1024 +# option ROM_SIZE = 524288 +# option ROM_SIZE = 425984 +# 64K for Etherboot +# option ROM_SIZE = 458752 + 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 /filo.elf + payload /tg3--filo.elf +# payload ../../../../payloads/e1000_vga.zelf +# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.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 + +romimage "fallback" + 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/filo_hda.zelf +# payload ../../../../payloads/tg3--filo_hda2_vga.zelf +# payload /filo.elf + payload /tg3--filo.elf +# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.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 + +buildrom ./ms9185.lxb ROM_SIZE "normal" "fallback" -------------- 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 Nov 1 15:32:22 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Wed, 1 Nov 2006 15:32:22 +0100 Subject: [LinuxBIOS] Improvements to "Supported Motherboards" wiki page. In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA412D768@ssvlexmb2.amd.com> <20061025231841.GB22616@coresystems.de> <20061026111748.GE6907@greenwood> Message-ID: <20061101143222.GB1145@greenwood> Hi, On Tue, Oct 31, 2006 at 09:01:18PM -0600, Alex Mauer wrote: > I noticed on that page that the bottom section, "Motherboards supported > in LinuxBIOSv1" lists the EPIA as "LBv2: Yes". If that is meant to > indicate that it works in LBv2 it should probably be changed; if it is > meant to indicate only that it exists in LBv2, then never mind. It's meant to indicate whether the board was ported to LinuxBIOSv2 at all. I clarified that a bit in the wiki. 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 Wed Nov 1 16:02:24 2006 From: svn at openbios.org (LinuxBIOS) Date: Wed, 01 Nov 2006 15:02:24 -0000 Subject: [LinuxBIOS] #10: test email interface of trac. In-Reply-To: <076.9e8f7f66c7e50fd849c179f41765ebb2@openbios.org> References: <076.9e8f7f66c7e50fd849c179f41765ebb2@openbios.org> Message-ID: <085.89fc49a7c1a7bc3e36df0b1392700074@openbios.org> #10: test email interface of trac. ---------------------------------------------------------+------------------ Reporter: Stefan Reinauer | Owner: stepan Type: enhancement | Status: assigned Priority: major | Milestone: Component: wiki/website | Version: v2 Resolution: | Keywords: Include_gantt: 1 | Dependencies: Due_assign: 10/01/2006 | Due_close: 10/30/2006 ---------------------------------------------------------+------------------ Comment (by stepan): all bugs get CCed to the list now. -- Ticket URL: LinuxBIOS From svn at openbios.org Wed Nov 1 16:05:09 2006 From: svn at openbios.org (LinuxBIOS) Date: Wed, 01 Nov 2006 15:05:09 -0000 Subject: [LinuxBIOS] #10: test email interface of trac. In-Reply-To: <076.9e8f7f66c7e50fd849c179f41765ebb2@openbios.org> References: <076.9e8f7f66c7e50fd849c179f41765ebb2@openbios.org> Message-ID: <085.9ca0b2900ceef6519cf13a8c947693e2@openbios.org> #10: test email interface of trac. ---------------------------------------------------------+------------------ Reporter: Stefan Reinauer | Owner: stepan Type: enhancement | Status: closed Priority: major | Milestone: Component: wiki/website | Version: v2 Resolution: fixed | Keywords: Include_gantt: 1 | Dependencies: Due_assign: 10/01/2006 | Due_close: 10/30/2006 ---------------------------------------------------------+------------------ Changes (by stepan): * status: assigned => closed * resolution: => fixed Comment: tracker seems to be finished for public use :-) -- Ticket URL: LinuxBIOS From rminnich at gmail.com Wed Nov 1 16:50:18 2006 From: rminnich at gmail.com (ron minnich) Date: Wed, 1 Nov 2006 08:50:18 -0700 Subject: [LinuxBIOS] [patch]MSI ms9185 Linuxbios In-Reply-To: <20061101143216.GA1145@greenwood> References: <20061101143216.GA1145@greenwood> Message-ID: <13426df10611010750v79b1e6a0s2ace8752cfd63902@mail.gmail.com> Is this patch acked now? Can I apply it? or has someone already? ron On 11/1/06, Uwe Hermann wrote: > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (GNU/Linux) > > iD8DBQFFSK/wXdVoV3jWIbQRAnhzAJ9uQ5pQa0UugtJzymxUPlKzsSdufACeN1IW > BuiUyWdsU7W6KmeiZSakw5w= > =Avm4 > -----END PGP SIGNATURE----- > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uwe at hermann-uwe.de Wed Nov 1 17:22:47 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Wed, 1 Nov 2006 17:22:47 +0100 Subject: [LinuxBIOS] [patch]MSI ms9185 Linuxbios In-Reply-To: <13426df10611010750v79b1e6a0s2ace8752cfd63902@mail.gmail.com> References: <20061101143216.GA1145@greenwood> <13426df10611010750v79b1e6a0s2ace8752cfd63902@mail.gmail.com> Message-ID: <20061101162247.GA9125@greenwood> Hi Ron, On Wed, Nov 01, 2006 at 08:50:18AM -0700, ron minnich wrote: > Is this patch acked now? Can I apply it? It's acked by be because it looks good as far as I can tell. I cannot test very much of it, though, as I said before. Note that it still contains the "Fix to vga emulator" part, which becomes obsolete if your patch from http://www.linuxbios.org/pipermail/linuxbios/2006-October/016478.html gets applied. I didn't Ack that one, because I don't know what it's all about. Someone else has to?look at it and Ack it. > or has someone already? No, I don't think so. Feel free to commit if nobody complains soon, and/or you yourself think the patch is ok and can be committed (i.e. Ack it too, then commit it, listing all Sign-offs and Acks it received). 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 stepan at coresystems.de Wed Nov 1 18:14:07 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 1 Nov 2006 18:14:07 +0100 Subject: [LinuxBIOS] [ANNOUNCE] LinuxBIOS bug and issue tracker Message-ID: <20061101171407.GA23845@coresystems.de> Dear LinuxBIOS community, we've set up a new issue tracker based on Edgewall Software's fine software "trac". Find it at http://tracker.linuxbios.org/ The tracker has the following features (amongst many others) * a timeline shows the latest work being done on the repository and on the issues/bugs. * a Roadmap that shows all current milestones, associated features and bugs, as well as the progress for each milestone. * A Source browser similar to viewvc, but much nicer looking. * management of bugs, features, addons for the different components of LinuxBIOS and its versions. * painting gantt charts on open features ;-) * Code tags, showing all occurences of "FIXME", "XXX" or "TODO" in the source tree. * triggers by svn commit messages: http://www.linuxbios.org/Development_Guidelines#Bug-Tracker All open tickets from the old tracker will be migrated soon as a further public test of the issue tracker ;-) and to bring some stale news back to mind You can add new tickets and also reply to tickets without logging in. But for some features, such as changing ticket descriptions later on, you need to log in using your svn account. From svn at openbios.org Wed Nov 1 20:09:20 2006 From: svn at openbios.org (LinuxBIOS) Date: Wed, 01 Nov 2006 19:09:20 -0000 Subject: [LinuxBIOS] #16: I2C driver and mainboard Config.lb Message-ID: <043.9971575dab9898fd0a98ed894c18b972@openbios.org> #16: I2C driver and mainboard Config.lb ---------------------------+------------------------------------------------ Reporter: stepan | Owner: ollie Type: defect | Status: new Priority: minor | Milestone: Component: code | Version: v2 Keywords: | Include_gantt: 0 Dependencies: | Due_assign: DD/MM/YYYY Due_close: DD/MM/YYYY | ---------------------------+------------------------------------------------ From Ollie Lho: 1. There are a lot of mainboards using driver/generic/generic as the i2c driver of their HW monitor. They should be changed to driver/i2c/*. 2. Rename driver/i2c/i2cmux to driver/i2c/pca9556 -- Ticket URL: LinuxBIOS From svn at openbios.org Wed Nov 1 20:13:36 2006 From: svn at openbios.org (LinuxBIOS) Date: Wed, 01 Nov 2006 19:13:36 -0000 Subject: [LinuxBIOS] #17: clean up linuxbios table handling Message-ID: <043.35c8f310c9e6bb0aa08b2e916cfd71e4@openbios.org> #17: clean up linuxbios table handling ---------------------------+------------------------------------------------ Reporter: stepan | Owner: stepan Type: task | Status: new Priority: major | Milestone: Component: code | Version: v2 Keywords: lbtable | Include_gantt: 0 Dependencies: | Due_assign: DD/MM/YYYY Due_close: DD/MM/YYYY | ---------------------------+------------------------------------------------ This patch does two things: - it drops duplicate code for linuxbios table creation to be the same for all platforms while allowing platform dependent additions to the table. - it adds a function to create the cmos checksum range table (which was specified but not implemented before, LB_TAG_OPTION_CHECKSUM) I applied the part which creates the LB_TAG_OPTION_CHECKSUM entry. The rest of this patch needs to be redone. -- Ticket URL: LinuxBIOS From svn at openbios.org Wed Nov 1 20:25:23 2006 From: svn at openbios.org (LinuxBIOS) Date: Wed, 01 Nov 2006 19:25:23 -0000 Subject: [LinuxBIOS] #18: autoprobe apic cluster and application processors on K8 systems Message-ID: <043.30821438b872a36b895426a82e94315a@openbios.org> #18: autoprobe apic cluster and application processors on K8 systems ---------------------------+------------------------------------------------ Reporter: stepan | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Keywords: | Include_gantt: 0 Dependencies: | Due_assign: DD/MM/YYYY Due_close: DD/MM/YYYY | ---------------------------+------------------------------------------------ In the config files the 19.x, 1a.x, 1b.x, 1c.x devices should be removed. In addition the apic cluster should be moved before the cpu devices. Additional CPUs and bridges can be autoprobed. -- Ticket URL: LinuxBIOS From svn at openbios.org Wed Nov 1 20:27:55 2006 From: svn at openbios.org (LinuxBIOS) Date: Wed, 01 Nov 2006 19:27:55 -0000 Subject: [LinuxBIOS] #18: autoprobe apic cluster and application processors on K8 systems In-Reply-To: <043.30821438b872a36b895426a82e94315a@openbios.org> References: <043.30821438b872a36b895426a82e94315a@openbios.org> Message-ID: <052.1908347aee9997d2ae1928af1059f50c@openbios.org> #18: autoprobe apic cluster and application processors on K8 systems ----------------------------+----------------------------------------------- Reporter: stepan | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: DD/MM/YYYY | Due_close: DD/MM/YYYY ----------------------------+----------------------------------------------- Comment (by stepan): YhLu explained: move the apic before other 1. solve the onboard vga init problem, otherwise if mtrr is inited after VGA init.. 0xa0000, can be used by VGA 2. one apic id path is enough, other will be created automatically....., So if only one cpu is installed and there will be complaint about the non-exist static device... We may only need northbridge with SB and SB in Config.lb YH -- Ticket URL: LinuxBIOS From svn at openbios.org Wed Nov 1 20:29:19 2006 From: svn at openbios.org (LinuxBIOS) Date: Wed, 01 Nov 2006 19:29:19 -0000 Subject: [LinuxBIOS] #18: autoprobe apic cluster and application processors on K8 systems In-Reply-To: <043.30821438b872a36b895426a82e94315a@openbios.org> References: <043.30821438b872a36b895426a82e94315a@openbios.org> Message-ID: <052.219e82abf230fc9e3683f231a3778f81@openbios.org> #18: autoprobe apic cluster and application processors on K8 systems ----------------------------+----------------------------------------------- Reporter: stepan | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: DD/MM/YYYY | Due_close: DD/MM/YYYY ----------------------------+----------------------------------------------- Comment (by stepan): Ollie Lho explained: On board VGA cards do depends on these patch to work correct. By moving the apic cluster in front of other devices, the CPU cache will inited before on board VGA cards are inited. Otherwise, memory transaction will not be passed to the VGA cards. -- Ticket URL: LinuxBIOS From stepan at coresystems.de Wed Nov 1 20:46:53 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 1 Nov 2006 20:46:53 +0100 Subject: [LinuxBIOS] [ANNOUNCE] LinuxBIOS bug and issue tracker In-Reply-To: <20061101171407.GA23845@coresystems.de> References: <20061101171407.GA23845@coresystems.de> Message-ID: <20061101194653.GC30675@coresystems.de> * Stefan Reinauer [061101 18:14]: > You can add new tickets and also reply to tickets without logging in. > But for some features, such as changing ticket descriptions later on, > you need to log in using your svn account. Please make sure you go to http://tracker.linuxbios.org/trac/LinuxBIOS/settings and enter a correct email address and name. -- 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 Nov 1 20:55:03 2006 From: svn at openbios.org (LinuxBIOS) Date: Wed, 01 Nov 2006 19:55:03 -0000 Subject: [LinuxBIOS] #18: autoprobe apic cluster and application processors on K8 systems In-Reply-To: <042.755dfc37e827871ad8b153e92799eacb@openbios.org> References: <042.755dfc37e827871ad8b153e92799eacb@openbios.org> Message-ID: <051.1fd4c5c49986e0a46991263d09d472b5@openbios.org> #18: autoprobe apic cluster and application processors on K8 systems ----------------------------+----------------------------------------------- Reporter: stepan | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Resolution: | Keywords: K8, cleanup Include_gantt: 0 | Dependencies: Due_assign: DD/MM/YYYY | Due_close: DD/MM/YYYY ----------------------------+----------------------------------------------- Changes (by stepan): * keywords: => K8, cleanup -- Ticket URL: LinuxBIOS From segher at kernel.crashing.org Wed Nov 1 21:10:19 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Wed, 1 Nov 2006 21:10:19 +0100 Subject: [LinuxBIOS] Tyan s2892 the OLPC way In-Reply-To: <20061101140151.GC1210@coresystems.de> References: <13426df10610310710oa5f286ehd65d2a6024c137f9@mail.gmail.com> <01M903SVCGK28YQEKP@EMAIL1.BYU.EDU> <20061031155926.GA2037@greenwood> <20061101140151.GC1210@coresystems.de> Message-ID: <9FBBCDD4-2930-4C4D-BD6F-6566838B43B8@kernel.crashing.org> > Patches should be kept in the tracker (tracker.linuxbios.org), or > on the > mailing list, until everyone is using the tracker. Can the tracker pick up patches from the mailing list automatically? Also, can it send all changes in whatever is tracked to a mailing list? Segher From stepan at coresystems.de Wed Nov 1 21:20:11 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 1 Nov 2006 21:20:11 +0100 Subject: [LinuxBIOS] Tyan s2892 the OLPC way In-Reply-To: <9FBBCDD4-2930-4C4D-BD6F-6566838B43B8@kernel.crashing.org> References: <13426df10610310710oa5f286ehd65d2a6024c137f9@mail.gmail.com> <01M903SVCGK28YQEKP@EMAIL1.BYU.EDU> <20061031155926.GA2037@greenwood> <20061101140151.GC1210@coresystems.de> <9FBBCDD4-2930-4C4D-BD6F-6566838B43B8@kernel.crashing.org> Message-ID: <20061101202011.GA11896@coresystems.de> * Segher Boessenkool [061101 21:10]: > >Patches should be kept in the tracker (tracker.linuxbios.org), or > >on the > >mailing list, until everyone is using the tracker. > > Can the tracker pick up patches from the mailing list > automatically? No, please go the other way round. Tracker is the first place for patches now. > Also, can it send all changes in whatever > is tracked to a mailing list? it does that. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From jrydberg at gnu.org Wed Nov 1 21:52:57 2006 From: jrydberg at gnu.org (Johan Rydberg) Date: Wed, 01 Nov 2006 21:52:57 +0100 Subject: [LinuxBIOS] [ANNOUNCE] LinuxBIOS bug and issue tracker References: <20061101171407.GA23845@coresystems.de> Message-ID: <87ac3ayjme.fsf@gnu.org> Stefan Reinauer writes: > we've set up a new issue tracker based on Edgewall Software's fine > software "trac". Find it at http://tracker.linuxbios.org/ Why not migrate the wiki as well? I rather enjoy the Trac wiki. It is simple, quite fast and you have quick and easy access to the other components of Trac (browser, tickets, ...). ~j -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From jrydberg at gnu.org Wed Nov 1 22:00:47 2006 From: jrydberg at gnu.org (Johan Rydberg) Date: Wed, 01 Nov 2006 22:00:47 +0100 Subject: [LinuxBIOS] #17: clean up linuxbios table handling References: <043.35c8f310c9e6bb0aa08b2e916cfd71e4@openbios.org> Message-ID: <8764dyyj9c.fsf@gnu.org> "LinuxBIOS" writes: > #17: clean up linuxbios table handling > ---------------------------+------------------------------------------------ > Reporter: stepan | Owner: stepan > [...] > > This patch does two things: > > - it drops duplicate code for linuxbios table creation to be the same for > all > platforms while allowing platform dependent additions to the table. > > - it adds a function to create the cmos checksum range table (which was > specified but not implemented before, LB_TAG_OPTION_CHECKSUM) > > I applied the part which creates the LB_TAG_OPTION_CHECKSUM entry. > > The rest of this patch needs to be redone. I thought I comment on this a bit; ticket comments and descriptors in Trac enjoy the same formatting rules as the wiki pages. Meaning, in the above comment you could get a nice bullet-list by simply replacing the dash with a star. It is even possible to nest lists. But that would require you to write the whole item on one line, which may be a bit frustrating from time to time (will there be a wiki-engine that can handle manual line-breaks any time soon?). (for reference; http://trac.edgewall.org/wiki/WikiFormatting ) Since most of the communicating in respect to tickets and patches should be done in the tracker from now on, I thought it was worth commenting on. If it wasn't, just ignore this mail. ~j -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From yinghai.lu at amd.com Wed Nov 1 23:12:58 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Wed, 1 Nov 2006 14:12:58 -0800 Subject: [LinuxBIOS] #17: clean up linuxbios table handling Message-ID: <5986589C150B2F49A46483AC44C7BCA412D7B8@ssvlexmb2.amd.com> I guess you may need to change file name for that. Otherwise you will have two linuxbios_table.o. YH From jeanraymond19769earrond at hotmail.com Thu Nov 2 07:53:46 2006 From: jeanraymond19769earrond at hotmail.com (jean raymond) Date: Thu, 02 Nov 2006 07:53:46 +0100 Subject: [LinuxBIOS] USB Bootloader Message-ID: Hello, I tried filo 0.4 from openbios.org, which was able to ide boot but hangs on usb boot with this: Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3 rom_stream: 0xfffe0000 - 0xfffeffff Found ELF candiate at offset 0 header_offset is 0 Header addresap[1].size = 0x9f390, mem->map[1].type = 0x1 n_type: 00000001 n_name(8): ELFBoot n_desc(10): Etherboot n_type: 00000002 n_name(8): ELFBoot n_desc(6): 5.4.2 Loading Etherboot version: 5.4.2 access the elf segments Dropping non PT_LOAD segment malloc Enter, size 32, free_mem_ptr 00122d0c malloc 0x00122d0c New segment addr 0x10000 size 0x430c0 offset 0x0 filesize 0xcc90 (cleaned up) New segment addr 0x10000 size 0x430c0 offset 0x0 filesize 0xcc90 lb_start : 0x0000000000100000, lb_end : 0x000000000012a000) start : 0x0000000000010000, middle : 0x000000000001cc90, end : 0x00000000000530c0 Load the segments Loading Segment: addr: 0x0000000000010000 memsz: 0x00000000000430c0 filesz: 0x000000000000cc90 dest:0x0000000000010000, middle:000000000001cc90, end:0x00000000000530c0, start_offset:0000000000000000, offset:0000000000000000 Skip the unused bytes Copy data from the initial buffer dest:0x0SOLE_BTEXT pci_init Scanning PCI: found 28 devices function allot, address = bffffc70 allot(0) function allot, address = bffffc60 Boot from (N)etwork (D)isk or (Q)uit? D Answer : Disk device present boot = 0x00000001, type = 1, failsafe = 0 function allot, address = bffffc60 Probing pci disk... [FILO]boot eax = 0xe1040170 boot ebx = 0x00800401 boot arg = 0x00000000 FILO version 0.4.1 (root at frlanzf00595) Tue Oct 31 17:00:24 CET 2006 Press for default boot, or for boot prompt... boot: uda1:/bzImage root=/dev/sda2 console=tty0 console=ttyS0,115200 dev=uda1, path=/bzImage name = uda1, type = 3, drive = 0, part = 1, offset = 0x00000000, length = 0x00000000 LinuxLabs USB bootloader Resetting UHCI uhc_init setting framelist to: 000101b0 Starting UHCI HCI at 000030c0 Resetting UHCI uhc_init setting framelist to: 000101b0 Starting UHCI HCI at 000030e0 frame_list is at bffede50 frame_list_link: addr: fffefe50 frame_list_link: raw addr: 00000800 frame_list_link: terminate: 00000000 frame_list_link: queue: 00000000 frame_list_link: depth: 00000000 frame_list is at bffebe50 frame_list_link: addr: ffff0650 frame_list_link: raw addr: 00000040 frame_list_link: terminate: 00000000 frame_list_link: queue: 00000000 frame_list_link: depth: 00000000 New USB device, setting address 2 port = 0x000030d0 controller =0x00000000 lowspeed = 0 next_usb_dev = 0x00000003 addr = 0x00000002 uhci_control_msg: request_type = 00000000 request = 00000005 wLength=0 ctrl_msg( 00000000, 00000000, 00000005, 00000002, 00000000, 00000000, p) 0 bytes in payload lowspeed = u HCI at 000030c0 failed_transaction: TD(0002e5a0): failed_transaction: type: SETUP failed_transaction: retries: 00000003 failed_transaction: IOC failed_transaction: active: 00000001 failed_transaction: device_addr: 00000000 failed_transaction: endpoint: 00000000 failed_transaction: data_toggle: 00000000 failed_transaction: max_transfer: 00000007 failed_transaction: actual: 00000000 failed_transaction: link: failed_transaction: addr: 0002e5c0 failed_transaction: raw addr: 0003e770 failed_transaction: terminate: 00000000 failed_transaction: queue: 00000000 failed_transaction: depth: 00000000 failed_transaction: TD(0002e5c0): failed_transaction: type: IN failed_transaction: retries: 00000000 failed_transaction: active: 00000001 failed_transaction: device_addr: 00000000 failed_transaction: endpoint: 00000000 failed_transaction: data_toggle: 00000001 failed_transaction: max_transfer: 000007ff failed_transaction: actual: 00000000 failed_transaction: link: failed_transaction: addr: fffefe50 failed_transaction: raw addr: 00000000 failed_transaction: terminate: 00000001 failed_transaction: queue: 00000000 failed_transaction: depth: 00000000 configure_device: set_address failed! value = 0x00001080 poll_usb 1 hc_type[1] = 00000000 ... There is a USB device, but it won't init! This is a bad thing. failed to open usb boot: uda1:/bzImage root=/dev/sda2 console=tty0 console=ttyS0,115200 Now, how can etherboot-filo be fixed to boot at all? And, how can filo 0.5 be fixed to boot USB? Thanks! _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From stepan at coresystems.de Thu Nov 2 11:32:44 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 2 Nov 2006 11:32:44 +0100 Subject: [LinuxBIOS] USB Bootloader In-Reply-To: References: Message-ID: <20061102103244.GA27497@coresystems.de> * jean raymond [061102 07:53]: > Hello, > > I tried filo 0.4 from openbios.org, which was able to ide boot but hangs > on usb boot with this: Interesting... There is no filo 0.4 on openbios.org ;-) Only 0.5... > n_type: 00000001 n_name(8): ELFBoot n_desc(10): Etherboot > n_type: 00000002 n_name(8): ELFBoot n_desc(6): 5.4.2 > Loading Etherboot version: 5.4.2 So you are using etherboot from etherboot.org? Yinghai, can you help? > Boot from (N)etwork (D)isk or (Q)uit? D > FILO version 0.4.1 (root at frlanzf00595) Tue Oct 31 17:00:24 CET 2006 > Press for default boot, or for boot prompt... > boot: uda1:/bzImage root=/dev/sda2 console=tty0 console=ttyS0,115200 > dev=uda1, path=/bzImage > name = uda1, type = 3, drive = 0, part = 1, offset = 0x00000000, length = > 0x00000000 > LinuxLabs USB bootloader > Resetting UHCI > uhc_init setting framelist to: 000101b0 > Starting UHCI > HCI at 000030c0 > Resetting UHCI > uhc_init setting framelist to: 000101b0 > Starting UHCI > HCI at 000030e0 > frame_list is at bffede50 > frame_list_link: addr: fffefe50 > frame_list_link: raw addr: 00000800 > frame_list_link: terminate: 00000000 > frame_list_link: queue: 00000000 > frame_list_link: depth: 00000000 > frame_list is at bffebe50 > frame_list_link: addr: ffff0650 > frame_list_link: raw addr: 00000040 > frame_list_link: terminate: 00000000 > frame_list_link: queue: 00000000 > frame_list_link: depth: 00000000 > New USB device, setting address 2 > port = 0x000030d0 controller =0x00000000 lowspeed = 0 next_usb_dev > = 0x00000003 addr = 0x00000002 > uhci_control_msg: request_type = 00000000 request = 00000005 wLength=0 > ctrl_msg( 00000000, 00000000, 00000005, 00000002, 00000000, 00000000, p) > 0 bytes in payload > lowspeed = u > HCI at 000030c0 > failed_transaction: TD(0002e5a0): > failed_transaction: type: SETUP > failed_transaction: retries: 00000003 > failed_transaction: IOC > failed_transaction: active: 00000001 > failed_transaction: device_addr: 00000000 > failed_transaction: endpoint: 00000000 > failed_transaction: data_toggle: 00000000 > failed_transaction: max_transfer: 00000007 > failed_transaction: actual: 00000000 > failed_transaction: link: > failed_transaction: addr: 0002e5c0 > failed_transaction: raw addr: 0003e770 > failed_transaction: terminate: 00000000 > failed_transaction: queue: 00000000 > failed_transaction: depth: 00000000 > failed_transaction: TD(0002e5c0): > failed_transaction: type: IN > failed_transaction: retries: 00000000 > failed_transaction: active: 00000001 > failed_transaction: device_addr: 00000000 > failed_transaction: endpoint: 00000000 > failed_transaction: data_toggle: 00000001 > failed_transaction: max_transfer: 000007ff > failed_transaction: actual: 00000000 > failed_transaction: link: > failed_transaction: addr: fffefe50 > failed_transaction: raw addr: 00000000 > failed_transaction: terminate: 00000001 > failed_transaction: queue: 00000000 > failed_transaction: depth: 00000000 > configure_device: set_address failed! > value = 0x00001080 > poll_usb 1 hc_type[1] = 00000000 > > ... > There is a USB device, but it won't init! This is a bad thing. > failed to open usb > boot: uda1:/bzImage root=/dev/sda2 console=tty0 console=ttyS0,115200 What board are you using, what LinuxBIOS revision,...? > Now, how can etherboot-filo be fixed to boot at all? > And, how can filo 0.5 be fixed to boot USB? What's the error you are seeing with filo 0.5? 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 jeanraymond19769earrond at hotmail.com Thu Nov 2 12:39:26 2006 From: jeanraymond19769earrond at hotmail.com (jean raymond) Date: Thu, 02 Nov 2006 12:39:26 +0100 Subject: [LinuxBIOS] USB Bootloader In-Reply-To: <20061102103244.GA27497@coresystems.de> Message-ID: I'm using Etherboot version 5.4.2 from etherboot.org. I'm using LinuxBIOS version2-2394 and a i386 board. The error is when I want to boot linux which is on device USB (so I use FILO in Etherboot). I use LinuxBIOS and Etherboot. LinuxBIOS works properly, and when I want to load linux, I have this error: HCI at 000030c0 failed_transaction: TD(0002e5a0): failed_transaction: type: SETUP failed_transaction: retries: 00000003 failed_transaction: IOC failed_transaction: active: 00000001 failed_transaction: device_addr: 00000000 failed_transaction: endpoint: 00000000 failed_transaction: data_toggle: 00000000 failed_transaction: max_transfer: 00000007 failed_transaction: actual: 00000000 failed_transaction: link: failed_transaction: addr: 0002e5c0 failed_transaction: raw addr: 0003e770 failed_transaction: terminate: 00000000 failed_transaction: queue: 00000000 failed_transaction: depth: 00000000 failed_transaction: TD(0002e5c0): failed_transaction: type: IN failed_transaction: retries: 00000000 failed_transaction: active: 00000001 failed_transaction: device_addr: 00000000 failed_transaction: endpoint: 00000000 failed_transaction: data_toggle: 00000001 failed_transaction: max_transfer: 000007ff failed_transaction: actual: 00000000 failed_transaction: link: failed_transaction: addr: fffefe50 failed_transaction: raw addr: 00000000 failed_transaction: terminate: 00000001 failed_transaction: queue: 00000000 failed_transaction: depth: 00000000 configure_device: set_address failed! and it repeats it. I suppose I have a bad config. So can you give me a config an example of config in order to boot on USB. Thanks for your help! >From: Stefan Reinauer >To: jean raymond >CC: linuxbios at linuxbios.org >Subject: Re: [LinuxBIOS] USB Bootloader >Date: Thu, 2 Nov 2006 11:32:44 +0100 > >* jean raymond [061102 07:53]: > > Hello, > > > > I tried filo 0.4 from openbios.org, which was able to ide boot but hangs > > on usb boot with this: > >Interesting... There is no filo 0.4 on openbios.org ;-) Only 0.5... > > > n_type: 00000001 n_name(8): ELFBoot n_desc(10): Etherboot > > n_type: 00000002 n_name(8): ELFBoot n_desc(6): 5.4.2 > > Loading Etherboot version: 5.4.2 > >So you are using etherboot from etherboot.org? > >Yinghai, can you help? > > > > Boot from (N)etwork (D)isk or (Q)uit? D > > > FILO version 0.4.1 (root at frlanzf00595) Tue Oct 31 17:00:24 CET 2006 > > Press for default boot, or for boot prompt... > > boot: uda1:/bzImage root=/dev/sda2 console=tty0 console=ttyS0,115200 > > dev=uda1, path=/bzImage > > name = uda1, type = 3, drive = 0, part = 1, offset = 0x00000000, length >= > > 0x00000000 > > LinuxLabs USB bootloader > > Resetting UHCI > > uhc_init setting framelist to: 000101b0 > > Starting UHCI > > HCI at 000030c0 > > Resetting UHCI > > uhc_init setting framelist to: 000101b0 > > Starting UHCI > > HCI at 000030e0 > > frame_list is at bffede50 > > frame_list_link: addr: fffefe50 > > frame_list_link: raw addr: 00000800 > > frame_list_link: terminate: 00000000 > > frame_list_link: queue: 00000000 > > frame_list_link: depth: 00000000 > > frame_list is at bffebe50 > > frame_list_link: addr: ffff0650 > > frame_list_link: raw addr: 00000040 > > frame_list_link: terminate: 00000000 > > frame_list_link: queue: 00000000 > > frame_list_link: depth: 00000000 > > New USB device, setting address 2 > > port = 0x000030d0 controller =0x00000000 lowspeed = 0 >next_usb_dev > > = 0x00000003 addr = 0x00000002 > > uhci_control_msg: request_type = 00000000 request = 00000005 wLength=0 > > ctrl_msg( 00000000, 00000000, 00000005, 00000002, 00000000, 00000000, p) > > 0 bytes in payload > > lowspeed = u > > HCI at 000030c0 > > failed_transaction: TD(0002e5a0): > > failed_transaction: type: SETUP > > failed_transaction: retries: 00000003 > > failed_transaction: IOC > > failed_transaction: active: 00000001 > > failed_transaction: device_addr: 00000000 > > failed_transaction: endpoint: 00000000 > > failed_transaction: data_toggle: 00000000 > > failed_transaction: max_transfer: 00000007 > > failed_transaction: actual: 00000000 > > failed_transaction: link: > > failed_transaction: addr: 0002e5c0 > > failed_transaction: raw addr: 0003e770 > > failed_transaction: terminate: 00000000 > > failed_transaction: queue: 00000000 > > failed_transaction: depth: 00000000 > > failed_transaction: TD(0002e5c0): > > failed_transaction: type: IN > > failed_transaction: retries: 00000000 > > failed_transaction: active: 00000001 > > failed_transaction: device_addr: 00000000 > > failed_transaction: endpoint: 00000000 > > failed_transaction: data_toggle: 00000001 > > failed_transaction: max_transfer: 000007ff > > failed_transaction: actual: 00000000 > > failed_transaction: link: > > failed_transaction: addr: fffefe50 > > failed_transaction: raw addr: 00000000 > > failed_transaction: terminate: 00000001 > > failed_transaction: queue: 00000000 > > failed_transaction: depth: 00000000 > > configure_device: set_address failed! > > value = 0x00001080 > > poll_usb 1 hc_type[1] = 00000000 > > > > ... > > > > There is a USB device, but it won't init! This is a bad thing. > > > failed to open usb > > boot: uda1:/bzImage root=/dev/sda2 console=tty0 console=ttyS0,115200 > >What board are you using, what LinuxBIOS revision,...? > > > Now, how can etherboot-filo be fixed to boot at all? > > And, how can filo 0.5 be fixed to boot USB? > >What's the error you are seeing with filo 0.5? > >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/ > >-- >linuxbios mailing list >linuxbios at linuxbios.org >http://www.openbios.org/mailman/listinfo/linuxbios _________________________________________________________________ Add a Yahoo! contact to Windows Live Messenger for a chance to win a free trip! http://www.imagine-windowslive.com/minisites/yahoo/default.aspx?locale=en-us&hmtagline From svn at openbios.org Thu Nov 2 13:06:27 2006 From: svn at openbios.org (LinuxBIOS) Date: Thu, 02 Nov 2006 12:06:27 -0000 Subject: [LinuxBIOS] #19: Remove useless #includes from mainboard.c files In-Reply-To: <060.90c6a1724c0dfb20c8eff5a14aefe6ab@openbios.org> References: <060.90c6a1724c0dfb20c8eff5a14aefe6ab@openbios.org> Message-ID: <069.58f7aa1f90bd77e11fcbb1b778b01257@openbios.org> #19: Remove useless #includes from mainboard.c files -----------------------------+---------------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: assigned Priority: minor | Milestone: Component: code | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: DD/MM/YYYY | Due_close: DD/MM/YYYY -----------------------------+---------------------------------------------- Changes (by uwe): * status: new => assigned * type: defect => enhancement Old description: > Remove some unneeded #includes from most mainboard.c files. > > Signed-off-by: Uwe Hemann > > --- > > Tested with abuild. New description: Remove some unneeded #includes from most mainboard.c files. Signed-off-by: Uwe Hermann --- Tested with abuild. -- Ticket URL: LinuxBIOS From stepan at coresystems.de Thu Nov 2 13:12:13 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 2 Nov 2006 13:12:13 +0100 Subject: [LinuxBIOS] USB Bootloader In-Reply-To: References: <20061102103244.GA27497@coresystems.de> Message-ID: <20061102121213.GA8883@coresystems.de> * jean raymond [061102 12:39]: > I'm using Etherboot version 5.4.2 from etherboot.org. > I'm using LinuxBIOS version2-2394 and a i386 board. which one? > I suppose I have a bad config. So can you give me a config an example of > config in order to boot on USB. It might just be a missing bit in the USB configuration of the board you are using. > Thanks for your help! you're welcome. -- 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 Thu Nov 2 13:25:13 2006 From: svn at openbios.org (LinuxBIOS) Date: Thu, 02 Nov 2006 12:25:13 -0000 Subject: [LinuxBIOS] #19: Remove useless #includes from mainboard.c files In-Reply-To: <060.90c6a1724c0dfb20c8eff5a14aefe6ab@openbios.org> References: <060.90c6a1724c0dfb20c8eff5a14aefe6ab@openbios.org> Message-ID: <069.91f66fc5c31eb5bb24ce85f55aedcc4f@openbios.org> #19: Remove useless #includes from mainboard.c files -----------------------------+---------------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: assigned Priority: minor | Milestone: Component: code | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: DD/MM/YYYY | Due_close: DD/MM/YYYY -----------------------------+---------------------------------------------- Comment (by stepan): Great. I believe we have a lot of useless includes all over the place due to the copy and paste nature of development in some circumstances. Acked-by: Stefan Reinauer -- Ticket URL: LinuxBIOS From jeanraymond19769earrond at hotmail.com Thu Nov 2 13:47:09 2006 From: jeanraymond19769earrond at hotmail.com (jean raymond) Date: Thu, 02 Nov 2006 13:47:09 +0100 Subject: [LinuxBIOS] USB Bootloader Message-ID: I have this config for FILO: #define AUTOBOOT_FILE "uda1:/bzImage root=/dev/sda2 console=tty0 console=ttyS0,115200" #define AUTOBOOT_DELAY 20 #define IDE_DISK 1 #define USB_DISK 1 #define FSYS_EXT2FS 1 #define FSYS_FAT 1 #define ELTORITO 1 #define SUPPORT_PCI 1 #define DEBUG_ALL 1 #define DEBUG_LINUXBIOS 1 #define DEBUG_PCI 1 #define DEBUG_USB 1 #define LINUX_LOADER 1 #define PCI_CONFIG_1 1 >From: Stefan Reinauer >To: jean raymond >CC: linuxbios at linuxbios.org >Subject: Re: [LinuxBIOS] USB Bootloader >Date: Thu, 2 Nov 2006 13:12:13 +0100 > >* jean raymond [061102 12:39]: > > I'm using Etherboot version 5.4.2 from etherboot.org. > > I'm using LinuxBIOS version2-2394 and a i386 board. > >which one? > > > I suppose I have a bad config. So can you give me a config an example of > > config in order to boot on USB. > >It might just be a missing bit in the USB configuration of the board you >are using. > > > Thanks for your help! > >you're welcome. > >-- >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/ > >-- >linuxbios mailing list >linuxbios at linuxbios.org >http://www.openbios.org/mailman/listinfo/linuxbios _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/ From svn at openbios.org Thu Nov 2 15:11:37 2006 From: svn at openbios.org (svn at openbios.org) Date: Thu, 02 Nov 2006 14:11:37 -0000 Subject: [LinuxBIOS] r2485 - in trunk/LinuxBIOSv2/src/mainboard: amd/quartet amd/serenade amd/serengeti_cheetah amd/serengeti_leopard amd/solo arima/hdama asus/p2b bitworks/ims broadcom/blast dell/s1850 densitron/dpx114 digitallogic/adl855pc eaglelion/5bcm emulation/qemu-i386 ibm/e325 ibm/e326 intel/jarrell intel/xe7501devkit iwill/dk8_htx iwill/dk8s2 iwill/dk8x lippert/frontrunner newisys/khepri sunw/ultra40 supermicro/x6dai_g supermicro/x6dhe_g supermicro/x6dhe_g2 supermicro/x6dhr_ig supermicro/x6dhr_ig2 tyan/s2735 tyan/s2850 tyan/s2875 tyan/s2880 tyan/s2881 tyan/s2882 tyan/s2885 tyan/s2891 tyan/s2892 tyan/s2895 tyan/s4880 tyan/s4882 via/epia Message-ID: Author: uwe Date: 2006-11-02 15:11:34 +0100 (Thu, 02 Nov 2006) New Revision: 2485 Modified: trunk/LinuxBIOSv2/src/mainboard/amd/quartet/mainboard.c trunk/LinuxBIOSv2/src/mainboard/amd/serenade/mainboard.c trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/mainboard.c trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/mainboard.c trunk/LinuxBIOSv2/src/mainboard/amd/solo/mainboard.c trunk/LinuxBIOSv2/src/mainboard/arima/hdama/mainboard.c trunk/LinuxBIOSv2/src/mainboard/asus/p2b/mainboard.c trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/mainboard.c trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/mainboard.c trunk/LinuxBIOSv2/src/mainboard/dell/s1850/mainboard.c trunk/LinuxBIOSv2/src/mainboard/densitron/dpx114/mainboard.c trunk/LinuxBIOSv2/src/mainboard/digitallogic/adl855pc/mainboard.c trunk/LinuxBIOSv2/src/mainboard/eaglelion/5bcm/mainboard.c trunk/LinuxBIOSv2/src/mainboard/emulation/qemu-i386/mainboard.c trunk/LinuxBIOSv2/src/mainboard/ibm/e325/mainboard.c trunk/LinuxBIOSv2/src/mainboard/ibm/e326/mainboard.c trunk/LinuxBIOSv2/src/mainboard/intel/jarrell/mainboard.c trunk/LinuxBIOSv2/src/mainboard/intel/xe7501devkit/mainboard.c trunk/LinuxBIOSv2/src/mainboard/iwill/dk8_htx/mainboard.c trunk/LinuxBIOSv2/src/mainboard/iwill/dk8s2/mainboard.c trunk/LinuxBIOSv2/src/mainboard/iwill/dk8x/mainboard.c trunk/LinuxBIOSv2/src/mainboard/lippert/frontrunner/mainboard.c trunk/LinuxBIOSv2/src/mainboard/newisys/khepri/mainboard.c trunk/LinuxBIOSv2/src/mainboard/sunw/ultra40/mainboard.c trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dai_g/mainboard.c trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g/mainboard.c trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g2/mainboard.c trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig/mainboard.c trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig2/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s2735/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s2850/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s2875/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s2880/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s2881/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s2882/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s2885/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s2891/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s2892/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s2895/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s4880/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s4882/mainboard.c trunk/LinuxBIOSv2/src/mainboard/via/epia/mainboard.c Log: Remove some unneeded #includes from most mainboard.c files. Signed-off-by: Uwe Hermann Acked-by: Stefan Reinauer Modified: trunk/LinuxBIOSv2/src/mainboard/amd/quartet/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/quartet/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/amd/quartet/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,11 +1,7 @@ -#include #include -#include -#include -#include #include "chip.h" - struct chip_operations mainboard_amd_quartet_ops = { CHIP_NAME("AMD Quartet mainboard") }; + Modified: trunk/LinuxBIOSv2/src/mainboard/amd/serenade/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/serenade/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/amd/serenade/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,10 +1,7 @@ -#include #include -#include -#include -#include #include "chip.h" struct chip_operations mainboard_amd_serenade_ops = { CHIP_NAME("AMD Serenade mainboard") }; + Modified: trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" #if CONFIG_CHIP_NAME == 1 @@ -10,3 +6,4 @@ CHIP_NAME("AMD Serengeti Cheetah mainboard") }; #endif + Modified: trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" #if CONFIG_CHIP_NAME == 1 @@ -10,3 +6,4 @@ CHIP_NAME("AMD Serengeti Leopard mainboard") }; #endif + Modified: trunk/LinuxBIOSv2/src/mainboard/amd/solo/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/solo/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/amd/solo/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,11 +1,7 @@ - -#include #include -#include -#include -#include #include "chip.h" struct chip_operations mainboard_amd_solo_ops = { CHIP_NAME("AMD Solo7 mainboard") }; + Modified: trunk/LinuxBIOSv2/src/mainboard/arima/hdama/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/arima/hdama/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/arima/hdama/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,15 +1,6 @@ -#include #include -#include -#include -#include -#include -#include -#include -#include #include "chip.h" - struct chip_operations mainboard_arima_hdama_ops = { CHIP_NAME("Arima HDAMA mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/asus/p2b/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/asus/p2b/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/asus/p2b/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,9 +1,4 @@ -#include #include -#include -#include -#include -#include #include "chip.h" struct chip_operations mainboard_asus_p2b_ops = { Modified: trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,9 +1,4 @@ -#include #include -#include -#include -#include -#include #include "chip.h" struct chip_operations mainboard_bitworks_ims_ops = { Modified: trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" #if CONFIG_CHIP_NAME == 1 @@ -10,3 +6,4 @@ CHIP_NAME("Broadcom Blast mainboard") }; #endif + Modified: trunk/LinuxBIOSv2/src/mainboard/dell/s1850/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/dell/s1850/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/dell/s1850/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,9 +1,4 @@ -#include #include -#include -#include -#include -#include #include "chip.h" struct chip_operations mainboard_dell_s1850_ops = { Modified: trunk/LinuxBIOSv2/src/mainboard/densitron/dpx114/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/densitron/dpx114/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/densitron/dpx114/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" struct chip_operations mainboard_densitron_dpx114_ops = { Modified: trunk/LinuxBIOSv2/src/mainboard/digitallogic/adl855pc/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/digitallogic/adl855pc/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/digitallogic/adl855pc/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" struct chip_operations mainboard_digitallogic_adl855pc_ops = { Modified: trunk/LinuxBIOSv2/src/mainboard/eaglelion/5bcm/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/eaglelion/5bcm/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/eaglelion/5bcm/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,9 +1,4 @@ -#include #include -#include -#include -#include -#include #include "chip.h" struct chip_operations mainboard_eaglelion_5bcm_ops = { Modified: trunk/LinuxBIOSv2/src/mainboard/emulation/qemu-i386/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/emulation/qemu-i386/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/emulation/qemu-i386/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" struct chip_operations mainboard_emulation_qemu_i386_ops = { Modified: trunk/LinuxBIOSv2/src/mainboard/ibm/e325/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/ibm/e325/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/ibm/e325/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,10 +1,7 @@ -#include #include -#include -#include -#include #include "chip.h" struct chip_operations mainboard_ibm_e325_ops = { CHIP_NAME("IBM eServer 325 mainboard") }; + Modified: trunk/LinuxBIOSv2/src/mainboard/ibm/e326/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/ibm/e326/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/ibm/e326/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,10 +1,7 @@ -#include #include -#include -#include -#include #include "chip.h" struct chip_operations mainboard_ibm_e326_ops = { CHIP_NAME("IBM eServer 326 mainboard") }; + Modified: trunk/LinuxBIOSv2/src/mainboard/intel/jarrell/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/intel/jarrell/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/intel/jarrell/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,10 +1,4 @@ -#include #include -#include -#include -#include -#include -#include #include "chip.h" struct chip_operations mainboard_intel_e7520_ops = { Modified: trunk/LinuxBIOSv2/src/mainboard/intel/xe7501devkit/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/intel/xe7501devkit/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/intel/xe7501devkit/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" #if CONFIG_CHIP_NAME == 1 @@ -10,3 +6,4 @@ CHIP_NAME("Intel Xeon E7501 DevKit mainboard") }; #endif + Modified: trunk/LinuxBIOSv2/src/mainboard/iwill/dk8_htx/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/iwill/dk8_htx/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/iwill/dk8_htx/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" #if CONFIG_CHIP_NAME == 1 @@ -10,3 +6,4 @@ CHIP_NAME("IWILL DK8-HTX mainboard") }; #endif + Modified: trunk/LinuxBIOSv2/src/mainboard/iwill/dk8s2/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/iwill/dk8s2/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/iwill/dk8s2/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" struct chip_operations mainboard_iwill_dk8s2_ops = { Modified: trunk/LinuxBIOSv2/src/mainboard/iwill/dk8x/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/iwill/dk8x/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/iwill/dk8x/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" struct chip_operations mainboard_iwill_dk8x_ops = { Modified: trunk/LinuxBIOSv2/src/mainboard/lippert/frontrunner/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/lippert/frontrunner/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/lippert/frontrunner/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,9 +1,4 @@ -#include #include -#include -#include -#include -#include #include "chip.h" struct chip_operations mainboard_lippert_frontrunner_ops = { Modified: trunk/LinuxBIOSv2/src/mainboard/newisys/khepri/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/newisys/khepri/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/newisys/khepri/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" struct chip_operations mainboard_newisys_khepri_ops = { Modified: trunk/LinuxBIOSv2/src/mainboard/sunw/ultra40/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/sunw/ultra40/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/sunw/ultra40/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" #if CONFIG_CHIP_NAME == 1 @@ -10,3 +6,4 @@ CHIP_NAME("Sun Ultra 40 mainboard") }; #endif + Modified: trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dai_g/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dai_g/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dai_g/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,9 +1,4 @@ -#include #include -#include -#include -#include -#include #include "chip.h" struct chip_operations supermicro_x6dai_g_ops = { Modified: trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,9 +1,4 @@ -#include #include -#include -#include -#include -#include #include "chip.h" struct chip_operations supermicro_x6dhe_g_ops = { Modified: trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g2/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g2/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g2/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,9 +1,4 @@ -#include #include -#include -#include -#include -#include #include "chip.h" struct chip_operations supermicro_x6dhe_g2_ops = { Modified: trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,9 +1,4 @@ -#include #include -#include -#include -#include -#include #include "chip.h" struct chip_operations mainboard_supermicro_x6dhr_ig_ops = { Modified: trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig2/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig2/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig2/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,9 +1,4 @@ -#include #include -#include -#include -#include -#include #include "chip.h" struct chip_operations mainboard_supermicro_x6dhr_ig2_ops = { Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2735/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2735/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2735/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" #if CONFIG_CHIP_NAME == 1 @@ -10,3 +6,4 @@ CHIP_NAME("Tyan S2735 mainboard") }; #endif + Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2850/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2850/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2850/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" #if CONFIG_CHIP_NAME == 1 @@ -10,3 +6,4 @@ CHIP_NAME("Tyan S2850 mainboard") }; #endif + Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2875/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2875/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2875/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" #if CONFIG_CHIP_NAME == 1 @@ -10,3 +6,4 @@ CHIP_NAME("Tyan S2875 mainboard") }; #endif + Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2880/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2880/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2880/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" #if CONFIG_CHIP_NAME == 1 @@ -10,3 +6,4 @@ CHIP_NAME("Tyan S2880 mainboard") }; #endif + Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2881/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2881/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2881/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" #if CONFIG_CHIP_NAME == 1 @@ -10,3 +6,4 @@ CHIP_NAME("Tyan S2881 mainboard") }; #endif + Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2882/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2882/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2882/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" #if CONFIG_CHIP_NAME == 1 @@ -10,3 +6,4 @@ CHIP_NAME("Tyan S2882 mainboard") }; #endif + Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2885/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2885/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2885/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" #if CONFIG_CHIP_NAME == 1 @@ -10,3 +6,4 @@ CHIP_NAME("Tyan S2885 mainboard") }; #endif + Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2891/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2891/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2891/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" #if CONFIG_CHIP_NAME == 1 @@ -10,3 +6,4 @@ CHIP_NAME("Tyan S2891 mainboard") }; #endif + Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2892/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2892/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2892/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" #if CONFIG_CHIP_NAME == 1 @@ -10,3 +6,4 @@ CHIP_NAME("Tyan S2892 mainboard") }; #endif + Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2895/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2895/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2895/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" #if CONFIG_CHIP_NAME == 1 @@ -10,3 +6,4 @@ CHIP_NAME("Tyan S2895 mainboard") }; #endif + Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s4880/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s4880/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s4880/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" #if CONFIG_CHIP_NAME == 1 @@ -10,3 +6,4 @@ CHIP_NAME("Tyan S4880 mainboard") }; #endif + Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s4882/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s4882/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s4882/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,8 +1,4 @@ -#include #include -#include -#include -#include #include "chip.h" #if CONFIG_CHIP_NAME == 1 @@ -10,3 +6,4 @@ CHIP_NAME("Tyan S4882 mainboard") }; #endif + Modified: trunk/LinuxBIOSv2/src/mainboard/via/epia/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/via/epia/mainboard.c 2006-11-01 14:31:00 UTC (rev 2484) +++ trunk/LinuxBIOSv2/src/mainboard/via/epia/mainboard.c 2006-11-02 14:11:34 UTC (rev 2485) @@ -1,9 +1,4 @@ -#include #include -#include -#include -#include -#include #include "chip.h" struct chip_operations mainboard_via_epia_ops = { From svn at openbios.org Thu Nov 2 15:16:54 2006 From: svn at openbios.org (LinuxBIOS) Date: Thu, 02 Nov 2006 14:16:54 -0000 Subject: [LinuxBIOS] #19: Remove useless #includes from mainboard.c files In-Reply-To: <060.90c6a1724c0dfb20c8eff5a14aefe6ab@openbios.org> References: <060.90c6a1724c0dfb20c8eff5a14aefe6ab@openbios.org> Message-ID: <069.bac5f0ea02e27e8b8d5b8f2825858902@openbios.org> #19: Remove useless #includes from mainboard.c files -----------------------------+---------------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: closed Priority: minor | Milestone: Component: code | Version: v2 Resolution: fixed | Keywords: Include_gantt: 0 | Dependencies: Due_assign: DD/MM/YYYY | Due_close: DD/MM/YYYY -----------------------------+---------------------------------------------- Changes (by uwe): * status: assigned => closed * resolution: => fixed Comment: Oops, I forgot to close the bug via the commit message (rev [2485]). Closing manually now. -- Ticket URL: LinuxBIOS From svn at openbios.org Thu Nov 2 15:23:57 2006 From: svn at openbios.org (LinuxBIOS) Date: Thu, 02 Nov 2006 14:23:57 -0000 Subject: [LinuxBIOS] #4: Directory names in svn should be (mostly) lower-case In-Reply-To: <060.970a7d667ffb1a41d8cf749df3519631@openbios.org> References: <060.970a7d667ffb1a41d8cf749df3519631@openbios.org> Message-ID: <069.2972fb21b32708770aa1e2c118444e4f@openbios.org> #4: Directory names in svn should be (mostly) lower-case -----------------------------+---------------------------------------------- Reporter: uwe | Owner: somebody Type: enhancement | Status: new Priority: minor | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: | Keywords: Include_gantt: 1 | Dependencies: Due_assign: | Due_close: 12/31/2006 -----------------------------+---------------------------------------------- Changes (by uwe): * milestone: => Cosmetic fixes -- Ticket URL: LinuxBIOS From svn at openbios.org Thu Nov 2 15:26:32 2006 From: svn at openbios.org (LinuxBIOS) Date: Thu, 02 Nov 2006 14:26:32 -0000 Subject: [LinuxBIOS] #14: Rename "stream" to "payload" In-Reply-To: <060.7ce253b9ecf6e23e1d409c7624ff96d8@openbios.org> References: <060.7ce253b9ecf6e23e1d409c7624ff96d8@openbios.org> Message-ID: <069.9c66597b8ccdba1a0fb1531c2b164d69@openbios.org> #14: Rename "stream" to "payload" -----------------------------+---------------------------------------------- Reporter: uwe | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: DD/MM/YYYY | Due_close: DD/MM/YYYY -----------------------------+---------------------------------------------- Changes (by uwe): * milestone: => Cosmetic fixes -- Ticket URL: LinuxBIOS From svn at openbios.org Thu Nov 2 15:27:35 2006 From: svn at openbios.org (LinuxBIOS) Date: Thu, 02 Nov 2006 14:27:35 -0000 Subject: [LinuxBIOS] #9: Do not hardcode iasl path In-Reply-To: <060.d4934ecb9e5bc6a67fe697c6d249e0e7@openbios.org> References: <060.d4934ecb9e5bc6a67fe697c6d249e0e7@openbios.org> Message-ID: <069.159306a9aeba08ec15da058b54a6f887@openbios.org> #9: Do not hardcode iasl path ------------------------+--------------------------------------------------- Reporter: uwe | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: | Keywords: Include_gantt: 1 | Dependencies: Due_assign: | Due_close: ------------------------+--------------------------------------------------- Changes (by uwe): * milestone: => Cosmetic fixes Old description: > The path to the 'iasl' compiler is currently hard-coded in the code. This > should be fixed. > > See also > http://www.linuxbios.org/pipermail/linuxbios/2006-September/015968.html New description: The path to the 'iasl' compiler is currently hard-coded in the code. This should be fixed. See also http://www.linuxbios.org/pipermail/linuxbios/2006-September/015968.html Signed-off-by: Uwe Hermann -- Ticket URL: LinuxBIOS From svn at openbios.org Thu Nov 2 15:27:53 2006 From: svn at openbios.org (LinuxBIOS) Date: Thu, 02 Nov 2006 14:27:53 -0000 Subject: [LinuxBIOS] #19: Remove useless #includes from mainboard.c files In-Reply-To: <060.90c6a1724c0dfb20c8eff5a14aefe6ab@openbios.org> References: <060.90c6a1724c0dfb20c8eff5a14aefe6ab@openbios.org> Message-ID: <069.0de88b961ed75d301f57ce028a76fbfa@openbios.org> #19: Remove useless #includes from mainboard.c files -----------------------------+---------------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: closed Priority: minor | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: fixed | Keywords: Include_gantt: 0 | Dependencies: Due_assign: DD/MM/YYYY | Due_close: DD/MM/YYYY -----------------------------+---------------------------------------------- Changes (by uwe): * milestone: => Cosmetic fixes -- Ticket URL: LinuxBIOS From svn at openbios.org Thu Nov 2 17:02:38 2006 From: svn at openbios.org (svn at openbios.org) Date: Thu, 02 Nov 2006 16:02:38 -0000 Subject: [LinuxBIOS] r2486 - in trunk/LinuxBIOSv2: src/mainboard src/mainboard/msi src/mainboard/msi/ms9185 src/southbridge/broadcom/bcm5785 targets targets/msi targets/msi/ms9185 Message-ID: Author: rminnich Date: 2006-11-02 17:02:33 +0100 (Thu, 02 Nov 2006) New Revision: 2486 Added: trunk/LinuxBIOSv2/src/mainboard/msi/ trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/ trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/Config.lb trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/Options.lb trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/cache_as_ram_auto.c trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/chip.h trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/cmos.layout trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/get_bus_conf.c trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/irq_tables.c trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/mainboard.c trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/mb_sysconf.h trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/mptable.c trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/resourcemap.c trunk/LinuxBIOSv2/targets/msi/ trunk/LinuxBIOSv2/targets/msi/ms9185/ trunk/LinuxBIOSv2/targets/msi/ms9185/Config.lb Modified: trunk/LinuxBIOSv2/src/southbridge/broadcom/bcm5785/bcm5785_sata.c Log: Sorry, this is the last commit I will do this way, but MSI has waited a long time and I could not get into the tracker. These are patches to enable ms9185 support. Abuild passes. Signed-off-by: bxshi Acked-by: Ronald G. Minnich Added: trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/Config.lb (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/Config.lb 2006-11-02 16:02:33 UTC (rev 2486) @@ -0,0 +1,299 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2006 AMD +## Written by Yinghai Lu for AMD. +## +## Copyright (C) 2006 MSI +## Written by bxshi for MSI. +## +## 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. +## +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 PAYLOAD_SIZE = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE ) +default CONFIG_ROM_STREAM_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) + +## +## Compute where this copy of linuxBIOS will start in the boot rom +## +default _ROMBASE = ( CONFIG_ROM_STREAM_START + PAYLOAD_SIZE ) + +## +## 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 ) + +arch i386 end + +## +## Build the objects we have code for in this directory. +## + +driver mainboard.o + +#dir /drivers/si/3114 + +#needed by irq_tables and mptable and acpi_tables +object get_bus_conf.o + +if HAVE_MP_TABLE + object mptable.o +end + +if HAVE_PIRQ_TABLE + object irq_tables.o +end + +if USE_DCACHE_RAM + + if CONFIG_USE_INIT + # compile cache_as_ram.c to auto.o + makerule ./cache_as_ram_auto.o + 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 -o $@" + end + + else + #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 +end +## +## Build our 16 bit and 32 bit linuxBIOS entry code +## + +if USE_FALLBACK_IMAGE + mainboardinit cpu/x86/16bit/entry16.inc + ldscript /cpu/x86/16bit/entry16.lds +end + +mainboardinit cpu/x86/32bit/entry32.inc +if USE_DCACHE_RAM + if CONFIG_USE_INIT + ldscript /cpu/x86/32bit/entry32.lds + end + + if CONFIG_USE_INIT + ldscript /cpu/amd/car/cache_as_ram.lds + end +end + +## +## 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 + +## +## Include an id string (For safe flashing) +## +mainboardinit arch/i386/lib/id.inc +ldscript /arch/i386/lib/id.lds + +if USE_DCACHE_RAM + ## + ## Setup Cache-As-Ram + ## + mainboardinit cpu/amd/car/cache_as_ram.inc +end + +### +### 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 + if USE_DCACHE_RAM + ldscript /arch/i386/lib/failover.lds + end +end + +### +### O.k. We aren't just an intermediary anymore! +### + +## +## Setup RAM +## +if USE_DCACHE_RAM + + if CONFIG_USE_INIT + initobject cache_as_ram_auto.o + else + mainboardinit ./cache_as_ram_auto.inc + end + +end + +## +## Include the secondary Configuration files +## +if CONFIG_CHIP_NAME + config chip.h +end + +# sample config for amd/serengeti_cheetah +chip northbridge/amd/amdk8/root_complex + device apic_cluster 0 on + chip cpu/amd/socket_F + device apic 0 on end + end + end + device pci_domain 0 on + chip northbridge/amd/amdk8 + device pci 18.0 on end + device pci 18.0 on end + device pci 18.0 on # northbridge + # devices on link 0 + chip southbridge/broadcom/bcm5780 # HT2000 + device pci 0.0 on end # PXB 1 0x0130 + device pci 1.0 on # PXB 2 0x0130 + device pci 4.0 on end # GB E 0x1668 vid = 0x14e4 + device pci 4.1 on end # GB E 0x1669 vid = 0x14e4 + end + device pci 2.0 on end # PCI E 1 #0x0132 + device pci 3.0 on end # PCI E 2 + device pci 4.0 on end # PCI E 3 + device pci 5.0 on end # PCI E 4 + end + chip southbridge/broadcom/bcm5785 # HT1000 + device pci 0.0 on # HT PXB 0x0036 + device pci d.0 on end # PPBX 0x0104 + device pci e.0 on end # SATA 0x024a + device pci e.1 on end # SATA 0x024a bx_a001 + device pci e.2 on end # SATA 0x024a bx_a001 + device pci e.3 on end # SATA 0x024a bx_a001 + end + device pci 1.0 on # Legacy pci main 0x0205 + end + device pci 1.1 on end # IDE 0x0214 + device pci 1.2 on # LPC 0x0234 + chip superio/nsc/pc87417 + device pnp 2e.0 off # Floppy + io 0x60 = 0x3f0 + irq 0x70 = 6 + drq 0x74 = 2 + end + device pnp 2e.1 off # Parallel Port + io 0x60 = 0x378 + irq 0x70 = 7 + end + device pnp 2e.2 off # Com 2 + io 0x60 = 0x2f8 + irq 0x70 = 3 + end + device pnp 2e.3 on # Com 1 + io 0x60 = 0x3f8 + irq 0x70 = 4 + end + device pnp 2e.4 off end # SWC + device pnp 2e.5 off end # Mouse + device pnp 2e.6 on # Keyboard + io 0x60 = 0x60 + io 0x62 = 0x64 + irq 0x70 = 1 + end + device pnp 2e.7 off end # GPIO + device pnp 2e.f off end # XBUS + device pnp 2e.10 on #RTC + io 0x60 = 0x70 + io 0x62 = 0x72 + end + end + end + device pci 1.3 on end # WDTimer 0x0238 + device pci 1.4 on end # XIOAPIC0 0x0235 + device pci 1.5 on end # XIOAPIC1 + device pci 1.6 on end # XIOAPIC2 + device pci 2.0 on end # USB 0x0223 + device pci 2.1 on end # USB + device pci 2.2 on end # USB + #when HT_CHAIN_END_UNITID_BASE (0,1) < HT_CHAIN_UNITID_BASE (6,,,,), + chip drivers/pci/onboard + device pci 3.0 on end # it is in bcm5785_0 bus, but the device id can not be changed even unitid is changed, fake one to get the rom_address + # if HT_CHAIN_END_UNITID_BASE=0, it is 4, if HT_CHAIN_END_UNITID_BASE=1, it is 3 + register "rom_address" = "0xfff80000" + end + #bx_a013+ start + #chip drivers/pci/onboard #SATA2 + # device pci 5.0 on end + # device pci 5.1 on end + # device pci 5.2 on end + # device pci 5.3 on end + #end + #bx_a013+ end + + end + #when HT_CHAIN_END_UNITID_BASE > HT_CHAIN_UNITID_BASE (6, ,,,,) +# chip drivers/pci/onboard +# device pci 0.0 on end # fake, will be disabled +# end +# chip drivers/pci/onboard +# device pci 4.0 on end # it is in bcm5785_0 bus, but the device id can not be changed even unitid is changed +# register "rom_address" = "0xfff80000" +# end + + end # device pci 18.0 + device pci 18.1 on end + device pci 18.2 on end + device pci 18.3 on end + end # amdk8 + end #pci_domain +# chip drivers/generic/debug +# device pnp 0.0 off end # chip name +# device pnp 0.1 on end # pci_regs_all +# device pnp 0.2 off end # mem +# device pnp 0.3 off end # cpuid +# device pnp 0.4 off end # smbus_regs_all +# device pnp 0.5 off end # dual core msr +# device pnp 0.6 off end # cache size +# device pnp 0.7 off end # tsc +# end + +end + + Added: trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/Options.lb (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/Options.lb 2006-11-02 16:02:33 UTC (rev 2486) @@ -0,0 +1,332 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2006 AMD +## Written by Yinghai Lu for AMD. +## +## Copyright (C) 2006 MSI +## Written by bxshi for MSI. +## +## 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 HAVE_ACPI_TABLES +uses ACPI_SSDTX_NUM +uses USE_FALLBACK_IMAGE +uses HAVE_FALLBACK_BOOT +uses HAVE_HARD_RESET +uses IRQ_SLOT_COUNT +uses HAVE_OPTION_TABLE +uses CONFIG_MAX_CPUS +uses CONFIG_MAX_PHYSICAL_CPUS +uses CONFIG_LOGICAL_CPUS +uses CONFIG_IOAPIC +uses CONFIG_SMP +uses FALLBACK_SIZE +uses ROM_SIZE +uses ROM_SECTION_SIZE +uses ROM_IMAGE_SIZE +uses ROM_SECTION_SIZE +uses ROM_SECTION_OFFSET +uses CONFIG_ROM_STREAM +uses CONFIG_ROM_STREAM_START +uses PAYLOAD_SIZE +uses _ROMBASE +uses XIP_ROM_SIZE +uses XIP_ROM_BASE +uses STACK_SIZE +uses HEAP_SIZE +uses USE_OPTION_TABLE +uses LB_CKS_RANGE_START +uses LB_CKS_RANGE_END +uses LB_CKS_LOC +uses MAINBOARD_PART_NUMBER +uses MAINBOARD_VENDOR +uses MAINBOARD +uses MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID +uses MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID +uses LINUXBIOS_EXTRA_VERSION +uses _RAMBASE +uses TTYS0_BAUD +uses TTYS0_BASE +uses TTYS0_LCS +uses DEFAULT_CONSOLE_LOGLEVEL +uses MAXIMUM_CONSOLE_LOGLEVEL +uses MAINBOARD_POWER_ON_AFTER_POWER_FAIL +uses CONFIG_CONSOLE_SERIAL8250 +uses HAVE_INIT_TIMER +uses CONFIG_GDB_STUB +uses CONFIG_GDB_STUB +uses CROSS_COMPILE +uses CC +uses HOSTCC +uses OBJCOPY +uses CONFIG_CHIP_NAME +uses CONFIG_CONSOLE_VGA +uses CONFIG_PCI_ROM_RUN +uses HW_MEM_HOLE_SIZEK +uses HW_MEM_HOLE_SIZE_AUTO_INC +uses K8_HT_FREQ_1G_SUPPORT + +uses HT_CHAIN_UNITID_BASE +uses HT_CHAIN_END_UNITID_BASE +uses SB_HT_CHAIN_ON_BUS0 +uses SB_HT_CHAIN_UNITID_OFFSET_ONLY + +uses USE_DCACHE_RAM +uses DCACHE_RAM_BASE +uses DCACHE_RAM_SIZE +uses DCACHE_RAM_GLOBAL_VAR_SIZE +uses CONFIG_USE_INIT + +uses SERIAL_CPU_INIT + +uses ENABLE_APIC_EXT_ID +uses APIC_ID_OFFSET +uses LIFT_BSP_APIC_ID + +uses CONFIG_PCI_64BIT_PREF_MEM + +uses CONFIG_LB_MEM_TOPK + + +### +### Build options +### + +## +## ROM_SIZE is the size of boot ROM that this board will use. +## +default ROM_SIZE=524288 + +## +## FALLBACK_SIZE is the amount of the ROM the complete fallback image will use +## +#default FALLBACK_SIZE=131072 +#256K +default FALLBACK_SIZE=0x40000 + +#more 1M for pgtbl +default CONFIG_LB_MEM_TOPK=2048 + +## +## Build code for the fallback boot +## +default HAVE_FALLBACK_BOOT=1 + +## +## Build code to reset the motherboard from linuxBIOS +## +default HAVE_HARD_RESET=1 + +## +## Build code to export a programmable irq routing table +## +default HAVE_PIRQ_TABLE=1 +default IRQ_SLOT_COUNT=11 + +## +## Build code to export an x86 MP table +## Useful for specifying IRQ routing values +## +default HAVE_MP_TABLE=1 + +## ACPI tables will be included +#default HAVE_ACPI_TABLES=1 +## extra SSDT num +#default ACPI_SSDTX_NUM=1 + +## +## Build code to export a CMOS option table +## +default HAVE_OPTION_TABLE=1 + +## +## Move the default LinuxBIOS cmos range off of AMD RTC registers +## +default LB_CKS_RANGE_START=49 +default LB_CKS_RANGE_END=122 +default LB_CKS_LOC=123 + +## +## Build code for SMP support +## Only worry about 2 micro processors +## +default CONFIG_SMP=1 +default CONFIG_MAX_CPUS=4 +default CONFIG_MAX_PHYSICAL_CPUS=2 +default CONFIG_LOGICAL_CPUS=1 + +default SERIAL_CPU_INIT=0 + +default ENABLE_APIC_EXT_ID=0 +default APIC_ID_OFFSET=0x8 +default LIFT_BSP_APIC_ID=1 + +#CHIP_NAME ? +default CONFIG_CHIP_NAME=1 + +#memory hole size, 0 mean disable, others will enable the hole, at that case if it is small than mmio_basek, it will use mmio_basek instead. +#2G +#default HW_MEM_HOLE_SIZEK=0x200000 +#1G +default HW_MEM_HOLE_SIZEK=0x100000 +#512M +#default HW_MEM_HOLE_SIZEK=0x80000 + +#make auto increase hole size to avoid hole_startk equal to basek so as to make some kernel happy +#default HW_MEM_HOLE_SIZE_AUTO_INC=1 + +#Opteron K8 1G HT Support +default K8_HT_FREQ_1G_SUPPORT=1 + +#VGA Console +default CONFIG_CONSOLE_VGA=1 +default CONFIG_PCI_ROM_RUN=1 + +#HT Unit ID offset, default is 1, the typical one +default HT_CHAIN_UNITID_BASE=0x06 + +#real SB Unit ID, default is 0x20, mean dont touch it at last +default HT_CHAIN_END_UNITID_BASE=0x01 + +#make the SB HT chain on bus 0, default is not (0) +default SB_HT_CHAIN_ON_BUS0=2 + +#only offset for SB chain?, default is yes(1) +#default SB_HT_CHAIN_UNITID_OFFSET_ONLY=0 + +#allow capable device use that above 4G +#default CONFIG_PCI_64BIT_PREF_MEM=1 + +## +## enable CACHE_AS_RAM specifics +## +default USE_DCACHE_RAM=1 +default DCACHE_RAM_BASE=0xcc000 +default DCACHE_RAM_SIZE=0x04000 +default DCACHE_RAM_GLOBAL_VAR_SIZE=0x01000 +default CONFIG_USE_INIT=0 + +## +## Build code to setup a generic IOAPIC +## +default CONFIG_IOAPIC=1 + +## +## Clean up the motherboard id strings +## +default MAINBOARD_PART_NUMBER="MS9185" +default MAINBOARD_VENDOR="MSI" +default MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID=0x1022 +default MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID=0x2b80 + +### +### LinuxBIOS layout values +### + +## ROM_IMAGE_SIZE is the amount of space to allow linuxBIOS to occupy. +default ROM_IMAGE_SIZE = 65536 + +## +## Use a small 8K stack +## +default STACK_SIZE=0x2000 + +## +## Use a small 32K heap +## +default HEAP_SIZE=0x8000 + +## +## Only use the option table in a normal image +## +default USE_OPTION_TABLE = !USE_FALLBACK_IMAGE + +## +## LinuxBIOS C code runs at this location in RAM +## +default _RAMBASE=0x00100000 + +## +## Load the payload from the ROM +## +default CONFIG_ROM_STREAM = 1 + +### +### Defaults of options that you may want to override in the target config file +### + +## +## The default compiler +## +default CC="$(CROSS_COMPILE)gcc -m32" +default HOSTCC="gcc" + +## +## Disable the gdb stub by default +## +default CONFIG_GDB_STUB=0 + +## +## 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 + +## +## Select power on after power fail setting +default MAINBOARD_POWER_ON_AFTER_POWER_FAIL="MAINBOARD_POWER_ON" + +### End Options.lb +end Added: trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/cache_as_ram_auto.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/cache_as_ram_auto.c (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/cache_as_ram_auto.c 2006-11-02 16:02:33 UTC (rev 2486) @@ -0,0 +1,375 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 Tyan + * Copyright (C) 2006 AMD + * Written by Yinghai Lu for Tyan and AMD. + * + * Copyright (C) 2006 MSI + * Written by bxshi for MSI. + * + * 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 +#define __ROMCC__ + +#define RAMINIT_SYSINFO 1 +#define CACHE_AS_RAM_ADDRESS_DEBUG 0 + +#define SET_NB_CFG_54 1 + +//used by raminit +#define QRANK_DIMM_SUPPORT 1 + +//used by incoherent_ht +//#define K8_SCAN_PCI_BUS 1 +//#define K8_ALLOCATE_IO_RANGE 1 + + +//used by init_cpus and fidvid +#define K8_SET_FIDVID 1 +//if we want to wait for core1 done before DQS training, set it to 0 +#define K8_SET_FIDVID_CORE0_ONLY 1 + +#define DEBUG_SMBUS 1 + +#include +#include +#include +#include +#include +#include +#include +#include "option_table.h" +#include "pc80/mc146818rtc_early.c" +#include "pc80/serial.c" +#include "arch/i386/lib/console.c" + +#if 0 +static void post_code(uint8_t value) { +#if 1 + int i; + for(i=0;i<0x80000;i++) { + outb(value, 0x80); + } +#endif +} +#endif + +#include +#include "southbridge/broadcom/bcm5785/bcm5785_early_smbus.c" +#include "northbridge/amd/amdk8/raminit.h" +#include "cpu/amd/model_fxx/apic_timer.c" +#include "lib/delay.c" + +#if CONFIG_USE_INIT == 0 + #include "lib/memcpy.c" +#endif + + +#include "cpu/x86/lapic/boot_cpu.c" +#include "northbridge/amd/amdk8/reset_test.c" +#include "northbridge/amd/amdk8/debug.c" +#include "superio/nsc/pc87417/pc87417_early_serial.c" +#include "cpu/amd/mtrr/amd_earlymtrr.c" +#include "cpu/x86/bist.h" + +#include "northbridge/amd/amdk8/setup_resource_map.c" + +#define SERIAL_DEV PNP_DEV(0x2e, PC87417_SP1) +#define RTC_DEV PNP_DEV(0x2e, PC87417_RTC) +#include "southbridge/broadcom/bcm5785/bcm5785_early_setup.c" +static void memreset_setup(void) +{ +} + +static void memreset(int controllers, const struct mem_controller *ctrl) +{ +} + +static inline void activate_spd_rom(const struct mem_controller *ctrl) +{ +#define SMBUS_SWITCH1 0x70 +#define SMBUS_SWITCH2 0x72 + unsigned device = (ctrl->channel0[0]) >> 8; + smbus_send_byte(SMBUS_SWITCH1, device & 0x0f); + smbus_send_byte(SMBUS_SWITCH2, (device >> 4) & 0x0f ); +} + +#if 0 +static inline void change_i2c_mux(unsigned device) +{ +#define SMBUS_SWITCH1 0x70 +#define SMBUS_SWITCH2 0x72 + smbus_send_byte(SMBUS_SWITCH1, device & 0x0f); + smbus_send_byte(SMBUS_SWITCH2, (device >> 4) & 0x0f ); +} +#endif + + + +static inline int spd_read_byte(unsigned device, unsigned address) +{ + return smbus_read_byte(device, address); +} + +#include "northbridge/amd/amdk8/amdk8_f.h" +#include "northbridge/amd/amdk8/coherent_ht.c" + +#include "northbridge/amd/amdk8/incoherent_ht.c" + +#include "northbridge/amd/amdk8/raminit_f.c" + +#include "sdram/generic_sdram.c" + + /* msi does not want the default */ +#include "resourcemap.c" + +#include "cpu/amd/dualcore/dualcore.c" + +#define RC0 (0x10<<8) +#define RC1 (0x01<<8) + +#define DIMM0 0x50 +#define DIMM1 0x51 +#define DIMM2 0x52 +#define DIMM3 0x53 +#define DIMM4 0x54 +#define DIMM5 0x55 +#define DIMM6 0x56 +#define DIMM7 0x57 + + +#include "cpu/amd/car/copy_and_run.c" +#include "cpu/amd/car/post_cache_as_ram.c" + +#include "cpu/amd/model_fxx/init_cpus.c" + +#include "cpu/amd/model_fxx/fidvid.c" + +#if USE_FALLBACK_IMAGE == 1 + +#include "northbridge/amd/amdk8/early_ht.c" + +void failover_process(unsigned long bist, unsigned long cpu_init_detectedx) +{ + + /* Is this a cpu only reset? Is this a secondary cpu? */ + if ((cpu_init_detectedx) || (!boot_cpu())) { + if (last_boot_normal()) { // RTC already inited + goto normal_image; + } else { + goto fallback_image; + } + } + /* Nothing special needs to be done to find bus 0 */ + /* Allow the HT devices to be found */ + + enumerate_ht_chain(); + + bcm5785_enable_rom(); + + bcm5785_enable_lpc(); + + //enable RTC + pc87417_enable_dev(RTC_DEV); + + /* Is this a deliberate reset by the bios */ +// post_code(0x22); + if (bios_reset_detected() && last_boot_normal()) { + goto normal_image; + } + /* This is the primary cpu how should I boot? */ + else if (do_normal_boot()) { + goto normal_image; + } + else { + goto fallback_image; + } + normal_image: +// post_code(0x23); + __asm__ volatile ("jmp __normal_image" + : /* outputs */ + : "a" (bist), "b" (cpu_init_detectedx) /* inputs */ + ); + + fallback_image: +// post_code(0x25); + ; + +} +#endif + +void real_main(unsigned long bist, unsigned long cpu_init_detectedx); + +void cache_as_ram_main(unsigned long bist, unsigned long cpu_init_detectedx) +{ + +#if USE_FALLBACK_IMAGE == 1 + failover_process(bist, cpu_init_detectedx); +#endif + real_main(bist, cpu_init_detectedx); + +} + +void real_main(unsigned long bist, unsigned long cpu_init_detectedx) +{ + static const uint16_t spd_addr[] = { + //first node + RC0|DIMM0, RC0|DIMM2, RC0|DIMM4, RC0|DIMM6, + RC0|DIMM1, RC0|DIMM3, RC0|DIMM5, RC0|DIMM7, +#if CONFIG_MAX_PHYSICAL_CPUS > 1 + //second node + RC1|DIMM0, RC1|DIMM2, RC1|DIMM4, RC1|DIMM6, + RC1|DIMM1, RC1|DIMM3, RC1|DIMM5, RC1|DIMM7, +#endif + + }; + + struct sys_info *sysinfo = (DCACHE_RAM_BASE + DCACHE_RAM_SIZE - DCACHE_RAM_GLOBAL_VAR_SIZE); + + int needs_reset; + unsigned bsp_apicid = 0; + + if (bist == 0) { + bsp_apicid = init_cpus(cpu_init_detectedx, sysinfo); + } + +// post_code(0x32); + + pc87417_enable_serial(SERIAL_DEV, TTYS0_BASE); + uart_init(); + console_init(); + +// dump_mem(DCACHE_RAM_BASE+DCACHE_RAM_SIZE-0x200, DCACHE_RAM_BASE+DCACHE_RAM_SIZE); + + /* Halt if there was a built in self test failure */ + report_bist_failure(bist); + + print_debug("*sysinfo range: ["); print_debug_hex32(sysinfo); print_debug(","); print_debug_hex32((unsigned long)sysinfo+sizeof(struct sys_info)); print_debug(")\r\n"); + + setup_ms9185_resource_map(); +#if 0 + dump_pci_device(PCI_DEV(0, 0x18, 0)); + dump_pci_device(PCI_DEV(0, 0x19, 0)); +#endif + + print_debug("bsp_apicid="); print_debug_hex8(bsp_apicid); print_debug("\r\n"); + + setup_coherent_ht_domain(); + + wait_all_core0_started(); +#if CONFIG_LOGICAL_CPUS==1 + // It is said that we should start core1 after all core0 launched + /* becase optimize_link_coherent_ht is moved out from setup_coherent_ht_domain, + * So here need to make sure last core0 is started, esp for two way system, + * (there may be apic id conflicts in that case) + */ + start_other_cores(); +//bx_a010- wait_all_other_cores_started(bsp_apicid); +#endif + + /* it will set up chains and store link pair for optimization later */ + ht_setup_chains_x(sysinfo); // it will init sblnk and sbbusn, nodes, sbdn + + bcm5785_early_setup(); + + +#if 0 + //it your CPU min fid is 1G, you can change HT to 1G and FID to max one time. + needs_reset = optimize_link_coherent_ht(); + needs_reset |= optimize_link_incoherent_ht(sysinfo); +#endif + +#if K8_SET_FIDVID == 1 + + { + msr_t msr; + msr=rdmsr(0xc0010042); + print_debug("begin msr fid, vid "); print_debug_hex32( msr.hi ); print_debug_hex32(msr.lo); print_debug("\r\n"); + + } + + enable_fid_change(); + + enable_fid_change_on_sb(sysinfo->sbbusn, sysinfo->sbdn); + + init_fidvid_bsp(bsp_apicid); + + // show final fid and vid + { + msr_t msr; + msr=rdmsr(0xc0010042); + print_debug("end msr fid, vid "); print_debug_hex32( msr.hi ); print_debug_hex32(msr.lo); print_debug("\r\n"); + + } +#endif + +#if 1 + needs_reset = optimize_link_coherent_ht(); + needs_reset |= optimize_link_incoherent_ht(sysinfo); + + // fidvid change will issue one LDTSTOP and the HT change will be effective too + if (needs_reset) { + print_info("ht reset -\r\n"); + soft_reset(); + } +#endif + allow_all_aps_stop(bsp_apicid); + + //It's the time to set ctrl in sysinfo now; + fill_mem_ctrl(sysinfo->nodes, sysinfo->ctrl, spd_addr); + + enable_smbus(); + +#if 0 + int i; + for(i=0;i<2;i++) { + activate_spd_rom(sysinfo->ctrl+i); + dump_smbus_registers(); + } +#endif + +#if 0 + int i; + for(i=1;i<256;i<<=1) { + change_i2c_mux(i); + dump_smbus_registers(); + } +#endif + + memreset_setup(); + + //do we need apci timer, tsc...., only debug need it for better output + /* all ap stopped? */ +// init_timer(); // Need to use TMICT to synconize FID/VID + + sdram_initialize(sysinfo->nodes, sysinfo->ctrl, sysinfo); + +#if 0 + print_pci_devices(); +#endif + +#if 0 +// dump_pci_devices(); + dump_pci_device_index_wait(PCI_DEV(0, 0x18, 2), 0x98); + dump_pci_device_index_wait(PCI_DEV(0, 0x19, 2), 0x98); +#endif + + post_cache_as_ram(); + + +} Added: trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/chip.h (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/chip.h 2006-11-02 16:02:33 UTC (rev 2486) @@ -0,0 +1,28 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 MSI + * Written by bxshi for MSI. + * + * 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_ms9185_ops; + +struct mainboard_msi_ms9185_config { +// int fixup_scsi; +// int fixup_vga; +}; + Added: trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/cmos.layout =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/cmos.layout (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/cmos.layout 2006-11-02 16:02:33 UTC (rev 2486) @@ -0,0 +1,98 @@ +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 +395 1 e 1 hw_scrubber +396 1 e 1 interleave_chip_selects +397 2 e 8 max_mem_clock +399 1 e 2 dual_core +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 +440 4 e 9 slow_cpu +444 1 e 1 nmi +445 1 e 1 iommu +728 256 h 0 user_data +984 16 h 0 check_sum +# Reserve the extended AMD configuration registers +1000 24 r 0 reserved_memory + + + +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 +8 0 400Mhz +8 1 333Mhz +8 2 266Mhz +8 3 200Mhz +9 0 off +9 1 87.5% +9 2 75.0% +9 3 62.5% +9 4 50.0% +9 5 37.5% +9 6 25.0% +9 7 12.5% + +checksums + +checksum 392 983 984 + + Added: trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/get_bus_conf.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/get_bus_conf.c (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/get_bus_conf.c 2006-11-02 16:02:33 UTC (rev 2486) @@ -0,0 +1,144 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 AMD + * Written by Yinghai Lu for AMD. + * + * Copyright (C) 2006 MSI + * Written by bxshi for MSI. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ +#include +#include +#include +#include +#include +#if CONFIG_LOGICAL_CPUS==1 +#include +#endif + +#include + +#include "mb_sysconf.h" + +// Global variables for MB layouts and these will be shared by irqtable mptable and acpi_tables +struct mb_sysconf_t mb_sysconf; + +static unsigned pci1234x[] = +{ //Here you only need to set value in pci1234 for HT-IO that could be installed or not + //You may need to preset pci1234 for HTIO board, please refer to src/northbridge/amd/amdk8/get_sblk_pci1234.c for detail + 0x0000ff0, + 0x0000ff0, +// 0x0000ff0, +// 0x0000ff0, +// 0x0000ff0, +// 0x0000ff0, +// 0x0000ff0, +// 0x0000ff0 +}; +static unsigned hcdnx[] = +{ //HT Chain device num, actually it is unit id base of every ht device in chain, assume every chain only have 4 ht device at most + 0x20202020, + 0x20202020, +// 0x20202020, +// 0x20202020, +// 0x20202020, +// 0x20202020, +// 0x20202020, +// 0x20202020, +}; + +extern void get_sblk_pci1234(void); + +static unsigned get_bus_conf_done = 0; + +void get_bus_conf(void) +{ + + unsigned apicid_base; + + device_t dev; + int i; + struct mb_sysconf_t *m; + + if(get_bus_conf_done==1) return; //do it only once + + get_bus_conf_done = 1; + + sysconf.mb = &mb_sysconf; + + m = sysconf.mb; + + sysconf.hc_possible_num = sizeof(pci1234x)/sizeof(pci1234x[0]); + + for(i=0;i> 8) & 0xff; + m->sbdn2 = sysconf.hcdn[0] & 0xff; // bcm5780 + + m->bus_bcm5785_0 = (sysconf.pci1234[0] >> 16) & 0xff; + m->bus_bcm5780[0] = m->bus_bcm5785_0; + + /* bcm5785 */ + dev = dev_find_slot(m->bus_bcm5785_0, PCI_DEVFN(sysconf.sbdn,0)); + if (dev) { + m->bus_bcm5785_1 = pci_read_config8(dev, PCI_SECONDARY_BUS); + dev = dev_find_slot(m->bus_bcm5785_1, PCI_DEVFN(0xd,0)); + if(dev) { + m->bus_bcm5785_1_1 = pci_read_config8(dev, PCI_SECONDARY_BUS); +#if HT_CHAIN_END_UNITID_BASE >= HT_CHAIN_UNITID_BASE + m->bus_isa = pci_read_config8(dev, PCI_SUBORDINATE_BUS); + m->bus_isa++; + printk_debug("bus_isa=%d\n",m->bus_isa); +#endif + } + } + else { + printk_debug("ERROR - could not find PCI %02x:%02x.0, using defaults\n", m->bus_bcm5785_0, sysconf.sbdn); + } + + /* bcm5780 */ + for(i = 1; i < 7; i++) { + dev = dev_find_slot(m->bus_bcm5780[0], PCI_DEVFN(m->sbdn2 + i - 1,0)); + if(dev) { + m->bus_bcm5780[i] = pci_read_config8(dev, PCI_SECONDARY_BUS); +#if HT_CHAIN_END_UNITID_BASE < HT_CHAIN_UNITID_BASE + m->bus_isa = pci_read_config8(dev, PCI_SUBORDINATE_BUS); + m->bus_isa++; + printk_debug("bus_isa=%d\n",m->bus_isa); +#endif + + } + else { + printk_debug("ERROR - could not find PCI %02x:%02x.0, using defaults\n", m->bus_bcm5780[0], m->sbdn2+i-1); + } + } + + +/*I/O APICs: APIC ID Version State Address*/ +#if CONFIG_LOGICAL_CPUS==1 + apicid_base = get_apicid_base(3); +#else + apicid_base = CONFIG_MAX_PHYSICAL_CPUS; +#endif + for(i=0;i<3;i++) + m->apicid_bcm5785[i] = apicid_base+i; +} Added: trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/irq_tables.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/irq_tables.c (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/irq_tables.c 2006-11-02 16:02:33 UTC (rev 2486) @@ -0,0 +1,126 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 AMD + * Written by Yinghai Lu for AMD. + * + * Copyright (C) 2006 MSI + * Written by bxshi for MSI. + * + * 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 + */ + +/* This file was generated by getpir.c, do not modify! + (but if you do, please run checkpir on it to verify) + Contains the IRQ Routing Table dumped directly from your memory , wich BIOS sets up + + Documentation at : http://www.microsoft.com/hwdev/busbios/PCIIRQ.HTM +*/ +#include +#include +#include +#include +#include +#include + +#include "mb_sysconf.h" + + +static void write_pirq_info(struct irq_info *pirq_info, uint8_t bus, uint8_t devfn, uint8_t link0, uint16_t bitmap0, + uint8_t link1, uint16_t bitmap1, uint8_t link2, uint16_t bitmap2,uint8_t link3, uint16_t bitmap3, + uint8_t slot, uint8_t rfu) +{ + pirq_info->bus = bus; + pirq_info->devfn = devfn; + + pirq_info->irq[0].link = link0; + pirq_info->irq[0].bitmap = bitmap0; + pirq_info->irq[1].link = link1; + pirq_info->irq[1].bitmap = bitmap1; + pirq_info->irq[2].link = link2; + pirq_info->irq[2].bitmap = bitmap2; + pirq_info->irq[3].link = link3; + pirq_info->irq[3].bitmap = bitmap3; + + pirq_info->slot = slot; + pirq_info->rfu = rfu; +} + +extern void get_bus_conf(void); + +unsigned long write_pirq_routing_table(unsigned long addr) +{ + + struct irq_routing_table *pirq; + struct irq_info *pirq_info; + unsigned slot_num; + uint8_t *v; + + uint8_t sum=0; + int i; + + struct mb_sysconf_t *m; + + get_bus_conf(); + + m = sysconf.mb; + + /* Align the table to be 16 byte aligned. */ + addr += 15; + addr &= ~15; + + /* This table must be betweeen 0xf0000 & 0x100000 */ + printk_info("Writing IRQ routing tables to 0x%x...", addr); + + pirq = (void *)(addr); + v = (uint8_t *)(addr); + + pirq->signature = PIRQ_SIGNATURE; + pirq->version = PIRQ_VERSION; + + pirq->rtr_bus = m->bus_bcm5785_0; + pirq->rtr_devfn = (sysconf.sbdn<<3)|0; + + pirq->exclusive_irqs = 0; + + pirq->rtr_vendor = 0x1166; + pirq->rtr_device = 0x0036; + + pirq->miniport_data = 0; + + memset(pirq->rfu, 0, sizeof(pirq->rfu)); + + pirq_info = (void *) ( &pirq->checksum + 1); + slot_num = 0; +//pci bridge + write_pirq_info(pirq_info, m->bus_bcm5785_0, (sysconf.sbdn<<3)|0, 0x1, 0xdef8, 0x2, 0xdef8, 0x3, 0xdef8, 0x4, 0xdef8, 0, 0); + pirq_info++; slot_num++; + + pirq->size = 32 + 16 * slot_num; + + for (i = 0; i < pirq->size; i++) + sum += v[i]; + + sum = pirq->checksum - sum; + + if (sum != pirq->checksum) { + pirq->checksum = sum; + } + + printk_info("done.\n"); + + return (unsigned long) pirq_info; + +} Added: trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/mainboard.c (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/mainboard.c 2006-11-02 16:02:33 UTC (rev 2486) @@ -0,0 +1,33 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 MSI + * Written by bxshi for MSI. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +#include +#include "chip.h" + +#if CONFIG_CHIP_NAME == 1 +struct chip_operations mainboard_msi_ms9185_ops = { + CHIP_NAME("MSI MS-9185 mainboard") +}; +#endif Added: trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/mb_sysconf.h =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/mb_sysconf.h (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/mb_sysconf.h 2006-11-02 16:02:33 UTC (rev 2486) @@ -0,0 +1,40 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 AMD + * Written by Yinghai Lu for AMD. + * + * Copyright (C) 2006 MSI + * Written by bxshi for MSI. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#ifndef MB_SYSCONF_H +#define MB_SYSCONF_H + +struct mb_sysconf_t { + unsigned char bus_isa; + unsigned char bus_bcm5780[7]; + unsigned char bus_bcm5785_0; + unsigned char bus_bcm5785_1; + unsigned char bus_bcm5785_1_1; + unsigned apicid_bcm5785[3]; + + unsigned sbdn2; +}; + +#endif + Added: trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/mptable.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/mptable.c (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/mptable.c 2006-11-02 16:02:33 UTC (rev 2486) @@ -0,0 +1,205 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2001 Eric W.Biederman + * + * Copyright (C) 2006 AMD + * Written by Yinghai Lu for AMD. + * + * Copyright (C) 2006 MSI + * Written by bxshi for MSI. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +#include +#include +#if CONFIG_LOGICAL_CPUS==1 +#include +#endif + +#include + +#include "mb_sysconf.h" + +extern void get_bus_conf(void); + +void *smp_write_config_table(void *v) +{ + static const char sig[4] = "PCMP"; + static const char oem[3] = "MSI"; + static const char productid[6] = "MS9185 "; + struct mp_config_table *mc; + + unsigned char bus_num; + int i; + struct mb_sysconf_t *m; + + mc = (void *)(((char *)v) + SMP_FLOATING_TABLE_LEN); + memset(mc, 0, sizeof(*mc)); + + memcpy(mc->mpc_signature, sig, sizeof(sig)); + mc->mpc_length = sizeof(*mc); /* initially just the header */ + mc->mpc_spec = 0x04; + mc->mpc_checksum = 0; /* not yet computed */ + memcpy(mc->mpc_oem, oem, sizeof(oem)); + memcpy(mc->mpc_productid, productid, sizeof(productid)); + mc->mpc_oemptr = 0; + mc->mpc_oemsize = 0; + mc->mpc_entry_count = 0; /* No entries yet... */ + mc->mpc_lapic = LAPIC_ADDR; + mc->mpe_length = 0; + mc->mpe_checksum = 0; + mc->reserved = 0; + + smp_write_processors(mc); + + get_bus_conf(); + m = sysconf.mb; + +/*Bus: Bus ID Type*/ + /* define bus and isa numbers */ + for(bus_num = 0; bus_num < m->bus_isa; bus_num++) { + smp_write_bus(mc, bus_num, "PCI "); + } + smp_write_bus(mc, m->bus_isa, "ISA "); + +/*I/O APICs: APIC ID Version State Address*/ + { + device_t dev = 0; + int i; + struct resource *res; + for(i=0; i<3; i++) { + dev = dev_find_device(0x1166, 0x0235, dev); + if (dev) { + res = find_resource(dev, PCI_BASE_ADDRESS_0); + if (res) { + smp_write_ioapic(mc, m->apicid_bcm5785[i], 0x11, res->base); + } + } + } + + } + +/*I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# */ + smp_write_intsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x0, m->apicid_bcm5785[0], 0x0); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x1, m->apicid_bcm5785[0], 0x1); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x0, m->apicid_bcm5785[0], 0x2); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x3, m->apicid_bcm5785[0], 0x3); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x4, m->apicid_bcm5785[0], 0x4); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x5, m->apicid_bcm5785[0], 0x5); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x6, m->apicid_bcm5785[0], 0x6); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x7, m->apicid_bcm5785[0], 0x7); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x8, m->apicid_bcm5785[0], 0x8); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x9, m->apicid_bcm5785[0], 0x9); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0xc, m->apicid_bcm5785[0], 0xc); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0xd, m->apicid_bcm5785[0], 0xd); + +//IDE + outb(0x02, 0xc00); outb(0x0e, 0xc01); + + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_bcm5785_0, ((1+sysconf.sbdn)<<2)|1, m->apicid_bcm5785[0], 0xe); // IDE + +//SATA + outb(0x07, 0xc00); outb(0x0f, 0xc01); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_bcm5785_1, (0x0e<<2)|0, m->apicid_bcm5785[0], 0xf); + +//USB + outb(0x01, 0xc00); outb(0x0a, 0xc01); + for(i=0;i<3;i++) { + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_bcm5785_0, ((2+sysconf.sbdn)<<2)|i, m->apicid_bcm5785[0], 0xa); // + } + + + + /* enable int */ + /* why here? must get the BAR and PCI command bit 1 set before enable it ....*/ + { + device_t dev; + dev = dev_find_device(0x1166, 0x0205, 0); + if(dev) { + uint32_t dword; + dword = pci_read_config32(dev, 0x6c); + dword |= (1<<4); // enable interrupts + pci_write_config32(dev, 0x6c, dword); + } + } + +//First pci-x slot (on bcm5785) under bus_bcm5785_1:d.0 + // AIC 8130 Galileo Technology... + for(i=0;i<4;i++) { + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_bcm5785_1_1, (6<<2)|i, m->apicid_bcm5785[1], 2 + (1+i)%4); // + } + + +//pci slot (on bcm5785) + for(i=0;i<4;i++) { + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_bcm5785_0, (5<<2)|i, m->apicid_bcm5785[1], 8+i%4); // + } + + +//onboard ati + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_bcm5785_0, (4<<2)|0, m->apicid_bcm5785[1], 0x1); + +//PCI-X on bcm5780 + for(i=0;i<4;i++) { + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_bcm5780[1], (4<<2)|i, m->apicid_bcm5785[1], 2 + (0+i)%4); // + } + +//onboard Broadcom + for(i=0;i<2;i++) { + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_bcm5780[2], (4<<2)|i, m->apicid_bcm5785[1], 0xa + (0+i)%4); // + } + + +// First PCI-E x8 + for(i=0;i<4;i++) { + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_bcm5780[5], (0<<2)|i, m->apicid_bcm5785[1], 0xe); // + } + + +// Second PCI-E x8 + for(i=0;i<4;i++) { + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_bcm5780[3], (0<<2)|i, m->apicid_bcm5785[1], 0xc); // + } + +// Third PCI-E x1 + for(i=0;i<4;i++) { + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, m->bus_bcm5780[4], (0<<2)|i, m->apicid_bcm5785[1], 0xd); // + } + +/*Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN#*/ + smp_write_intsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x0, MP_APIC_ALL, 0x0); + smp_write_intsrc(mc, mp_NMI, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, m->bus_isa, 0x0, MP_APIC_ALL, 0x1); + /* There is no extension information... */ + + /* Compute the checksums */ + mc->mpe_checksum = smp_compute_checksum(smp_next_mpc_entry(mc), mc->mpe_length); + mc->mpc_checksum = smp_compute_checksum(mc, mc->mpc_length); + printk_debug("Wrote the mp table end at: %p - %p\n", + mc, smp_next_mpe_entry(mc)); + return smp_next_mpe_entry(mc); +} + +unsigned long write_smp_table(unsigned long addr) +{ + void *v; + v = smp_write_floating_table(addr); + return (unsigned long)smp_write_config_table(v); +} Added: trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/resourcemap.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/resourcemap.c (rev 0) +++ trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/resourcemap.c 2006-11-02 16:02:33 UTC (rev 2486) @@ -0,0 +1,291 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2003 Stefan Reinauer + * + * Copyright (C) 2006 AMD + * Written by Yinghai Lu for AMD. + * + * Copyright (C) 2006 MSI + * Written by bxshi for MSI. + * + * 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 + */ + +/* + * ms9185 needs a different resource map + * + */ + +static void setup_ms9185_resource_map(void) +{ + static const unsigned int register_values[] = { + /* Careful set limit registers before base registers which contain the enables */ + /* DRAM Limit i Registers + * F1:0x44 i = 0 + * F1:0x4C i = 1 + * F1:0x54 i = 2 + * F1:0x5C i = 3 + * F1:0x64 i = 4 + * F1:0x6C i = 5 + * F1:0x74 i = 6 + * F1:0x7C i = 7 + * [ 2: 0] Destination Node ID + * 000 = Node 0 + * 001 = Node 1 + * 010 = Node 2 + * 011 = Node 3 + * 100 = Node 4 + * 101 = Node 5 + * 110 = Node 6 + * 111 = Node 7 + * [ 7: 3] Reserved + * [10: 8] Interleave select + * specifies the values of A[14:12] to use with interleave enable. + * [15:11] Reserved + * [31:16] DRAM Limit Address i Bits 39-24 + * This field defines the upper address bits of a 40 bit address + * that define the end of the DRAM region. + */ + PCI_ADDR(0, 0x18, 1, 0x44), 0x0000f8f8, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x4C), 0x0000f8f8, 0x00000001, + PCI_ADDR(0, 0x18, 1, 0x54), 0x0000f8f8, 0x00000002, + PCI_ADDR(0, 0x18, 1, 0x5C), 0x0000f8f8, 0x00000003, + PCI_ADDR(0, 0x18, 1, 0x64), 0x0000f8f8, 0x00000004, + PCI_ADDR(0, 0x18, 1, 0x6C), 0x0000f8f8, 0x00000005, + PCI_ADDR(0, 0x18, 1, 0x74), 0x0000f8f8, 0x00000006, + PCI_ADDR(0, 0x18, 1, 0x7C), 0x0000f8f8, 0x00000007, + /* DRAM Base i Registers + * F1:0x40 i = 0 + * F1:0x48 i = 1 + * F1:0x50 i = 2 + * F1:0x58 i = 3 + * F1:0x60 i = 4 + * F1:0x68 i = 5 + * F1:0x70 i = 6 + * F1:0x78 i = 7 + * [ 0: 0] Read Enable + * 0 = Reads Disabled + * 1 = Reads Enabled + * [ 1: 1] Write Enable + * 0 = Writes Disabled + * 1 = Writes Enabled + * [ 7: 2] Reserved + * [10: 8] Interleave Enable + * 000 = No interleave + * 001 = Interleave on A[12] (2 nodes) + * 010 = reserved + * 011 = Interleave on A[12] and A[14] (4 nodes) + * 100 = reserved + * 101 = reserved + * 110 = reserved + * 111 = Interleve on A[12] and A[13] and A[14] (8 nodes) + * [15:11] Reserved + * [13:16] DRAM Base Address i Bits 39-24 + * This field defines the upper address bits of a 40-bit address + * that define the start of the DRAM region. + */ + PCI_ADDR(0, 0x18, 1, 0x40), 0x0000f8fc, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x48), 0x0000f8fc, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x50), 0x0000f8fc, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x58), 0x0000f8fc, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x60), 0x0000f8fc, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x68), 0x0000f8fc, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x70), 0x0000f8fc, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x78), 0x0000f8fc, 0x00000000, + + /* Memory-Mapped I/O Limit i Registers + * F1:0x84 i = 0 + * F1:0x8C i = 1 + * F1:0x94 i = 2 + * F1:0x9C i = 3 + * F1:0xA4 i = 4 + * F1:0xAC i = 5 + * F1:0xB4 i = 6 + * F1:0xBC i = 7 + * [ 2: 0] Destination Node ID + * 000 = Node 0 + * 001 = Node 1 + * 010 = Node 2 + * 011 = Node 3 + * 100 = Node 4 + * 101 = Node 5 + * 110 = Node 6 + * 111 = Node 7 + * [ 3: 3] Reserved + * [ 5: 4] Destination Link ID + * 00 = Link 0 + * 01 = Link 1 + * 10 = Link 2 + * 11 = Reserved + * [ 6: 6] Reserved + * [ 7: 7] Non-Posted + * 0 = CPU writes may be posted + * 1 = CPU writes must be non-posted + * [31: 8] Memory-Mapped I/O Limit Address i (39-16) + * This field defines the upp adddress bits of a 40-bit address that + * defines the end of a memory-mapped I/O region n + */ + PCI_ADDR(0, 0x18, 1, 0x84), 0x00000048, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x8C), 0x00000048, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x94), 0x00000048, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x9C), 0x00000048, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xA4), 0x00000048, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xAC), 0x00000048, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xB4), 0x00000048, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xBC), 0x00000048, 0x00ffff20, + + /* Memory-Mapped I/O Base i Registers + * F1:0x80 i = 0 + * F1:0x88 i = 1 + * F1:0x90 i = 2 + * F1:0x98 i = 3 + * F1:0xA0 i = 4 + * F1:0xA8 i = 5 + * F1:0xB0 i = 6 + * F1:0xB8 i = 7 + * [ 0: 0] Read Enable + * 0 = Reads disabled + * 1 = Reads Enabled + * [ 1: 1] Write Enable + * 0 = Writes disabled + * 1 = Writes Enabled + * [ 2: 2] Cpu Disable + * 0 = Cpu can use this I/O range + * 1 = Cpu requests do not use this I/O range + * [ 3: 3] Lock + * 0 = base/limit registers i are read/write + * 1 = base/limit registers i are read-only + * [ 7: 4] Reserved + * [31: 8] Memory-Mapped I/O Base Address i (39-16) + * This field defines the upper address bits of a 40bit address + * that defines the start of memory-mapped I/O region i + */ + PCI_ADDR(0, 0x18, 1, 0x80), 0x000000f0, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x88), 0x000000f0, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x90), 0x000000f0, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0x98), 0x000000f0, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xA0), 0x000000f0, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xA8), 0x000000f0, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xB0), 0x000000f0, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xB8), 0x000000f0, 0x00fc0003, + + /* PCI I/O Limit i Registers + * F1:0xC4 i = 0 + * F1:0xCC i = 1 + * F1:0xD4 i = 2 + * F1:0xDC i = 3 + * [ 2: 0] Destination Node ID + * 000 = Node 0 + * 001 = Node 1 + * 010 = Node 2 + * 011 = Node 3 + * 100 = Node 4 + * 101 = Node 5 + * 110 = Node 6 + * 111 = Node 7 + * [ 3: 3] Reserved + * [ 5: 4] Destination Link ID + * 00 = Link 0 + * 01 = Link 1 + * 10 = Link 2 + * 11 = reserved + * [11: 6] Reserved + * [24:12] PCI I/O Limit Address i + * This field defines the end of PCI I/O region n + * [31:25] Reserved + */ + PCI_ADDR(0, 0x18, 1, 0xC4), 0xFE000FC8, 0x01fff020, + PCI_ADDR(0, 0x18, 1, 0xCC), 0xFE000FC8, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xD4), 0xFE000FC8, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xDC), 0xFE000FC8, 0x00000000, + + /* PCI I/O Base i Registers + * F1:0xC0 i = 0 + * F1:0xC8 i = 1 + * F1:0xD0 i = 2 + * F1:0xD8 i = 3 + * [ 0: 0] Read Enable + * 0 = Reads Disabled + * 1 = Reads Enabled + * [ 1: 1] Write Enable + * 0 = Writes Disabled + * 1 = Writes Enabled + * [ 3: 2] Reserved + * [ 4: 4] VGA Enable + * 0 = VGA matches Disabled + * 1 = matches all address < 64K and where A[9:0] is in the + * range 3B0-3BB or 3C0-3DF independen of the base & limit registers + * [ 5: 5] ISA Enable + * 0 = ISA matches Disabled + * 1 = Blocks address < 64K and in the last 768 bytes of eack 1K block + * from matching agains this base/limit pair + * [11: 6] Reserved + * [24:12] PCI I/O Base i + * This field defines the start of PCI I/O region n + * [31:25] Reserved + */ + PCI_ADDR(0, 0x18, 1, 0xC0), 0xFE000FCC, 0x00000003, + PCI_ADDR(0, 0x18, 1, 0xC8), 0xFE000FCC, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xD0), 0xFE000FCC, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xD8), 0xFE000FCC, 0x00000000, + + /* Config Base and Limit i Registers + * F1:0xE0 i = 0 + * F1:0xE4 i = 1 + * F1:0xE8 i = 2 + * F1:0xEC i = 3 + * [ 0: 0] Read Enable + * 0 = Reads Disabled + * 1 = Reads Enabled + * [ 1: 1] Write Enable + * 0 = Writes Disabled + * 1 = Writes Enabled + * [ 2: 2] Device Number Compare Enable + * 0 = The ranges are based on bus number + * 1 = The ranges are ranges of devices on bus 0 + * [ 3: 3] Reserved + * [ 6: 4] Destination Node + * 000 = Node 0 + * 001 = Node 1 + * 010 = Node 2 + * 011 = Node 3 + * 100 = Node 4 + * 101 = Node 5 + * 110 = Node 6 + * 111 = Node 7 + * [ 7: 7] Reserved + * [ 9: 8] Destination Link + * 00 = Link 0 + * 01 = Link 1 + * 10 = Link 2 + * 11 - Reserved + * [15:10] Reserved + * [23:16] Bus Number Base i + * This field defines the lowest bus number in configuration region i + * [31:24] Bus Number Limit i + * This field defines the highest bus number in configuration regin i + */ + PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0xff000203, + PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xE8), 0x0000FC88, 0x00000000, + PCI_ADDR(0, 0x18, 1, 0xEC), 0x0000FC88, 0x00000000, + }; + + int max; + max = sizeof(register_values)/sizeof(register_values[0]); + setup_resource_map(register_values, max); +} + Modified: trunk/LinuxBIOSv2/src/southbridge/broadcom/bcm5785/bcm5785_sata.c =================================================================== --- trunk/LinuxBIOSv2/src/southbridge/broadcom/bcm5785/bcm5785_sata.c 2006-11-02 14:11:34 UTC (rev 2485) +++ trunk/LinuxBIOSv2/src/southbridge/broadcom/bcm5785/bcm5785_sata.c 2006-11-02 16:02:33 UTC (rev 2486) @@ -21,6 +21,8 @@ uint8_t *base; uint8_t *mmio; struct resource *res; + unsigned int mmio_base; + volatile unsigned int *mmio_reg; int i; if(!(dev->path.u.pci.devfn & 7)) { // only set it in Func0 @@ -30,6 +32,21 @@ res = find_resource(dev, 0x24); base = res->base; + + mmio_base = base; + mmio_base &= 0xfffffffc; + mmio_reg = (unsigned int *)( mmio_base + 0x10f0 ); + * mmio_reg = 0x40000001; + mmio_reg = ( unsigned int *)( mmio_base + 0x8c ); + * mmio_reg = 0x00ff2007; + mdelay( 10 ); + * mmio_reg = 0x78592009; + mdelay( 10 ); + * mmio_reg = 0x00082004; + mdelay( 10 ); + * mmio_reg = 0x00002004; + mdelay( 10 ); + //init PHY printk_debug("init PHY...\n"); Added: trunk/LinuxBIOSv2/targets/msi/ms9185/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/msi/ms9185/Config.lb (rev 0) +++ trunk/LinuxBIOSv2/targets/msi/ms9185/Config.lb 2006-11-02 16:02:33 UTC (rev 2486) @@ -0,0 +1,94 @@ +## +## This file is part of the LinuxBIOS project. +## +## Copyright (C) 2006 MSI +## Written by bxshi for MSI. +## +## 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 +## + +# Sample config file for +# the msi ms9185 +# This will make a target directory of ./ms9185 + +target ms9185 +mainboard msi/ms9185 + +# ms9185 +romimage "normal" +# 36k for ATI option rom + option ROM_SIZE = 512*1024-36*1024 +# option ROM_SIZE = 524288 +# option ROM_SIZE = 425984 +# 64K for Etherboot +# option ROM_SIZE = 458752 + 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 /filo.elf + payload /tg3--filo.elf +# payload ../../../../payloads/e1000_vga.zelf +# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.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 + +romimage "fallback" + 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/filo_hda.zelf +# payload ../../../../payloads/tg3--filo_hda2_vga.zelf +# payload /filo.elf + payload /tg3--filo.elf +# payload ../../../../payloads/tg3--filo_hda2_vga_5_4.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 + +buildrom ./ms9185.lxb ROM_SIZE "normal" "fallback" From svn at openbios.org Thu Nov 2 17:17:02 2006 From: svn at openbios.org (LinuxBIOS) Date: Thu, 02 Nov 2006 16:17:02 -0000 Subject: [LinuxBIOS] #21: Library to unpack, repack, change and use DTB structures In-Reply-To: <060.c14d79488a05b319bcf4c8496151ef66@openbios.org> References: <060.c14d79488a05b319bcf4c8496151ef66@openbios.org> Message-ID: <069.87d1953bb472bdf174827d5d6b3c0766@openbios.org> #21: Library to unpack, repack, change and use DTB structures ----------------------------+----------------------------------------------- Reporter: stepan | Owner: segher Type: task | Status: new Priority: blocker | Milestone: Setting up LinuxBIOS v3 Component: code | Version: v3 Resolution: | Keywords: device tree Include_gantt: 1 | Dependencies: Due_assign: 11/02/2006 | Due_close: 11/09/2006 ----------------------------+----------------------------------------------- Changes (by stepan): * due_assign: 02/11/2006 => 11/02/2006 * due_close: 09/11/2006 => 11/09/2006 -- Ticket URL: LinuxBIOS From yinghailu at gmail.com Thu Nov 2 17:23:49 2006 From: yinghailu at gmail.com (yhlu) Date: Thu, 2 Nov 2006 08:23:49 -0800 Subject: [LinuxBIOS] USB Bootloader In-Reply-To: References: Message-ID: <2ea3fae10611020823q37b08801t9f774a95dec85821@mail.gmail.com> 1. gcc version? you may try 4.0.2 2. UHCI? I didn't test that much. 3. don't not enable too much debug... YH On 11/2/06, jean raymond wrote: > I have this config for FILO: > > #define AUTOBOOT_FILE "uda1:/bzImage root=/dev/sda2 console=tty0 > console=ttyS0,115200" > #define AUTOBOOT_DELAY 20 > #define IDE_DISK 1 > #define USB_DISK 1 > #define FSYS_EXT2FS 1 > #define FSYS_FAT 1 > #define ELTORITO 1 > #define SUPPORT_PCI 1 > #define DEBUG_ALL 1 > #define DEBUG_LINUXBIOS 1 > #define DEBUG_PCI 1 > #define DEBUG_USB 1 > #define LINUX_LOADER 1 > #define PCI_CONFIG_1 1 > > > > > >From: Stefan Reinauer > >To: jean raymond > >CC: linuxbios at linuxbios.org > >Subject: Re: [LinuxBIOS] USB Bootloader > >Date: Thu, 2 Nov 2006 13:12:13 +0100 > > > >* jean raymond [061102 12:39]: > > > I'm using Etherboot version 5.4.2 from etherboot.org. > > > I'm using LinuxBIOS version2-2394 and a i386 board. > > > >which one? > > > > > I suppose I have a bad config. So can you give me a config an example of > > > config in order to boot on USB. > > > >It might just be a missing bit in the USB configuration of the board you > >are using. > > > > > Thanks for your help! > > > >you're welcome. > > > >-- > >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/ > > > >-- > >linuxbios mailing list > >linuxbios at linuxbios.org > >http://www.openbios.org/mailman/listinfo/linuxbios > > _________________________________________________________________ > Don't just search. Find. Check out the new MSN Search! > http://search.msn.com/ > > > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > > From uwe at hermann-uwe.de Thu Nov 2 22:36:34 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 2 Nov 2006 22:36:34 +0100 Subject: [LinuxBIOS] Fix to vga emulator (from MSI) In-Reply-To: <13426df10610270813jfd34b75g2cdeca8bd176745b@mail.gmail.com> References: <13426df10610270813jfd34b75g2cdeca8bd176745b@mail.gmail.com> Message-ID: <20061102213633.GD21637@greenwood> On Fri, Oct 27, 2006 at 09:13:04AM -0600, ron minnich wrote: > This change fixes a long-standing bug, whereby we do not set ret for an > un-inited vector, which we should have done. > Signed-off-by: Ronald G. Minnich > > --- > > Index: devices/emulator/biosemu.c > =================================================================== > --- devices/emulator/biosemu.c (revision 2470) > +++ devices/emulator/biosemu.c (working copy) > @@ -122,6 +122,7 @@ > case 0x6D: > if (getIntVect(num) == 0x0000) { > printk_debug("un-inited int vector\n"); > + ret = 1; > } > if (getIntVect(num) == 0xFF065) { > //ret = int42_handler(); I think this is fixed and obsolete now since the MSI patch got committed, right? Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From stepan at coresystems.de Thu Nov 2 23:02:41 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 2 Nov 2006 23:02:41 +0100 Subject: [LinuxBIOS] Fix to vga emulator (from MSI) In-Reply-To: <20061102213633.GD21637@greenwood> References: <13426df10610270813jfd34b75g2cdeca8bd176745b@mail.gmail.com> <20061102213633.GD21637@greenwood> Message-ID: <20061102220241.GA8007@coresystems.de> * Uwe Hermann [061102 22:36]: > On Fri, Oct 27, 2006 at 09:13:04AM -0600, ron minnich wrote: > > This change fixes a long-standing bug, whereby we do not set ret for an > > un-inited vector, which we should have done. > > Signed-off-by: Ronald G. Minnich > > I think this is fixed and obsolete now since the MSI patch got > committed, right? This got committed ad 2479. http://snapshots.linuxbios.org/stats/commit-LinuxBIOSv2-2479.log -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From svn at openbios.org Fri Nov 3 10:22:31 2006 From: svn at openbios.org (LinuxBIOS) Date: Fri, 03 Nov 2006 09:22:31 -0000 Subject: [LinuxBIOS] #14: Rename "stream" to "payload" In-Reply-To: <060.7ce253b9ecf6e23e1d409c7624ff96d8@openbios.org> References: <060.7ce253b9ecf6e23e1d409c7624ff96d8@openbios.org> Message-ID: <069.3d0cee971710e8758f060b683a26768d@openbios.org> #14: Rename "stream" to "payload" -----------------------------+---------------------------------------------- Reporter: uwe | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: #22 Due_assign: DD/MM/YYYY | Due_close: DD/MM/YYYY -----------------------------+---------------------------------------------- Changes (by uwe): * dependencies: => #22 -- Ticket URL: LinuxBIOS From svn at openbios.org Fri Nov 3 10:23:56 2006 From: svn at openbios.org (LinuxBIOS) Date: Fri, 03 Nov 2006 09:23:56 -0000 Subject: [LinuxBIOS] #22: sed error in abuild In-Reply-To: <060.5c46f9c57a78cecc432ab4e830a2d4dc@openbios.org> References: <060.5c46f9c57a78cecc432ab4e830a2d4dc@openbios.org> Message-ID: <069.263c3dd36994bf7e83b6b00a41bb2bfc@openbios.org> #22: sed error in abuild ----------------------------+----------------------------------------------- Reporter: uwe | Owner: uwe Type: defect | Status: assigned Priority: critical | Milestone: Component: testsystem | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY ----------------------------+----------------------------------------------- Changes (by uwe): * owner: somebody => uwe * status: new => assigned * reporter: anonymous => uwe -- Ticket URL: LinuxBIOS From svn at openbios.org Fri Nov 3 11:28:45 2006 From: svn at openbios.org (LinuxBIOS) Date: Fri, 03 Nov 2006 10:28:45 -0000 Subject: [LinuxBIOS] #23: Use Doxygen-style comments In-Reply-To: <060.8e8e2ae35130c112bdec739d2a3a7598@openbios.org> References: <060.8e8e2ae35130c112bdec739d2a3a7598@openbios.org> Message-ID: <069.1920d186a8c1ca5c687cd11a65287af0@openbios.org> #23: Use Doxygen-style comments -----------------------------+---------------------------------------------- Reporter: uwe | Owner: somebody Type: enhancement | Status: new Priority: minor | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY -----------------------------+---------------------------------------------- Comment (by stepan): > We should probably use Doxygen-style comments to document (at least) the core API/code of LinuxBIOS. This documentation is automatically available at: http://qa.linuxbios.org/docs/doxygen.php It does not cover the romcc compiled parts though. Should we bother? -- Ticket URL: LinuxBIOS From svn at openbios.org Fri Nov 3 12:14:14 2006 From: svn at openbios.org (LinuxBIOS) Date: Fri, 03 Nov 2006 11:14:14 -0000 Subject: [LinuxBIOS] #23: Use Doxygen-style comments In-Reply-To: <060.8e8e2ae35130c112bdec739d2a3a7598@openbios.org> References: <060.8e8e2ae35130c112bdec739d2a3a7598@openbios.org> Message-ID: <069.4e2410bfcec39845fad0470dd47f2830@openbios.org> #23: Use Doxygen-style comments -----------------------------+---------------------------------------------- Reporter: uwe | Owner: somebody Type: enhancement | Status: new Priority: minor | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY -----------------------------+---------------------------------------------- Comment (by uwe): Replying to [comment:1 stepan]: > > We should probably use Doxygen-style comments to document (at least) the core API/code of LinuxBIOS. > > This documentation is automatically available at: > > http://qa.linuxbios.org/docs/doxygen.php > > It does not cover the romcc compiled parts though. Should we bother? No, probably not. But I was referring to actually documenting the code. I know that the doxygen output is already available, but as there's very few comments (and none which have doxygen-syntax) the doxygen output is only of limited use. -- Ticket URL: LinuxBIOS From svn at openbios.org Fri Nov 3 16:01:40 2006 From: svn at openbios.org (LinuxBIOS) Date: Fri, 03 Nov 2006 15:01:40 -0000 Subject: [LinuxBIOS] #21: Library to unpack, repack, change and use DTB structures In-Reply-To: <060.c14d79488a05b319bcf4c8496151ef66@openbios.org> References: <060.c14d79488a05b319bcf4c8496151ef66@openbios.org> Message-ID: <069.a940e919ee4361c5e1be165a8f6258eb@openbios.org> #21: Library to unpack, repack, change and use DTB structures ----------------------------+----------------------------------------------- Reporter: stepan | Owner: segher Type: task | Status: assigned Priority: blocker | Milestone: Setting up LinuxBIOS v3 Component: code | Version: v3 Resolution: | Keywords: device tree Include_gantt: 1 | Dependencies: Due_assign: 11/02/2006 | Due_close: 11/09/2006 ----------------------------+----------------------------------------------- Changes (by segher): * status: new => assigned Comment: Replying to [comment:1 stepan]: How about you change the trac settings so it displays dates in a readable format instead? Month as alpha might be best for everyone? Oh, and ticket accepted, let's see if I can get a grasp on trac :-) -- Ticket URL: LinuxBIOS From myles at pel.cs.byu.edu Fri Nov 3 20:02:12 2006 From: myles at pel.cs.byu.edu (Myles Watson) Date: Fri, 03 Nov 2006 12:02:12 -0700 Subject: [LinuxBIOS] Disabled device help Message-ID: <01M94I3BYZRM8YJ57I@EMAIL1.BYU.EDU> My large device gets disabled somewhere in LinuxBIOS or the kernel. This is the encouraging line from LinuxBIOS telling me that the registers are indeed set correctly. PCI: 05:01.0 18 <- [8000000000 - bfffffffff] prefmem64 Unfortunately, Linux sees something different and fails to allocate this region because it sees it at 00000080-000000bf and that conflicts with other things. Does anyone have a pointer to where I should look for this problem? Has anyone else had problems with devices larger than 4GB? Thanks, Myles From rminnich at gmail.com Fri Nov 3 20:19:53 2006 From: rminnich at gmail.com (ron minnich) Date: Fri, 3 Nov 2006 12:19:53 -0700 Subject: [LinuxBIOS] Disabled device help In-Reply-To: <01M94I3BYZRM8YJ57I@EMAIL1.BYU.EDU> References: <01M94I3BYZRM8YJ57I@EMAIL1.BYU.EDU> Message-ID: <13426df10611031119u36ae0376s16868f55fbbbe77d@mail.gmail.com> On 11/3/06, Myles Watson wrote: > > My large device gets disabled somewhere in LinuxBIOS or the kernel. This > is > the encouraging line from LinuxBIOS telling me that the registers are > indeed > set correctly. > > PCI: 05:01.0 18 <- [8000000000 - bfffffffff] prefmem64 > > Unfortunately, Linux sees something different and fails to allocate this > region because it sees it at 00000080-000000bf and that conflicts with > other > things. > > Does anyone have a pointer to where I should look for this problem? Has > anyone else had problems with devices larger than 4GB? you may be the first lucky person to do this. I assume this is an opteron in 64-bit mode? ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinghai.lu at amd.com Fri Nov 3 20:45:55 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 3 Nov 2006 11:45:55 -0800 Subject: [LinuxBIOS] Disabled device help Message-ID: <5986589C150B2F49A46483AC44C7BCA412D7D1@ssvlexmb2.amd.com> Boot log? In LinuxBIOS, there is CONFIG_PCI_64BIT_PREF_MEM, did you try to enable it in you MB Options.lb In the kernel, there is pci_assign_unassigned_resources that try to allocate resource for some devices, and it could cause problem because Opteron could bave multi ht chain, Aka peer root bus, and every root bus need to have its own ioport_resource, and iomem_resource. But that only happen when BIOS is not allocating resource correctly. And LinuxBIOS does a good job, and every device have be handled properly. In case, you have werid pci devices, you still can use pci_quirks in kernel to do some fix up. YH -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Myles Watson Sent: Friday, November 03, 2006 11:02 AM To: 'LinuxBIOS' Subject: [LinuxBIOS] Disabled device help My large device gets disabled somewhere in LinuxBIOS or the kernel. This is the encouraging line from LinuxBIOS telling me that the registers are indeed set correctly. PCI: 05:01.0 18 <- [8000000000 - bfffffffff] prefmem64 Unfortunately, Linux sees something different and fails to allocate this region because it sees it at 00000080-000000bf and that conflicts with other things. Does anyone have a pointer to where I should look for this problem? Has anyone else had problems with devices larger than 4GB? Thanks, Myles -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios From ewaguespack at gmail.com Fri Nov 3 21:25:57 2006 From: ewaguespack at gmail.com (Eric Waguespack) Date: Fri, 3 Nov 2006 14:25:57 -0600 Subject: [LinuxBIOS] well supported current cheap desktop pc mobo recommendation? Message-ID: <1c246150611031225v43be7df3w219b837fae0975a6@mail.gmail.com> I have looked at the products page, read the faq, and looked at the supported chipsets, but I thought I would pose the question to the list. Can someone please provide me with a short list of (current / cheap / desktop oriented) motherboards that enjoy full support with linuxbios? you get bonus points and a free spot on my Christmas list if you provide a link to newegg or outpost.com, thanks in advance. From myles at pel.cs.byu.edu Fri Nov 3 21:42:20 2006 From: myles at pel.cs.byu.edu (Myles Watson) Date: Fri, 03 Nov 2006 13:42:20 -0700 Subject: [LinuxBIOS] Disabled device help In-Reply-To: <13426df10611031119u36ae0376s16868f55fbbbe77d@mail.gmail.com> Message-ID: <01M94LKIBVLY8YQY6G@EMAIL1.BYU.EDU> >>My large device gets disabled somewhere in LinuxBIOS or the kernel. This >>is the encouraging line from LinuxBIOS telling me that the registers are >>indeed set correctly. >>PCI: 05:01.0 18 <- [8000000000 - bfffffffff] prefmem64 >>Unfortunately, Linux sees something different and fails to allocate this >>region because it sees it at 00000080-000000bf and that conflicts with >>other things. >>Does anyone have a pointer to where I should look for this problem? Has >>anyone else had problems with devices larger than 4GB? >you may be the first lucky person to do this. >I assume this is an opteron in 64-bit mode? That's correct. Myles From c-d.hailfinger.devel.2006 at gmx.net Fri Nov 3 22:23:58 2006 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 03 Nov 2006 22:23:58 +0100 Subject: [LinuxBIOS] well supported current cheap desktop pc mobo recommendation? In-Reply-To: <1c246150611031225v43be7df3w219b837fae0975a6@mail.gmail.com> References: <1c246150611031225v43be7df3w219b837fae0975a6@mail.gmail.com> Message-ID: <454BB36E.6090909@gmx.net> Eric Waguespack wrote: > Can someone please provide me with a short list of (current / cheap / > desktop oriented) motherboards that enjoy full support with linuxbios? Sorry, there are none. But you are welcome to help us with the task to get at least one modern bard supported. It would certainly be appreciated. Regards, Carl-Daniel -- http://www.hailfinger.org/ From yinghai.lu at amd.com Fri Nov 3 22:23:07 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 3 Nov 2006 13:23:07 -0800 Subject: [LinuxBIOS] Disabled device help Message-ID: <5986589C150B2F49A46483AC44C7BCA412D7D9@ssvlexmb2.amd.com> Get one infiband pci-e card, it should works with LinuxBIOS and kernel with 4G above pref-mem. I wonder if the recent pci_assign_unassigned_resources moving around in kernel, broke sth. YH -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Myles Watson Sent: Friday, November 03, 2006 11:02 AM To: 'LinuxBIOS' Subject: [LinuxBIOS] Disabled device help My large device gets disabled somewhere in LinuxBIOS or the kernel. This is the encouraging line from LinuxBIOS telling me that the registers are indeed set correctly. PCI: 05:01.0 18 <- [8000000000 - bfffffffff] prefmem64 Unfortunately, Linux sees something different and fails to allocate this region because it sees it at 00000080-000000bf and that conflicts with other things. Does anyone have a pointer to where I should look for this problem? Has anyone else had problems with devices larger than 4GB? Thanks, Myles -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios From yinghai.lu at amd.com Fri Nov 3 23:25:21 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 3 Nov 2006 14:25:21 -0800 Subject: [LinuxBIOS] Disabled device help Message-ID: <5986589C150B2F49A46483AC44C7BCA412D7DC@ssvlexmb2.amd.com> Your device need 256G pref mem? YH -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Myles Watson Sent: Friday, November 03, 2006 12:42 PM To: 'ron minnich' Cc: 'LinuxBIOS' Subject: Re: [LinuxBIOS] Disabled device help >>My large device gets disabled somewhere in LinuxBIOS or the kernel. This >>is the encouraging line from LinuxBIOS telling me that the registers are >>indeed set correctly. >>PCI: 05:01.0 18 <- [8000000000 - bfffffffff] prefmem64 >>Unfortunately, Linux sees something different and fails to allocate this >>region because it sees it at 00000080-000000bf and that conflicts with >>other things. >>Does anyone have a pointer to where I should look for this problem? Has >>anyone else had problems with devices larger than 4GB? >you may be the first lucky person to do this. >I assume this is an opteron in 64-bit mode? That's correct. Myles -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios From dhbarr at gozelle.com Sat Nov 4 00:30:34 2006 From: dhbarr at gozelle.com (David H. Barr) Date: Fri, 3 Nov 2006 17:30:34 -0600 Subject: [LinuxBIOS] well supported current cheap desktop pc mobo recommendation? In-Reply-To: <454BB36E.6090909@gmx.net> References: <1c246150611031225v43be7df3w219b837fae0975a6@mail.gmail.com> <454BB36E.6090909@gmx.net> Message-ID: On 11/3/06, Carl-Daniel Hailfinger wrote: > Eric Waguespack wrote: > > Can someone please provide me with a short list of (current / cheap / > > desktop oriented) motherboards that enjoy full support with linuxbios? > > Sorry, there are none. But you are welcome to help us with the task > to get at least one modern bard supported. It would certainly be > appreciated. There was recently some discussion with regard to the ASUS A8N-VM CSM, which is a widely available and fairly inexpensive motherboard. That effort seems to be somewhat off the radar at this point, pending something about a check-in to the tree of C51 code, as I recall. I, for one, look forward to the first widely-available entry-level board since the PC-Chips stuff from V1. -dhbarr. From yinghai.lu at amd.com Sat Nov 4 00:53:31 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 3 Nov 2006 15:53:31 -0800 Subject: [LinuxBIOS] well supported current cheap desktop pc mobo recommendation? Message-ID: <5986589C150B2F49A46483AC44C7BCA4907188@ssvlexmb2.amd.com> It seems there is platform with mcp55 for AM2. Is that cheap enough? YH From c-d.hailfinger.devel.2006 at gmx.net Sat Nov 4 01:08:21 2006 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 04 Nov 2006 01:08:21 +0100 Subject: [LinuxBIOS] two x86 emulators in the tree... Message-ID: <454BD9F5.6060006@gmx.net> Hi, which of the following x86 emulators in the tree works better and are there any plans to eliminate one of them? LinuxBIOSv2/src/devices/emulator/x86emu/ LinuxBIOSv2/util/vgabios/x86emu/src/x86emu/ Has anyone recently worked to merge this with current x.org and scitech code? Regards, Carl-Daniel -- http://www.hailfinger.org/ From rminnich at gmail.com Sat Nov 4 01:13:12 2006 From: rminnich at gmail.com (ron minnich) Date: Fri, 3 Nov 2006 17:13:12 -0700 Subject: [LinuxBIOS] two x86 emulators in the tree... In-Reply-To: <454BD9F5.6060006@gmx.net> References: <454BD9F5.6060006@gmx.net> Message-ID: <13426df10611031613s35f8a3eeu2966d8572367567e@mail.gmail.com> On 11/3/06, Carl-Daniel Hailfinger wrote: > > Hi, > > which of the following x86 emulators in the tree works better > and are there any plans to eliminate one of them? > > LinuxBIOSv2/src/devices/emulator/x86emu/ part of linuxbios LinuxBIOSv2/util/vgabios/x86emu/src/x86emu/ standalone, for testing. They had to fork, since one can use glibc, the other can not. Has anyone recently worked to merge this with current x.org > and scitech code? it's been on the list for years. The last time we tried it, with some "optimized" code from other places, it totally broke. So we need to be careful. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhbarr at gozelle.com Sat Nov 4 01:57:20 2006 From: dhbarr at gozelle.com (David H. Barr) Date: Fri, 3 Nov 2006 18:57:20 -0600 Subject: [LinuxBIOS] well supported current cheap desktop pc mobo recommendation? In-Reply-To: <5986589C150B2F49A46483AC44C7BCA4907188@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA4907188@ssvlexmb2.amd.com> Message-ID: On 11/3/06, Lu, Yinghai wrote: > It seems there is platform with mcp55 for AM2. Is that cheap enough? That sounds -very- attractive -- I see several boards in the right range, and the Opteron 12xx has a good price point, as well. I've wanted a student cluster for some time, and that would fit the bill nicely. -dhbarr. From yinghai.lu at amd.com Sat Nov 4 02:01:56 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 3 Nov 2006 17:01:56 -0800 Subject: [LinuxBIOS] Disabled device help Message-ID: <5986589C150B2F49A46483AC44C7BCA490718C@ssvlexmb2.amd.com> The Kernel pci_read_bases in drivers/pci/probe.c. has problem when size if bigger than 4G. It will first check the 32 bit SPACE_ADDRESS, and pci_size will return 0, So it will skip that resource. And the pre-set values is ignored. And later, it will try to allocate the value. It will fail. I will produce one patch for you. YH -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Lu, Yinghai Sent: Friday, November 03, 2006 11:46 AM To: myles at mouselemur.cs.byu.edu; LinuxBIOS Subject: Re: [LinuxBIOS] Disabled device help Boot log? In LinuxBIOS, there is CONFIG_PCI_64BIT_PREF_MEM, did you try to enable it in you MB Options.lb In the kernel, there is pci_assign_unassigned_resources that try to allocate resource for some devices, and it could cause problem because Opteron could bave multi ht chain, Aka peer root bus, and every root bus need to have its own ioport_resource, and iomem_resource. But that only happen when BIOS is not allocating resource correctly. And LinuxBIOS does a good job, and every device have be handled properly. In case, you have werid pci devices, you still can use pci_quirks in kernel to do some fix up. YH -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Myles Watson Sent: Friday, November 03, 2006 11:02 AM To: 'LinuxBIOS' Subject: [LinuxBIOS] Disabled device help My large device gets disabled somewhere in LinuxBIOS or the kernel. This is the encouraging line from LinuxBIOS telling me that the registers are indeed set correctly. PCI: 05:01.0 18 <- [8000000000 - bfffffffff] prefmem64 Unfortunately, Linux sees something different and fails to allocate this region because it sees it at 00000080-000000bf and that conflicts with other things. Does anyone have a pointer to where I should look for this problem? Has anyone else had problems with devices larger than 4GB? Thanks, Myles -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios From yinghai.lu at amd.com Sat Nov 4 02:36:19 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 3 Nov 2006 17:36:19 -0800 Subject: [LinuxBIOS] Disabled device help References: <5986589C150B2F49A46483AC44C7BCA490718C@ssvlexmb2.amd.com> Message-ID: <5986589C150B2F49A46483AC44C7BCA413067A@ssvlexmb2.amd.com> Please check the patch. YH -----Original Message----- From: linuxbios-bounces at linuxbios.org on behalf of Lu, Yinghai Sent: Fri 11/3/2006 5:01 PM To: myles at mouselemur.cs.byu.edu; LinuxBIOS Subject: Re: [LinuxBIOS] Disabled device help The Kernel pci_read_bases in drivers/pci/probe.c. has problem when size if bigger than 4G. It will first check the 32 bit SPACE_ADDRESS, and pci_size will return 0, So it will skip that resource. And the pre-set values is ignored. And later, it will try to allocate the value. It will fail. I will produce one patch for you. YH -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Lu, Yinghai Sent: Friday, November 03, 2006 11:46 AM To: myles at mouselemur.cs.byu.edu; LinuxBIOS Subject: Re: [LinuxBIOS] Disabled device help Boot log? In LinuxBIOS, there is CONFIG_PCI_64BIT_PREF_MEM, did you try to enable it in you MB Options.lb In the kernel, there is pci_assign_unassigned_resources that try to allocate resource for some devices, and it could cause problem because Opteron could bave multi ht chain, Aka peer root bus, and every root bus need to have its own ioport_resource, and iomem_resource. But that only happen when BIOS is not allocating resource correctly. And LinuxBIOS does a good job, and every device have be handled properly. In case, you have werid pci devices, you still can use pci_quirks in kernel to do some fix up. YH -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Myles Watson Sent: Friday, November 03, 2006 11:02 AM To: 'LinuxBIOS' Subject: [LinuxBIOS] Disabled device help My large device gets disabled somewhere in LinuxBIOS or the kernel. This is the encouraging line from LinuxBIOS telling me that the registers are indeed set correctly. PCI: 05:01.0 18 <- [8000000000 - bfffffffff] prefmem64 Unfortunately, Linux sees something different and fails to allocate this region because it sees it at 00000080-000000bf and that conflicts with other things. Does anyone have a pointer to where I should look for this problem? Has anyone else had problems with devices larger than 4GB? Thanks, Myles -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pci_64bit_pref_4g.patch Type: text/x-patch Size: 1545 bytes Desc: pci_64bit_pref_4g.patch URL: From rminnich at gmail.com Sat Nov 4 02:57:51 2006 From: rminnich at gmail.com (ron minnich) Date: Fri, 3 Nov 2006 18:57:51 -0700 Subject: [LinuxBIOS] well supported current cheap desktop pc mobo recommendation? In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA4907188@ssvlexmb2.amd.com> Message-ID: <13426df10611031757o4fbd1e2dnaff1b075cedab0a4@mail.gmail.com> This might be a good time to start a page on the wiki: LinuxBIOS desktop, documenting the boards, and how to build a linuxbios desktop, where to buy, etc. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinghai.lu at amd.com Sat Nov 4 03:02:48 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 3 Nov 2006 18:02:48 -0800 Subject: [LinuxBIOS] well supported current cheap desktop pc mobo recommendation? Message-ID: <5986589C150B2F49A46483AC44C7BCA490718D@ssvlexmb2.amd.com> I could spend some time to port one AM2 socket based MB, but the MB should be more popular in the open market. Any good candidate? YH ________________________________ From: ron minnich [mailto:rminnich at gmail.com] Sent: Friday, November 03, 2006 5:58 PM To: David H. Barr Cc: Lu, Yinghai; linuxbios at linuxbios.org Subject: Re: [LinuxBIOS] well supported current cheap desktop pc mobo recommendation? This might be a good time to start a page on the wiki: LinuxBIOS desktop, documenting the boards, and how to build a linuxbios desktop, where to buy, etc. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinghai.lu at amd.com Sat Nov 4 03:31:00 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 3 Nov 2006 18:31:00 -0800 Subject: [LinuxBIOS] 64 bit pref mem patch for ck804 References: <5986589C150B2F49A46483AC44C7BCA490718C@ssvlexmb2.amd.com> <5986589C150B2F49A46483AC44C7BCA413067A@ssvlexmb2.amd.com> Message-ID: <5986589C150B2F49A46483AC44C7BCA413067B@ssvlexmb2.amd.com> Myles, I can not commit the patch directly, So please apply that in your own tree. YH -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ck804_64bit_pref_mem.diff Type: text/x-patch Size: 1498 bytes Desc: ck804_64bit_pref_mem.diff URL: From dhbarr at gozelle.com Sat Nov 4 07:42:00 2006 From: dhbarr at gozelle.com (David H. Barr) Date: Sat, 4 Nov 2006 00:42:00 -0600 Subject: [LinuxBIOS] well supported current cheap desktop pc mobo recommendation? In-Reply-To: <5986589C150B2F49A46483AC44C7BCA490718D@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA490718D@ssvlexmb2.amd.com> Message-ID: Ron: >> This might be a good time to start a page on the wiki: LinuxBIOS desktop, >> documenting the boards, and how to build a linuxbios desktop, where to buy, >> etc. Count me in! YH: > I could spend some time to port one AM2 socket based MB, but the MB should > be more popular in the open market. Any good candidate? What are the limitations here? I see four vanilla AM2 MCP 550 boards, two of which have wide availability. I don't know that much about the "higher" versions such as 570u, etc. -dhb. From ward at pong.be Sat Nov 4 14:41:14 2006 From: ward at pong.be (Ward Vandewege) Date: Sat, 4 Nov 2006 08:41:14 -0500 Subject: [LinuxBIOS] well supported current cheap desktop pc mobo recommendation? In-Reply-To: References: <1c246150611031225v43be7df3w219b837fae0975a6@mail.gmail.com> <454BB36E.6090909@gmx.net> Message-ID: <20061104134114.GA7080@countzero.vandewege.net> On Fri, Nov 03, 2006 at 05:30:34PM -0600, David H. Barr wrote: > On 11/3/06, Carl-Daniel Hailfinger wrote: > > Eric Waguespack wrote: > > > Can someone please provide me with a short list of (current / cheap / > > > desktop oriented) motherboards that enjoy full support with linuxbios? > > > > Sorry, there are none. But you are welcome to help us with the task > > to get at least one modern bard supported. It would certainly be > > appreciated. > > There was recently some discussion with regard to the ASUS A8N-VM CSM, > which is a widely available and fairly inexpensive motherboard. That > effort seems to be somewhat off the radar at this point, pending > something about a check-in to the tree of C51 code, as I recall. Yeah. I've got one of these sitting on my desk and can do testing, but I'm currently hung up on flashrom (can't write) and the C51 code. Thanks, Ward. -- Pong.be -( "Those who do not understand Unix are condemned to )- Virtual hosting -( reinvent it, poorly." -- Henry Spencer )- http://pong.be -( )- GnuPG public key: http://gpg.dtype.org From ebiederm at xmission.com Sat Nov 4 14:52:13 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Sat, 04 Nov 2006 06:52:13 -0700 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage In-Reply-To: <5986589C150B2F49A46483AC44C7BCA412D7AE@ssvlexmb2.amd.com> (Yinghai Lu's message of "Tue, 31 Oct 2006 18:25:28 -0800") References: <5986589C150B2F49A46483AC44C7BCA412D7AE@ssvlexmb2.amd.com> Message-ID: "Lu, Yinghai" writes: > Please check patch attached. It could be applied to mkelfImage cleanly. > > Make mkelfImage to take vmlinux in elf64 for amd64 > > Actually the vmlinux on amd64 is elf64, so parse it and set it back to > elf32. Nack. The 32bit entry point for 64bit kernels is going away. If you want to use vmlinux directly for 64bit kernels please use the 64bit entry point. That requires a whole new kernel type to be added to mkelfImage, unless I am missing something obvious. Eric p.s. Sorry for the delayed reply. From svn at openbios.org Sat Nov 4 15:47:03 2006 From: svn at openbios.org (LinuxBIOS) Date: Sat, 04 Nov 2006 14:47:03 -0000 Subject: [LinuxBIOS] #25: Remove one x86 emulator from the tree? Message-ID: <060.a36e25b2d3cfc44372bb5af07b2d1ba1@openbios.org> #25: Remove one x86 emulator from the tree? ---------------------------+------------------------------------------------ Reporter: uwe | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Keywords: | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Due_close: MM/DD/YYYY | ---------------------------+------------------------------------------------ From http://www.linuxbios.org/pipermail/linuxbios/2006-November/016626.html: {{{ which of the following x86 emulators in the tree works better and are there any plans to eliminate one of them? LinuxBIOSv2/src/devices/emulator/x86emu/ LinuxBIOSv2/util/vgabios/x86emu/src/x86emu/ Has anyone recently worked to merge this with current x.org and scitech code? }}} From http://www.linuxbios.org/pipermail/linuxbios/2006-November/016627.html: {{{ > LinuxBIOSv2/src/devices/emulator/x86emu/ part of linuxbios > LinuxBIOSv2/util/vgabios/x86emu/src/x86emu/ standalone, for testing. They had to fork, since one can use glibc, the other can not. > Has anyone recently worked to merge this with current x.org > and scitech code? it's been on the list for years. The last time we tried it, with some "optimized" code from other places, it totally broke. So we need to be careful. }}} -- Ticket URL: LinuxBIOS From uwe at hermann-uwe.de Sat Nov 4 16:05:45 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 4 Nov 2006 16:05:45 +0100 Subject: [LinuxBIOS] well supported current cheap desktop pc mobo recommendation? In-Reply-To: <454BB36E.6090909@gmx.net> References: <1c246150611031225v43be7df3w219b837fae0975a6@mail.gmail.com> <454BB36E.6090909@gmx.net> Message-ID: <20061104150545.GA13414@greenwood> Hi, On Fri, Nov 03, 2006 at 10:23:58PM +0100, Carl-Daniel Hailfinger wrote: > Eric Waguespack wrote: > > Can someone please provide me with a short list of (current / cheap / > > desktop oriented) motherboards that enjoy full support with linuxbios? > > Sorry, there are none. But you are welcome to help us with the task > to get at least one modern bard supported. It would certainly be > appreciated. I'm currently reading the Intel 845GE/PE datasheet, trying to understand all the RAM init stuff. I intend to add support for that chipset, based on the 855PM code. I do have a testboard (ASUS P4PE-X TE) with that northbridge, and the ICH4 as southbridge (which is supported already AFAIK). The Super I/O is an IT8708F for which I'll post a patch soon. I guess this chipset should enable us to support quite a number of recent Intel-based boards. Any help with the northbridge is really 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 Sat Nov 4 16:05:53 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 4 Nov 2006 16:05:53 +0100 Subject: [LinuxBIOS] well supported current cheap desktop pc mobo recommendation? In-Reply-To: <13426df10611031757o4fbd1e2dnaff1b075cedab0a4@mail.gmail.com> References: <5986589C150B2F49A46483AC44C7BCA4907188@ssvlexmb2.amd.com> <13426df10611031757o4fbd1e2dnaff1b075cedab0a4@mail.gmail.com> Message-ID: <20061104150553.GB13414@greenwood> On Fri, Nov 03, 2006 at 06:57:51PM -0700, ron minnich wrote: > This might be a good time to start a page on the wiki: LinuxBIOS desktop, > documenting the boards, and how to build a linuxbios desktop, where to buy, > etc. Done: http://www.linuxbios.org/Desktops To be filled, of course. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From uwe at hermann-uwe.de Sat Nov 4 16:05:56 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 4 Nov 2006 16:05:56 +0100 Subject: [LinuxBIOS] two x86 emulators in the tree... In-Reply-To: <13426df10611031613s35f8a3eeu2966d8572367567e@mail.gmail.com> References: <454BD9F5.6060006@gmx.net> <13426df10611031613s35f8a3eeu2966d8572367567e@mail.gmail.com> Message-ID: <20061104150556.GC13414@greenwood> On Fri, Nov 03, 2006 at 05:13:12PM -0700, ron minnich wrote: > >which of the following x86 emulators in the tree works better > >and are there any plans to eliminate one of them? I've added this to the issue tracker so we don't forget about it: http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/25 Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From uwe at hermann-uwe.de Sat Nov 4 16:05:59 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 4 Nov 2006 16:05:59 +0100 Subject: [LinuxBIOS] well supported current cheap desktop pc mobo recommendation? In-Reply-To: References: <1c246150611031225v43be7df3w219b837fae0975a6@mail.gmail.com> <454BB36E.6090909@gmx.net> Message-ID: <20061104150559.GD13414@greenwood> Hi, On Fri, Nov 03, 2006 at 05:30:34PM -0600, David H. Barr wrote: > There was recently some discussion with regard to the ASUS A8N-VM CSM, > which is a widely available and fairly inexpensive motherboard. That > effort seems to be somewhat off the radar at this point, pending > something about a check-in to the tree of C51 code, as I recall. > > I, for one, look forward to the first widely-available entry-level > board since the PC-Chips stuff from V1. It would be nice if we could port some of the v1 boards to v2. That would be a start. And that's gonna be a lot easier than adding support for completely new chipsets etc. Are any of the v1 mainboards widespread desktops? 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 stepan at coresystems.de Sat Nov 4 16:51:44 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 4 Nov 2006 16:51:44 +0100 Subject: [LinuxBIOS] 64 bit pref mem patch for ck804 In-Reply-To: <5986589C150B2F49A46483AC44C7BCA413067B@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA490718C@ssvlexmb2.amd.com> <5986589C150B2F49A46483AC44C7BCA413067A@ssvlexmb2.amd.com> <5986589C150B2F49A46483AC44C7BCA413067B@ssvlexmb2.amd.com> Message-ID: <20061104155144.GA8664@coresystems.de> * Lu, Yinghai [061104 03:31]: > > Myles, > > I can not commit the patch directly, So please apply that in your own tree. Is a similar patch required for amd 8xxx? Content-Description: ck804_64bit_pref_mem.diff > ck804 64bit pref mem support > > Signed-off-by: Yinghai Lu Acked-by: Stefan Reinauer > > Index: ck804_pci.c > =================================================================== > --- ck804_pci.c (revision 2486) > +++ ck804_pci.c (working copy) > @@ -14,6 +14,10 @@ > { > > uint32_t dword; > +#if CONFIG_PCI_64BIT_PREF_MEM == 1 > + device_t pci_domain_dev; > + struct resource *mem1, *mem2; > +#endif > > /* System error enable */ > dword = pci_read_config32(dev, 0x04); > @@ -34,8 +38,27 @@ > pci_write_config32(dev, 0x4c, dword); > #endif > > +#if CONFIG_PCI_64BIT_PREF_MEM == 1 > + pci_domain_dev = dev->bus->dev; > + while(pci_domain_dev) { > + if(pci_domain_dev->path.type == DEVICE_PATH_PCI_DOMAIN) break; > + pci_domain_dev = pci_domain_dev->bus->dev; > + } > + > + if(!pci_domain_dev) return; // impossiable It should read "impossible" or better "impossible because we need a PCI domain" but how can we end up without a pci domain on a ck804 mainboard? I would think this can only happen if the mainboard config file is wrong? > + mem1 = find_resource(pci_domain_dev, 1); // prefmem, it could be 64bit > + mem2 = find_resource(pci_domain_dev, 2); // mem > + if(mem1->base > mem2->base) { > + dword = mem2->base & (0xffff0000UL); > + printk_debug("PCI DOMAIN mem2 base = 0x%010Lx\n", mem2->base); > + } else { > + dword = mem1->base & (0xffff0000UL); > + printk_debug("PCI DOMAIN mem1 (prefmem) base = 0x%010Lx\n", mem1->base); > + } > +#else > dword = dev_root.resource[1].base & (0xffff0000UL); > - printk_debug("dev_root mem base = 0x%010Lx\n", dev_root.resource[1].base); > + printk_debug("dev_root mem base = 0x%010Lx\n", dev_root.resource[1].base); > +#endif > > printk_debug("[0x50] <-- 0x%08x\n", dword); > pci_write_config32(dev, 0x50, dword); //TOM -- 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 Sat Nov 4 16:59:25 2006 From: svn at openbios.org (LinuxBIOS) Date: Sat, 04 Nov 2006 15:59:25 -0000 Subject: [LinuxBIOS] #25: Remove one x86 emulator from the tree? In-Reply-To: <060.a36e25b2d3cfc44372bb5af07b2d1ba1@openbios.org> References: <060.a36e25b2d3cfc44372bb5af07b2d1ba1@openbios.org> Message-ID: <069.c60b8e6b0f5565241fc290fc6e64d237@openbios.org> #25: Remove one x86 emulator from the tree? ----------------------------+----------------------------------------------- Reporter: uwe | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v3 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY ----------------------------+----------------------------------------------- Changes (by stepan): * version: v2 => v3 Comment: I suggest we leave the userspace version out of v3, but dont touch it in v2. This way we can always easily find it but it does not become a burden -- Ticket URL: LinuxBIOS From svn at openbios.org Sat Nov 4 17:02:50 2006 From: svn at openbios.org (LinuxBIOS) Date: Sat, 04 Nov 2006 16:02:50 -0000 Subject: [LinuxBIOS] #25: Clean up x86 emulator in the tree? In-Reply-To: <049.30219c860e0d78b96949686ab7000325@openbios.org> References: <049.30219c860e0d78b96949686ab7000325@openbios.org> Message-ID: <058.e521f1ae7b42d714d7e32040a890fe82@openbios.org> #25: Clean up x86 emulator in the tree? ----------------------------+----------------------------------------------- Reporter: uwe | Owner: somebody Type: task | Status: new Priority: major | Milestone: Component: code | Version: v3 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY ----------------------------+----------------------------------------------- Changes (by stepan): * cc: eich at suse.de (added) * type: defect => task * summary: Remove one x86 emulator from the tree? => Clean up x86 emulator in the tree? Comment: I am adding Egbert Eich from the X.org team to this issue. Maybe we find some time at some point to do such a merge / unification together. -- Ticket URL: LinuxBIOS From smithbone at gmail.com Sat Nov 4 17:46:55 2006 From: smithbone at gmail.com (Richard Smith) Date: Sat, 04 Nov 2006 10:46:55 -0600 Subject: [LinuxBIOS] Improvements to "Supported Motherboards" wiki page. In-Reply-To: <20061101142216.GA6713@coresystems.de> References: <20061020210845.GA13614@greenwood> <20061025175032.GB8535@greenwood> <20061031162901.GH2037@greenwood> <45477FD0.6020704@gmail.com> <20061101142216.GA6713@coresystems.de> Message-ID: <454CC3FF.6040108@gmail.com> Stefan Reinauer wrote: > * Richard Smith [061031 17:54]: >> You can essentially drop this one. I started on it to work on the OLPC >> (is a geode) but found out it had a cs5535 rather than a cs5536. It >> would be marked RED. > > I dropped it on your behalf. Thanks. > Should we delete the cs5535 component as well? If it was the only motherboard to use it then yeah. -- Richard A. Smith From stepan at coresystems.de Sat Nov 4 17:57:01 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 4 Nov 2006 17:57:01 +0100 Subject: [LinuxBIOS] Improvements to "Supported Motherboards" wiki page. In-Reply-To: <454CC3FF.6040108@gmail.com> References: <20061020210845.GA13614@greenwood> <20061025175032.GB8535@greenwood> <20061031162901.GH2037@greenwood> <45477FD0.6020704@gmail.com> <20061101142216.GA6713@coresystems.de> <454CC3FF.6040108@gmail.com> Message-ID: <20061104165701.GA17955@coresystems.de> * Richard Smith [061104 17:46]: > Stefan Reinauer wrote: > > > * Richard Smith [061031 17:54]: > >> You can essentially drop this one. I started on it to work on the OLPC > >> (is a geode) but found out it had a cs5535 rather than a cs5536. It > >> would be marked RED. > > > > I dropped it on your behalf. > > Thanks. > > > Should we delete the cs5535 component as well? > > If it was the only motherboard to use it then yeah. I think the GX1 code does not do any memory sizing, does it? Though the eaglelion/5bcm is using it lippert/frontrunner seems to be using cs5535 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 Sat Nov 4 18:02:09 2006 From: yinghailu at gmail.com (yhlu) Date: Sat, 4 Nov 2006 09:02:09 -0800 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA412D7AE@ssvlexmb2.amd.com> Message-ID: <2ea3fae10611040902g6038bf05k7e06a31923b7036a@mail.gmail.com> On 11/4/06, Eric W. Biederman wrote: > The 32bit entry point for 64bit kernels is going away. If you want to use > vmlinux directly for 64bit kernels please use the 64bit entry point. > then with the 64bit entry point in 64bit kernel vmlinux, is it ok with elfboot in current 32bit LinuxBIOS? YH From yinghailu at gmail.com Sat Nov 4 18:08:18 2006 From: yinghailu at gmail.com (yhlu) Date: Sat, 4 Nov 2006 09:08:18 -0800 Subject: [LinuxBIOS] 64 bit pref mem patch for ck804 In-Reply-To: <20061104155144.GA8664@coresystems.de> References: <5986589C150B2F49A46483AC44C7BCA490718C@ssvlexmb2.amd.com> <5986589C150B2F49A46483AC44C7BCA413067A@ssvlexmb2.amd.com> <5986589C150B2F49A46483AC44C7BCA413067B@ssvlexmb2.amd.com> <20061104155144.GA8664@coresystems.de> Message-ID: <2ea3fae10611040908y7cb3e021l2bb66d2c82ec89a@mail.gmail.com> amd8111, don't need that. YH From lfcorreia at lfcorreia.dyndns.org Sat Nov 4 18:11:43 2006 From: lfcorreia at lfcorreia.dyndns.org (Luis Correia) Date: Sat, 04 Nov 2006 17:11:43 +0000 Subject: [LinuxBIOS] Improvements to "Supported Motherboards" wiki page. In-Reply-To: <20061104165701.GA17955@coresystems.de> References: <20061020210845.GA13614@greenwood> <20061025175032.GB8535@greenwood> <20061031162901.GH2037@greenwood> <45477FD0.6020704@gmail.com> <20061101142216.GA6713@coresystems.de> <454CC3FF.6040108@gmail.com> <20061104165701.GA17955@coresystems.de> Message-ID: <454CC9CF.80203@lfcorreia.dyndns.org> Stefan Reinauer wrote: > * Richard Smith [061104 17:46]: > >> Stefan Reinauer wrote: >> >> >>> * Richard Smith [061031 17:54]: >>> >>>> You can essentially drop this one. I started on it to work on the OLPC >>>> (is a geode) but found out it had a cs5535 rather than a cs5536. It >>>> would be marked RED. >>>> >>> I dropped it on your behalf. >>> >> Thanks. >> >> >>> Should we delete the cs5535 component as well? >>> >> If it was the only motherboard to use it then yeah. >> > > I think the GX1 code does not do any memory sizing, does it? > Though the eaglelion/5bcm is using it > > The board i'm working on (IEI Nova 4899R) does detect properly the memory I'm using (124Mb, 128Mb total with 4Mb reserved for the VGA). > lippert/frontrunner seems to be using cs5535 > But it uses the cs5530 :) > Stefan > I'm going to need some assistance with this board, but i'll start a new thread about it soon. Luis Correia -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From ebiederm at xmission.com Sat Nov 4 18:51:51 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Sat, 04 Nov 2006 10:51:51 -0700 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage In-Reply-To: <2ea3fae10611040902g6038bf05k7e06a31923b7036a@mail.gmail.com> (yinghailu@gmail.com's message of "Sat, 4 Nov 2006 09:02:09 -0800") References: <5986589C150B2F49A46483AC44C7BCA412D7AE@ssvlexmb2.amd.com> <2ea3fae10611040902g6038bf05k7e06a31923b7036a@mail.gmail.com> Message-ID: yhlu writes: > On 11/4/06, Eric W. Biederman wrote: >> The 32bit entry point for 64bit kernels is going away. If you want to use >> vmlinux directly for 64bit kernels please use the 64bit entry point. >> > then with the 64bit entry point in 64bit kernel vmlinux, is it ok with > elfboot in current 32bit LinuxBIOS? Well you either there needs to be a trampoline to go from 32 to 64bit mode in mkelfImage or that little bit of logic needs to be in elfboot. That logic already exists in etherboot. Eric From lfcorreia at lfcorreia.dyndns.org Sat Nov 4 21:37:41 2006 From: lfcorreia at lfcorreia.dyndns.org (Luis Correia) Date: Sat, 04 Nov 2006 20:37:41 +0000 Subject: [LinuxBIOS] Support for IEI Nova4899R [1] Message-ID: <454CFA15.3080501@lfcorreia.dyndns.org> Hi, i'm currently trying to build a linuxbios ROM for this embedded board and there are some questions that need some answers. This board uses the following components: Geode GX1 300Mhz Geode cs5530 SuperIO Winbond w83977f sensor chip Winbond w83782 3 * realtek rtl8100 ethernet chips 1 ICP HA6629, presumably an hw watchdog and digital io chip ac97 sound chip AD1881 a PCI slot as for the connection, it also provides: two serial ports one irda pin header the vga output one floppy one paralell port one standard IDE one laptop style 44 pin IDE onboard compactflash socket one socket for DoM module The reason behind the need for linuxbios is that the original bios does not have any good method for IRQ sharing, and it simply freezes when eth0 is up and some device on the PCI bus is also up. Which means that the IRQ sharing is not happening at all... (unless i'm talking rubbish...) I have managed to build a rom for it, using the eaglelion as a base setup, but modifying the superio chip and the PCI device assignments. And for my surprise, it worked right from the start with some minor tweaking to the FILO 0.5 commandline parameters. Since i didn't load any VGA bios i'm stuck with serial console only. --- now for my questions: a) can the VGA rom be loaded as some sort of payload, and thus be automatically added during the build process, or the described procedure here http://www.linuxbios.org/VGA_support is still the best way ? b) is there any way to tell where the IRQ pins for each PCI device are connected to the IRQ router chip? c) i built an irq_tables.c using getpir, but it didn't actually helped much, as now i've got fewer devices working compared with the original bios :) (which i'm not that surprised at all) is getpir still the best method of detecting the original configuration? d) any other input you might give for help is welcome p.s. i apologise in advance for any blunt mistakes or typo's i may have wrote, as English is not my native language, i'm Portuguese btw. ;) Luis Correia -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From yinghailu at gmail.com Sat Nov 4 21:39:09 2006 From: yinghailu at gmail.com (yhlu) Date: Sat, 4 Nov 2006 12:39:09 -0800 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA412D7AE@ssvlexmb2.amd.com> <2ea3fae10611040902g6038bf05k7e06a31923b7036a@mail.gmail.com> Message-ID: <2ea3fae10611041239h637cd0d9s3716dc950193bb10@mail.gmail.com> So the start32 will go way in vmlinx 64 bit? Then you will need 64bit boot loader. Or can I use entrypoint for start64-0x100 to get the address for start32 YH On 11/4/06, Eric W. Biederman wrote: > yhlu writes: > > > On 11/4/06, Eric W. Biederman wrote: > >> The 32bit entry point for 64bit kernels is going away. If you want to use > >> vmlinux directly for 64bit kernels please use the 64bit entry point. > >> > > then with the 64bit entry point in 64bit kernel vmlinux, is it ok with > > elfboot in current 32bit LinuxBIOS? > > Well you either there needs to be a trampoline to go from 32 to 64bit mode in mkelfImage > or that little bit of logic needs to be in elfboot. That logic already exists > in etherboot. > > Eric > From yinghailu at gmail.com Sat Nov 4 22:05:11 2006 From: yinghailu at gmail.com (yhlu) Date: Sat, 4 Nov 2006 13:05:11 -0800 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA412D7AE@ssvlexmb2.amd.com> Message-ID: <2ea3fae10611041305p17d68a8aq16c161fcb65f8660@mail.gmail.com> the latest kernel still put startup_32 on the 0x100000. when will be startup_64/startup_32 be relocatable? YH On 11/4/06, Eric W. Biederman wrote: > "Lu, Yinghai" writes: > > > Please check patch attached. It could be applied to mkelfImage cleanly. > > > > Make mkelfImage to take vmlinux in elf64 for amd64 > > > > Actually the vmlinux on amd64 is elf64, so parse it and set it back to > > elf32. > > Nack. > > The 32bit entry point for 64bit kernels is going away. If you want to use > vmlinux directly for 64bit kernels please use the 64bit entry point. > > That requires a whole new kernel type to be added to mkelfImage, unless > I am missing something obvious. > > Eric > > p.s. Sorry for the delayed reply. > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From ebiederm at xmission.com Sat Nov 4 22:18:36 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Sat, 04 Nov 2006 14:18:36 -0700 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage In-Reply-To: <2ea3fae10611041239h637cd0d9s3716dc950193bb10@mail.gmail.com> (yinghailu@gmail.com's message of "Sat, 4 Nov 2006 12:39:09 -0800") References: <5986589C150B2F49A46483AC44C7BCA412D7AE@ssvlexmb2.amd.com> <2ea3fae10611040902g6038bf05k7e06a31923b7036a@mail.gmail.com> <2ea3fae10611041239h637cd0d9s3716dc950193bb10@mail.gmail.com> Message-ID: yhlu writes: > So the start32 will go way in vmlinx 64 bit? > > Then you will need 64bit boot loader. If you are booting vmlinux yes. > Or can I use entrypoint for start64-0x100 to get the address for start32 Nope. The code will go 64bit in the decompresser. Eric From ebiederm at xmission.com Sat Nov 4 22:20:26 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Sat, 04 Nov 2006 14:20:26 -0700 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage In-Reply-To: <2ea3fae10611041305p17d68a8aq16c161fcb65f8660@mail.gmail.com> (yinghailu@gmail.com's message of "Sat, 4 Nov 2006 13:05:11 -0800") References: <5986589C150B2F49A46483AC44C7BCA412D7AE@ssvlexmb2.amd.com> <2ea3fae10611041305p17d68a8aq16c161fcb65f8660@mail.gmail.com> Message-ID: yhlu writes: > the latest kernel still put startup_32 on the 0x100000. > > when will be startup_64/startup_32 be relocatable? Well the patches for 32bit relocatability are in Andi Kleen's tree. The 64bit stuff will come when someone has time to merge the code. It's just a matter of working through a bunch of stupid little things. Eric From svn at openbios.org Sun Nov 5 00:19:05 2006 From: svn at openbios.org (svn at openbios.org) Date: Sat, 04 Nov 2006 23:19:05 -0000 Subject: [LinuxBIOS] r2487 - in trunk/LinuxBIOSv2/src/superio/ite: it8661f it8671f it8673f it8705f it8712f it8716f it8718f Message-ID: Author: uwe Date: 2006-11-05 00:19:00 +0100 (Sun, 05 Nov 2006) New Revision: 2487 Modified: trunk/LinuxBIOSv2/src/superio/ite/it8661f/Config.lb trunk/LinuxBIOSv2/src/superio/ite/it8661f/chip.h trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f.h trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8671f/Config.lb trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8673f/Config.lb trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f.h trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8705f/Config.lb trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f.h trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8712f/Config.lb trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f.h trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8716f/Config.lb trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f.h trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c trunk/LinuxBIOSv2/src/superio/ite/it8718f/Config.lb trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f.h trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f_early_serial.c Log: Various minor cosmetic changes in the ITE Super I/Os, mostly whitespace changes and fixing of comments. Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Modified: trunk/LinuxBIOSv2/src/superio/ite/it8661f/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8661f/Config.lb 2006-11-02 16:02:33 UTC (rev 2486) +++ trunk/LinuxBIOSv2/src/superio/ite/it8661f/Config.lb 2006-11-04 23:19:00 UTC (rev 2487) @@ -20,3 +20,4 @@ config chip.h object superio.o + Modified: trunk/LinuxBIOSv2/src/superio/ite/it8661f/chip.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8661f/chip.h 2006-11-02 16:02:33 UTC (rev 2486) +++ trunk/LinuxBIOSv2/src/superio/ite/it8661f/chip.h 2006-11-04 23:19:00 UTC (rev 2487) @@ -23,14 +23,12 @@ /* This chip doesn't seem to have keyboard and mouse support. */ -/* #include */ #include extern struct chip_operations superio_ite_it8661f_ops; struct superio_ite_it8661f_config { struct uart8250 com1, com2; - /* struct pc_keyboard keyboard; */ }; #endif /* _SUPERIO_ITE_IT8661F */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f.h 2006-11-02 16:02:33 UTC (rev 2486) +++ trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f.h 2006-11-04 23:19:00 UTC (rev 2487) @@ -19,7 +19,7 @@ */ /* Datasheet: http://www.ite.com.tw/product_info/PC/Brief-IT8661_2.asp */ -/* Status: untested on real hardware, but it compiles. */ +/* Status: Untested on real hardware, but it compiles. */ /* This chip doesn't seem to have keyboard and mouse support. */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f_early_serial.c 2006-11-02 16:02:33 UTC (rev 2486) +++ trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f_early_serial.c 2006-11-04 23:19:00 UTC (rev 2487) @@ -26,7 +26,7 @@ #define SIO_INDEX SIO_BASE #define SIO_DATA SIO_BASE+1 -/* Global Configuration Registers. */ +/* Global configuration registers. */ #define IT8661F_CONFIG_REG_CC 0x02 /* Configure Control (write-only). */ #define IT8661F_CONFIG_REG_LDN 0x07 /* Logical Device Number. */ #define IT8661F_CONFIG_REG_LDE 0x23 /* PnP Logical Device Enable. */ @@ -35,7 +35,7 @@ #define IT8661F_CONFIGURATION_PORT 0x0279 /* Write-only. */ /* Special values used for entering MB PnP mode. The first four bytes of - * each line determine the address port, the last four are data. */ + each line determine the address port, the last four are data. */ static const uint8_t init_values[] = { 0x6a, 0xb5, 0xda, 0xed, /**/ 0xf6, 0xfb, 0x7d, 0xbe, 0xdf, 0x6f, 0x37, 0x1b, /**/ 0x0d, 0x86, 0xc3, 0x61, @@ -44,7 +44,7 @@ }; /* The content of IT8661F_CONFIG_REG_LDN (index 0x07) must be set to the - * LDN the register belongs to, before you can access the register. */ + LDN the register belongs to, before you can access the register. */ static void it8661f_sio_write(uint8_t ldn, uint8_t index, uint8_t value) { outb(IT8661F_CONFIG_REG_LDN, SIO_BASE); @@ -53,7 +53,7 @@ outb(value, SIO_DATA); } -/* Enable the peripheral devices on the IT8661F Super IO chip. */ +/* Enable the peripheral devices on the IT8661F Super I/O chip. */ static void it8661f_enable_serial(device_t dev, unsigned iobase) { uint8_t i; @@ -88,10 +88,10 @@ it8661f_sio_write(IT8661F_IR, 0x30, 0x1); /* IR */ /* Select 24MHz CLKIN (clear bit 1) and clear software suspend mode - (clear bit 0). */ + (clear bit 0). */ it8661f_sio_write(0x00, IT8661F_CONFIG_REG_SWSUSP, 0x00); /* (3) Exit the configuration state (MB PnP mode). */ - it8661f_sio_write(0x00, IT8661F_CONFIG_REG_CC, 0x02); + it8661f_sio_write(0x00, IT8661F_CONFIG_REG_CC, 0x02); } Modified: trunk/LinuxBIOSv2/src/superio/ite/it8671f/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8671f/Config.lb 2006-11-02 16:02:33 UTC (rev 2486) +++ trunk/LinuxBIOSv2/src/superio/ite/it8671f/Config.lb 2006-11-04 23:19:00 UTC (rev 2487) @@ -20,3 +20,4 @@ config chip.h object superio.o + Modified: trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f_early_serial.c 2006-11-02 16:02:33 UTC (rev 2486) +++ trunk/LinuxBIOSv2/src/superio/ite/it8671f/it8671f_early_serial.c 2006-11-04 23:19:00 UTC (rev 2487) @@ -26,7 +26,7 @@ #define SIO_INDEX SIO_BASE #define SIO_DATA SIO_BASE+1 -/* Global Configuration Registers. */ +/* Global configuration registers. */ #define IT8671F_CONFIG_REG_CC 0x02 /* Configure Control (write-only). */ #define IT8671F_CONFIG_REG_LDN 0x07 /* Logical Device Number. */ #define IT8671F_CONFIG_REG_LDE 0x23 /* PnP Logical Device Enable. */ @@ -35,7 +35,7 @@ #define IT8671F_CONFIGURATION_PORT 0x0279 /* Write-only. */ /* Special values used for entering MB PnP mode. The first four bytes of - * each line determine the address port, the last four are data. */ + each line determine the address port, the last four are data. */ static const uint8_t init_values[] = { 0x6a, 0xb5, 0xda, 0xed, /**/ 0xf6, 0xfb, 0x7d, 0xbe, 0xdf, 0x6f, 0x37, 0x1b, /**/ 0x0d, 0x86, 0xc3, 0x61, @@ -44,7 +44,7 @@ }; /* The content of IT8671F_CONFIG_REG_LDN (index 0x07) must be set to the - * LDN the register belongs to, before you can access the register. */ + LDN the register belongs to, before you can access the register. */ static void it8671f_sio_write(uint8_t ldn, uint8_t index, uint8_t value) { outb(IT8671F_CONFIG_REG_LDN, SIO_BASE); @@ -53,7 +53,7 @@ outb(value, SIO_DATA); } -/* Enable the peripheral devices on the IT8671F Super IO chip. */ +/* Enable the peripheral devices on the IT8671F Super I/O chip. */ static void it8671f_enable_serial(device_t dev, unsigned iobase) { uint8_t i; @@ -80,7 +80,7 @@ PP (3), Reserved (4), KBCK (5), KBCM (6), Reserved (7). */ it8671f_sio_write(0x00, IT8671F_CONFIG_REG_LDE, 0x6f); - /* Activate all devices. */ + /* Activate all devices. */ it8671f_sio_write(IT8671F_FDC, 0x30, 0x01); /* Floppy */ it8671f_sio_write(IT8671F_SP1, 0x30, 0x01); /* Serial port 1 */ it8671f_sio_write(IT8671F_SP2, 0x30, 0x01); /* Serial port 2 */ @@ -93,6 +93,6 @@ it8671f_sio_write(0x00, IT8671F_CONFIG_REG_SWSUSP, 0x00); /* (3) Exit the configuration state (MB PnP mode). */ - it8671f_sio_write(0x00, IT8671F_CONFIG_REG_CC, 0x02); + it8671f_sio_write(0x00, IT8671F_CONFIG_REG_CC, 0x02); } Modified: trunk/LinuxBIOSv2/src/superio/ite/it8673f/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8673f/Config.lb 2006-11-02 16:02:33 UTC (rev 2486) +++ trunk/LinuxBIOSv2/src/superio/ite/it8673f/Config.lb 2006-11-04 23:19:00 UTC (rev 2487) @@ -20,3 +20,4 @@ config chip.h object superio.o + Modified: trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f.h 2006-11-02 16:02:33 UTC (rev 2486) +++ trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f.h 2006-11-04 23:19:00 UTC (rev 2487) @@ -19,7 +19,7 @@ */ /* Datasheet: http://www.datasheet4u.com/html/I/T/8/IT8673F_ITE.pdf.html */ -/* Status: untested on real hardware, but it compiles. */ +/* Status: Untested on real hardware, but it compiles. */ #define IT8673F_FDC 0x00 /* Floppy */ #define IT8673F_SP1 0x01 /* Com1 */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f_early_serial.c 2006-11-02 16:02:33 UTC (rev 2486) +++ trunk/LinuxBIOSv2/src/superio/ite/it8673f/it8673f_early_serial.c 2006-11-04 23:19:00 UTC (rev 2487) @@ -26,7 +26,7 @@ #define SIO_INDEX SIO_BASE #define SIO_DATA SIO_BASE+1 -/* Global Configuration Registers. */ +/* Global configuration registers. */ #define IT8673F_CONFIG_REG_CC 0x02 /* Configure Control (write-only). */ #define IT8673F_CONFIG_REG_LDN 0x07 /* Logical Device Number. */ #define IT8673F_CONFIG_REG_CLOCKSEL 0x23 /* Clock Selection. */ @@ -35,7 +35,7 @@ #define IT8673F_CONFIGURATION_PORT 0x0279 /* Write-only. */ /* Special values used for entering MB PnP mode. The first four bytes of - * each line determine the address port, the last four are data. */ + each line determine the address port, the last four are data. */ static const uint8_t init_values[] = { 0x6a, 0xb5, 0xda, 0xed, /**/ 0xf6, 0xfb, 0x7d, 0xbe, 0xdf, 0x6f, 0x37, 0x1b, /**/ 0x0d, 0x86, 0xc3, 0x61, @@ -44,7 +44,7 @@ }; /* The content of IT8673F_CONFIG_REG_LDN (index 0x07) must be set to the - * LDN the register belongs to, before you can access the register. */ + LDN the register belongs to, before you can access the register. */ static void it8673f_sio_write(uint8_t ldn, uint8_t index, uint8_t value) { outb(IT8673F_CONFIG_REG_LDN, SIO_BASE); @@ -53,7 +53,7 @@ outb(value, SIO_DATA); } -/* Enable the peripheral devices on the IT8673F Super IO chip. */ +/* Enable the peripheral devices on the IT8673F Super I/O chip. */ static void it8673f_enable_serial(device_t dev, unsigned iobase) { uint8_t i; @@ -92,6 +92,6 @@ it8673f_sio_write(0x00, IT8673F_CONFIG_REG_SWSUSP, 0x00); /* (3) Exit the configuration state (MB PnP mode). */ - it8673f_sio_write(0x00, IT8673F_CONFIG_REG_CC, 0x02); + it8673f_sio_write(0x00, IT8673F_CONFIG_REG_CC, 0x02); } Modified: trunk/LinuxBIOSv2/src/superio/ite/it8705f/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8705f/Config.lb 2006-11-02 16:02:33 UTC (rev 2486) +++ trunk/LinuxBIOSv2/src/superio/ite/it8705f/Config.lb 2006-11-04 23:19:00 UTC (rev 2487) @@ -20,3 +20,4 @@ config chip.h object superio.o + Modified: trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f.h 2006-11-02 16:02:33 UTC (rev 2486) +++ trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f.h 2006-11-04 23:19:00 UTC (rev 2487) @@ -19,7 +19,7 @@ */ /* Datasheet: http://www.ite.com.tw/product_info/PC/Brief-IT8705_2.asp */ -/* Status: untested on real hardware, but it compiles. */ +/* Status: Untested on real hardware, but it compiles. */ /* Note: This should also work on an IT8705AF, they're almost the same. */ /* This chip doesn't seem to have keyboard and mouse support. */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c 2006-11-02 16:02:33 UTC (rev 2486) +++ trunk/LinuxBIOSv2/src/superio/ite/it8705f/it8705f_early_serial.c 2006-11-04 23:19:00 UTC (rev 2487) @@ -26,19 +26,19 @@ #define SIO_INDEX SIO_BASE #define SIO_DATA SIO_BASE+1 -/* Global Configuration Registers. */ +/* Global configuration registers. */ #define IT8705F_CONFIG_REG_CC 0x02 /* Configure Control (write-only). */ #define IT8705F_CONFIG_REG_LDN 0x07 /* Logical Device Number. */ #define IT8705F_CONFIG_REG_CONFIGSEL 0x22 /* Configuration Select. */ /* WTF? 0x23 and 0x24 are swapped here (when compared to other IT87xx). */ -#define IT8705F_CONFIG_REG_CLOCKSEL 0x24 /* Clock Selection. */ -#define IT8705F_CONFIG_REG_SWSUSP 0x23 /* Software Suspend, Flash I/F. */ +#define IT8705F_CONFIG_REG_CLOCKSEL 0x24 /* Clock Selection, Flash I/F. */ +#define IT8705F_CONFIG_REG_SWSUSP 0x23 /* Software Suspend. */ #define IT8705F_CONFIGURATION_PORT 0x2e /* Write-only. */ /* The content of IT8705F_CONFIG_REG_LDN (index 0x07) must be set to the - * LDN the register belongs to, before you can access the register. */ + LDN the register belongs to, before you can access the register. */ static void it8705f_sio_write(uint8_t ldn, uint8_t index, uint8_t value) { outb(IT8705F_CONFIG_REG_LDN, SIO_BASE); @@ -47,7 +47,7 @@ outb(value, SIO_DATA); } -/* Enable the peripheral devices on the IT8705F Super IO chip. */ +/* Enable the peripheral devices on the IT8705F Super I/O chip. */ static void it8705f_enable_serial(device_t dev, unsigned iobase) { /* (1) Enter the configuration state (MB PnP mode). */ @@ -63,8 +63,8 @@ /* (2) Modify the data of configuration registers. */ /* Select the chip to configure (if there's more than one). - * Set bit 7 to select JP3=1, clear bit 7 to select JP3=0. - * If this register is not written, both chips are configured. */ + Set bit 7 to select JP3=1, clear bit 7 to select JP3=0. + If this register is not written, both chips are configured. */ /* it8705f_sio_write(0x00, IT8705F_CONFIG_REG_CONFIGSEL, 0x00); */ /* Enable all devices. */ @@ -73,18 +73,17 @@ it8705f_sio_write(IT8705F_SP2, 0x30, 0x1); /* Serial port 2 */ it8705f_sio_write(IT8705F_PP, 0x30, 0x1); /* Parallel port */ it8705f_sio_write(IT8705F_EC, 0x30, 0x1); /* Environment controller */ - /* GPIO */ it8705f_sio_write(IT8705F_GAME, 0x30, 0x1); /* GAME port */ it8705f_sio_write(IT8705F_IR, 0x30, 0x1); /* Consumer IR */ it8705f_sio_write(IT8705F_MIDI, 0x30, 0x1); /* MIDI port */ /* Select 24MHz/48MHz CLKIN (set/clear bit 0). TODO: Needed? */ - /* it8705f_sio_write(0x00, IT8705F_CONFIG_REG_CLOCKSEL, 0x00); */ + /* it8705f_sio_write(0x00, IT8705F_CONFIG_REG_CLOCKSEL, 0x01); */ /* Clear software suspend mode (clear bit 0). TODO: Needed? */ /* it8705f_sio_write(0x00, IT8705F_CONFIG_REG_SWSUSP, 0x00); */ /* (3) Exit the configuration state (MB PnP mode). */ - it8705f_sio_write(0x00, IT8705F_CONFIG_REG_CC, 0x02); + it8705f_sio_write(0x00, IT8705F_CONFIG_REG_CC, 0x02); } Modified: trunk/LinuxBIOSv2/src/superio/ite/it8712f/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8712f/Config.lb 2006-11-02 16:02:33 UTC (rev 2486) +++ trunk/LinuxBIOSv2/src/superio/ite/it8712f/Config.lb 2006-11-04 23:19:00 UTC (rev 2487) @@ -20,3 +20,4 @@ config chip.h object superio.o + Modified: trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f.h 2006-11-02 16:02:33 UTC (rev 2486) +++ trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f.h 2006-11-04 23:19:00 UTC (rev 2487) @@ -19,7 +19,7 @@ */ /* Datasheet: http://www.ite.com.tw/product_info/PC/Brief-IT8712_2.asp */ -/* Status: untested on real hardware, but it compiles. */ +/* Status: Untested on real hardware, but it compiles. */ #define IT8712F_FDC 0x00 /* Floppy */ #define IT8712F_SP1 0x01 /* Com1 */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c 2006-11-02 16:02:33 UTC (rev 2486) +++ trunk/LinuxBIOSv2/src/superio/ite/it8712f/it8712f_early_serial.c 2006-11-04 23:19:00 UTC (rev 2487) @@ -26,7 +26,7 @@ #define SIO_INDEX SIO_BASE #define SIO_DATA SIO_BASE+1 -/* Global Configuration Registers. */ +/* Global configuration registers. */ #define IT8712F_CONFIG_REG_CC 0x02 /* Configure Control (write-only). */ #define IT8712F_CONFIG_REG_LDN 0x07 /* Logical Device Number. */ #define IT8712F_CONFIG_REG_CONFIGSEL 0x22 /* Configuration Select. */ @@ -36,7 +36,7 @@ #define IT8712F_CONFIGURATION_PORT 0x2e /* Write-only. */ /* The content of IT8712F_CONFIG_REG_LDN (index 0x07) must be set to the - * LDN the register belongs to, before you can access the register. */ + LDN the register belongs to, before you can access the register. */ static void it8712f_sio_write(uint8_t ldn, uint8_t index, uint8_t value) { outb(IT8712F_CONFIG_REG_LDN, SIO_BASE); @@ -45,7 +45,7 @@ outb(value, SIO_DATA); } -/* Enable the peripheral devices on the IT8712F Super IO chip. */ +/* Enable the peripheral devices on the IT8712F Super I/O chip. */ static void it8712f_enable_serial(device_t dev, unsigned iobase) { /* (1) Enter the configuration state (MB PnP mode). */ @@ -61,8 +61,8 @@ /* (2) Modify the data of configuration registers. */ /* Select the chip to configure (if there's more than one). - * Set bit 7 to select JP3=1, clear bit 7 to select JP3=0. - * If this register is not written, both chips are configured. */ + Set bit 7 to select JP3=1, clear bit 7 to select JP3=0. + If this register is not written, both chips are configured. */ /* it8712f_sio_write(0x00, IT8712F_CONFIG_REG_CONFIGSEL, 0x00); */ /* Enable all devices. */ @@ -78,12 +78,12 @@ it8712f_sio_write(IT8712F_IR, 0x30, 0x1); /* Consumer IR */ /* Select 24MHz/48MHz CLKIN (set/clear bit 0). TODO: Needed? */ - /* it8712f_sio_write(0x00, IT8712F_CONFIG_REG_CLOCKSEL, 0x00); */ + /* it8712f_sio_write(0x00, IT8712F_CONFIG_REG_CLOCKSEL, 0x01); */ /* Clear software suspend mode (clear bit 0). TODO: Needed? */ /* it8712f_sio_write(0x00, IT8712F_CONFIG_REG_SWSUSP, 0x00); */ /* (3) Exit the configuration state (MB PnP mode). */ - it8712f_sio_write(0x00, IT8712F_CONFIG_REG_CC, 0x02); + it8712f_sio_write(0x00, IT8712F_CONFIG_REG_CC, 0x02); } Modified: trunk/LinuxBIOSv2/src/superio/ite/it8716f/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8716f/Config.lb 2006-11-02 16:02:33 UTC (rev 2486) +++ trunk/LinuxBIOSv2/src/superio/ite/it8716f/Config.lb 2006-11-04 23:19:00 UTC (rev 2487) @@ -20,3 +20,4 @@ config chip.h object superio.o + Modified: trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f.h 2006-11-02 16:02:33 UTC (rev 2486) +++ trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f.h 2006-11-04 23:19:00 UTC (rev 2487) @@ -19,7 +19,7 @@ */ /* Datasheet: http://www.ite.com.tw/product_info/PC/Brief-IT8716_2.asp */ -/* Status: untested on real hardware, but it compiles. */ +/* Status: Untested on real hardware, but it compiles. */ #define IT8716F_FDC 0x00 /* Floppy */ #define IT8716F_SP1 0x01 /* Com1 */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c 2006-11-02 16:02:33 UTC (rev 2486) +++ trunk/LinuxBIOSv2/src/superio/ite/it8716f/it8716f_early_serial.c 2006-11-04 23:19:00 UTC (rev 2487) @@ -26,7 +26,7 @@ #define SIO_INDEX SIO_BASE #define SIO_DATA SIO_BASE+1 -/* Global Configuration Registers. */ +/* Global configuration registers. */ #define IT8716F_CONFIG_REG_CC 0x02 /* Configure Control (write-only). */ #define IT8716F_CONFIG_REG_LDN 0x07 /* Logical Device Number. */ #define IT8716F_CONFIG_REG_CONFIGSEL 0x22 /* Configuration Select. */ @@ -36,7 +36,7 @@ #define IT8716F_CONFIGURATION_PORT 0x2e /* Write-only. */ /* The content of IT8716F_CONFIG_REG_LDN (index 0x07) must be set to the - * LDN the register belongs to, before you can access the register. */ + LDN the register belongs to, before you can access the register. */ static void it8716f_sio_write(uint8_t ldn, uint8_t index, uint8_t value) { outb(IT8716F_CONFIG_REG_LDN, SIO_BASE); @@ -45,7 +45,7 @@ outb(value, SIO_DATA); } -/* Enable the peripheral devices on the IT8716F Super IO chip. */ +/* Enable the peripheral devices on the IT8716F Super I/O chip. */ static void it8716f_enable_serial(device_t dev, unsigned iobase) { /* (1) Enter the configuration state (MB PnP mode). */ @@ -61,8 +61,8 @@ /* (2) Modify the data of configuration registers. */ /* Select the chip to configure (if there's more than one). - * Set bit 7 to select JP3=1, clear bit 7 to select JP3=0. - * If this register is not written, both chips are configured. */ + Set bit 7 to select JP3=1, clear bit 7 to select JP3=0. + If this register is not written, both chips are configured. */ /* it8716f_sio_write(0x00, IT8716F_CONFIG_REG_CONFIGSEL, 0x00); */ /* Enable all devices. */ @@ -78,12 +78,12 @@ it8716f_sio_write(IT8716F_IR, 0x30, 0x1); /* Consumer IR */ /* Select 24MHz/48MHz CLKIN (set/clear bit 0). TODO: Needed? */ - /* it8716f_sio_write(0x00, IT8716F_CONFIG_REG_CLOCKSEL, 0x00); */ + /* it8716f_sio_write(0x00, IT8716F_CONFIG_REG_CLOCKSEL, 0x01); */ /* Clear software suspend mode (clear bit 0). TODO: Needed? */ /* it8716f_sio_write(0x00, IT8716F_CONFIG_REG_SWSUSP, 0x00); */ /* (3) Exit the configuration state (MB PnP mode). */ - it8716f_sio_write(0x00, IT8716F_CONFIG_REG_CC, 0x02); + it8716f_sio_write(0x00, IT8716F_CONFIG_REG_CC, 0x02); } Modified: trunk/LinuxBIOSv2/src/superio/ite/it8718f/Config.lb =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8718f/Config.lb 2006-11-02 16:02:33 UTC (rev 2486) +++ trunk/LinuxBIOSv2/src/superio/ite/it8718f/Config.lb 2006-11-04 23:19:00 UTC (rev 2487) @@ -20,3 +20,4 @@ config chip.h object superio.o + Modified: trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f.h =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f.h 2006-11-02 16:02:33 UTC (rev 2486) +++ trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f.h 2006-11-04 23:19:00 UTC (rev 2487) @@ -19,7 +19,7 @@ */ /* Datasheet: http://www.ite.com.tw/product_info/PC/Brief-IT8718_2.asp */ -/* Status: untested on real hardware, but it compiles. */ +/* Status: Untested on real hardware, but it compiles. */ #define IT8718F_FDC 0x00 /* Floppy */ #define IT8718F_SP1 0x01 /* Com1 */ Modified: trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f_early_serial.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f_early_serial.c 2006-11-02 16:02:33 UTC (rev 2486) +++ trunk/LinuxBIOSv2/src/superio/ite/it8718f/it8718f_early_serial.c 2006-11-04 23:19:00 UTC (rev 2487) @@ -26,7 +26,7 @@ #define SIO_INDEX SIO_BASE #define SIO_DATA SIO_BASE+1 -/* Global Configuration Registers. */ +/* Global configuration registers. */ #define IT8718F_CONFIG_REG_CC 0x02 /* Configure Control (write-only). */ #define IT8718F_CONFIG_REG_LDN 0x07 /* Logical Device Number. */ #define IT8718F_CONFIG_REG_CONFIGSEL 0x22 /* Configuration Select. */ @@ -36,7 +36,7 @@ #define IT8718F_CONFIGURATION_PORT 0x2e /* Write-only. */ /* The content of IT8718F_CONFIG_REG_LDN (index 0x07) must be set to the - * LDN the register belongs to, before you can access the register. */ + LDN the register belongs to, before you can access the register. */ static void it8718f_sio_write(uint8_t ldn, uint8_t index, uint8_t value) { outb(IT8718F_CONFIG_REG_LDN, SIO_BASE); @@ -45,7 +45,7 @@ outb(value, SIO_DATA); } -/* Enable the peripheral devices on the IT8718F Super IO chip. */ +/* Enable the peripheral devices on the IT8718F Super I/O chip. */ static void it8718f_enable_serial(device_t dev, unsigned iobase) { /* (1) Enter the configuration state (MB PnP mode). */ @@ -61,8 +61,8 @@ /* (2) Modify the data of configuration registers. */ /* Select the chip to configure (if there's more than one). - * Set bit 7 to select JP3=1, clear bit 7 to select JP3=0. - * If this register is not written, both chips are configured. */ + Set bit 7 to select JP3=1, clear bit 7 to select JP3=0. + If this register is not written, both chips are configured. */ /* it8718f_sio_write(0x00, IT8718F_CONFIG_REG_CONFIGSEL, 0x00); */ /* Enable all devices. */ @@ -76,12 +76,12 @@ it8718f_sio_write(IT8718F_IR, 0x30, 0x1); /* Consumer IR */ /* Select 24MHz/48MHz CLKIN (set/clear bit 0). TODO: Needed? */ - /* it8718f_sio_write(0x00, IT8718F_CONFIG_REG_CLOCKSEL, 0x00); */ + /* it8718f_sio_write(0x00, IT8718F_CONFIG_REG_CLOCKSEL, 0x01); */ /* Clear software suspend mode (clear bit 0). TODO: Needed? */ /* it8718f_sio_write(0x00, IT8718F_CONFIG_REG_SWSUSP, 0x00); */ /* (3) Exit the configuration state (MB PnP mode). */ - it8718f_sio_write(0x00, IT8718F_CONFIG_REG_CC, 0x02); + it8718f_sio_write(0x00, IT8718F_CONFIG_REG_CC, 0x02); } From rminnich at gmail.com Sun Nov 5 01:40:41 2006 From: rminnich at gmail.com (ron minnich) Date: Sat, 4 Nov 2006 17:40:41 -0700 Subject: [LinuxBIOS] Support for IEI Nova4899R [1] In-Reply-To: <454CFA15.3080501@lfcorreia.dyndns.org> References: <454CFA15.3080501@lfcorreia.dyndns.org> Message-ID: <13426df10611041640o2008c16fj21ccfb55fe0c8929@mail.gmail.com> On 11/4/06, Luis Correia wrote: > > > > --- > > now for my questions: > > a) can the VGA rom be loaded as some sort of payload, and thus be > automatically added during the build process, or the described > procedure here http://www.linuxbios.org/VGA_support is still > the best way ? that's still the only way for now. b) is there any way to tell where the IRQ pins for each PCI device > are connected to the IRQ router chip? schematics. Or a volt-ohm meter. In all too many cases, the IRQ table in the fuctory bios is wrong. It can not be trusted. c) i built an irq_tables.c using getpir, but it didn't actually > helped much, as now i've got fewer devices working compared with > the original bios :) (which i'm not that surprised at all) > is getpir still the best method of detecting the original configuration? I used to depend on getpir, until I found out how many bioses have the wrong PIRQ table, and then I found that after 2.4.18 Linux is parsing the IRQ tables incorrectly for cs5530, due to the fact that about half the GX1 tables in the world are wrong ... it is a terrible mess. So, getpir is only as good as the tables in the fuctory bios, which nowadays means ... maybe it will be good, but it is highly probable to have errors. d) any other input you might give for help is welcome nice work! how much did this board cost, and where do we get one? Everyone, I think we can NOT delete the cs5530 support, or gx1 support in general; we have a new motherboard! Luis, can you do an svn diff and post a patch to the list; or use the tracker? thanks ron p.s. your english is better than most US high school students :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfcorreia at lfcorreia.dyndns.org Sun Nov 5 02:07:38 2006 From: lfcorreia at lfcorreia.dyndns.org (Luis Correia) Date: Sun, 05 Nov 2006 01:07:38 +0000 Subject: [LinuxBIOS] Support for IEI Nova4899R [1] In-Reply-To: <13426df10611041640o2008c16fj21ccfb55fe0c8929@mail.gmail.com> References: <454CFA15.3080501@lfcorreia.dyndns.org> <13426df10611041640o2008c16fj21ccfb55fe0c8929@mail.gmail.com> Message-ID: <454D395A.3020205@lfcorreia.dyndns.org> ron minnich wrote: > > > On 11/4/06, *Luis Correia* > wrote: > > > > --- > > now for my questions: > > a) can the VGA rom be loaded as some sort of payload, and thus be > automatically added during the build process, or the described > procedure here http://www.linuxbios.org/VGA_support is still > the best way ? > > > > that's still the only way for now. bummer! I've managed to reduce the overall size of the bios and added the original VGA bios rom. But my guess (from reading the archives) that VSA is still not supported and such, my hopes of seeing any image on teh VGA screen are now even more reduced... > > b) is there any way to tell where the IRQ pins for each PCI device > are connected to the IRQ router chip? > > > > schematics. Or a volt-ohm meter. In all too many cases, the IRQ table > in the fuctory bios is wrong. It can not be trusted. > I don't have any schematics, but there is an ohm meter around here. but the chips are BGA, i can't just rip them off the board to read the pins :) > > c) i built an irq_tables.c using getpir, but it didn't actually > helped much, as now i've got fewer devices working compared with > the original bios :) (which i'm not that surprised at all) > is getpir still the best method of detecting the original > configuration? > > > > I used to depend on getpir, until I found out how many bioses have the > wrong PIRQ table, and then I found that after 2.4.18 Linux is parsing > the IRQ tables incorrectly for cs5530, due to the fact that about half > the GX1 tables in the world are wrong ... it is a terrible mess. So, > getpir is only as good as the tables in the fuctory bios, which > nowadays means ... maybe it will be good, but it is highly probable to > have errors. > I have also managed to mess around with the PIRQ table and now linux does not complain about devices having IRQ0 assigned. But there are still problems. It locks up under some irq sharing scenarios. it might take a long while before i get the IRQ assignments right. > d) any other input you might give for help is welcome > > > > nice work! how much did this board cost, and where do we get one? Thanks! This is a surplus board, that cost me 75?. (Manufacturer's website: http://www.ieiworld.com/en/product_IPC.asp?model=NOVA-4899) It's an old not RoHS compliant, and I don't even were supposed to have it here in Europe ;) but it is obsolete industrial equipment parts, and I got it from my friend Martin Hoehne at www.minipci.biz . These boards are sold out now, but it has some similar ones, also using a Geode GX1. (http://www.ieiworld.com/en/product_IPC.asp?model=ISS-102) > > Everyone, I think we can NOT delete the cs5530 support, or gx1 support > in general; we have a new motherboard! > > Luis, can you do an svn diff and post a patch to the list; or use the > tracker? Let me get this into a better shape, and i'll post a patch diff here (let me know which is the right way to present the patch). > > thanks > > ron > p.s. your english is better than most US high school students :-) well, that is maybe because i'm 41 and try a lot not to make a fool out of myself :) (most of the time anyway...) Luis -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From segher at kernel.crashing.org Sun Nov 5 02:40:09 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 5 Nov 2006 02:40:09 +0100 Subject: [LinuxBIOS] Support for IEI Nova4899R [1] In-Reply-To: <13426df10611041640o2008c16fj21ccfb55fe0c8929@mail.gmail.com> References: <454CFA15.3080501@lfcorreia.dyndns.org> <13426df10611041640o2008c16fj21ccfb55fe0c8929@mail.gmail.com> Message-ID: > b) is there any way to tell where the IRQ pins for each PCI device > are connected to the IRQ router chip? > > > schematics. Or a volt-ohm meter. In all too many cases, the IRQ > table in the fuctory bios is wrong. It can not be trusted. [OT: Google reports 485 hits for "fuctory bios"]. Another way is to add some instrumentation code to either the kernel or your firmware to report which IRQ triggered (and as what all the way on your interrupt chain), and then "manually" trigger an interrupt event on one of your devices, and see what happens. With something like Open Firmware, this isn't all that hard, as the firmware typically runs with interrupts disabled on the CPU, so you get no bad side effects; when done on a running kernel, it's pretty easy to hang the system. But most often you'll at least see what IRQ it was :-) Doing this properly requires some in-depth knowledge of the whole interrupt chain on your system -- you'll need that to correctly program the interrupt subsystem anyway, though. Segher From yinghailu at gmail.com Sun Nov 5 02:56:39 2006 From: yinghailu at gmail.com (yhlu) Date: Sat, 4 Nov 2006 17:56:39 -0800 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA412D7AE@ssvlexmb2.amd.com> <2ea3fae10611040902g6038bf05k7e06a31923b7036a@mail.gmail.com> <2ea3fae10611041239h637cd0d9s3716dc950193bb10@mail.gmail.com> Message-ID: <2ea3fae10611041756w25975ca5o3a9facc726378ecd@mail.gmail.com> On 11/4/06, Eric W. Biederman wrote: > > > > Then you will need 64bit boot loader. > > If you are booting vmlinux yes. Wow? what happened? > > > Or can I use entrypoint for start64-0x100 to get the address for start32 > > Nope. The code will go 64bit in the decompresser. vmlinux should not include decompressor. or vmlinux will become vmlinuz? YH From stepan at coresystems.de Sun Nov 5 03:12:00 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 5 Nov 2006 03:12:00 +0100 Subject: [LinuxBIOS] Support for IEI Nova4899R [1] In-Reply-To: <454D395A.3020205@lfcorreia.dyndns.org> References: <454CFA15.3080501@lfcorreia.dyndns.org> <13426df10611041640o2008c16fj21ccfb55fe0c8929@mail.gmail.com> <454D395A.3020205@lfcorreia.dyndns.org> Message-ID: <20061105021200.GA5020@coresystems.de> * Luis Correia [061105 02:07]: > I've managed to reduce the overall size of the bios and added the original > VGA bios rom. But my guess (from reading the archives) that VSA is still > not supported and such, my hopes of seeing any image on teh VGA screen are > now even more reduced... VSA is supported since the OLPC. -- 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 Sun Nov 5 03:44:30 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 02:44:30 -0000 Subject: [LinuxBIOS] #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M Message-ID: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M ----------------------------+----------------------------------------------- Reporter: uwe | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: flashrom | Version: v2 Keywords: | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Due_close: MM/DD/YYYY | ----------------------------+----------------------------------------------- Add support for Intel PIIX4/PIIX4E/PIIX4M based mainboards to flashrom. Tested on real hardware, reading, detecting and writing various chips works. Signed-off-by: Uwe Hermann --- Just curious: in the datasheet I see three BIOS-related bits, "Lower BIOS Enable", "Extended BIOS Enable", and "1-Meg Extended BIOS Enable". I only enabled the "Extended BIOS Enable" (FFF80000-FFFDFFFF); do I need to touch one of the others, too? -- Ticket URL: LinuxBIOS From ebiederm at xmission.com Sun Nov 5 03:46:56 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Sat, 04 Nov 2006 19:46:56 -0700 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage In-Reply-To: <2ea3fae10611041756w25975ca5o3a9facc726378ecd@mail.gmail.com> (yinghailu@gmail.com's message of "Sat, 4 Nov 2006 17:56:39 -0800") References: <5986589C150B2F49A46483AC44C7BCA412D7AE@ssvlexmb2.amd.com> <2ea3fae10611040902g6038bf05k7e06a31923b7036a@mail.gmail.com> <2ea3fae10611041239h637cd0d9s3716dc950193bb10@mail.gmail.com> <2ea3fae10611041756w25975ca5o3a9facc726378ecd@mail.gmail.com> Message-ID: yhlu writes: > On 11/4/06, Eric W. Biederman wrote: >> > >> > Then you will need 64bit boot loader. >> >> If you are booting vmlinux yes. > > Wow? what happened? Nothing. That is just where it looks like vmlinux on x86_64 is going. There are two separate conversations to take it there. >> > Or can I use entrypoint for start64-0x100 to get the address for start32 >> >> Nope. The code will go 64bit in the decompresser. > > vmlinux should not include decompressor. or vmlinux will become vmlinuz? The standard thing to boot is bzImage. Like I said the 32bit entry point is really not supported for vmlinux on x86_64 please don't count on it being there. bzImage will shortly also become ELF but that is another story... Eric From yinghailu at gmail.com Sun Nov 5 04:21:29 2006 From: yinghailu at gmail.com (yhlu) Date: Sat, 4 Nov 2006 19:21:29 -0800 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA412D7AE@ssvlexmb2.amd.com> <2ea3fae10611040902g6038bf05k7e06a31923b7036a@mail.gmail.com> <2ea3fae10611041239h637cd0d9s3716dc950193bb10@mail.gmail.com> <2ea3fae10611041756w25975ca5o3a9facc726378ecd@mail.gmail.com> Message-ID: <2ea3fae10611041921h5d453fbao90b21e9bb793e1e@mail.gmail.com> for x86_64 there will be vmlinux and bzImage. current vmlinux entry point is startup_32, bzImage will be in elf64, and together with vmlinux will not have startup_32. So we must use 64bit boot loader. Do we have 64bit boot loader except kexec? but question is for AP, you will still need from 16bit(trampoline.S)-->32bit(startup_32 in head.S )-->64bit (startup_64 in head.S). are you going to move startup_32 to trampoline.S? YH On 11/4/06, Eric W. Biederman wrote: > yhlu writes: > > > On 11/4/06, Eric W. Biederman wrote: > >> > > >> > Then you will need 64bit boot loader. > >> > >> If you are booting vmlinux yes. > > > > Wow? what happened? > > Nothing. That is just where it looks like vmlinux on x86_64 is going. > There are two separate conversations to take it there. > > >> > Or can I use entrypoint for start64-0x100 to get the address for start32 > >> > >> Nope. The code will go 64bit in the decompresser. > > > > vmlinux should not include decompressor. or vmlinux will become vmlinuz? > > The standard thing to boot is bzImage. > > Like I said the 32bit entry point is really not supported for vmlinux on x86_64 > please don't count on it being there. > > bzImage will shortly also become ELF but that is another story... > > Eric > From stuge-linuxbios at cdy.org Sun Nov 5 04:35:35 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Sun, 5 Nov 2006 04:35:35 +0100 Subject: [LinuxBIOS] #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M In-Reply-To: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> References: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> Message-ID: <20061105033535.1862.qmail@cdy.org> I don't work well with web applications but tried submitting a note via trac anyway, only to be rejected as potential spam, according to "Akismet". I would love some way to interact with trac that is not web based. Does anyone know? On Sun, Nov 05, 2006 at 02:44:30AM -0000, LinuxBIOS wrote: > Just curious: in the datasheet I see three BIOS-related bits, "Lower > BIOS Enable", "Extended BIOS Enable", and "1-Meg Extended BIOS > Enable". > > I only enabled the "Extended BIOS Enable" (FFF80000-FFFDFFFF); do I > need to touch one of the others, too? That enables top-512kb -> top-128k so I think you'll want to touch more bits. 1-Meg sounds good. What is Lower? //Peter From segher at kernel.crashing.org Sun Nov 5 04:35:54 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 5 Nov 2006 04:35:54 +0100 Subject: [LinuxBIOS] #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M In-Reply-To: <20061105033535.1862.qmail@cdy.org> References: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> <20061105033535.1862.qmail@cdy.org> Message-ID: > I don't work well with web applications but tried submitting a note > via trac anyway, only to be rejected as potential spam, according to > "Akismet". I would love some way to interact with trac that is not > web based. Does anyone know? I don't know but I'd sure like it. >> Just curious: in the datasheet I see three BIOS-related bits, "Lower >> BIOS Enable", "Extended BIOS Enable", and "1-Meg Extended BIOS >> Enable". >> >> I only enabled the "Extended BIOS Enable" (FFF80000-FFFDFFFF); do I >> need to touch one of the others, too? > > That enables top-512kb -> top-128k so I think you'll want to touch > more bits. 1-Meg sounds good. What is Lower? Sounds like the legacy BIOS range at e00000..fffff, aliased to fffe0000..ffffffff (or aliased the other way around, whatever). One bit gives you access to 128kB ROM space, two gets you 512kB, all three makes 1MB. Enable all you need to map your flash but not more (as it eats address space and potentially even DRAM). In the flashrom tool you probably want to enable as large a window as possible of course. Segher From ebiederm at xmission.com Sun Nov 5 04:46:54 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Sat, 04 Nov 2006 20:46:54 -0700 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage In-Reply-To: <2ea3fae10611041921h5d453fbao90b21e9bb793e1e@mail.gmail.com> (yinghailu@gmail.com's message of "Sat, 4 Nov 2006 19:21:29 -0800") References: <5986589C150B2F49A46483AC44C7BCA412D7AE@ssvlexmb2.amd.com> <2ea3fae10611040902g6038bf05k7e06a31923b7036a@mail.gmail.com> <2ea3fae10611041239h637cd0d9s3716dc950193bb10@mail.gmail.com> <2ea3fae10611041756w25975ca5o3a9facc726378ecd@mail.gmail.com> <2ea3fae10611041921h5d453fbao90b21e9bb793e1e@mail.gmail.com> Message-ID: yhlu writes: > for x86_64 there will be vmlinux and bzImage. > current vmlinux entry point is startup_32, > bzImage will be in elf64, and together with vmlinux will not have startup_32. > > So we must use 64bit boot loader. Do we have 64bit boot loader except kexec? Etherboot qualifies. It at least has the necessary code to switch into 64bit mode if it hasn't bit rotted since I added it. > but question is for AP, you will still need from > 16bit(trampoline.S)-->32bit(startup_32 in head.S )-->64bit (startup_64 > in head.S). > > are you going to move startup_32 to trampoline.S? Yes. Because it allows startup_64 to be above 4G. Eric From yinghailu at gmail.com Sun Nov 5 05:33:56 2006 From: yinghailu at gmail.com (yhlu) Date: Sat, 4 Nov 2006 20:33:56 -0800 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA412D7AE@ssvlexmb2.amd.com> <2ea3fae10611040902g6038bf05k7e06a31923b7036a@mail.gmail.com> <2ea3fae10611041239h637cd0d9s3716dc950193bb10@mail.gmail.com> <2ea3fae10611041756w25975ca5o3a9facc726378ecd@mail.gmail.com> <2ea3fae10611041921h5d453fbao90b21e9bb793e1e@mail.gmail.com> Message-ID: <2ea3fae10611042033r7fe4d03fj3022efd73e222432@mail.gmail.com> more worse latest one put startup_32 to 0x200000. and mkelfImage is harded code to call startup_32 or other entry_point in bzImage at 0x100000. # Jump to the linux kernel ljmp $ PROT_CODE_SEG , $ 0x100000 need to make head.S to get into 64bit and use real entry pointer by vmlinux and bzImage in elf64 format. YH yhlunb:/home/yhlu/xxx/xx/kernel/linux-2.6 # readelf -hl vmlinux ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x200100 Start of program headers: 64 (bytes into file) Start of section headers: 7192496 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 5 Size of section headers: 64 (bytes) Number of section headers: 42 Section header string table index: 39 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000100000 0xffffffff80200000 0x0000000000200000 0x000000000032f508 0x000000000032f508 R E 100000 LOAD 0x0000000000430000 0xffffffff80530000 0x0000000000530000 0x0000000000148ec8 0x0000000000148ec8 RWE 100000 LOAD 0x0000000000600000 0xffffffffff600000 0x0000000000679000 0x0000000000000c08 0x0000000000000c08 RWE 100000 LOAD 0x000000000067a000 0xffffffff8067a000 0x000000000067a000 0x000000000005dd68 0x00000000000e91c8 RWE 100000 NOTE 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 R 8 From ebiederm at xmission.com Sun Nov 5 06:51:06 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Sat, 04 Nov 2006 22:51:06 -0700 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage In-Reply-To: <2ea3fae10611042033r7fe4d03fj3022efd73e222432@mail.gmail.com> (yinghailu@gmail.com's message of "Sat, 4 Nov 2006 20:33:56 -0800") References: <5986589C150B2F49A46483AC44C7BCA412D7AE@ssvlexmb2.amd.com> <2ea3fae10611040902g6038bf05k7e06a31923b7036a@mail.gmail.com> <2ea3fae10611041239h637cd0d9s3716dc950193bb10@mail.gmail.com> <2ea3fae10611041756w25975ca5o3a9facc726378ecd@mail.gmail.com> <2ea3fae10611041921h5d453fbao90b21e9bb793e1e@mail.gmail.com> <2ea3fae10611042033r7fe4d03fj3022efd73e222432@mail.gmail.com> Message-ID: yhlu writes: > more worse latest one put startup_32 to 0x200000. > > and mkelfImage is harded code to call startup_32 or other entry_point > in bzImage at 0x100000. > # Jump to the linux kernel > ljmp $ PROT_CODE_SEG , $ 0x100000 > > need to make head.S to get into 64bit and use real entry pointer by > vmlinux and bzImage in elf64 format. 1M for bzImage remains fine. All bootloaders would break if you changed that. But for vmlinux you pretty much have it nailed. Eric From yinghailu at gmail.com Sun Nov 5 08:05:57 2006 From: yinghailu at gmail.com (yhlu) Date: Sat, 4 Nov 2006 23:05:57 -0800 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA412D7AE@ssvlexmb2.amd.com> <2ea3fae10611041239h637cd0d9s3716dc950193bb10@mail.gmail.com> <2ea3fae10611041756w25975ca5o3a9facc726378ecd@mail.gmail.com> <2ea3fae10611041921h5d453fbao90b21e9bb793e1e@mail.gmail.com> <2ea3fae10611042033r7fe4d03fj3022efd73e222432@mail.gmail.com> Message-ID: <2ea3fae10611042305i4e6a05f8yba2cfab323ab3fd7@mail.gmail.com> On 11/4/06, Eric W. Biederman wrote: > 1M for bzImage remains fine. All bootloaders would break if you > changed that. But for vmlinux you pretty much have it nailed. Actually, we only mkelfImage with bzImage before we are trying to use lzma to compress elf (tiny kernel vmlinux + uncompressed). lzma can get 5% more space than bz2. I hope you can keep startup_32 in your new arch/x86_64/kernel/head.S. then we don't need to switch from 32bit mode to 64 bit mode in head.s of mkelfImage. and still convert 64elf to 32bit elf. Also it would make other 32 bit bootloader still can load vmlinux64. Then we only need to make sure head.s of mkelfImage can get correct entry_point. Or we need to make elfboot in LinuxBIOS to be 64elf aware, and it need to switch 64bit before load 64bit elf. YH From haiqiang2linux at yahoo.com Sun Nov 5 11:34:42 2006 From: haiqiang2linux at yahoo.com (Li Haiqiang) Date: Sun, 5 Nov 2006 02:34:42 -0800 (PST) Subject: [LinuxBIOS] Hello, I have a problem to put the linuxbios on my mainboard ms6163. Message-ID: <20061105103442.74909.qmail@web56004.mail.re3.yahoo.com> My mainboard's northbridge is i440bx, southbridge is i82371eb, superio is w83977ef, cpu is pentium III 450MHz(slot 1). I use the asus/p2b 's config file to build the linuxbios, but it stopped at debug code 0x12. The last debug string is "Copying LinuxBIOS to ram. Jumping to LinuxBIOS.", then it stopped. Can you help solve the problem? I find the most files in the asus/p2b are copied from via/epia?? -------------- next part -------------- An HTML attachment was scrubbed... URL: From stepan at coresystems.de Sun Nov 5 12:52:19 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 5 Nov 2006 12:52:19 +0100 Subject: [LinuxBIOS] Hello, I have a problem to put the linuxbios on my mainboard ms6163. In-Reply-To: <20061105103442.74909.qmail@web56004.mail.re3.yahoo.com> References: <20061105103442.74909.qmail@web56004.mail.re3.yahoo.com> Message-ID: <20061105115219.GA17235@coresystems.de> * Li Haiqiang [061105 11:34]: > My mainboard's northbridge is i440bx, southbridge is i82371eb, superio is > w83977ef, cpu is pentium III 450MHz(slot 1). > I use the asus/p2b 's config file to build the linuxbios, but it stopped at > debug code 0x12. > The last debug string is "Copying LinuxBIOS to ram. > Jumping to LinuxBIOS.", then it stopped. > Can you help solve the problem? > I find the most files in the asus/p2b are copied from via/epia?? Yes, DRAM init is not yet working for the i440BX. Can you send the complete serial output to the list? Not sure how much is actually missing to get this working. 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 Sun Nov 5 12:57:59 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 5 Nov 2006 12:57:59 +0100 Subject: [LinuxBIOS] #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M In-Reply-To: <20061105033535.1862.qmail@cdy.org> References: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> <20061105033535.1862.qmail@cdy.org> Message-ID: <20061105115759.GC17235@coresystems.de> * Peter Stuge [061105 04:35]: > I don't work well with web applications but tried submitting a note > via trac anyway, only to be rejected as potential spam, according to > "Akismet". I would love some way to interact with trac that is not > web based. Does anyone know? it is possible to send emails to trac-at-linuxbios.org (lets hope spammers wont find out this way. I had to disable this feature in the old tracker due to massive amounts of spam) 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 Sun Nov 5 13:00:06 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 12:00:06 -0000 Subject: [LinuxBIOS] #27: Minor typo Message-ID: <060.a9aa5063cefa73c1bcdec6d6b963b3c4@openbios.org> #27: Minor typo --------------------------------------------------------+------------------- Reporter: Luis Correia | Owner: somebody Type: enhancement | Status: new Priority: trivial | Milestone: Cosmetic fixes Component: code | Version: v2 Keywords: typo fix | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Due_close: MM/DD/YYYY | --------------------------------------------------------+------------------- [PATCH] Index: elfboot.c =================================================================== --- elfboot.c (revision 2487) +++ elfboot.c (working copy) @@ -630,7 +630,7 @@ printk_spew("NO header at %d\n", i); continue; } - printk_debug("Found ELF candiate at offset %d\n", i); + printk_debug("Found ELF candidate at offset %d\n", i); /* Sanity check the elf header */ if ((ehdr->e_type == ET_EXEC) && elf_check_arch(ehdr) && -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 13:05:47 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 12:05:47 -0000 Subject: [LinuxBIOS] #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M In-Reply-To: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> References: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> Message-ID: <069.9ba512c22612d9d02ffb36709a783685@openbios.org> #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M -----------------------------+---------------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: new Priority: major | Milestone: Component: flashrom | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY -----------------------------+---------------------------------------------- Changes (by stepan): * owner: somebody => uwe Comment: It reads register 4e. Are you sure its not just the enable_flash_ich_4e() function that most other chipsets are using? Please remember: when testing this you need to test from cold start because flashrom does not reset the registers to their original state. Also, FFF80000-FFFDFFFF is not enough. You need to enable the range from FFFE0000-FFFFFFFF as well. Ignore the "Lower BIOS Enable" stuff. This is only required for 16bit operating systems and a really ugly mess. -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 13:13:38 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 12:13:38 -0000 Subject: [LinuxBIOS] #27: Minor typo In-Reply-To: <060.a9aa5063cefa73c1bcdec6d6b963b3c4@openbios.org> References: <060.a9aa5063cefa73c1bcdec6d6b963b3c4@openbios.org> Message-ID: <069.54bb5b3b9e2accc9aeaa80f6ccd85296@openbios.org> #27: Minor typo ---------------------------------------------------------+------------------ Reporter: Luis Correia | Owner: somebody Type: enhancement | Status: new Priority: trivial | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: | Keywords: typo fix Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY ---------------------------------------------------------+------------------ Comment (by Luis Correia ): Replying to [ticket:27 Luis Correia ]: > [PATCH] > Index: elfboot.c > =================================================================== > --- elfboot.c (revision 2487) > +++ elfboot.c (working copy) > @@ -630,7 +630,7 @@ > printk_spew("NO header at %d\n", i); > continue; > } > - printk_debug("Found ELF candiate at offset %d\n", i); > + printk_debug("Found ELF candidate at offset %d\n", i); > /* Sanity check the elf header */ > if ((ehdr->e_type == ET_EXEC) && > elf_check_arch(ehdr) && Signed-off-by: Luis Correia -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 13:19:00 2006 From: svn at openbios.org (svn at openbios.org) Date: Sun, 05 Nov 2006 12:19:00 -0000 Subject: [LinuxBIOS] r2488 - trunk/LinuxBIOSv2/src/boot Message-ID: Author: stepan Date: 2006-11-05 13:18:58 +0100 (Sun, 05 Nov 2006) New Revision: 2488 Modified: trunk/LinuxBIOSv2/src/boot/elfboot.c Log: Fix a typo in elfboot.c. Closes #27 Signed-off-by: Luis Correia Acked-by: Stefan Reinauer Modified: trunk/LinuxBIOSv2/src/boot/elfboot.c =================================================================== --- trunk/LinuxBIOSv2/src/boot/elfboot.c 2006-11-04 23:19:00 UTC (rev 2487) +++ trunk/LinuxBIOSv2/src/boot/elfboot.c 2006-11-05 12:18:58 UTC (rev 2488) @@ -630,7 +630,7 @@ printk_spew("NO header at %d\n", i); continue; } - printk_debug("Found ELF candiate at offset %d\n", i); + printk_debug("Found ELF candidate at offset %d\n", i); /* Sanity check the elf header */ if ((ehdr->e_type == ET_EXEC) && elf_check_arch(ehdr) && From lfcorreia at lfcorreia.dyndns.org Sun Nov 5 13:35:15 2006 From: lfcorreia at lfcorreia.dyndns.org (Luis Correia) Date: Sun, 05 Nov 2006 12:35:15 +0000 Subject: [LinuxBIOS] Support for IEI Nova4899R [1] In-Reply-To: <20061105021200.GA5020@coresystems.de> References: <454CFA15.3080501@lfcorreia.dyndns.org> <13426df10611041640o2008c16fj21ccfb55fe0c8929@mail.gmail.com> <454D395A.3020205@lfcorreia.dyndns.org> <20061105021200.GA5020@coresystems.de> Message-ID: <454DDA83.8040401@lfcorreia.dyndns.org> Stefan Reinauer wrote: > * Luis Correia [061105 02:07]: > >> I've managed to reduce the overall size of the bios and added the original >> VGA bios rom. But my guess (from reading the archives) that VSA is still >> not supported and such, my hopes of seeing any image on teh VGA screen are >> now even more reduced... >> > > VSA is supported since the OLPC. > > Ok, got it. Managed to reduce Linuxbios and filo payload sizes to fit into 96k and prepended the VGA and VSA bios code in order to create a 256k rom. It still boots as before but to change was made in relation to the VGA activation. From the OLPC code i can't figure out how to properly activate VSA, any hints? p.s. flashrom works fine in this motherboard Luis Correia -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From stepan at coresystems.de Sun Nov 5 13:40:12 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 5 Nov 2006 13:40:12 +0100 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage In-Reply-To: <2ea3fae10611042305i4e6a05f8yba2cfab323ab3fd7@mail.gmail.com> References: <2ea3fae10611041239h637cd0d9s3716dc950193bb10@mail.gmail.com> <2ea3fae10611041756w25975ca5o3a9facc726378ecd@mail.gmail.com> <2ea3fae10611041921h5d453fbao90b21e9bb793e1e@mail.gmail.com> <2ea3fae10611042033r7fe4d03fj3022efd73e222432@mail.gmail.com> <2ea3fae10611042305i4e6a05f8yba2cfab323ab3fd7@mail.gmail.com> Message-ID: <20061105124012.GA5110@coresystems.de> * yhlu [061105 08:05]: > I hope you can keep startup_32 in your new arch/x86_64/kernel/head.S. > then we don't need to switch from 32bit mode to 64 bit mode in head.s > of mkelfImage. and still convert 64elf to 32bit elf. Also it would > make other 32 bit bootloader still can load vmlinux64. Are we not going to switch to 64bit mode in LinuxBIOS anyways? Then we just need a 64bit version of mkelfimage. > Or we need to make elfboot in LinuxBIOS to be 64elf aware, and it need > to switch 64bit before load 64bit elf. This is the preferred thing I guess, because it will allow us to use other 64bit payloads as well without requiring that they do the same weird 32->64bit trampolining as Linux does... -- 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 Sun Nov 5 15:49:41 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 14:49:41 -0000 Subject: [LinuxBIOS] #28: Finish Intel 440BX port Message-ID: <060.01473e4e80de4582a0ff0c94985dda64@openbios.org> #28: Finish Intel 440BX port ---------------------------+------------------------------------------------ Reporter: uwe | Owner: somebody Type: task | Status: new Priority: critical | Milestone: Going mainstream Component: code | Version: v2 Keywords: | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Due_close: MM/DD/YYYY | ---------------------------+------------------------------------------------ There have been a _lot_ of requests for 440BX-based mainboards in the past, so this chipset seems to be really popular and we should support it. -- Ticket URL: LinuxBIOS From ebiederm at xmission.com Sun Nov 5 16:05:09 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Sun, 05 Nov 2006 08:05:09 -0700 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage In-Reply-To: <2ea3fae10611042305i4e6a05f8yba2cfab323ab3fd7@mail.gmail.com> (yinghailu@gmail.com's message of "Sat, 4 Nov 2006 23:05:57 -0800") References: <5986589C150B2F49A46483AC44C7BCA412D7AE@ssvlexmb2.amd.com> <2ea3fae10611041239h637cd0d9s3716dc950193bb10@mail.gmail.com> <2ea3fae10611041756w25975ca5o3a9facc726378ecd@mail.gmail.com> <2ea3fae10611041921h5d453fbao90b21e9bb793e1e@mail.gmail.com> <2ea3fae10611042033r7fe4d03fj3022efd73e222432@mail.gmail.com> <2ea3fae10611042305i4e6a05f8yba2cfab323ab3fd7@mail.gmail.com> Message-ID: yhlu writes: > On 11/4/06, Eric W. Biederman wrote: >> 1M for bzImage remains fine. All bootloaders would break if you >> changed that. But for vmlinux you pretty much have it nailed. > > Actually, we only mkelfImage with bzImage before we are trying to use > lzma to compress elf (tiny kernel vmlinux + uncompressed). lzma can > get 5% more space than bz2. First a decode of letters, in bzImage the b stands for big and the z stands for gzip. We don't have a bzip2 decompressor in there. An interesting question is if we make a bImage target that does everything except the decompression (because nothing would be compressed) would that suit your needs? > I hope you can keep startup_32 in your new arch/x86_64/kernel/head.S. > then we don't need to switch from 32bit mode to 64 bit mode in head.s > of mkelfImage. and still convert 64elf to 32bit elf. Also it would > make other 32 bit bootloader still can load vmlinux64. > Then we only need to make sure head.s of mkelfImage can get correct entry_point. Hacks like that are a support pain. I don't have a problem with weird magic compatibility glue in the bzImage format but I don't want to introduce another one. > Or we need to make elfboot in LinuxBIOS to be 64elf aware, and it need > to switch 64bit before load 64bit elf. At least before we jump to the 64bit elf. For size the 32bit kernel should be smaller, so I don't understand the interest in the 64bit kernel at this point. If we do the 32/64bit transition at the last moment like etherboot does this requires about 100-200 extra lines of code. Eric From svn at openbios.org Sun Nov 5 16:10:24 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 15:10:24 -0000 Subject: [LinuxBIOS] #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M In-Reply-To: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> References: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> Message-ID: <069.8f7fc7eaf25506fe0fdcfe7ebfcc96df@openbios.org> #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M -----------------------------+---------------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: new Priority: major | Milestone: Component: flashrom | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY -----------------------------+---------------------------------------------- Comment (by rsmith): Replying to [comment:1 stepan]: > Also, FFF80000-FFFDFFFF is not enough. You need to enable the range from FFFE0000-FFFFFFFF as well. As pointed out you should just enable the full 1-Meg space. Several of those settings are jsut for the legacy alias into the lower 1 Meg of address space. Since we don't have that legacy baggage you can just eanble the entire upper 1 Meg (0xfff00000- 0xffffffff). And let flashrom mmap it. -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 16:19:14 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 15:19:14 -0000 Subject: [LinuxBIOS] #28: Finish Intel 440BX port In-Reply-To: <060.01473e4e80de4582a0ff0c94985dda64@openbios.org> References: <060.01473e4e80de4582a0ff0c94985dda64@openbios.org> Message-ID: <069.a90a6151de1f15a74474bd80db315874@openbios.org> #28: Finish Intel 440BX port ----------------------------+----------------------------------------------- Reporter: uwe | Owner: somebody Type: task | Status: new Priority: critical | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY ----------------------------+----------------------------------------------- Comment (by rsmith): Replying to [ticket:28 uwe]: > There have been a _lot_ of requests for 440BX-based mainboards in the past, so this chipset seems to be really popular and we should support it. So far it seems to have only been user requests. :( And the one developer who has a 440bx setup can't seem to find any time to work on it. I've outlined what needs to be done a few times. Seriously, its in the top of my to do stack. But I'm a bit bandlimited still. Also complicated by the fact that I don't have all my previous tools handy anymore. It wont be until I get up to Boston that I can start aquiring new tools. So if nobody else steps up to the plate then I can hopfully get to this in January or 07. -- Ticket URL: LinuxBIOS From ebiederm at xmission.com Sun Nov 5 16:24:44 2006 From: ebiederm at xmission.com (Eric W. Biederman) Date: Sun, 05 Nov 2006 08:24:44 -0700 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage In-Reply-To: <20061105124012.GA5110@coresystems.de> (Stefan Reinauer's message of "Sun, 5 Nov 2006 13:40:12 +0100") References: <2ea3fae10611041239h637cd0d9s3716dc950193bb10@mail.gmail.com> <2ea3fae10611041756w25975ca5o3a9facc726378ecd@mail.gmail.com> <2ea3fae10611041921h5d453fbao90b21e9bb793e1e@mail.gmail.com> <2ea3fae10611042033r7fe4d03fj3022efd73e222432@mail.gmail.com> <2ea3fae10611042305i4e6a05f8yba2cfab323ab3fd7@mail.gmail.com> <20061105124012.GA5110@coresystems.de> Message-ID: Stefan Reinauer writes: >> Or we need to make elfboot in LinuxBIOS to be 64elf aware, and it need >> to switch 64bit before load 64bit elf. > > This is the preferred thing I guess, because it will allow us to use > other 64bit payloads as well without requiring that they do the same > weird 32->64bit trampolining as Linux does... Yes. Not imposing hacks on other solutions is nice. Linux is important enough we can jump through hoops to get it loaded we shouldn't need that for other things. Eric From svn at openbios.org Sun Nov 5 16:43:58 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 15:43:58 -0000 Subject: [LinuxBIOS] #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M In-Reply-To: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> References: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> Message-ID: <069.4a31120907fa7011a9cf089b1b543233@openbios.org> #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M -----------------------------+---------------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: assigned Priority: major | Milestone: Component: flashrom | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY -----------------------------+---------------------------------------------- Changes (by uwe): * status: new => assigned Comment: Replying to [comment:1 stepan]: > It reads register 4e. Are you sure its not just the enable_flash_ich_4e() function that most other chipsets are using? Yes. The 0x4e is the same, but on the PIIX4 it's called XBCS instead of BIOS_CNTL and the bits have completely different meanings. > Please remember: when testing this you need to test from cold start because flashrom does not reset the registers to their original state. Thanks, will redo some tests from cold start. -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 16:51:34 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 15:51:34 -0000 Subject: [LinuxBIOS] #29: this is a captcha test Message-ID: <060.ca520007e3ca25a907b60a83b34b12a2@openbios.org> #29: this is a captcha test ---------------------------+------------------------------------------------ Reporter: anonymous | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Keywords: | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Due_close: MM/DD/YYYY | ---------------------------+------------------------------------------------ sorry for the inconvenience -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 17:04:46 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 16:04:46 -0000 Subject: [LinuxBIOS] #29: this is a captcha test In-Reply-To: <060.ca520007e3ca25a907b60a83b34b12a2@openbios.org> References: <060.ca520007e3ca25a907b60a83b34b12a2@openbios.org> Message-ID: <069.83604f36c03d8fd1b2bf7b66141ac116@openbios.org> #29: this is a captcha test ----------------------------+----------------------------------------------- Reporter: anonymous | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY ----------------------------+----------------------------------------------- Comment (by anonymous): test -- Ticket URL: LinuxBIOS From smithbone at gmail.com Sun Nov 5 17:07:58 2006 From: smithbone at gmail.com (Richard Smith) Date: Sun, 05 Nov 2006 10:07:58 -0600 Subject: [LinuxBIOS] 440bx stuff Message-ID: <454E0C5E.3020501@gmail.com> Thinking about this some more, whats needed is a lot of grunt work that doesn't necessarily have to be done by the same person who fixes the ram init code. Here's TODO from my past emails.. > 1. I named both the northbridge and the southbridge i440bx. While I > don't think it s a huge problem. The southbridge code needs to be > changed to piix4 since thats really what the part is. I'll hopefully > be able to do that soon. This has been done. It's now i82371eb. > 2. I seemed to have based the framework on one of the VIA chips. But > looking at things now I see a much better choice would have been the > Intel e7501. Hopefully I can find some time to work on this a bit > this week. This still outstanding. If someone is feeling spunky they could go through the code re-do most of the stuff thats there. The only thing functional in the current code is the boot stuff and the core SPD read functions, everything else is up for grabs. Its possible, (but I won't promise anything) that if someone were to get the framework all setup that I could come in and spend an hour or 2 comparing the ram init code to V1 and fixup the missing details. One thing that can be done that doesn't require you to grok the ram init code but is still necessary is verifying the SPD support code functions are spiting out the right values. The e7501 raminit code is _very_ well commented and pretty easy to follow even if you don't understand whats happening. A lot of the registers also seem very familiar to what I remember from the 440bx data sheet. So the first step here is to start patching in the e7501 code and auditing it against the 440bx datasheet and V1 and then checking to see if the sane values are popping out of the various spd_support functions. Things like number of dram sticks installed, what the min cas timing is across all sticks, etc. None of this is really hard just very time consuming. That would go a _long_ way in helping me make this chipset fly again. -- Richard A. Smith From yinghailu at gmail.com Sun Nov 5 18:09:49 2006 From: yinghailu at gmail.com (yhlu) Date: Sun, 5 Nov 2006 09:09:49 -0800 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA412D7AE@ssvlexmb2.amd.com> <2ea3fae10611041756w25975ca5o3a9facc726378ecd@mail.gmail.com> <2ea3fae10611041921h5d453fbao90b21e9bb793e1e@mail.gmail.com> <2ea3fae10611042033r7fe4d03fj3022efd73e222432@mail.gmail.com> <2ea3fae10611042305i4e6a05f8yba2cfab323ab3fd7@mail.gmail.com> Message-ID: <2ea3fae10611050909pe9277dbo87194b68f4657eb2@mail.gmail.com> On 11/5/06, Eric W. Biederman wrote: > First a decode of letters, in bzImage the b stands for big and the > z stands for gzip. We don't have a bzip2 decompressor in there. Thanks for the explanation... > > An interesting question is if we make a bImage target that does everything > except the decompression (because nothing would be compressed) would that > suit your needs? That could be good for us. > > > Hacks like that are a support pain. I don't have a problem with weird > magic compatibility glue in the bzImage format but I don't want to introduce > another one. But it seems that current boot loader only use first program header's p_addr? > At least before we jump to the 64bit elf. For size the 32bit kernel should > be smaller, so I don't understand the interest in the 64bit kernel at this > point. If we do the 32/64bit transition at the last moment like etherboot > does this requires about 100-200 extra lines of code. that 256 byte code could be done in elfboot, or head.s of mkelfImage. A: elfboot (not 64bit aware) ---> 32bit elf --->64 bit kernel (head.S startup_32 then startup_64) B: elfboot (not 64bit aware) ---> 32bit elf ( elf do the 32->64 transition) --->64 bit kernel (startup_64) C: elfboot (64bit aware, switch to 64bit) ---> 64bit elf --->64 bit kernel (startup_64) the A is less work in all. the reason for using 64bit kernel: 1. don't want to dig i386 arch together with final x86_64 2. for 64bit resource support, the 32bit kernel will ignore or clear that resource. YH From yinghailu at gmail.com Sun Nov 5 18:15:35 2006 From: yinghailu at gmail.com (yhlu) Date: Sun, 5 Nov 2006 09:15:35 -0800 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage In-Reply-To: <20061105124012.GA5110@coresystems.de> References: <2ea3fae10611041756w25975ca5o3a9facc726378ecd@mail.gmail.com> <2ea3fae10611041921h5d453fbao90b21e9bb793e1e@mail.gmail.com> <2ea3fae10611042033r7fe4d03fj3022efd73e222432@mail.gmail.com> <2ea3fae10611042305i4e6a05f8yba2cfab323ab3fd7@mail.gmail.com> <20061105124012.GA5110@coresystems.de> Message-ID: <2ea3fae10611050915s5ee10f4g379c5b7f997dc18e@mail.gmail.com> On 11/5/06, Stefan Reinauer wrote: > Are we not going to switch to 64bit mode in LinuxBIOS anyways? Then we > just need a 64bit version of mkelfimage. Yes. actually the elf64 aware elfboot too. > > This is the preferred thing I guess, because it will allow us to use > other 64bit payloads as well without requiring that they do the same > weird 32->64bit trampolining as Linux does... depends, you could have two entries, so your payload could be loaded by 32elfboot or 64elfboot. YH From stepan at coresystems.de Sun Nov 5 18:18:06 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 5 Nov 2006 18:18:06 +0100 Subject: [LinuxBIOS] Hello, I have a problem to put the linuxbios on my mainboard ms6163. In-Reply-To: <20061105125638.20219.qmail@web56004.mail.re3.yahoo.com> References: <20061105125638.20219.qmail@web56004.mail.re3.yahoo.com> Message-ID: <20061105171806.GA10932@coresystems.de> * Li Haiqiang [061105 13:56]: > Yes, 1 sdram module installed. > But how to "Late in auto.c please enable dumping all PCI devices"? You need to run dump_pci_devices(); as last command in auto.c > lspci -xxx: > > 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge > (rev 03) > 00: 86 80 90 71 06 00 10 22 03 00 00 06 00 40 00 00 > 10: 08 00 00 e0 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 a0 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: 0c 8a 00 ff 00 00 00 09 03 10 11 01 00 00 00 00 > 60: 08 10 10 10 10 10 10 10 00 0f c0 00 00 8a 00 00 > 70: 20 1f 0a 38 05 00 03 01 26 ff 10 38 00 00 00 00 > 80: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 90: 98 22 00 00 04 61 00 00 00 05 00 00 00 00 00 00 > a0: 02 00 10 00 03 02 00 1f 00 00 00 00 00 00 00 00 > b0: 80 20 00 00 30 00 00 00 00 00 ef 07 20 10 00 00 > c0: 00 00 00 00 00 00 00 00 18 0c ff ff 67 00 00 00 > d0: 00 00 00 00 00 00 00 00 0c 00 00 00 00 00 00 00 > e0: 4c ad ff bb 8a 3e 00 80 2c d3 f7 cf 9d 3e 00 00 > f0: 40 01 00 00 00 f8 00 60 20 0f 00 00 00 00 00 00 > > 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge > (rev 03) > 00: 86 80 91 71 07 01 20 02 03 00 04 06 00 40 01 00 > 10: 00 00 00 00 00 00 00 00 00 01 01 40 d0 d0 a0 22 > 20: 00 e4 f0 e5 00 e6 f0 e7 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 88 00 > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 50: 00 00 00 00 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 00 00 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 00 00 00 00 > > 00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02) > 00: 86 80 10 71 0f 00 80 02 02 00 01 06 00 00 80 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 4d 00 30 00 > 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 60: 0b 80 05 0a 10 00 00 00 00 f2 80 00 00 00 00 00 > 70: 00 00 00 00 00 00 0c 0c 00 00 00 00 00 00 00 00 > 80: 00 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 > 90: 00 00 00 00 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: 05 00 00 f0 00 00 00 00 00 00 00 00 00 00 00 00 > c0: 00 00 00 00 00 00 00 00 00 00 00 21 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 30 0f 00 00 00 00 00 00 > > 00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) > 00: 86 80 11 71 05 00 80 02 01 80 01 01 00 40 00 00 > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 01 f0 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: 07 a3 00 80 00 00 00 00 01 00 02 00 00 00 00 00 > 50: 00 00 00 00 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 00 00 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 30 0f 00 00 00 00 00 00 > > 00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) > 00: 86 80 12 71 05 00 80 02 01 00 03 0c 00 40 00 00 > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 01 e0 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 0a 04 00 00 > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 60: 10 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 00 00 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 20 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 30 0f 00 00 00 00 00 00 > > 00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02) > 00: 86 80 13 71 03 00 80 02 02 00 80 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: 01 40 00 00 00 00 00 00 00 30 00 00 00 00 00 00 > 50: 00 58 1f 00 00 00 00 00 04 00 00 02 00 00 00 00 > 60: 94 02 83 00 00 00 00 10 71 00 10 00 00 00 00 00 > 70: 04 40 11 00 00 00 00 00 00 00 00 00 00 00 00 00 > 80: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 90: 01 50 00 00 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 09 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 30 0f 00 00 00 00 00 00 > > 00:0c.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06) > 00: 74 12 71 13 05 00 10 04 06 00 01 04 00 40 00 00 > 10: 01 e4 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 74 12 71 13 > 30: 00 00 00 00 dc 00 00 00 00 00 00 00 05 01 0c 80 > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 50: 00 00 00 00 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 00 00 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 01 00 31 6c > 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 00 00 00 00 > > 01:00.0 VGA compatible controller: nVidia Corporation NV5 [RIVA TNT2/TNT2 Pro] > (rev 11) > 00: de 10 28 00 07 00 b0 02 11 00 00 03 00 40 00 00 > 10: 00 00 00 e4 08 00 00 e6 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 48 10 28 0c > 30: 00 00 00 e5 60 00 00 00 00 00 00 00 0b 01 05 01 > 40: 48 10 28 0c 02 00 20 00 07 02 00 1f 00 00 00 00 > 50: 01 00 00 00 01 00 00 00 ce d6 23 00 0f 00 00 00 > 60: 01 44 01 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 00 00 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 00 00 00 00 > > > > > > > > ----- Original Message ---- > From: Stefan Reinauer > To: Li Haiqiang > Sent: Sunday, November 5, 2006 8:31:37 PM > Subject: Re: [LinuxBIOS] Hello, I have a problem to put the linuxbios on my > mainboard ms6163. > > [..] > > Ok. Its reading 1 SPD-ROM. Do you have 1 memory module > installed? If yes: Everything is fine here. If you have more, > we need to find out where they are. > > Next step is: Late in auto.c please enable dumping all PCI devices. > (Needs to happen after mem init) > > Then do the same thing with "lspci -xxx" as root and send ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > both to the mailing list. (Many eyes know/see more!) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- 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 Sun Nov 5 18:20:50 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 17:20:50 -0000 Subject: [LinuxBIOS] #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M In-Reply-To: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> References: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> Message-ID: <069.d5e0746cc27d920f78c01fb4b876e8d5@openbios.org> #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M -----------------------------+---------------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: assigned Priority: major | Milestone: Component: flashrom | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY -----------------------------+---------------------------------------------- Comment (by stepan): Ah, sorry. I did not check the data sheet. Just 0x4e seemed so familiar. Then make sure all of FFF80000-FFFFFFFF or, if possible all of FFF00000-FFFFFFFF is enabled and submit the patch. -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 18:33:57 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 17:33:57 -0000 Subject: [LinuxBIOS] #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M In-Reply-To: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> References: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> Message-ID: <069.fa19a064c48aa321487698f8e4611293@openbios.org> #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M -----------------------------+---------------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: assigned Priority: major | Milestone: Component: flashrom | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY -----------------------------+---------------------------------------------- Comment (by uwe): Replying to [comment:2 rsmith]: > Replying to [comment:1 stepan]: > > > Also, FFF80000-FFFDFFFF is not enough. You need to enable the range from FFFE0000-FFFFFFFF as well. > > As pointed out you should just enable the full 1-Meg space. Several of those settings are jsut for the legacy alias into the lower 1 Meg of address space. Since we don't have that legacy baggage you can just eanble the entire upper 1 Meg (0xfff00000- 0xffffffff). And let flashrom mmap it. I have now enabled all three relevant bits, which should result in all of the upper meg (I hope). It's tested from cold boot, I can detect, read, and write multiple 256K chips. I'll attach an updated patch. -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 18:41:53 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 17:41:53 -0000 Subject: [LinuxBIOS] #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M In-Reply-To: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> References: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> Message-ID: <069.f4855991493ef9ecf11797492385ee9f@openbios.org> #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M -----------------------------+---------------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: assigned Priority: major | Milestone: Component: flashrom | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY -----------------------------+---------------------------------------------- Comment (by stepan): Replying to [comment:5 uwe]: > I have now enabled all three relevant bits, which should result in all of the upper meg (I hope). It's tested from cold boot, I can detect, read, and write multiple 256K chips. I'll attach an updated patch. This looks very good to me. Acked-By: Stefan Reinauer -- Ticket URL: LinuxBIOS From uwe at hermann-uwe.de Sun Nov 5 18:50:15 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 5 Nov 2006 18:50:15 +0100 Subject: [LinuxBIOS] 440bx stuff In-Reply-To: <454E0C5E.3020501@gmail.com> References: <454E0C5E.3020501@gmail.com> Message-ID: <20061105175015.GA32414@greenwood> Hi, On Sun, Nov 05, 2006 at 10:07:58AM -0600, Richard Smith wrote: > > 1. I named both the northbridge and the southbridge i440bx. While I > > don't think it s a huge problem. The southbridge code needs to be > > changed to piix4 since thats really what the part is. I'll hopefully > > be able to do that soon. > > This has been done. It's now i82371eb. Why not 82371eb (that's the official name AFAIK)? Is there some requirement that directories have to start with a letter? > The e7501 raminit code is _very_ well commented and pretty easy to > follow even if you don't understand whats happening. A lot of the > registers also seem very familiar to what I remember from the 440bx data > sheet. I think I'll have a look at this in the next few days. But I might use the 855pm code (derived from e7501) as a basis, that looks even better. 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 Nov 5 19:26:11 2006 From: svn at openbios.org (svn at openbios.org) Date: Sun, 05 Nov 2006 18:26:11 -0000 Subject: [LinuxBIOS] r2489 - trunk/LinuxBIOSv2/util/flashrom Message-ID: Author: uwe Date: 2006-11-05 19:26:08 +0100 (Sun, 05 Nov 2006) New Revision: 2489 Modified: trunk/LinuxBIOSv2/util/flashrom/flash_enable.c Log: Add support for Intel PIIX4/PIIX4E/PIIX4M-based mainboards to flashrom. Tested on real hardware, reading, detecting and writing various chips works. Signed-off-by: Uwe Hermann Acked-by: Stefan Reinauer Modified: trunk/LinuxBIOSv2/util/flashrom/flash_enable.c =================================================================== --- trunk/LinuxBIOSv2/util/flashrom/flash_enable.c 2006-11-05 12:18:58 UTC (rev 2488) +++ trunk/LinuxBIOSv2/util/flashrom/flash_enable.c 2006-11-05 18:26:08 UTC (rev 2489) @@ -77,6 +77,37 @@ return 0; } +/* Datasheet: http://www.intel.com/design/intarch/datashts/290562.htm */ +static int enable_flash_piix4(struct pci_dev *dev, char *name) +{ + uint16_t old, new; + uint16_t xbcs = 0x4e; /* X-Bus Chip Select register. */ + + old = pci_read_word(dev, xbcs); + + /* Set bit 9: 1-Meg Extended BIOS Enable (PCI master accesses to + FFF00000-FFF7FFFF are forwarded to ISA). + Set bit 7: Extended BIOS Enable (PCI master accesses to + FFF80000-FFFDFFFF are forwarded to ISA). + Set bit 6: Lower BIOS Enable (PCI master, or ISA master accesses to + the lower 64-Kbyte BIOS block (E00000?EFFFF) at the top + of 1 Mbyte, or the aliases at the top of 4 Gbyte + (FFFE0000-FFFEFFF) result in the generation of BIOSCS#. + Set bit 2: BIOSCS# Write Protect Enable (1=enable, 0=disable). */ + new = old | 0x2c4; + + if (new == old) + return 0; + + pci_write_word(dev, xbcs, new); + + if (pci_read_word(dev, xbcs) != new) { + printf("tried to set 0x%x to 0x%x on %s failed (WARNING ONLY)\n", xbcs, new, name); + return -1; + } + return 0; +} + static int enable_flash_ich(struct pci_dev *dev, char *name, int bios_cntl) { /* register 4e.b gets or'ed with one */ @@ -362,6 +393,7 @@ static FLASH_ENABLE enables[] = { {0x1039, 0x0630, "SIS630", enable_flash_sis630}, + {0x8086, 0x7110, "PIIX4/PIIX4E/PIIX4M", enable_flash_piix4}, {0x8086, 0x2410, "ICH", enable_flash_ich_4e}, {0x8086, 0x2420, "ICH0", enable_flash_ich_4e}, {0x8086, 0x2440, "ICH2", enable_flash_ich_4e}, From svn at openbios.org Sun Nov 5 19:26:53 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 18:26:53 -0000 Subject: [LinuxBIOS] #20: Cleanup of all CHIP_NAME() entries In-Reply-To: <060.68503be5d6132cbfcbc83dcf54946a9a@openbios.org> References: <060.68503be5d6132cbfcbc83dcf54946a9a@openbios.org> Message-ID: <069.506ea890d1417cba93af4e3503dcd0ab@openbios.org> #20: Cleanup of all CHIP_NAME() entries ----------------------------+----------------------------------------------- Reporter: uwe | Owner: uwe Type: defect | Status: new Priority: minor | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: DD/MM/YYYY | Due_close: DD/MM/YYYY ----------------------------+----------------------------------------------- Comment (by stepan): In my opinion we should go further and drop the CHIP_NAME macro completely. So instead of CHIP_NAME("Via VT8263") it should just read "Via VT8263" The CHIP_NAME macro was invented at a time when we were really tight in rom space, but it is obviously the wrong approach. Otherwise: Acked-by: Stefan Reinauer -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 19:27:36 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 18:27:36 -0000 Subject: [LinuxBIOS] #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M In-Reply-To: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> References: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> Message-ID: <069.b6bd6d1e281edb0e377f0a083cb8d38d@openbios.org> #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M -----------------------------+---------------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: closed Priority: major | Milestone: Component: flashrom | Version: v2 Resolution: fixed | Keywords: Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY -----------------------------+---------------------------------------------- Changes (by uwe): * status: assigned => closed * resolution: => fixed Comment: Fixed in [2489]. -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 19:29:12 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 18:29:12 -0000 Subject: [LinuxBIOS] #14: Rename "stream" to "payload" In-Reply-To: <060.7ce253b9ecf6e23e1d409c7624ff96d8@openbios.org> References: <060.7ce253b9ecf6e23e1d409c7624ff96d8@openbios.org> Message-ID: <069.d49bb76d4a2ce8387659e4ca3b18e54b@openbios.org> #14: Rename "stream" to "payload" -----------------------------+---------------------------------------------- Reporter: uwe | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: #22 Due_assign: DD/MM/YYYY | Due_close: DD/MM/YYYY -----------------------------+---------------------------------------------- Comment (by stepan): Acked-By: Stefan Reinauer -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 19:32:21 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 18:32:21 -0000 Subject: [LinuxBIOS] #22: sed error in abuild In-Reply-To: <060.5c46f9c57a78cecc432ab4e830a2d4dc@openbios.org> References: <060.5c46f9c57a78cecc432ab4e830a2d4dc@openbios.org> Message-ID: <069.e5f09c9ba3298ad65b8a56be4cc68a5a@openbios.org> #22: sed error in abuild ----------------------------+----------------------------------------------- Reporter: uwe | Owner: uwe Type: defect | Status: assigned Priority: critical | Milestone: Component: testsystem | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY ----------------------------+----------------------------------------------- Comment (by stepan): Acked-By: Stefan Reinauer -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 19:37:02 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 18:37:02 -0000 Subject: [LinuxBIOS] #7: flashrom: Doesn't seem to be able to write on ICH-2 (maybe other ICH-x) mainboards In-Reply-To: <060.7f1ab5f716c2ef6f172c83f4640ec181@openbios.org> References: <060.7f1ab5f716c2ef6f172c83f4640ec181@openbios.org> Message-ID: <069.bed3c72a131f9e2fb9d45b07b450a14d@openbios.org> #7: flashrom: Doesn't seem to be able to write on ICH-2 (maybe other ICH-x) mainboards ----------------------------+----------------------------------------------- Reporter: uwe | Owner: uwe Type: defect | Status: new Priority: critical | Milestone: Component: flashrom | Version: v2 Resolution: | Keywords: Include_gantt: 1 | Dependencies: Due_assign: 11/30/2006 | Due_close: 12/31/2006 ----------------------------+----------------------------------------------- Changes (by stepan): * owner: somebody => uwe Comment: Is this related to #26? -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 19:37:56 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 18:37:56 -0000 Subject: [LinuxBIOS] #15: fix abuild for all boards that use the "three images solution In-Reply-To: <060.c096c6387436d64a72ea1ca53bd2931d@openbios.org> References: <060.c096c6387436d64a72ea1ca53bd2931d@openbios.org> Message-ID: <069.d5f0b41d05be95c979ca955be0cc0472@openbios.org> #15: fix abuild for all boards that use the "three images solution ----------------------------+----------------------------------------------- Reporter: anonymous | Owner: yhlu Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Resolution: | Keywords: abuild Include_gantt: 0 | Dependencies: Due_assign: DD/MM/YYYY | Due_close: DD/MM/YYYY ----------------------------+----------------------------------------------- Changes (by stepan): * owner: somebody => yhlu -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 19:38:59 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 18:38:59 -0000 Subject: [LinuxBIOS] #11: pirq table automation In-Reply-To: <060.bdcfee00b7c82f4e231cf7120fd5ebe5@openbios.org> References: <060.bdcfee00b7c82f4e231cf7120fd5ebe5@openbios.org> Message-ID: <069.bd141adc785ff2a5c7f5bd79dc6d8eb0@openbios.org> #11: pirq table automation -----------------------------+---------------------------------------------- Reporter: stepan | Owner: yhlu Type: enhancement | Status: new Priority: major | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: DD/MM/YYYY | Due_close: DD/MM/YYYY -----------------------------+---------------------------------------------- Changes (by stepan): * owner: somebody => yhlu * milestone: => Going mainstream -- Ticket URL: LinuxBIOS From segher at kernel.crashing.org Sun Nov 5 19:38:49 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 5 Nov 2006 19:38:49 +0100 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage In-Reply-To: <20061105124012.GA5110@coresystems.de> References: <2ea3fae10611041239h637cd0d9s3716dc950193bb10@mail.gmail.com> <2ea3fae10611041756w25975ca5o3a9facc726378ecd@mail.gmail.com> <2ea3fae10611041921h5d453fbao90b21e9bb793e1e@mail.gmail.com> <2ea3fae10611042033r7fe4d03fj3022efd73e222432@mail.gmail.com> <2ea3fae10611042305i4e6a05f8yba2cfab323ab3fd7@mail.gmail.com> <20061105124012.GA5110@coresystems.de> Message-ID: <438F425C-B110-406C-834F-C2D2E1E704A0@kernel.crashing.org> > Are we not going to switch to 64bit mode in LinuxBIOS anyways? We probably should, PCIe requires 64-bit loads and stores (well most devices don't need those, but hey). It also makes accessing stuff above 4GB way easier, and you can use all 16 regs without needing prefixes. >> Or we need to make elfboot in LinuxBIOS to be 64elf aware, and it >> need >> to switch 64bit before load 64bit elf. > > This is the preferred thing I guess, because it will allow us to use > other 64bit payloads as well without requiring that they do the same > weird 32->64bit trampolining as Linux does... That trampoline is really simple actually (well, after I sat down with it and a lot of paper for a few hours). A similar thing is needed to start a 32-bit payload from a 64-bit firmware of course. [OT: want to see *really* simple? On PowerPC it's one bit only to select between 32- and 64-bit mode. I'm sooo spoilt]. Segher From segher at kernel.crashing.org Sun Nov 5 19:45:19 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 5 Nov 2006 19:45:19 +0100 Subject: [LinuxBIOS] Hello, I have a problem to put the linuxbios on my mainboard ms6163. In-Reply-To: <20061105171806.GA10932@coresystems.de> References: <20061105125638.20219.qmail@web56004.mail.re3.yahoo.com> <20061105171806.GA10932@coresystems.de> Message-ID: <81A80BE6-62D4-4124-BC2C-70D4FB696CB1@kernel.crashing.org> > You need to run > dump_pci_devices(); > > as last command in auto.c > >> lspci -xxx: If you resend this lspci output with the dump_pci_devices() output (and please do!), use lspci -xxx -s0:0 or just cut'n'paste only device 0 ("Host Bridge"), the rest isn't interesting. Did you send the SPD contents dump already? I didn't see it yet -- if you didn't send it to the list, please do. Oh and answer Stefan's question: >> Ok. Its reading 1 SPD-ROM. Do you have 1 memory module >> installed? If yes: Everything is fine here. If you have more, >> we need to find out where they are. Segher From svn at openbios.org Sun Nov 5 19:49:53 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 18:49:53 -0000 Subject: [LinuxBIOS] #29: this is a captcha test In-Reply-To: <060.ca520007e3ca25a907b60a83b34b12a2@openbios.org> References: <060.ca520007e3ca25a907b60a83b34b12a2@openbios.org> Message-ID: <069.4db588f7412f8f55f6a12832b2a3c81e@openbios.org> #29: this is a captcha test ----------------------------+----------------------------------------------- Reporter: anonymous | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY ----------------------------+----------------------------------------------- Comment (by anonymous): Replying to [comment:1 anonymous]: > test ... sorry for the inconvenience -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 19:50:53 2006 From: svn at openbios.org (svn at openbios.org) Date: Sun, 05 Nov 2006 18:50:53 -0000 Subject: [LinuxBIOS] r2490 - in trunk/LinuxBIOSv2: src/cpu/amd/sc520 src/cpu/amd/socket_754 src/cpu/amd/socket_939 src/cpu/amd/socket_940 src/cpu/amd/socket_AM2 src/cpu/amd/socket_F src/cpu/intel/slot_2 src/cpu/intel/socket_PGA370 src/cpu/intel/socket_mPGA479M src/cpu/intel/socket_mPGA603 src/cpu/intel/socket_mPGA604_533Mhz src/cpu/intel/socket_mPGA604_800Mhz src/drivers/i2c/lm63 src/mainboard/amd/quartet src/mainboard/amd/rumba src/mainboard/amd/serenade src/mainboard/amd/serengeti_cheetah src/mainboard/amd/serengeti_leopard src/mainboard/amd/solo src/mainboard/arima/hdama src/mainboard/artecgroup/dbe61 src/mainboard/asus/p2b src/mainboard/bitworks/ims src/mainboard/broadcom/blast src/mainboard/dell/s1850 src/mainboard/densitron/dpx114 src/mainboard/digitallogic/adl855pc src/mainboard/digitallogic/msm586seg src/mainboard/digitallogic/msm800sev src/mainboard/eaglelion/5bcm src/mainboard/emulation/qemu-i386 src/mainboard/ibm/e325 src/mainboard/ibm/e326 src/mainboard/intel/jarrell src/mainboard/intel/xe7501devkit src/mainboard/iwill/dk8_htx src/mainboard/iwill/dk8s2 src/mainboard/iwill/dk8x src/mainboard/lippert/frontrunner src/mainboard/newisys/khepri src/mainboard/olpc/btest src/mainboard/olpc/rev_a src/mainboard/sunw/ultra40 src/mainboard/supermicro/x6dai_g src/mainboard/supermicro/x6dhe_g src/mainboard/supermicro/x6dhe_g2 src/mainboard/supermicro/x6dhr_ig src/mainboard/supermicro/x6dhr_ig2 src/mainboard/technologic/ts5300 src/mainboard/tyan/s2735 src/mainboard/tyan/s2850 src/mainboard/tyan/s2875 src/mainboard/tyan/s2880 src/mainboard/tyan/s2881 src/mainboard/tyan/s2882 src/mainboard/tyan/s2885 src/mainboard/tyan/s2891 src/mainboard/tyan/s2892 src/mainboard/tyan/s2895 src/mainboard/tyan/s4880 src/mainboard/tyan/s4882 src/mainboard/via/epia src/mainboard/via/epia-m src/northbridge/amd/gx2 src/northbridge/ibm/cpc710 src/northbridge/ibm/cpc925 src/northbridge/intel/e7501 src/northbridge/intel/i440bx src/northbridge/intel/i855pm src/northbridge/transmeta/tm5800 src/northbridge/via/vt8601 src/northbridge/via/vt8623 src/southbridge/amd/amd8111 src/southbridge/amd/cs5536 src/southbridge/amd/cs5536_lx src/southbridge/broadcom/bcm5785 src/southbridge/intel/esb6300 src/southbridge/intel/i82801ca src/southbridge/intel/i82801dbm src/southbridge/intel/pxhd src/southbridge/nvidia/ck804 src/southbridge/ricoh/rl5c476 src/southbridge/via/vt8231 src/southbridge/via/vt8235 src/superio/ite/it8661f src/superio/ite/it8671f src/superio/ite/it8673f src/superio/ite/it8705f src/superio/ite/it8712f src/superio/ite/it8716f src/superio/ite/it8718f src/superio/nsc/pc8374 src/superio/nsc/pc87351 src/superio/nsc/pc87360 src/superio/nsc/pc87366 src/superio/nsc/pc87417 src/superio/nsc/pc87427 src/superio/nsc/pc97307 src/superio/nsc/pc97317 src/superio/smsc/lpc47b272 src/superio/smsc/lpc47b397 src/superio/smsc/lpc47m10x src/superio/smsc/lpc47n217 src/superio/via/vt1211 src/superio/winbond/w83627hf src/superio/winbond/w83627thf src/superio/winbond/w83977tf targets/iwill/dk8s2 Message-ID: Author: uwe Date: 2006-11-05 19:50:49 +0100 (Sun, 05 Nov 2006) New Revision: 2490 Modified: trunk/LinuxBIOSv2/src/cpu/amd/sc520/sc520.c trunk/LinuxBIOSv2/src/cpu/amd/socket_754/socket_754.c trunk/LinuxBIOSv2/src/cpu/amd/socket_939/socket_939.c trunk/LinuxBIOSv2/src/cpu/amd/socket_940/socket_940.c trunk/LinuxBIOSv2/src/cpu/amd/socket_AM2/socket_AM2.c trunk/LinuxBIOSv2/src/cpu/amd/socket_F/socket_F.c trunk/LinuxBIOSv2/src/cpu/intel/slot_2/slot_2.c trunk/LinuxBIOSv2/src/cpu/intel/socket_PGA370/socket_PGA370.c trunk/LinuxBIOSv2/src/cpu/intel/socket_mPGA479M/socket_mPGA479M.c trunk/LinuxBIOSv2/src/cpu/intel/socket_mPGA603/socket_mPGA603_400Mhz.c trunk/LinuxBIOSv2/src/cpu/intel/socket_mPGA604_533Mhz/socket_mPGA604_533Mhz.c trunk/LinuxBIOSv2/src/cpu/intel/socket_mPGA604_800Mhz/socket_mPGA604_800Mhz.c trunk/LinuxBIOSv2/src/drivers/i2c/lm63/lm63.c trunk/LinuxBIOSv2/src/mainboard/amd/quartet/mainboard.c trunk/LinuxBIOSv2/src/mainboard/amd/rumba/mainboard.c trunk/LinuxBIOSv2/src/mainboard/amd/serenade/mainboard.c trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/mainboard.c trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/mainboard.c trunk/LinuxBIOSv2/src/mainboard/amd/solo/mainboard.c trunk/LinuxBIOSv2/src/mainboard/arima/hdama/mainboard.c trunk/LinuxBIOSv2/src/mainboard/artecgroup/dbe61/mainboard.c trunk/LinuxBIOSv2/src/mainboard/asus/p2b/mainboard.c trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/mainboard.c trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/mainboard.c trunk/LinuxBIOSv2/src/mainboard/dell/s1850/mainboard.c trunk/LinuxBIOSv2/src/mainboard/densitron/dpx114/mainboard.c trunk/LinuxBIOSv2/src/mainboard/digitallogic/adl855pc/mainboard.c trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm586seg/mainboard.c trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm800sev/mainboard.c trunk/LinuxBIOSv2/src/mainboard/eaglelion/5bcm/mainboard.c trunk/LinuxBIOSv2/src/mainboard/emulation/qemu-i386/mainboard.c trunk/LinuxBIOSv2/src/mainboard/ibm/e325/mainboard.c trunk/LinuxBIOSv2/src/mainboard/ibm/e326/mainboard.c trunk/LinuxBIOSv2/src/mainboard/intel/jarrell/mainboard.c trunk/LinuxBIOSv2/src/mainboard/intel/xe7501devkit/mainboard.c trunk/LinuxBIOSv2/src/mainboard/iwill/dk8_htx/Options.lb trunk/LinuxBIOSv2/src/mainboard/iwill/dk8_htx/mainboard.c trunk/LinuxBIOSv2/src/mainboard/iwill/dk8s2/mainboard.c trunk/LinuxBIOSv2/src/mainboard/iwill/dk8x/mainboard.c trunk/LinuxBIOSv2/src/mainboard/lippert/frontrunner/mainboard.c trunk/LinuxBIOSv2/src/mainboard/newisys/khepri/Options.lb trunk/LinuxBIOSv2/src/mainboard/newisys/khepri/mainboard.c trunk/LinuxBIOSv2/src/mainboard/olpc/btest/mainboard.c trunk/LinuxBIOSv2/src/mainboard/olpc/rev_a/mainboard.c trunk/LinuxBIOSv2/src/mainboard/sunw/ultra40/mainboard.c trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dai_g/mainboard.c trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g/mainboard.c trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g2/mainboard.c trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig/mainboard.c trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig2/mainboard.c trunk/LinuxBIOSv2/src/mainboard/technologic/ts5300/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s2735/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s2850/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s2875/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s2880/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s2881/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s2882/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s2885/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s2891/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s2892/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s2895/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s4880/mainboard.c trunk/LinuxBIOSv2/src/mainboard/tyan/s4882/mainboard.c trunk/LinuxBIOSv2/src/mainboard/via/epia-m/mainboard.c trunk/LinuxBIOSv2/src/mainboard/via/epia/mainboard.c trunk/LinuxBIOSv2/src/northbridge/amd/gx2/northbridge.c trunk/LinuxBIOSv2/src/northbridge/ibm/cpc710/cpc710_northbridge.c trunk/LinuxBIOSv2/src/northbridge/ibm/cpc925/cpc925_northbridge.c trunk/LinuxBIOSv2/src/northbridge/intel/e7501/northbridge.c trunk/LinuxBIOSv2/src/northbridge/intel/i440bx/northbridge.c trunk/LinuxBIOSv2/src/northbridge/intel/i855pm/northbridge.c trunk/LinuxBIOSv2/src/northbridge/transmeta/tm5800/northbridge.c trunk/LinuxBIOSv2/src/northbridge/via/vt8601/northbridge.c trunk/LinuxBIOSv2/src/northbridge/via/vt8623/northbridge.c trunk/LinuxBIOSv2/src/southbridge/amd/amd8111/amd8111.c trunk/LinuxBIOSv2/src/southbridge/amd/cs5536/cs5536.c trunk/LinuxBIOSv2/src/southbridge/amd/cs5536_lx/cs5536.c trunk/LinuxBIOSv2/src/southbridge/broadcom/bcm5785/bcm5785.c trunk/LinuxBIOSv2/src/southbridge/intel/esb6300/esb6300.c trunk/LinuxBIOSv2/src/southbridge/intel/i82801ca/i82801ca.c trunk/LinuxBIOSv2/src/southbridge/intel/i82801dbm/i82801dbm.c trunk/LinuxBIOSv2/src/southbridge/intel/pxhd/pxhd_bridge.c trunk/LinuxBIOSv2/src/southbridge/nvidia/ck804/ck804.c trunk/LinuxBIOSv2/src/southbridge/ricoh/rl5c476/rl5c476.c trunk/LinuxBIOSv2/src/southbridge/via/vt8231/vt8231.c trunk/LinuxBIOSv2/src/southbridge/via/vt8235/vt8235.c trunk/LinuxBIOSv2/src/superio/ite/it8661f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8671f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8673f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8705f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8712f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8716f/superio.c trunk/LinuxBIOSv2/src/superio/ite/it8718f/superio.c trunk/LinuxBIOSv2/src/superio/nsc/pc8374/superio.c trunk/LinuxBIOSv2/src/superio/nsc/pc87351/superio.c trunk/LinuxBIOSv2/src/superio/nsc/pc87360/superio.c trunk/LinuxBIOSv2/src/superio/nsc/pc87366/superio.c trunk/LinuxBIOSv2/src/superio/nsc/pc87417/superio.c trunk/LinuxBIOSv2/src/superio/nsc/pc87427/superio.c trunk/LinuxBIOSv2/src/superio/nsc/pc97307/superio.c trunk/LinuxBIOSv2/src/superio/nsc/pc97317/superio.c trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/superio.c trunk/LinuxBIOSv2/src/superio/smsc/lpc47b397/superio.c trunk/LinuxBIOSv2/src/superio/smsc/lpc47m10x/superio.c trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/superio.c trunk/LinuxBIOSv2/src/superio/via/vt1211/vt1211.c trunk/LinuxBIOSv2/src/superio/winbond/w83627hf/superio.c trunk/LinuxBIOSv2/src/superio/winbond/w83627thf/superio.c trunk/LinuxBIOSv2/src/superio/winbond/w83977tf/superio.c trunk/LinuxBIOSv2/targets/iwill/dk8s2/Config.lb Log: Use the canonical name of the vendors/devices and the same format for all CHIP_NAME() entries in LinuxBIOS (Closes #20). Signed-off-by: Uwe Hermann Acked-by: Stefan Reinauer Modified: trunk/LinuxBIOSv2/src/cpu/amd/sc520/sc520.c =================================================================== --- trunk/LinuxBIOSv2/src/cpu/amd/sc520/sc520.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/cpu/amd/sc520/sc520.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -265,6 +265,6 @@ struct chip_operations cpu_amd_sc520_ops = { - CHIP_NAME("AMD SC520") + CHIP_NAME("AMD Elan SC520 CPU") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/cpu/amd/socket_754/socket_754.c =================================================================== --- trunk/LinuxBIOSv2/src/cpu/amd/socket_754/socket_754.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/cpu/amd/socket_754/socket_754.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,5 +3,5 @@ struct chip_operations cpu_amd_socket_754_ops = { - CHIP_NAME("socket 754") + CHIP_NAME("Socket 754 CPU") }; Modified: trunk/LinuxBIOSv2/src/cpu/amd/socket_939/socket_939.c =================================================================== --- trunk/LinuxBIOSv2/src/cpu/amd/socket_939/socket_939.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/cpu/amd/socket_939/socket_939.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,5 +2,5 @@ #include "chip.h" struct chip_operations cpu_amd_socket_939_ops = { - CHIP_NAME("socket 939") + CHIP_NAME("Socket 939 CPU") }; Modified: trunk/LinuxBIOSv2/src/cpu/amd/socket_940/socket_940.c =================================================================== --- trunk/LinuxBIOSv2/src/cpu/amd/socket_940/socket_940.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/cpu/amd/socket_940/socket_940.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,5 +2,5 @@ #include "chip.h" struct chip_operations cpu_amd_socket_940_ops = { - CHIP_NAME("socket 940") + CHIP_NAME("Socket 940 CPU") }; Modified: trunk/LinuxBIOSv2/src/cpu/amd/socket_AM2/socket_AM2.c =================================================================== --- trunk/LinuxBIOSv2/src/cpu/amd/socket_AM2/socket_AM2.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/cpu/amd/socket_AM2/socket_AM2.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,5 +2,5 @@ #include "chip.h" struct chip_operations cpu_amd_socket_AM2_ops = { - CHIP_NAME("socket AM2") + CHIP_NAME("Socket AM2 CPU") }; Modified: trunk/LinuxBIOSv2/src/cpu/amd/socket_F/socket_F.c =================================================================== --- trunk/LinuxBIOSv2/src/cpu/amd/socket_F/socket_F.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/cpu/amd/socket_F/socket_F.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,5 +2,5 @@ #include "chip.h" struct chip_operations cpu_amd_socket_F_ops = { - CHIP_NAME("socket F") + CHIP_NAME("Socket F CPU") }; Modified: trunk/LinuxBIOSv2/src/cpu/intel/slot_2/slot_2.c =================================================================== --- trunk/LinuxBIOSv2/src/cpu/intel/slot_2/slot_2.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/cpu/intel/slot_2/slot_2.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,5 +3,5 @@ struct chip_operations cpu_intel_slot_2_ops = { - CHIP_NAME("slot 2") + CHIP_NAME("Slot 2 CPU") }; Modified: trunk/LinuxBIOSv2/src/cpu/intel/socket_PGA370/socket_PGA370.c =================================================================== --- trunk/LinuxBIOSv2/src/cpu/intel/socket_PGA370/socket_PGA370.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/cpu/intel/socket_PGA370/socket_PGA370.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,5 +3,5 @@ struct chip_operations cpu_intel_socket_PGA370_ops = { - CHIP_NAME("socket PGA370") + CHIP_NAME("Socket PGA370 CPU") }; Modified: trunk/LinuxBIOSv2/src/cpu/intel/socket_mPGA479M/socket_mPGA479M.c =================================================================== --- trunk/LinuxBIOSv2/src/cpu/intel/socket_mPGA479M/socket_mPGA479M.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/cpu/intel/socket_mPGA479M/socket_mPGA479M.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,5 +3,5 @@ struct chip_operations cpu_intel_socket_mPGA479M_ops = { - CHIP_NAME("socket mPGA479M") + CHIP_NAME("Socket mPGA479M CPU") }; Modified: trunk/LinuxBIOSv2/src/cpu/intel/socket_mPGA603/socket_mPGA603_400Mhz.c =================================================================== --- trunk/LinuxBIOSv2/src/cpu/intel/socket_mPGA603/socket_mPGA603_400Mhz.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/cpu/intel/socket_mPGA603/socket_mPGA603_400Mhz.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,5 +3,5 @@ struct chip_opertations cpu_intel_socket_mPGA603_ops = { - CHIP_NAME("socket mPGA603_400Mhz") + CHIP_NAME("Socket mPGA603 400Mhz CPU") }; Modified: trunk/LinuxBIOSv2/src/cpu/intel/socket_mPGA604_533Mhz/socket_mPGA604_533Mhz.c =================================================================== --- trunk/LinuxBIOSv2/src/cpu/intel/socket_mPGA604_533Mhz/socket_mPGA604_533Mhz.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/cpu/intel/socket_mPGA604_533Mhz/socket_mPGA604_533Mhz.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,5 +3,5 @@ struct chip_operations cpu_intel_socket_mPGA604_533Mhz_ops = { - CHIP_NAME("socket mPGA604_533Mhz") + CHIP_NAME("Socket mPGA604 533Mhz CPU") }; Modified: trunk/LinuxBIOSv2/src/cpu/intel/socket_mPGA604_800Mhz/socket_mPGA604_800Mhz.c =================================================================== --- trunk/LinuxBIOSv2/src/cpu/intel/socket_mPGA604_800Mhz/socket_mPGA604_800Mhz.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/cpu/intel/socket_mPGA604_800Mhz/socket_mPGA604_800Mhz.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,5 +3,5 @@ struct chip_operations cpu_intel_socket_mPGA604_800Mhz_ops = { - CHIP_NAME("socket mPGA604_800Mhz") + CHIP_NAME("Socket mPGA604 800Mhz CPU") }; Modified: trunk/LinuxBIOSv2/src/drivers/i2c/lm63/lm63.c =================================================================== --- trunk/LinuxBIOSv2/src/drivers/i2c/lm63/lm63.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/drivers/i2c/lm63/lm63.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -41,6 +41,6 @@ } struct chip_operations drivers_i2c_lm63_ops = { - CHIP_NAME("lm63") + CHIP_NAME("National Semiconductor LM63") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/mainboard/amd/quartet/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/quartet/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/amd/quartet/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations mainboard_amd_quartet_ops = { - CHIP_NAME("AMD Quartet mainboard") + CHIP_NAME("AMD Quartet Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/amd/rumba/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/rumba/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/amd/rumba/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -37,7 +37,7 @@ } struct chip_operations mainboard_amd_rumba_ops = { - CHIP_NAME("AMD Rumba mainboard") + CHIP_NAME("AMD Rumba Mainboard") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/mainboard/amd/serenade/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/serenade/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/amd/serenade/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations mainboard_amd_serenade_ops = { - CHIP_NAME("AMD Serenade mainboard") + CHIP_NAME("AMD Serenade Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,7 +3,7 @@ #if CONFIG_CHIP_NAME == 1 struct chip_operations mainboard_amd_serengeti_cheetah_ops = { - CHIP_NAME("AMD Serengeti Cheetah mainboard") + CHIP_NAME("AMD Serengeti Cheetah Mainboard") }; #endif Modified: trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,7 +3,7 @@ #if CONFIG_CHIP_NAME == 1 struct chip_operations mainboard_amd_serengeti_leopard_ops = { - CHIP_NAME("AMD Serengeti Leopard mainboard") + CHIP_NAME("AMD Serengeti Leopard Mainboard") }; #endif Modified: trunk/LinuxBIOSv2/src/mainboard/amd/solo/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/solo/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/amd/solo/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations mainboard_amd_solo_ops = { - CHIP_NAME("AMD Solo7 mainboard") + CHIP_NAME("AMD Solo7 Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/arima/hdama/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/arima/hdama/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/arima/hdama/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations mainboard_arima_hdama_ops = { - CHIP_NAME("Arima HDAMA mainboard") + CHIP_NAME("Arima HDAMA Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/artecgroup/dbe61/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/artecgroup/dbe61/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/artecgroup/dbe61/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -39,6 +39,6 @@ } struct chip_operations mainboard_artecgroup_dbe61_ops = { - CHIP_NAME("Artec Group dbe61 mainboard") + CHIP_NAME("Artec Group dbe61 Mainboard") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/mainboard/asus/p2b/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/asus/p2b/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/asus/p2b/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations mainboard_asus_p2b_ops = { - CHIP_NAME("ASUS P2B mainboard") + CHIP_NAME("ASUS P2B Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations mainboard_bitworks_ims_ops = { - CHIP_NAME("Bitworks IMS mainboard") + CHIP_NAME("Bitworks IMS Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,7 +3,7 @@ #if CONFIG_CHIP_NAME == 1 struct chip_operations mainboard_broadcom_blast_ops = { - CHIP_NAME("Broadcom Blast mainboard") + CHIP_NAME("Broadcom Blast Mainboard") }; #endif Modified: trunk/LinuxBIOSv2/src/mainboard/dell/s1850/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/dell/s1850/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/dell/s1850/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations mainboard_dell_s1850_ops = { - CHIP_NAME("Dell S1850 mainboard") + CHIP_NAME("Dell S1850 Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/densitron/dpx114/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/densitron/dpx114/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/densitron/dpx114/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations mainboard_densitron_dpx114_ops = { - CHIP_NAME("Densitron DPX114 mainboard") + CHIP_NAME("Densitron DPX114 Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/digitallogic/adl855pc/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/digitallogic/adl855pc/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/digitallogic/adl855pc/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations mainboard_digitallogic_adl855pc_ops = { - CHIP_NAME("DIGITAL-LOGIC ADL855PC mainboard") + CHIP_NAME("DIGITAL-LOGIC ADL855PC Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm586seg/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm586seg/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm586seg/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -142,7 +142,7 @@ } struct chip_operations mainboard_digitallogic_msm586seg_ops = { - CHIP_NAME("DIGITAL-LOGIC MSM586SEG mainboard") + CHIP_NAME("DIGITAL-LOGIC MSM586SEG Mainboard") .enable_dev = enable_dev }; Modified: trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm800sev/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm800sev/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm800sev/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -62,7 +62,7 @@ } struct chip_operations mainboard_digitallogic_msm800sev_ops = { - CHIP_NAME("DIGITAL-LOGIC MSM800SEV mainboard") + CHIP_NAME("DIGITAL-LOGIC MSM800SEV Mainboard") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/mainboard/eaglelion/5bcm/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/eaglelion/5bcm/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/eaglelion/5bcm/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations mainboard_eaglelion_5bcm_ops = { - CHIP_NAME("Eaglelion 5BCM mainboard") + CHIP_NAME("Eaglelion 5BCM Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/emulation/qemu-i386/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/emulation/qemu-i386/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/emulation/qemu-i386/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations mainboard_emulation_qemu_i386_ops = { - CHIP_NAME("QEMU mainboard") + CHIP_NAME("QEMU Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/ibm/e325/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/ibm/e325/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/ibm/e325/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations mainboard_ibm_e325_ops = { - CHIP_NAME("IBM eServer 325 mainboard") + CHIP_NAME("IBM eServer 325 Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/ibm/e326/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/ibm/e326/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/ibm/e326/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations mainboard_ibm_e326_ops = { - CHIP_NAME("IBM eServer 326 mainboard") + CHIP_NAME("IBM eServer 326 Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/intel/jarrell/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/intel/jarrell/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/intel/jarrell/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations mainboard_intel_e7520_ops = { - CHIP_NAME("Intel Jarell mainboard") + CHIP_NAME("Intel Jarell Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/intel/xe7501devkit/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/intel/xe7501devkit/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/intel/xe7501devkit/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,7 +3,7 @@ #if CONFIG_CHIP_NAME == 1 struct chip_operations mainboard_intel_xe7501devkit_ops = { - CHIP_NAME("Intel Xeon E7501 DevKit mainboard") + CHIP_NAME("Intel Xeon E7501 DevKit Mainboard") }; #endif Modified: trunk/LinuxBIOSv2/src/mainboard/iwill/dk8_htx/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/iwill/dk8_htx/Options.lb 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/iwill/dk8_htx/Options.lb 2006-11-05 18:50:49 UTC (rev 2490) @@ -230,7 +230,7 @@ ## Clean up the motherboard id strings ## default MAINBOARD_PART_NUMBER="dk8_htx" -default MAINBOARD_VENDOR="iwill" +default MAINBOARD_VENDOR="IWILL" default MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID=0x1022 default MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID=0x2b80 Modified: trunk/LinuxBIOSv2/src/mainboard/iwill/dk8_htx/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/iwill/dk8_htx/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/iwill/dk8_htx/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,7 +3,7 @@ #if CONFIG_CHIP_NAME == 1 struct chip_operations mainboard_iwill_dk8_htx_ops = { - CHIP_NAME("IWILL DK8-HTX mainboard") + CHIP_NAME("IWILL DK8-HTX Mainboard") }; #endif Modified: trunk/LinuxBIOSv2/src/mainboard/iwill/dk8s2/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/iwill/dk8s2/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/iwill/dk8s2/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations mainboard_iwill_dk8s2_ops = { - CHIP_NAME("IWILL DK8S2 mainboard") + CHIP_NAME("IWILL DK8S2 Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/iwill/dk8x/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/iwill/dk8x/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/iwill/dk8x/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations mainboard_iwill_dk8x_ops = { - CHIP_NAME("IWILL DK8X mainboard") + CHIP_NAME("IWILL DK8X Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/lippert/frontrunner/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/lippert/frontrunner/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/lippert/frontrunner/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations mainboard_lippert_frontrunner_ops = { - CHIP_NAME("Lippert Cool Frontrunner mainboard") + CHIP_NAME("Lippert Cool Frontrunner Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/newisys/khepri/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/newisys/khepri/Options.lb 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/newisys/khepri/Options.lb 2006-11-05 18:50:49 UTC (rev 2490) @@ -110,8 +110,8 @@ ## ## Clean up the motherboard id strings ## -default MAINBOARD_PART_NUMBER="KHEPRI" -default MAINBOARD_VENDOR="NEWISYS" +default MAINBOARD_PART_NUMBER="Khepri" +default MAINBOARD_VENDOR="Newisys" ### ### LinuxBIOS layout values Modified: trunk/LinuxBIOSv2/src/mainboard/newisys/khepri/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/newisys/khepri/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/newisys/khepri/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations mainboard_newisys_khepri_ops = { - CHIP_NAME("Newisys 2100 mainboard") + CHIP_NAME("Newisys 2100 Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/olpc/btest/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/olpc/btest/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/olpc/btest/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -131,6 +131,6 @@ } struct chip_operations mainboard_olpc_btest_ops = { - CHIP_NAME("OLPC btest mainboard") + CHIP_NAME("OLPC btest Mainboard") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/mainboard/olpc/rev_a/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/olpc/rev_a/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/olpc/rev_a/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -103,6 +103,6 @@ } struct chip_operations mainboard_olpc_rev_a_ops = { - CHIP_NAME("OLPC rev_a mainboard") + CHIP_NAME("OLPC rev_a Mainboard") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/mainboard/sunw/ultra40/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/sunw/ultra40/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/sunw/ultra40/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,7 +3,7 @@ #if CONFIG_CHIP_NAME == 1 struct chip_operations mainboard_sunw_ultra40_ops = { - CHIP_NAME("Sun Ultra 40 mainboard") + CHIP_NAME("Sun Ultra 40 Mainboard") }; #endif Modified: trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dai_g/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dai_g/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dai_g/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations supermicro_x6dai_g_ops = { - CHIP_NAME("Supermicro X6DAi-G mainboard") + CHIP_NAME("Supermicro X6DAi-G Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations supermicro_x6dhe_g_ops = { - CHIP_NAME("Supermicro X6DHE-G mainboard") + CHIP_NAME("Supermicro X6DHE-G Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g2/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g2/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g2/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations supermicro_x6dhe_g2_ops = { - CHIP_NAME("Supermicro X6DHE-G2 mainboard") + CHIP_NAME("Supermicro X6DHE-G2 Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations mainboard_supermicro_x6dhr_ig_ops = { - CHIP_NAME("Supermicro X6DHR-iG mainboard") + CHIP_NAME("Supermicro X6DHR-iG Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig2/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig2/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig2/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations mainboard_supermicro_x6dhr_ig2_ops = { - CHIP_NAME("Supermicro X6DHR-iG2 mainboard") + CHIP_NAME("Supermicro X6DHR-iG2 Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/technologic/ts5300/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/technologic/ts5300/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/technologic/ts5300/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -149,7 +149,7 @@ } struct chip_operations mainboard_technologic_ts5300_ops = { - CHIP_NAME("Technologic Systems TS-5300 mainboard") + CHIP_NAME("Technologic Systems TS-5300 Mainboard") .enable_dev = enable_dev }; Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2735/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2735/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2735/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,7 +3,7 @@ #if CONFIG_CHIP_NAME == 1 struct chip_operations mainboard_tyan_s2735_ops = { - CHIP_NAME("Tyan S2735 mainboard") + CHIP_NAME("Tyan S2735 Mainboard") }; #endif Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2850/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2850/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2850/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,7 +3,7 @@ #if CONFIG_CHIP_NAME == 1 struct chip_operations mainboard_tyan_s2850_ops = { - CHIP_NAME("Tyan S2850 mainboard") + CHIP_NAME("Tyan S2850 Mainboard") }; #endif Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2875/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2875/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2875/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,7 +3,7 @@ #if CONFIG_CHIP_NAME == 1 struct chip_operations mainboard_tyan_s2875_ops = { - CHIP_NAME("Tyan S2875 mainboard") + CHIP_NAME("Tyan S2875 Mainboard") }; #endif Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2880/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2880/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2880/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,7 +3,7 @@ #if CONFIG_CHIP_NAME == 1 struct chip_operations mainboard_tyan_s2880_ops = { - CHIP_NAME("Tyan S2880 mainboard") + CHIP_NAME("Tyan S2880 Mainboard") }; #endif Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2881/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2881/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2881/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,7 +3,7 @@ #if CONFIG_CHIP_NAME == 1 struct chip_operations mainboard_tyan_s2881_ops = { - CHIP_NAME("Tyan S2881 mainboard") + CHIP_NAME("Tyan S2881 Mainboard") }; #endif Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2882/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2882/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2882/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,7 +3,7 @@ #if CONFIG_CHIP_NAME == 1 struct chip_operations mainboard_tyan_s2882_ops = { - CHIP_NAME("Tyan S2882 mainboard") + CHIP_NAME("Tyan S2882 Mainboard") }; #endif Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2885/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2885/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2885/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,7 +3,7 @@ #if CONFIG_CHIP_NAME == 1 struct chip_operations mainboard_tyan_s2885_ops = { - CHIP_NAME("Tyan S2885 mainboard") + CHIP_NAME("Tyan S2885 Mainboard") }; #endif Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2891/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2891/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2891/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,7 +3,7 @@ #if CONFIG_CHIP_NAME == 1 struct chip_operations mainboard_tyan_s2891_ops = { - CHIP_NAME("Tyan S2891 mainboard") + CHIP_NAME("Tyan S2891 Mainboard") }; #endif Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2892/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2892/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2892/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,7 +3,7 @@ #if CONFIG_CHIP_NAME == 1 struct chip_operations mainboard_tyan_s2892_ops = { - CHIP_NAME("Tyan S2892 mainboard") + CHIP_NAME("Tyan S2892 Mainboard") }; #endif Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2895/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2895/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2895/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,7 +3,7 @@ #if CONFIG_CHIP_NAME == 1 struct chip_operations mainboard_tyan_s2895_ops = { - CHIP_NAME("Tyan S2895 mainboard") + CHIP_NAME("Tyan S2895 Mainboard") }; #endif Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s4880/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s4880/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s4880/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,7 +3,7 @@ #if CONFIG_CHIP_NAME == 1 struct chip_operations mainboard_tyan_s4880_ops = { - CHIP_NAME("Tyan S4880 mainboard") + CHIP_NAME("Tyan S4880 Mainboard") }; #endif Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s4882/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s4882/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s4882/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -3,7 +3,7 @@ #if CONFIG_CHIP_NAME == 1 struct chip_operations mainboard_tyan_s4882_ops = { - CHIP_NAME("Tyan S4882 mainboard") + CHIP_NAME("Tyan S4882 Mainboard") }; #endif Modified: trunk/LinuxBIOSv2/src/mainboard/via/epia/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/via/epia/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/via/epia/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -2,6 +2,6 @@ #include "chip.h" struct chip_operations mainboard_via_epia_ops = { - CHIP_NAME("VIA EPIA mainboard") + CHIP_NAME("VIA EPIA Mainboard") }; Modified: trunk/LinuxBIOSv2/src/mainboard/via/epia-m/mainboard.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/via/epia-m/mainboard.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/mainboard/via/epia-m/mainboard.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -41,6 +41,6 @@ } struct chip_operations mainboard_via_epia_m_ops = { - CHIP_NAME("VIA EPIA-M mainboard") + CHIP_NAME("VIA EPIA-M Mainboard") }; Modified: trunk/LinuxBIOSv2/src/northbridge/amd/gx2/northbridge.c =================================================================== --- trunk/LinuxBIOSv2/src/northbridge/amd/gx2/northbridge.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/northbridge/amd/gx2/northbridge.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -531,6 +531,6 @@ } struct chip_operations northbridge_amd_gx2_ops = { - CHIP_NAME("AMD GX2 Northbridge") + CHIP_NAME("AMD GX (previously GX2) Northbridge") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/northbridge/ibm/cpc710/cpc710_northbridge.c =================================================================== --- trunk/LinuxBIOSv2/src/northbridge/ibm/cpc710/cpc710_northbridge.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/northbridge/ibm/cpc710/cpc710_northbridge.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -98,6 +98,6 @@ } struct chip_operations northbridge_ibm_cpc710_ops = { - CHIP_NAME("CPC710") + CHIP_NAME("IBM CPC710 Northbridge") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/northbridge/ibm/cpc925/cpc925_northbridge.c =================================================================== --- trunk/LinuxBIOSv2/src/northbridge/ibm/cpc925/cpc925_northbridge.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/northbridge/ibm/cpc925/cpc925_northbridge.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -98,6 +98,6 @@ } struct chip_operations northbridge_ibm_cpc925_ops = { - CHIP_NAME("CPC925") + CHIP_NAME("IBM CPC925 Northbridge") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/northbridge/intel/e7501/northbridge.c =================================================================== --- trunk/LinuxBIOSv2/src/northbridge/intel/e7501/northbridge.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/northbridge/intel/e7501/northbridge.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -187,6 +187,6 @@ } struct chip_operations northbridge_intel_e7501_ops = { - CHIP_NAME("Intel E7501 northbridge") + CHIP_NAME("Intel E7501 Northbridge") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/northbridge/intel/i440bx/northbridge.c =================================================================== --- trunk/LinuxBIOSv2/src/northbridge/intel/i440bx/northbridge.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/northbridge/intel/i440bx/northbridge.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -181,6 +181,6 @@ } struct chip_operations northbridge_intel_i440bx_ops = { - CHIP_NAME("Intel 440bx Northbridge") + CHIP_NAME("Intel 440BX Northbridge") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/northbridge/intel/i855pm/northbridge.c =================================================================== --- trunk/LinuxBIOSv2/src/northbridge/intel/i855pm/northbridge.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/northbridge/intel/i855pm/northbridge.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -157,6 +157,6 @@ } struct chip_operations northbridge_intel_i855pm_ops = { - CHIP_NAME("intel i855pm Northbridge") + CHIP_NAME("Intel 855PM Northbridge") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/northbridge/transmeta/tm5800/northbridge.c =================================================================== --- trunk/LinuxBIOSv2/src/northbridge/transmeta/tm5800/northbridge.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/northbridge/transmeta/tm5800/northbridge.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -150,6 +150,6 @@ } struct chip_operations northbridge_transmeta_tm5800_control = { - CHIP_NAME("Transmeta tm5800 Northbridge") + CHIP_NAME("Transmeta TM5800 Northbridge") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/northbridge/via/vt8601/northbridge.c =================================================================== --- trunk/LinuxBIOSv2/src/northbridge/via/vt8601/northbridge.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/northbridge/via/vt8601/northbridge.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -190,6 +190,6 @@ } struct chip_operations northbridge_via_vt8601_ops = { - CHIP_NAME("VIA vt8601 Northbridge") + CHIP_NAME("VIA VT8601 Northbridge") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/northbridge/via/vt8623/northbridge.c =================================================================== --- trunk/LinuxBIOSv2/src/northbridge/via/vt8623/northbridge.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/northbridge/via/vt8623/northbridge.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -364,6 +364,6 @@ } struct chip_operations northbridge_via_vt8623_ops = { - CHIP_NAME("VIA vt8623 Northbridge") + CHIP_NAME("VIA VT8623 Northbridge") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/southbridge/amd/amd8111/amd8111.c =================================================================== --- trunk/LinuxBIOSv2/src/southbridge/amd/amd8111/amd8111.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/southbridge/amd/amd8111/amd8111.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -65,7 +65,7 @@ } struct chip_operations southbridge_amd_amd8111_ops = { - CHIP_NAME("AMD 8111") + CHIP_NAME("AMD-8111 Southbridge") /* This only called when this device is listed in the * static device tree. */ Modified: trunk/LinuxBIOSv2/src/southbridge/amd/cs5536/cs5536.c =================================================================== --- trunk/LinuxBIOSv2/src/southbridge/amd/cs5536/cs5536.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/southbridge/amd/cs5536/cs5536.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -198,7 +198,7 @@ }; struct chip_operations southbridge_amd_cs5536_ops = { - CHIP_NAME("AMD cs5536") + CHIP_NAME("AMD Geode CS5536 Southbridge") /* This only called when this device is listed in the * static device tree. */ Modified: trunk/LinuxBIOSv2/src/southbridge/amd/cs5536_lx/cs5536.c =================================================================== --- trunk/LinuxBIOSv2/src/southbridge/amd/cs5536_lx/cs5536.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/southbridge/amd/cs5536_lx/cs5536.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -323,7 +323,7 @@ }; struct chip_operations southbridge_amd_cs5536_lx_ops = { - CHIP_NAME("AMD cs5536 (LX)") + CHIP_NAME("AMD Geode CS5536 (LX) Southbridge") /* This only called when this device is listed in the * static device tree. */ Modified: trunk/LinuxBIOSv2/src/southbridge/broadcom/bcm5785/bcm5785.c =================================================================== --- trunk/LinuxBIOSv2/src/southbridge/broadcom/bcm5785/bcm5785.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/southbridge/broadcom/bcm5785/bcm5785.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -75,6 +75,6 @@ } struct chip_operations southbridge_broadcom_bcm5785_ops = { - CHIP_NAME("Serverworks bcm5785") + CHIP_NAME("Serverworks BCM5785 Southbridge") .enable_dev = bcm5785_enable, }; Modified: trunk/LinuxBIOSv2/src/southbridge/intel/esb6300/esb6300.c =================================================================== --- trunk/LinuxBIOSv2/src/southbridge/intel/esb6300/esb6300.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/southbridge/intel/esb6300/esb6300.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -43,6 +43,6 @@ } struct chip_operations southbridge_intel_esb6300_ops = { - CHIP_NAME("INTEL 6300ESB") + CHIP_NAME("Intel 6300ESB Southbridge") .enable_dev = esb6300_enable, }; Modified: trunk/LinuxBIOSv2/src/southbridge/intel/i82801ca/i82801ca.c =================================================================== --- trunk/LinuxBIOSv2/src/southbridge/intel/i82801ca/i82801ca.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/southbridge/intel/i82801ca/i82801ca.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -48,6 +48,6 @@ } struct chip_operations southbridge_intel_i82801ca_ops = { - CHIP_NAME("Intel 82801ca Southbridge") + CHIP_NAME("Intel 82801CA Southbridge") .enable_dev = i82801ca_enable, }; Modified: trunk/LinuxBIOSv2/src/southbridge/intel/i82801dbm/i82801dbm.c =================================================================== --- trunk/LinuxBIOSv2/src/southbridge/intel/i82801dbm/i82801dbm.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/southbridge/intel/i82801dbm/i82801dbm.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -60,6 +60,6 @@ } struct chip_operations southbridge_intel_i82801dbm_control = { - CHIP_NAME("Intel 82801dbm Southbridge") + CHIP_NAME("Intel 82801DBM Southbridge") .enable_dev = i82801dbm_enable, }; Modified: trunk/LinuxBIOSv2/src/southbridge/intel/pxhd/pxhd_bridge.c =================================================================== --- trunk/LinuxBIOSv2/src/southbridge/intel/pxhd/pxhd_bridge.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/southbridge/intel/pxhd/pxhd_bridge.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -253,6 +253,6 @@ }; struct chip_operations southbridge_intel_pxhd_ops = { - CHIP_NAME("PXHD") + CHIP_NAME("Intel PXHD Southbridge") .enable_dev = pxhd_enable, }; Modified: trunk/LinuxBIOSv2/src/southbridge/nvidia/ck804/ck804.c =================================================================== --- trunk/LinuxBIOSv2/src/southbridge/nvidia/ck804/ck804.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/southbridge/nvidia/ck804/ck804.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -192,6 +192,6 @@ } struct chip_operations southbridge_nvidia_ck804_ops = { - CHIP_NAME("Nvidia ck804") + CHIP_NAME("NVIDIA CK804 Southbridge") .enable_dev = ck804_enable, }; Modified: trunk/LinuxBIOSv2/src/southbridge/ricoh/rl5c476/rl5c476.c =================================================================== --- trunk/LinuxBIOSv2/src/southbridge/ricoh/rl5c476/rl5c476.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/southbridge/ricoh/rl5c476/rl5c476.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -212,6 +212,6 @@ } struct chip_operations southbridge_ricoh_rl5c476_ops = { - CHIP_NAME("RICOH RL5C476") + CHIP_NAME("Ricoh RL5C476 CardBus Controller") .enable_dev = southbridge_init, }; Modified: trunk/LinuxBIOSv2/src/southbridge/via/vt8231/vt8231.c =================================================================== --- trunk/LinuxBIOSv2/src/southbridge/via/vt8231/vt8231.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/southbridge/via/vt8231/vt8231.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -68,6 +68,6 @@ } struct chip_operations southbridge_via_vt8231_ops = { - CHIP_NAME("VIA vt8231") + CHIP_NAME("VIA VT8231 Southbridge") .enable_dev = vt8231_enable, }; Modified: trunk/LinuxBIOSv2/src/southbridge/via/vt8235/vt8235.c =================================================================== --- trunk/LinuxBIOSv2/src/southbridge/via/vt8235/vt8235.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/southbridge/via/vt8235/vt8235.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -92,6 +92,6 @@ } struct chip_operations southbridge_via_vt8235_ops = { - CHIP_NAME("VIA vt8235") + CHIP_NAME("VIA VT8235 Southbridge") .enable_dev = vt8235_enable, }; Modified: trunk/LinuxBIOSv2/src/superio/ite/it8661f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8661f/superio.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/superio/ite/it8661f/superio.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -75,7 +75,7 @@ } struct chip_operations superio_ite_it8661f_ops = { - CHIP_NAME("ITE it8661f") + CHIP_NAME("ITE IT8661F Super I/O") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/ite/it8671f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8671f/superio.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/superio/ite/it8671f/superio.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -79,7 +79,7 @@ } struct chip_operations superio_ite_it8671f_ops = { - CHIP_NAME("ITE it8671f") + CHIP_NAME("ITE IT8671F Super I/O") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/ite/it8673f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8673f/superio.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/superio/ite/it8673f/superio.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -81,7 +81,7 @@ } struct chip_operations superio_ite_it8673f_ops = { - CHIP_NAME("ITE it8673f") + CHIP_NAME("ITE IT8673F Super I/O") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/ite/it8705f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8705f/superio.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/superio/ite/it8705f/superio.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -82,7 +82,7 @@ } struct chip_operations superio_ite_it8705f_ops = { - CHIP_NAME("ITE it8705f") + CHIP_NAME("ITE IT8705F Super I/O") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/ite/it8712f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8712f/superio.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/superio/ite/it8712f/superio.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -87,7 +87,7 @@ } struct chip_operations superio_ite_it8712f_ops = { - CHIP_NAME("ITE it8712f") + CHIP_NAME("ITE IT8712F Super I/O") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/ite/it8716f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8716f/superio.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/superio/ite/it8716f/superio.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -87,7 +87,7 @@ } struct chip_operations superio_ite_it8716f_ops = { - CHIP_NAME("ITE it8716f") + CHIP_NAME("ITE IT8716F Super I/O") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/ite/it8718f/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/ite/it8718f/superio.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/superio/ite/it8718f/superio.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -83,7 +83,7 @@ } struct chip_operations superio_ite_it8718f_ops = { - CHIP_NAME("ITE it8718f") + CHIP_NAME("ITE IT8718F Super I/O") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/nsc/pc8374/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/nsc/pc8374/superio.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/superio/nsc/pc8374/superio.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -68,6 +68,6 @@ } struct chip_operations superio_nsc_pc8374_ops = { - CHIP_NAME("NSC 8374") + CHIP_NAME("NSC PC8374 Super I/O") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/nsc/pc87351/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/nsc/pc87351/superio.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/superio/nsc/pc87351/superio.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -75,6 +75,6 @@ } struct chip_operations superio_nsc_pc87351_ops = { - CHIP_NAME("NSC 87351") + CHIP_NAME("NSC PC87351 Super I/O") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/nsc/pc87360/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/nsc/pc87360/superio.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/superio/nsc/pc87360/superio.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -71,6 +71,6 @@ } struct chip_operations superio_nsc_pc87360_ops = { - CHIP_NAME("NSC 87360") + CHIP_NAME("NSC PC87360 Super I/O") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/nsc/pc87366/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/nsc/pc87366/superio.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/superio/nsc/pc87366/superio.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -71,6 +71,6 @@ } struct chip_operations superio_nsc_pc87366_ops = { - CHIP_NAME("NSC 87366") + CHIP_NAME("NSC PC87366 Super I/O") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/nsc/pc87417/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/nsc/pc87417/superio.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/superio/nsc/pc87417/superio.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -72,6 +72,6 @@ } struct chip_operations superio_nsc_pc87417_ops = { - CHIP_NAME("NSC pc87417") + CHIP_NAME("NSC PC87417 Super I/O") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/nsc/pc87427/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/nsc/pc87427/superio.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/superio/nsc/pc87427/superio.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -72,6 +72,6 @@ } struct chip_operations superio_nsc_pc87427_ops = { - CHIP_NAME("NSC 87427") + CHIP_NAME("NSC PC87427 Super I/O") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/nsc/pc97307/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/nsc/pc97307/superio.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/superio/nsc/pc97307/superio.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -83,6 +83,6 @@ } struct chip_operations superio_nsc_pc97307_ops = { - CHIP_NAME("NSC 97307") + CHIP_NAME("NSC PC97307 Super I/O") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/nsc/pc97317/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/nsc/pc97317/superio.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/superio/nsc/pc97317/superio.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -85,6 +85,6 @@ } struct chip_operations superio_nsc_pc97317_ops = { - CHIP_NAME("NSC 97317") + CHIP_NAME("NSC PC97317 Super I/O") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/superio.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/superio/smsc/lpc47b272/superio.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -47,7 +47,7 @@ struct chip_operations superio_smsc_lpc47b272_ops = { - CHIP_NAME("smsc lpc47b272") + CHIP_NAME("SMSC LPC47B272 Super I/O") .enable_dev = enable_dev }; Modified: trunk/LinuxBIOSv2/src/superio/smsc/lpc47b397/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/smsc/lpc47b397/superio.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/superio/smsc/lpc47b397/superio.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -211,7 +211,7 @@ } struct chip_operations superio_smsc_lpc47b397_ops = { - CHIP_NAME("smsc lpc47b397") + CHIP_NAME("SMSC LPC47B397 Super I/O") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/smsc/lpc47m10x/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/smsc/lpc47m10x/superio.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/superio/smsc/lpc47m10x/superio.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -48,7 +48,7 @@ struct chip_operations superio_smsc_lpc47m10x_ops = { - CHIP_NAME("smsc lpc47m10x") + CHIP_NAME("SMSC LPC47M10x Super I/O") .enable_dev = enable_dev }; Modified: trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/superio.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/superio/smsc/lpc47n217/superio.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -53,7 +53,7 @@ struct chip_operations superio_smsc_lpc47n217_ops = { - CHIP_NAME("smsc lpc47n217") + CHIP_NAME("SMSC LPC47N217 Super I/O") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/via/vt1211/vt1211.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/via/vt1211/vt1211.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/superio/via/vt1211/vt1211.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -217,6 +217,6 @@ } struct chip_operations superio_via_vt1211_ops = { - CHIP_NAME("VIA vt1211") + CHIP_NAME("VIA VT1211 Super I/O") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/winbond/w83627hf/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/winbond/w83627hf/superio.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/superio/winbond/w83627hf/superio.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -193,6 +193,6 @@ } struct chip_operations superio_winbond_w83627hf_ops = { - CHIP_NAME("Winbond w83627hf") + CHIP_NAME("Winbond W83627HF Super I/O") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/winbond/w83627thf/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/winbond/w83627thf/superio.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/superio/winbond/w83627thf/superio.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -105,6 +105,6 @@ } struct chip_operations superio_winbond_w83627thf_ops = { - CHIP_NAME("Winbond w83627thf") + CHIP_NAME("Winbond W83627THF Super I/O") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/src/superio/winbond/w83977tf/superio.c =================================================================== --- trunk/LinuxBIOSv2/src/superio/winbond/w83977tf/superio.c 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/src/superio/winbond/w83977tf/superio.c 2006-11-05 18:50:49 UTC (rev 2490) @@ -109,6 +109,6 @@ } struct chip_operations superio_winbond_w83977tf_ops = { - CHIP_NAME("Winbond w83977tf") + CHIP_NAME("Winbond W83977TF Super I/O") .enable_dev = enable_dev, }; Modified: trunk/LinuxBIOSv2/targets/iwill/dk8s2/Config.lb =================================================================== --- trunk/LinuxBIOSv2/targets/iwill/dk8s2/Config.lb 2006-11-05 18:26:08 UTC (rev 2489) +++ trunk/LinuxBIOSv2/targets/iwill/dk8s2/Config.lb 2006-11-05 18:50:49 UTC (rev 2490) @@ -53,7 +53,7 @@ ### Clean up the motherboard id strings ### option MAINBOARD_PART_NUMBER="DK8S2" -option MAINBOARD_VENDOR="Iwill" +option MAINBOARD_VENDOR="IWILL" # ### ### Compute the location and size of where this firmware image From yinghailu at gmail.com Sun Nov 5 20:17:51 2006 From: yinghailu at gmail.com (yhlu) Date: Sun, 5 Nov 2006 11:17:51 -0800 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA412D7AE@ssvlexmb2.amd.com> <2ea3fae10611041756w25975ca5o3a9facc726378ecd@mail.gmail.com> <2ea3fae10611041921h5d453fbao90b21e9bb793e1e@mail.gmail.com> <2ea3fae10611042033r7fe4d03fj3022efd73e222432@mail.gmail.com> <2ea3fae10611042305i4e6a05f8yba2cfab323ab3fd7@mail.gmail.com> Message-ID: <2ea3fae10611051117ubcd6e40re81ef86611436e7e@mail.gmail.com> On 11/5/06, Eric W. Biederman wrote: > An interesting question is if we make a bImage target that does everything > except the decompression (because nothing would be compressed) would that > suit your needs? because the decompression in bzImage, So could do some selection about compression way or even not compression. That is good point, Eric. So I can use startup_32 in head.S in kernel. YH From svn at openbios.org Sun Nov 5 20:20:36 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 19:20:36 -0000 Subject: [LinuxBIOS] #30: Support for VIA VT82C686 in flashrom Message-ID: <060.b7bf006a0db81bb4230b08879c9216f8@openbios.org> #30: Support for VIA VT82C686 in flashrom ---------------------------+------------------------------------------------ Reporter: stepan | Owner: stepan Type: defect | Status: new Priority: major | Milestone: Enhance the flashrom utility Component: flashrom | Version: v2 Keywords: | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Due_close: MM/DD/YYYY | ---------------------------+------------------------------------------------ This patch adds support for the VIA VT82C686 to the flashrom utility. -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 20:23:08 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 19:23:08 -0000 Subject: [LinuxBIOS] #31: Do proper checking for flash erase for SST FWH parts Message-ID: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> #31: Do proper checking for flash erase for SST FWH parts ---------------------------+------------------------------------------------ Reporter: stepan | Owner: stepan Type: defect | Status: new Priority: major | Milestone: Enhance the flashrom utility Component: flashrom | Version: v2 Keywords: | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Due_close: MM/DD/YYYY | ---------------------------+------------------------------------------------ Instead of checking the first byte only, the whole part is checked now. This will detect any improper erase. The patch removes a FIXME. :-) Signed-off-by: Stefan Reinauer -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 20:25:20 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 19:25:20 -0000 Subject: [LinuxBIOS] #31: Do proper checking for flash erase for SST FWH parts In-Reply-To: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> References: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> Message-ID: <069.fe69a488967f31eb06df2ed986b6d253@openbios.org> #31: Do proper checking for flash erase for SST FWH parts ----------------------------+----------------------------------------------- Reporter: stepan | Owner: stepan Type: defect | Status: assigned Priority: minor | Milestone: Enhance the flashrom utility Component: flashrom | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY ----------------------------+----------------------------------------------- Changes (by stepan): * priority: major => minor * status: new => assigned -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 20:25:55 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 19:25:55 -0000 Subject: [LinuxBIOS] #30: Support for VIA VT82C686 in flashrom In-Reply-To: <060.b7bf006a0db81bb4230b08879c9216f8@openbios.org> References: <060.b7bf006a0db81bb4230b08879c9216f8@openbios.org> Message-ID: <069.54c9f755494d2243457c5c7c79eacad3@openbios.org> #30: Support for VIA VT82C686 in flashrom -----------------------------+---------------------------------------------- Reporter: stepan | Owner: stepan Type: enhancement | Status: assigned Priority: minor | Milestone: Enhance the flashrom utility Component: flashrom | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY -----------------------------+---------------------------------------------- Changes (by stepan): * priority: major => minor * status: new => assigned * type: defect => enhancement Comment: Signed-off-by: Stefan Reinauer -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 20:30:01 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 19:30:01 -0000 Subject: [LinuxBIOS] #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M In-Reply-To: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> References: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> Message-ID: <069.8409ece8f8d7a6f159cdcbd765b410d8@openbios.org> #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M -----------------------------+---------------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: closed Priority: major | Milestone: Enhance the flashrom utility Component: flashrom | Version: v2 Resolution: fixed | Keywords: Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY -----------------------------+---------------------------------------------- Changes (by uwe): * milestone: => Enhance the flashrom utility -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 20:31:50 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 19:31:50 -0000 Subject: [LinuxBIOS] #32: New motherboard IEI NOVA4899R Message-ID: <060.c3a3c2f45e93a6296863c1cd84d73236@openbios.org> #32: New motherboard IEI NOVA4899R --------------------------------------------------------+------------------- Reporter: Luis Correia | Owner: somebody Type: enhancement | Status: new Priority: trivial | Milestone: Going mainstream Component: code | Version: v2 Keywords: | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Due_close: MM/DD/YYYY | --------------------------------------------------------+------------------- WARNING!!! this is work in progress! The following files add support for the IEI NOVA4899R 5.25 SBC mainboard. As of now, it does boot with serial console only (no vga), and two ethernet cards work sometimes. This has to do with the IRQ assignments, which are a complete mess. USB is now apparently working, but I can't make any device to be recognized. The PCI slot is still unusable due to the IRQ thing. Audio, other serial ports, irda, floppy and paralell port support is unknown aka untested yet. Please forgive me for not supplying a proper patch file. Signed-off-by: Luis Correia -- Ticket URL: LinuxBIOS From smithbone at gmail.com Sun Nov 5 20:06:40 2006 From: smithbone at gmail.com (Richard Smith) Date: Sun, 05 Nov 2006 13:06:40 -0600 Subject: [LinuxBIOS] 440bx stuff In-Reply-To: <20061105175015.GA32414@greenwood> References: <454E0C5E.3020501@gmail.com> <20061105175015.GA32414@greenwood> Message-ID: <454E3640.40609@gmail.com> Uwe Hermann wrote: >> This has been done. It's now i82371eb. > > Why not 82371eb (that's the official name AFAIK)? Is there some > requirement that directories have to start with a letter? Its a C thing. You can't start a variable with a number. That allows you to match the directory name to the struct statements in the code. > I think I'll have a look at this in the next few days. But I might use > the 855pm code (derived from e7501) as a basis, that looks even better. the e7501 datasheet has a date on it thats almost a full year earlier than the 855pm. I think the register names and operation may be closer to the 440bx. But feel free to use whatever. Its mostly about framework. -- Richard A. Smith From svn at openbios.org Sun Nov 5 20:33:37 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 19:33:37 -0000 Subject: [LinuxBIOS] #33: New motherboard IEI NOVA4899R Message-ID: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> #33: New motherboard IEI NOVA4899R --------------------------------------------------------+------------------- Reporter: Luis Correia | Owner: somebody Type: enhancement | Status: new Priority: trivial | Milestone: Going mainstream Component: code | Version: v2 Keywords: | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Due_close: MM/DD/YYYY | --------------------------------------------------------+------------------- WARNING!!! this is work in progress! The following files add support for the IEI NOVA4899R 5.25 SBC mainboard. As of now, it does boot with serial console only (no vga), and two ethernet cards work sometimes. This has to do with the IRQ assignments, which are a complete mess. USB is now apparently working, but I can't make any device to be recognized. The PCI slot is still unusable due to the IRQ thing. Audio, other serial ports, irda, floppy and paralell port support is unknown aka untested yet. Please forgive me for not supplying a proper patch file. Signed-off-by: Luis Correia -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 20:36:19 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 19:36:19 -0000 Subject: [LinuxBIOS] #33: New motherboard IEI NOVA4899R In-Reply-To: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> References: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> Message-ID: <069.cf08b7c71481f471f3554acf73472397@openbios.org> #33: New motherboard IEI NOVA4899R ---------------------------------------------------------+------------------ Reporter: Luis Correia | Owner: somebody Type: enhancement | Status: new Priority: trivial | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY ---------------------------------------------------------+------------------ Comment (by Luis Correia ): Please close this ticket as it was a browser mishap. Luis Correia -- Ticket URL: LinuxBIOS From segher at kernel.crashing.org Sun Nov 5 20:49:54 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 5 Nov 2006 20:49:54 +0100 Subject: [LinuxBIOS] r2489 - trunk/LinuxBIOSv2/util/flashrom In-Reply-To: <200611051828.kA5ISVA1019141@gate.crashing.org> References: <200611051828.kA5ISVA1019141@gate.crashing.org> Message-ID: <1BD06569-949E-4243-909E-69359AAD8994@kernel.crashing.org> > +/* Datasheet: http://www.intel.com/design/intarch/datashts/ > 290562.htm */ Trivial in this case, but in general: can we please add the name or document number (not just the URL) for datasheets and other documentation? Vendors just _love_ to rearrange their websites (and some pull their old docs altogether); if we have the name/number (or even just the filename of the pdf) at least there's a chance to google for it again (either on the vendor's site or on some archive). > + the lower 64-Kbyte BIOS block (E00000- > EFFFF) at the top A 0 too many. > + of 1 Mbyte, or the aliases at the top of 4 > Gbyte > + (FFFE0000-FFFEFFF) result in the generation > of BIOSCS#. But you balanced it by dropping an F :-) > + Set bit 2: BIOSCS# Write Protect Enable (1=enable, > 0=disable). */ The bit is misnamed in the datasheet: it's the "write enable" bit, not the "write protect enable" (which would be "write disable"). > + printf("tried to set 0x%x to 0x%x on %s failed (WARNING ONLY) > \n", xbcs, new, name); Warning only? It's pretty damn fatal :-) Or does this mean "trying to continue anyway" (which might not be such a great plan for a utility that can brick your system)? Would be nice if this message could be made a bit less cryptic, for example, "WARNING: failed setting %s register %#x to %#x\n". Yes I realise this is probably copied all over the place ;-) Segher From svn at openbios.org Sun Nov 5 20:56:44 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 19:56:44 -0000 Subject: [LinuxBIOS] #20: Cleanup of all CHIP_NAME() entries In-Reply-To: <060.68503be5d6132cbfcbc83dcf54946a9a@openbios.org> References: <060.68503be5d6132cbfcbc83dcf54946a9a@openbios.org> Message-ID: <069.7bfa17ffb842832f85c3cb08a23030a8@openbios.org> #20: Cleanup of all CHIP_NAME() entries ----------------------------+----------------------------------------------- Reporter: uwe | Owner: uwe Type: defect | Status: closed Priority: minor | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: fixed | Keywords: Include_gantt: 0 | Dependencies: Due_assign: DD/MM/YYYY | Due_close: DD/MM/YYYY ----------------------------+----------------------------------------------- Comment (by anonymous): > In my opinion we should go further and drop the CHIP_NAME macro completely. > So instead of CHIP_NAME("Via VT8263") it should just read "Via VT8263" No, it would read .name = "Via VT8263" . _Always_ use designated initialisers, that's what they're there for (well there are exceptions of course, but those are just that: exceptions). > The CHIP_NAME macro was invented at a time when we were really tight in rom space, but it is obviously the wrong approach. I don't see how a macro would help any in this regard? Segher -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 21:03:34 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 20:03:34 -0000 Subject: [LinuxBIOS] #33: Signed-off-by in trac is meaningless Message-ID: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> #33: Signed-off-by in trac is meaningless ---------------------------+------------------------------------------------ Reporter: segher | Owner: somebody Type: defect | Status: new Priority: critical | Milestone: Resolve license issues Component: misc | Version: Keywords: trac | Include_gantt: 1 Dependencies: | Due_assign: MM/DD/YYYY Due_close: MM/DD/YYYY | ---------------------------+------------------------------------------------ See for example ticket #26 -- which of those two patches does the Signed-off-by: refer to? -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 21:08:04 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 20:08:04 -0000 Subject: [LinuxBIOS] #33: Signed-off-by in trac is meaningless In-Reply-To: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> References: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> Message-ID: <069.476308f682fe973b537031e8212fba04@openbios.org> #33: Signed-off-by in trac is meaningless ----------------------------+----------------------------------------------- Reporter: segher | Owner: somebody Type: defect | Status: new Priority: critical | Milestone: Resolve license issues Component: misc | Version: Resolution: | Keywords: trac Include_gantt: 1 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY ----------------------------+----------------------------------------------- Comment (by segher): Acked-by: like in #14 doesn't say which patch it is supporting, either. Worse, that ticket doesn't hold any patches; it merely points to a mailing list archive that happily dropped the message attachments. -- Ticket URL: LinuxBIOS From luis.f.correia at gmail.com Sun Nov 5 21:13:03 2006 From: luis.f.correia at gmail.com (Luis Correia) Date: Sun, 5 Nov 2006 20:13:03 +0000 Subject: [LinuxBIOS] #33: Signed-off-by in trac is meaningless In-Reply-To: <069.476308f682fe973b537031e8212fba04@openbios.org> References: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> <069.476308f682fe973b537031e8212fba04@openbios.org> Message-ID: On 11/5/06, LinuxBIOS wrote: > #33: Signed-off-by in trac is meaningless > ----------------------------+----------------------------------------------- > Reporter: segher | Owner: somebody > Type: defect | Status: new > Priority: critical | Milestone: Resolve license issues > Component: misc | Version: > Resolution: | Keywords: trac > Include_gantt: 1 | Dependencies: > Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY > ----------------------------+----------------------------------------------- > Comment (by segher): > > Acked-by: like in #14 doesn't say which patch it is supporting, either. > Worse, that ticket doesn't hold any patches; it merely points to a mailing > list > archive that happily dropped the message attachments. > > -- > Ticket URL: > LinuxBIOS What should be done then? Send the PATCH to the mailing list instead of creating the ticket? I'm still struggling to provide a proper diff file for ticket #32, will be done in a sec. Luis From svn at openbios.org Sun Nov 5 21:23:58 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 20:23:58 -0000 Subject: [LinuxBIOS] #32: New motherboard IEI NOVA4899R In-Reply-To: <060.c3a3c2f45e93a6296863c1cd84d73236@openbios.org> References: <060.c3a3c2f45e93a6296863c1cd84d73236@openbios.org> Message-ID: <069.42b558a30acc8a714c05881afa13df41@openbios.org> #32: New motherboard IEI NOVA4899R ---------------------------------------------------------+------------------ Reporter: Luis Correia | Owner: somebody Type: enhancement | Status: new Priority: trivial | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY ---------------------------------------------------------+------------------ Comment (by Luis Correia ): Please accept my apologies for taking so long to produce a proper patch. I'm new to SVN and providing a 'svn diff' didn't work this time. This fileset is loosely based on the eaglelion 5bcm mainboard, as it was one that shared most components to this board. Some ideas from OLPC, although not all of them are working. Any help is appreciated. -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 21:26:53 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 20:26:53 -0000 Subject: [LinuxBIOS] #33: Signed-off-by in trac is meaningless In-Reply-To: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> References: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> Message-ID: <069.cce461280d6d74d0152f9148b27bda3f@openbios.org> #33: Signed-off-by in trac is meaningless ----------------------------+----------------------------------------------- Reporter: segher | Owner: somebody Type: defect | Status: new Priority: critical | Milestone: Resolve license issues Component: misc | Version: Resolution: | Keywords: trac Include_gantt: 1 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY ----------------------------+----------------------------------------------- Comment (by uwe): Replying to [ticket:33 segher]: > See for example ticket #26 -- which of those two patches does > the Signed-off-by: refer to? Both. But I agree that we should probably have a sign-off for _every_ patch, even if it's only a small variation of an already signed-off patch. -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 21:33:32 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 20:33:32 -0000 Subject: [LinuxBIOS] #33: Signed-off-by in trac is meaningless In-Reply-To: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> References: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> Message-ID: <069.f8f85db8f095938260ffc187fec0be2b@openbios.org> #33: Signed-off-by in trac is meaningless ----------------------------+----------------------------------------------- Reporter: segher | Owner: somebody Type: defect | Status: new Priority: critical | Milestone: Resolve license issues Component: misc | Version: Resolution: | Keywords: trac Include_gantt: 1 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY ----------------------------+----------------------------------------------- Comment (by uwe): Replying to [comment:1 segher]: > Acked-by: like in #14 doesn't say which patch it is supporting, either. Hm, true. The intention usually is to support the latest incarnation of the patch, but we should make that explicit, I think. > Worse, that ticket doesn't hold any patches; it merely points to a mailing list > archive that happily dropped the message attachments. The ticket should have the patch, yes. I'll append it soon. There was a Trac bug that caused some mails to not being sent to the list (might be related to this issue). Stefan has since fixed that bug. The mailing list archive _should_ always contain attachments (the patches), that used to work... -- Ticket URL: LinuxBIOS From stepan at coresystems.de Sun Nov 5 21:34:05 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 5 Nov 2006 21:34:05 +0100 Subject: [LinuxBIOS] r2489 - trunk/LinuxBIOSv2/util/flashrom In-Reply-To: <1BD06569-949E-4243-909E-69359AAD8994@kernel.crashing.org> References: <200611051828.kA5ISVA1019141@gate.crashing.org> <1BD06569-949E-4243-909E-69359AAD8994@kernel.crashing.org> Message-ID: <20061105203405.GB18221@coresystems.de> * Segher Boessenkool [061105 20:49]: > Trivial in this case, but in general: can we please add > the name or document number (not just the URL) for datasheets > and other documentation? Vendors just _love_ to rearrange > their websites (and some pull their old docs altogether); > if we have the name/number (or even just the filename of > the pdf) at least there's a chance to google for it again > (either on the vendor's site or on some archive). good hint. I added this to the devel guidelines. > >+ Set bit 2: BIOSCS# Write Protect Enable (1=enable, > >0=disable). */ > > The bit is misnamed in the datasheet: it's the "write enable" > bit, not the "write protect enable" (which would be "write disable"). nitpicking award 2006 ;-) > >+ printf("tried to set 0x%x to 0x%x on %s failed (WARNING > >ONLY) \n", xbcs, new, name); > > Warning only? It's pretty damn fatal :-) Or does this mean > "trying to continue anyway" (which might not be such a great > plan for a utility that can brick your system)? it actually is. For the Via Epia you have to continue, because this test basically fails every second time. But flashing works like a charme. It's not that bad either, because if it really fails, you fail to write to flash. In which case you dont brick your system. > Would be nice if this message could be made a bit less cryptic, > for example, "WARNING: failed setting %s register %#x to %#x\n". > Yes I realise this is probably copied all over the place ;-) Good idea. Or should we just drop this message all together? Or make it printf_debug? If its an error, writing will fail later on anyways. -- 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 Sun Nov 5 21:37:36 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 20:37:36 -0000 Subject: [LinuxBIOS] #20: Cleanup of all CHIP_NAME() entries In-Reply-To: <060.68503be5d6132cbfcbc83dcf54946a9a@openbios.org> References: <060.68503be5d6132cbfcbc83dcf54946a9a@openbios.org> Message-ID: <069.70cc282ecc55ca0f8114b84a2690a2c1@openbios.org> #20: Cleanup of all CHIP_NAME() entries ----------------------------+----------------------------------------------- Reporter: uwe | Owner: uwe Type: defect | Status: closed Priority: minor | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: fixed | Keywords: Include_gantt: 0 | Dependencies: Due_assign: DD/MM/YYYY | Due_close: DD/MM/YYYY ----------------------------+----------------------------------------------- Comment (by stepan): Replying to [comment:3 anonymous]: > > The CHIP_NAME macro was invented at a time when we were really tight in rom space, but it is obviously the wrong approach. > > I don't see how a macro would help any in this regard? It was used to drop the "name" in the structure completely, thus saving a couple of bytes for every device. Since romcc was easily bloating auto.c up to 64k, the savings can be considered non-existent -- Ticket URL: LinuxBIOS From segher at kernel.crashing.org Sun Nov 5 21:40:04 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 5 Nov 2006 21:40:04 +0100 Subject: [LinuxBIOS] #31: Do proper checking for flash erase for SST FWH parts In-Reply-To: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> References: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> Message-ID: > Instead of checking the first byte only, the whole part is checked > now. > This will detect any improper erase. The patch removes a FIXME. :-) ... and adds one, heh :-) > Signed-off-by: Stefan Reinauer The patch never made it to the mailing list. To review the patch I now have to: 1) Click the link in the trac mail; 2) Find the correct patch in the list, click it; 3) Scroll all the way to the bottom, click "download original format"; 4) Remember the file name (and see that it has a MIME type of; "text/x-diff", whatever that is); 5) Open the file in some editor; 6) Copy all text; 7) Press "reply" somewhere in the trac page; 8) Paste that patch; 9) Fixup all mangling (insofar as possible) that the HTML textfield did to the whitespace etc.; 10) Type my comments; 11) Click "submit"; 12) See my mail on the mailinglist and discover it doesn't do mail threading; 13) Clean up the garbage file. While with reviewing a patch on a mailing list I do 1) Hit the "reply to all" button (so that all interested people will see my comments first thing!); 2) Type my comments. This isn't working too well, even for just *reading* submitted patches I'll have to do steps 1) and 2) now, and close the browser window and return to the mail window; this is a non-linear workflow, while with mail I just go scroll-scroll-scroll-scroll. LinuxBIOS is really low-volume but it already almost takes me longer to keep up with the patch flow than it takes for Linux. Don't take this as a flame, I just need a working working environment :-) Segher From svn at openbios.org Sun Nov 5 21:44:37 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 20:44:37 -0000 Subject: [LinuxBIOS] #33: Signed-off-by in trac is meaningless In-Reply-To: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> References: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> Message-ID: <069.5af62a678d7067e432d503ffce3c4572@openbios.org> #33: Signed-off-by in trac is meaningless ----------------------------+----------------------------------------------- Reporter: segher | Owner: somebody Type: defect | Status: new Priority: critical | Milestone: Resolve license issues Component: misc | Version: Resolution: | Keywords: trac Include_gantt: 1 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY ----------------------------+----------------------------------------------- Comment (by stepan): Signed-off-by: and Acked-by: always corresponds to the latest added patch, unless otherwise noted. Since each patch and each comment has a timestamp, everything is clear, right? -- Ticket URL: LinuxBIOS From segher at kernel.crashing.org Sun Nov 5 21:46:29 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 5 Nov 2006 21:46:29 +0100 Subject: [LinuxBIOS] #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M In-Reply-To: <20061105115759.GC17235@coresystems.de> References: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> <20061105033535.1862.qmail@cdy.org> <20061105115759.GC17235@coresystems.de> Message-ID: <31F5F7E4-40C0-4163-9F8B-CB09CD50A778@kernel.crashing.org> >> I don't work well with web applications but tried submitting a note >> via trac anyway, only to be rejected as potential spam, according to >> "Akismet". I would love some way to interact with trac that is not >> web based. Does anyone know? > > it is possible to send emails to trac-at-linuxbios.org (lets hope > spammers wont find out this way. I had to disable this feature in the > old tracker due to massive amounts of spam) Will it recognise a) what ticket I'm replying to and b) what comment I'm replying to? From the threading mail headers, preferably. If both are true, we can probably make this work, there'll still be a load of "minor annoyances" but all those can be easily fixed. Segher From smithbone at gmail.com Sun Nov 5 21:54:54 2006 From: smithbone at gmail.com (Richard Smith) Date: Sun, 05 Nov 2006 14:54:54 -0600 Subject: [LinuxBIOS] Using trac In-Reply-To: References: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> Message-ID: <454E4F9E.6030201@gmail.com> Segher Boessenkool wrote: > LinuxBIOS is really low-volume but it already almost takes me longer > to keep up with the patch flow than it takes for Linux. > > > Don't take this as a flame, I just need a working working > environment :-) OLPC uses trac as well and I'm going to have to side with Segher. Although it does keep things together its a much larger PITA to work with. And I find it cumbersome to find the stuff I'm looking for unless I just happen to remember the Trac ID#. However, An issue tracker is essential. I don't want us to stop using it but the workflow could be a lot nicer. Finding/implementing some sort of trac<->mailing list gateway would be ideal. This is really OT for this trac ticket so I'm replying to the list rather than in trac. -- Richard A. Smith From segher at kernel.crashing.org Sun Nov 5 21:57:16 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 5 Nov 2006 21:57:16 +0100 Subject: [LinuxBIOS] 440bx stuff In-Reply-To: <454E3640.40609@gmail.com> References: <454E0C5E.3020501@gmail.com> <20061105175015.GA32414@greenwood> <454E3640.40609@gmail.com> Message-ID: <9CB2096C-E78B-49A8-B7CA-D8F5F4300D62@kernel.crashing.org> >>> This has been done. It's now i82371eb. >> >> Why not 82371eb (that's the official name AFAIK)? Is there some >> requirement that directories have to start with a letter? > > Its a C thing. You can't start a variable with a number. That allows > you to match the directory name to the struct statements in the code. Why not call it piix4e (or just piix4), much easier to type and proofread and understand in general? Segher From stepan at coresystems.de Sun Nov 5 21:57:41 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 5 Nov 2006 21:57:41 +0100 Subject: [LinuxBIOS] #31: Do proper checking for flash erase for SST FWH parts In-Reply-To: References: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> Message-ID: <20061105205741.GA1578@coresystems.de> * Segher Boessenkool [061105 21:40]: > The patch never made it to the mailing list. To review the > patch I now have to: I contacted the trac folks for that problem. Attachments should make it into notification mails. > Don't take this as a flame, I just need a working working > environment :-) Of course not. ;-) There was public discussion on the symposium about which tracker to use, and we all participated, so I am of course glad about your late feedback. Nobody wanted bugzilla nor roundup. Nobody opposed to trac either, so we worked around some problems, and bought us into some others. Patch management on the mailing list just does not work. It never will. Here's the golden open source rule that applies to trac as well: If you want it fixed, send a fix ;-) Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From segher at kernel.crashing.org Sun Nov 5 22:03:19 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 5 Nov 2006 22:03:19 +0100 Subject: [LinuxBIOS] r2489 - trunk/LinuxBIOSv2/util/flashrom In-Reply-To: <20061105203405.GB18221@coresystems.de> References: <200611051828.kA5ISVA1019141@gate.crashing.org> <1BD06569-949E-4243-909E-69359AAD8994@kernel.crashing.org> <20061105203405.GB18221@coresystems.de> Message-ID: <2B875EFD-893C-4F67-A841-CD6D1C6A7409@kernel.crashing.org> >>> + Set bit 2: BIOSCS# Write Protect Enable (1=enable, >>> 0=disable). */ >> >> The bit is misnamed in the datasheet: it's the "write enable" >> bit, not the "write protect enable" (which would be "write disable"). > > nitpicking award 2006 ;-) Not really -- I thought I spotted a code error but then went to look at the datasheet and _it_ is wrong. What else is new :-) >>> + printf("tried to set 0x%x to 0x%x on %s failed (WARNING >>> ONLY) \n", xbcs, new, name); >> >> Warning only? It's pretty damn fatal :-) Or does this mean >> "trying to continue anyway" (which might not be such a great >> plan for a utility that can brick your system)? > > it actually is. For the Via Epia you have to continue, because this > test basically fails every second time. But flashing works like a > charme. > > It's not that bad either, because if it really fails, you fail to > write > to flash. In which case you dont brick your system. Well you might be able to write to _half_ the flash... >> Would be nice if this message could be made a bit less cryptic, >> for example, "WARNING: failed setting %s register %#x to %#x\n". >> Yes I realise this is probably copied all over the place ;-) > > Good idea. Or should we just drop this message all together? Or > make it > printf_debug? If its an error, writing will fail later on anyways. Nah, report problems as soon as you detect them (unless you're actually coding a workaround for a chip bug). Segher From smithbone at gmail.com Sun Nov 5 22:03:44 2006 From: smithbone at gmail.com (Richard Smith) Date: Sun, 05 Nov 2006 15:03:44 -0600 Subject: [LinuxBIOS] #31: Do proper checking for flash erase for SST FWH parts In-Reply-To: <20061105205741.GA1578@coresystems.de> References: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> <20061105205741.GA1578@coresystems.de> Message-ID: <454E51B0.70505@gmail.com> Stefan Reinauer wrote: > Patch management on the mailing list just does not work. It never will. > The Linux Kernel guys seem to think otherwise. -- Richard A. Smith From stepan at coresystems.de Sun Nov 5 22:04:34 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 5 Nov 2006 22:04:34 +0100 Subject: [LinuxBIOS] Using trac In-Reply-To: <454E4F9E.6030201@gmail.com> References: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> <454E4F9E.6030201@gmail.com> Message-ID: <20061105210434.GA10587@coresystems.de> * Richard Smith [061105 21:54]: > Although it does keep things together its a much larger PITA to work > with. And I find it cumbersome to find the stuff I'm looking for unless > I just happen to remember the Trac ID#. The search function is not worse than searching the mailing list.. > Finding/implementing some sort of trac<->mailing list gateway would be > ideal. Ok. So what should the gateway look like? I am pretty unreligious about which system to use, but we should stay with what we decided to use at least until we find a better solution or we just fix the solution we have. But this is only possible if there's a common sense about the requirements. As always: He who sends a working patch usually wins. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From segher at kernel.crashing.org Sun Nov 5 22:06:00 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 5 Nov 2006 22:06:00 +0100 Subject: [LinuxBIOS] r2489 - trunk/LinuxBIOSv2/util/flashrom In-Reply-To: <200611051828.kA5ISVA1019141@gate.crashing.org> References: <200611051828.kA5ISVA1019141@gate.crashing.org> Message-ID: <1607A6C9-B9EC-4FF9-9492-5227BF64F8A9@kernel.crashing.org> > + /* Set bit 9: 1-Meg Extended BIOS Enable (PCI master accesses to > + FFF00000-FFF7FFFF are forwarded to ISA). > + Set bit 7: Extended BIOS Enable (PCI master accesses to > + FFF80000-FFFDFFFF are forwarded to ISA). > + Set bit 6: Lower BIOS Enable (PCI master, or ISA master > accesses to > + the lower 64-Kbyte BIOS block (E00000 EFFFF) > at the top > + of 1 Mbyte, or the aliases at the top of 4 > Gbyte > + (FFFE0000-FFFEFFF) result in the generation > of BIOSCS#. One more thing, you might want to add a comment to say that accesses to the 64kB @ f00000 and it's alias are always forwarded to the ISA bus. Segher From stepan at coresystems.de Sun Nov 5 22:09:46 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 5 Nov 2006 22:09:46 +0100 Subject: [LinuxBIOS] #31: Do proper checking for flash erase for SST FWH parts In-Reply-To: <454E51B0.70505@gmail.com> References: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> <20061105205741.GA1578@coresystems.de> <454E51B0.70505@gmail.com> Message-ID: <20061105210946.GA17340@coresystems.de> * Richard Smith [061105 22:03]: > Stefan Reinauer wrote: > > > Patch management on the mailing list just does not work. It never will. > > > > The Linux Kernel guys seem to think otherwise. 1. There are _lots_ of people hired full time to check no patches get lost. 2. Patches still get lost or stay ignored pretty often. -- 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 Sun Nov 5 22:13:05 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 5 Nov 2006 22:13:05 +0100 Subject: [LinuxBIOS] 440bx stuff In-Reply-To: <9CB2096C-E78B-49A8-B7CA-D8F5F4300D62@kernel.crashing.org> References: <454E0C5E.3020501@gmail.com> <20061105175015.GA32414@greenwood> <454E3640.40609@gmail.com> <9CB2096C-E78B-49A8-B7CA-D8F5F4300D62@kernel.crashing.org> Message-ID: <20061105211305.GA22679@coresystems.de> * Segher Boessenkool [061105 21:57]: > >>> This has been done. It's now i82371eb. > > Why not call it piix4e (or just piix4), much easier to type > and proofread and understand in general? because we called all the others after their part numbers rather than their code names, too. -- 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 Sun Nov 5 22:14:13 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 21:14:13 -0000 Subject: [LinuxBIOS] #20: Cleanup of all CHIP_NAME() entries In-Reply-To: <060.68503be5d6132cbfcbc83dcf54946a9a@openbios.org> References: <060.68503be5d6132cbfcbc83dcf54946a9a@openbios.org> Message-ID: <069.911aee6a367115ef3ffa87a9ac6f5dd1@openbios.org> #20: Cleanup of all CHIP_NAME() entries ----------------------------+----------------------------------------------- Reporter: uwe | Owner: uwe Type: defect | Status: closed Priority: minor | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: fixed | Keywords: Include_gantt: 0 | Dependencies: Due_assign: DD/MM/YYYY | Due_close: DD/MM/YYYY ----------------------------+----------------------------------------------- Comment (by segher): > It was used to drop the "name" in the structure completely, thus saving a couple of bytes for every device. Since romcc was easily bloating auto.c up to 64k, the savings can be considered non-existent Ah I see, it's conditionally compiled out. Yeah let's always enable it, it doesn't take much space, and the (potentially) improved diagnostics are worth it /me thinks. Segher -- Ticket URL: LinuxBIOS From smithbone at gmail.com Sun Nov 5 22:13:15 2006 From: smithbone at gmail.com (Richard Smith) Date: Sun, 05 Nov 2006 15:13:15 -0600 Subject: [LinuxBIOS] Using trac In-Reply-To: <20061105210434.GA10587@coresystems.de> References: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> <454E4F9E.6030201@gmail.com> <20061105210434.GA10587@coresystems.de> Message-ID: <454E53EB.5040503@gmail.com> Stefan Reinauer wrote: > The search function is not worse than searching the mailing list.. Its on organizational thing rather than a brute force search function thing. >> Finding/implementing some sort of trac<->mailing list gateway would be >> ideal. > > Ok. So what should the gateway look like? > > I am pretty unreligious about which system to use, but we should stay > with what we decided to use at least until we find a better solution or > we just fix the solution we have. But this is only possible if there's a > common sense about the requirements. > > As always: He who sends a working patch usually wins. I don't claim to have solutions... It's a complex task. I'll continue to use trac until we get something worked out. I'm just backing up Segher that dealing with patch review in Trac is not as easy as looking at them on the mailing list. One of the OLPC guys is a trac developer and maintainer of our trac interface. I'll try to buy him a beer when I'm up there next week and see what his thoughts are on something like this. -- Richard A. Smith From svn at openbios.org Sun Nov 5 22:22:04 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 21:22:04 -0000 Subject: [LinuxBIOS] #33: Signed-off-by in trac is meaningless In-Reply-To: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> References: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> Message-ID: <069.48adb0126737a6c1a5ae0d5caea094bb@openbios.org> #33: Signed-off-by in trac is meaningless ----------------------------+----------------------------------------------- Reporter: segher | Owner: somebody Type: defect | Status: new Priority: critical | Milestone: Resolve license issues Component: misc | Version: Resolution: | Keywords: trac Include_gantt: 1 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY ----------------------------+----------------------------------------------- Comment (by segher): > The mailing list archive _should_ always contain attachments (the patches), that used to work... It actually did have the patches but they couldn't be viewed in my browser (either the sender used the wrong MIME-type, or the web server did and the mailing list archive software is too stupid to set it from the mail and just guesses instead. Or something else still ;-) ) Segher -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 5 22:27:54 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 21:27:54 -0000 Subject: [LinuxBIOS] #33: Signed-off-by in trac is meaningless In-Reply-To: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> References: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> Message-ID: <069.e913f60f95e6880fb601236baf698901@openbios.org> #33: Signed-off-by in trac is meaningless ----------------------------+----------------------------------------------- Reporter: segher | Owner: somebody Type: defect | Status: new Priority: critical | Milestone: Resolve license issues Component: misc | Version: Resolution: | Keywords: trac Include_gantt: 1 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY ----------------------------+----------------------------------------------- Comment (by Luis Correia ): Please kill me :) Honestly, being new here, i must agree that working out patches through trac is not easy... -- Ticket URL: LinuxBIOS From segher at kernel.crashing.org Sun Nov 5 22:32:59 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 5 Nov 2006 22:32:59 +0100 Subject: [LinuxBIOS] #33: Signed-off-by in trac is meaningless In-Reply-To: <069.5af62a678d7067e432d503ffce3c4572@openbios.org> References: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> <069.5af62a678d7067e432d503ffce3c4572@openbios.org> Message-ID: <3A45F617-C98B-4CDD-BFA6-77ED2ECF6546@kernel.crashing.org> > #33: Signed-off-by in trac is meaningless > Signed-off-by: and Acked-by: always corresponds to the latest > added patch, > unless otherwise noted. Since each patch and each comment has a > timestamp, > everything is clear, right? IU&^*^*(^(*^*(^*(^(*&!!!!!!!!!!!!!! Internal Error Sorry, can not save your changes. This ticket has been modified by someone else since you started TracGuide ? The Trac User and Administration Guide --- Well I'll paste my comment here then. Here goes: --- > Signed-off-by: and Acked-by: always corresponds to the latest added patch, unless otherwise noted. Since each patch and each comment has a timestamp, everything is clear, right? So two patches by Uwe on a ticket with 3 comments -- yeah sure we can handle that. Now how about a ticket with 12 proposed patches by 4 people, each fixing part of the problem, some superseded by newer patches; and all of that intermingled with some odd 100 comments? Can you still align that so that you clearly see or supposed "paper" track of origin of the code? Maybe this is all just a symptom of a greater problem: patches should always be presented with a proposed check-in comment, and the signed-off-by should be part of that comment. Segher From svn at openbios.org Sun Nov 5 22:36:04 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 21:36:04 -0000 Subject: [LinuxBIOS] #33: Signed-off-by in trac is meaningless In-Reply-To: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> References: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> Message-ID: <069.653566ea4c9ce329568a8b4fe67e3f30@openbios.org> #33: Signed-off-by in trac is meaningless ----------------------------+----------------------------------------------- Reporter: segher | Owner: somebody Type: defect | Status: new Priority: critical | Milestone: Resolve license issues Component: misc | Version: Resolution: | Keywords: trac Include_gantt: 1 | Dependencies: Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY ----------------------------+----------------------------------------------- Comment (by segher): > Please kill me :) Heh no :-) > Honestly, being new here, i must agree that working out patches through trac is not easy... I'm not new to track, but I wonder if it really is fit for what we're trying to use it for right now. Segher -- Ticket URL: LinuxBIOS From segher at kernel.crashing.org Sun Nov 5 23:08:44 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 5 Nov 2006 23:08:44 +0100 Subject: [LinuxBIOS] 440bx stuff In-Reply-To: <20061105211305.GA22679@coresystems.de> References: <454E0C5E.3020501@gmail.com> <20061105175015.GA32414@greenwood> <454E3640.40609@gmail.com> <9CB2096C-E78B-49A8-B7CA-D8F5F4300D62@kernel.crashing.org> <20061105211305.GA22679@coresystems.de> Message-ID: <6CEB15EE-3DF8-4AF6-90F7-8807DCFCBB91@kernel.crashing.org> >> Why not call it piix4e (or just piix4), much easier to type >> and proofread and understand in general? > > because we called all the others after their part numbers rather than > their code names, too. But the PIIX4 family has 12-or-so part numbers and only very minor differences between those parts, they could all be handled by one and the same driver? Segher From uwe at hermann-uwe.de Sun Nov 5 23:15:53 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 5 Nov 2006 23:15:53 +0100 Subject: [LinuxBIOS] #33: Signed-off-by in trac is meaningless In-Reply-To: <3A45F617-C98B-4CDD-BFA6-77ED2ECF6546@kernel.crashing.org> References: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> <069.5af62a678d7067e432d503ffce3c4572@openbios.org> <3A45F617-C98B-4CDD-BFA6-77ED2ECF6546@kernel.crashing.org> Message-ID: <20061105221553.GA10831@greenwood> Hi, On Sun, Nov 05, 2006 at 10:32:59PM +0100, Segher Boessenkool wrote: > > Signed-off-by: and Acked-by: always corresponds to the latest > added patch, unless otherwise noted. Since each patch and each > comment has a timestamp, everything is clear, right? > > So two patches by Uwe on a ticket with 3 comments -- yeah sure > we can handle that. Now how about a ticket with 12 proposed > patches by 4 people, each fixing part of the problem, some superseded > by newer patches; and all of that intermingled with some odd 100 > comments? Can you still align that so that you clearly see or supposed > "paper" track of origin of the code? Where appropriate different issues should be "outsourced" to different tickets. Yes, there will probably be some tickets with a huge number of comments and patches. But that should be an exception. > Maybe this is all just a symptom of a greater problem: patches should > always be presented with a proposed check-in comment, and the > signed-off-by should be part of that comment. Yes, definately. I tried to do this for my last few patches already. It should be documented correctly in the development guidelines, though (those need some updates currently). 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 segher at kernel.crashing.org Sun Nov 5 23:26:06 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 5 Nov 2006 23:26:06 +0100 Subject: [LinuxBIOS] #31: Do proper checking for flash erase for SST FWH parts In-Reply-To: <20061105205741.GA1578@coresystems.de> References: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> <20061105205741.GA1578@coresystems.de> Message-ID: >> The patch never made it to the mailing list. To review the >> patch I now have to: > > I contacted the trac folks for that problem. Attachments should > make it > into notification mails. Thanks! >> Don't take this as a flame, I just need a working working >> environment :-) > > Of course not. ;-) There was public discussion on the symposium about > which tracker to use, and we all participated, so I am of course glad > about your late feedback. > > Nobody wanted bugzilla nor roundup. I wanted (a heavily patched) Bugzilla, but I of course know all the reasons people hate it. It "works for me" though ;-) > Nobody opposed to trac either, > so we worked around some problems, and bought us into some others. Yeah, it seems trac isn't too good a fit for us yet. Some patching will help, I have no idea how much effort it is. Do we have contact with some friendly trac developer(s) who could help us out? > Patch management on the mailing list just does not work. It never > will. It works fine (and has worked fine since basically forever) for: -- linux-kernel and all its children lists; -- gcc-patches; -- binutils; -- libc-alpha; -- many other GNU mailing lists; -- and who knows what else. The only thing that's needed are some "maintainers" (or whatever you want to call them, "gatekeepers" or whatever) who review patches and ACK or NAK them for inclusion into the main tree. And hey, we have that already. Even if patch review is done on the mailing list a) all actual checkins still go over SVN so trac sees them; and b) there's nothing that stops people from associating a mailing list mail with a trac ticket (either manually write a comment saying "patch posted at this-or-that-ml-archive-address", or have trac snoop the list and recognise certain tags and attach the stuff by itself (for example, "Closes: #21" and "Patch-for: #21", etc.) > Here's the golden open source rule that applies to trac as well: > If you want it fixed, send a fix ;-) Trust me I would if I could. But I a) don't have the time; and b) I don't have the configuration files or the exact source code for our installed version of trac. Segher From stepan at coresystems.de Sun Nov 5 23:38:05 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 5 Nov 2006 23:38:05 +0100 Subject: [LinuxBIOS] #33: Signed-off-by in trac is meaningless In-Reply-To: <3A45F617-C98B-4CDD-BFA6-77ED2ECF6546@kernel.crashing.org> References: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> <069.5af62a678d7067e432d503ffce3c4572@openbios.org> <3A45F617-C98B-4CDD-BFA6-77ED2ECF6546@kernel.crashing.org> Message-ID: <20061105223805.GA7619@coresystems.de> * Segher Boessenkool [061105 22:32]: > > Signed-off-by: and Acked-by: always corresponds to the latest > added patch, unless otherwise noted. Since each patch and each > comment has a timestamp, everything is clear, right? > > So two patches by Uwe on a ticket with 3 comments -- yeah sure > we can handle that. Now how about a ticket with 12 proposed > patches by 4 people, each fixing part of the problem, some superseded > by newer patches; and all of that intermingled with some odd 100 > comments? Can you still align that so that you clearly see or supposed > "paper" track of origin of the code? Not easily, because trac groups all attachments together instead of packing them into their submission comments. In such a case you should write the name of the patch you Sign-off or Ack. "Unless otherwise noted". In theory, a patch that solves half the problem only should not get Acked. > Maybe this is all just a symptom of a greater problem: patches should > always be presented with a proposed check-in comment, and the > signed-off-by should be part of that comment. Yes. The check-in comment should be "all of the discussion done on this check-in", so you get a non-ambiguous bidirectional connection between a check-in and the discussion that led to this check-in. If you go through the revisions of v1 and v2, you will find a lot of stuff that nobody will ever be able to find out what it was good for. This was fine when it was done, but it will not be fine for a high quality "product". And with a userbase of 10mio we should aim at that. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From uwe at hermann-uwe.de Sun Nov 5 23:39:03 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 5 Nov 2006 23:39:03 +0100 Subject: [LinuxBIOS] #31: Do proper checking for flash erase for SST FWH parts In-Reply-To: References: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> Message-ID: <20061105223902.GB10831@greenwood> On Sun, Nov 05, 2006 at 09:40:04PM +0100, Segher Boessenkool wrote: > The patch never made it to the mailing list. To review the > patch I now have to: > > 1) Click the link in the trac mail; The patches should really be sent together with the notifications. This will make your list a lot shorter. This will be basically almost equal to a mail-only handling... Optionally, you could use the web only.?Example: 1) Go to http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/26 2) Click on a patch. It'll be displayed syntax-highlighted in a nice format in your browser (or else your browser sucks ;) The problem is, you currently cannot "reply" to a patch there (as is possible with Trac comments) and insert your comments. Would this be nice-to-have? In that case we could fix Trac to do just that. The nice thing about Trac is that it is very customizable. We can fix it with patches, configure it, add plugins, whatever. We just need to have a common understanding of what features we expect from it, the rest is "easy"... > 2) Find the correct patch in the list, click it; > 3) Scroll all the way to the bottom, click "download original format"; > 4) Remember the file name (and see that it has a MIME type of; > "text/x-diff", whatever that is); > 5) Open the file in some editor; > 6) Copy all text; > 7) Press "reply" somewhere in the trac page; > 8) Paste that patch; > 9) Fixup all mangling (insofar as possible) that the HTML textfield > did to the whitespace etc.; Enclose patches you want to comment on with {{{ foo }}} That will prevent lots of mangling. > 12) See my mail on the mailinglist and discover it doesn't do > mail threading; I think it does a "flat" threading, i.e. all comments are marked as replies to the original issue. It could be better, but at least the mails are held together in a thread at all :) > While with reviewing a patch on a mailing list I do > > 1) Hit the "reply to all" button (so that all interested people > will see my comments first thing!); Well, that's a matter of taste. I have to delete whole _threads_ of duplicated mails all the time, just because I replied to a single mail in that thread. WTF? I'm subscribed, I _already_ get all the emails, why should I be CC'd explicitly all the time? That's why I remove all the CC's from every mail I reply to. I only reply to the list. End of rant ;-) 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 Sun Nov 5 23:42:31 2006 From: rminnich at gmail.com (ron minnich) Date: Sun, 5 Nov 2006 15:42:31 -0700 Subject: [LinuxBIOS] #33: Signed-off-by in trac is meaningless In-Reply-To: <20061105223805.GA7619@coresystems.de> References: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> <069.5af62a678d7067e432d503ffce3c4572@openbios.org> <3A45F617-C98B-4CDD-BFA6-77ED2ECF6546@kernel.crashing.org> <20061105223805.GA7619@coresystems.de> Message-ID: <13426df10611051442x692b77d1pe4b89173f5708bb3@mail.gmail.com> We have to have something like trak. If trak is not it then let's pick something better. But don't underestimate how hard the problem is, or how hard stefan has thought about this :-) ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From luis.f.correia at gmail.com Sun Nov 5 23:49:22 2006 From: luis.f.correia at gmail.com (Luis Correia) Date: Sun, 5 Nov 2006 22:49:22 +0000 Subject: [LinuxBIOS] #33: Signed-off-by in trac is meaningless In-Reply-To: <069.653566ea4c9ce329568a8b4fe67e3f30@openbios.org> References: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> <069.653566ea4c9ce329568a8b4fe67e3f30@openbios.org> Message-ID: On 11/5/06, LinuxBIOS wrote: > #33: Signed-off-by in trac is meaningless > ----------------------------+----------------------------------------------- > Reporter: segher | Owner: somebody > Type: defect | Status: new > Priority: critical | Milestone: Resolve license issues > Component: misc | Version: > Resolution: | Keywords: trac > Include_gantt: 1 | Dependencies: > Due_assign: MM/DD/YYYY | Due_close: MM/DD/YYYY > ----------------------------+----------------------------------------------- > Comment (by segher): > > > Please kill me :) > > Heh no :-) I tought this whole ticket #33 was about my double ticket creation... it was not apparently. my mistake! Luis From lfcorreia at lfcorreia.dyndns.org Mon Nov 6 00:00:57 2006 From: lfcorreia at lfcorreia.dyndns.org (Luis Correia) Date: Sun, 05 Nov 2006 23:00:57 +0000 Subject: [LinuxBIOS] Support for IEI Nova4899R [1] In-Reply-To: <13426df10611041640o2008c16fj21ccfb55fe0c8929@mail.gmail.com> References: <454CFA15.3080501@lfcorreia.dyndns.org> <13426df10611041640o2008c16fj21ccfb55fe0c8929@mail.gmail.com> Message-ID: <454E6D29.70908@lfcorreia.dyndns.org> ron minnich wrote: > > b) is there any way to tell where the IRQ pins for each PCI device > are connected to the IRQ router chip? > > > > schematics. Or a volt-ohm meter. > I followed your advice :) With the purchase of this nova board, Martin also gave me another one, that was broken. I grabbed my mini torch and after the fumes from the removal of the companion chip (cs5530) were gone, access to the pads is now available. Here is how things are connected: CS5530 pins INTA# internal USB controller and INTC# on the PCI slot INTB# eth2 chip and INTD# on the PCI slot INTC# eth1 chip and INTA# on the PCI slot INTD# eth0 chip and INTB# on the PCI slot Following this, i changed the irq_tables.c file to be like this: /* bus, dev|fn, {link, bitmap}, {link, bitmap}, {link, bitmap}, {link, bitmap}, slot, rfu */ // USB {0x00,(0x13<<3)|0x0, {{0x01, 0xdeb8}, {0x00, 0xdeb8}, {0x00, 0xdeb8}, {0x00, 0x0deb8}}, 0x0, 0x0}, // eth0 {0x00,(0x0a<<3)|0x0, {{0x04, 0xdeb8}, {0x00, 0xdeb8}, {0x00, 0xdeb8}, {0x00, 0x0deb8}}, 0x0, 0x0}, // eth1 {0x00,(0x0b<<3)|0x0, {{0x03, 0xdeb8}, {0x00, 0xdeb8}, {0x00, 0xdeb8}, {0x00, 0x0deb8}}, 0x0, 0x0}, // eth2 {0x00,(0x0c<<3)|0x0, {{0x02, 0xdeb8}, {0x00, 0xdeb8}, {0x00, 0xdeb8}, {0x00, 0x0deb8}}, 0x0, 0x0}, // PCI slot {0x00,(0x0f<<3)|0x0, {{0x03, 0xdeb8}, {0x04, 0xdeb8}, {0x01, 0xdeb8}, {0x02, 0x0deb8}}, 0x0, 0x0}, Nonetheless, the kernel assumes some strange things, let's keep in mind that the kernel i'm using is an old 2.4.20, which may or may not treat this IRQ assignments correctly. Using pci=biosirq makes no change. These are the IRQ's the kernel assigns: USB IRQ9 eth0 IRQ10 eth1 IRQ11 eth2 IRQ9 any help ? anyone ? volunteers are being accepted... :) Luis Correia -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From svn at openbios.org Mon Nov 6 00:05:31 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 23:05:31 -0000 Subject: [LinuxBIOS] #31: Do proper checking for flash erase for SST FWH parts In-Reply-To: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> References: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> Message-ID: <069.0fd009b9834fcd8fe2449020411d3c80@openbios.org> #31: Do proper checking for flash erase for SST FWH parts -----------------------------------+---------------------------------------- Reporter: stepan | Owner: stepan Type: defect | Status: assigned Priority: minor | Milestone: Enhance the flashrom utility Component: flashrom | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: patch needs review | -----------------------------------+---------------------------------------- Changes (by uwe): * patchstatus: => patch needs review -- Ticket URL: LinuxBIOS From rminnich at gmail.com Mon Nov 6 00:07:41 2006 From: rminnich at gmail.com (ron minnich) Date: Sun, 5 Nov 2006 16:07:41 -0700 Subject: [LinuxBIOS] Support for IEI Nova4899R [1] In-Reply-To: <454E6D29.70908@lfcorreia.dyndns.org> References: <454CFA15.3080501@lfcorreia.dyndns.org> <13426df10611041640o2008c16fj21ccfb55fe0c8929@mail.gmail.com> <454E6D29.70908@lfcorreia.dyndns.org> Message-ID: <13426df10611051507y1454350ej51961a18f6b81d1e@mail.gmail.com> What I recommend is that you skip the PIRQ crap and just hardwire the IRQs in linuxbios. OLPC is one example of a system which does this. PIRQ does not work in many cases. ron p.s. heroic work there with the VOM, I am very impressed! -------------- next part -------------- An HTML attachment was scrubbed... URL: From svn at openbios.org Mon Nov 6 00:08:51 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 23:08:51 -0000 Subject: [LinuxBIOS] #22: sed error in abuild In-Reply-To: <060.5c46f9c57a78cecc432ab4e830a2d4dc@openbios.org> References: <060.5c46f9c57a78cecc432ab4e830a2d4dc@openbios.org> Message-ID: <069.1cad3453afec818d00a0ef850fe7deaa@openbios.org> #22: sed error in abuild -----------------------------------------------+---------------------------- Reporter: uwe | Owner: uwe Type: defect | Status: assigned Priority: critical | Milestone: Component: testsystem | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: patch is ready to be committed | -----------------------------------------------+---------------------------- Changes (by uwe): * patchstatus: => patch is ready to be committed -- Ticket URL: LinuxBIOS From lfcorreia at lfcorreia.dyndns.org Mon Nov 6 00:09:55 2006 From: lfcorreia at lfcorreia.dyndns.org (Luis Correia) Date: Sun, 05 Nov 2006 23:09:55 +0000 Subject: [LinuxBIOS] Support for IEI Nova4899R [1] In-Reply-To: <13426df10611051507y1454350ej51961a18f6b81d1e@mail.gmail.com> References: <454CFA15.3080501@lfcorreia.dyndns.org> <13426df10611041640o2008c16fj21ccfb55fe0c8929@mail.gmail.com> <454E6D29.70908@lfcorreia.dyndns.org> <13426df10611051507y1454350ej51961a18f6b81d1e@mail.gmail.com> Message-ID: <454E6F43.7070708@lfcorreia.dyndns.org> ron minnich wrote: > What I recommend is that you skip the PIRQ crap and just hardwire the > IRQs in linuxbios. OLPC is one example of a system which does this. > PIRQ does not work in many cases. > > ron > p.s. heroic work there with the VOM, I am very impressed! > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* , and is > believed to be clean. You will see the pictures of the board after being hit with the torch... btw, please direct me with the exact OLPC board, rev_a or btest? Luis Correia -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From stuge-linuxbios at cdy.org Mon Nov 6 00:22:41 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Mon, 6 Nov 2006 00:22:41 +0100 Subject: [LinuxBIOS] #31: Do proper checking for flash erase for SST FWH parts In-Reply-To: <20061105223902.GB10831@greenwood> References: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> <20061105223902.GB10831@greenwood> Message-ID: <20061105232241.7688.qmail@cdy.org> On Sun, Nov 05, 2006 at 11:39:03PM +0100, Uwe Hermann wrote: > Well, that's a matter of taste. I have to delete whole _threads_ of > duplicated mails all the time, just because I replied to a single mail > in that thread. WTF? I'm subscribed, I _already_ get all the emails, > why should I be CC'd explicitly all the time? You can configure Mailman to not send you another copy if it sees your subscribed address among the recipients. See your options page for the list. //Peter From rminnich at gmail.com Mon Nov 6 00:18:19 2006 From: rminnich at gmail.com (ron minnich) Date: Sun, 5 Nov 2006 16:18:19 -0700 Subject: [LinuxBIOS] Support for IEI Nova4899R [1] In-Reply-To: <454E6F43.7070708@lfcorreia.dyndns.org> References: <454CFA15.3080501@lfcorreia.dyndns.org> <13426df10611041640o2008c16fj21ccfb55fe0c8929@mail.gmail.com> <454E6D29.70908@lfcorreia.dyndns.org> <13426df10611051507y1454350ej51961a18f6b81d1e@mail.gmail.com> <454E6F43.7070708@lfcorreia.dyndns.org> Message-ID: <13426df10611051518g93100ebge43124fb32fa9108@mail.gmail.com> either one will let you see the way we hard wire IRQs ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From svn at openbios.org Mon Nov 6 00:18:49 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 23:18:49 -0000 Subject: [LinuxBIOS] #9: Do not hardcode iasl path In-Reply-To: <060.d4934ecb9e5bc6a67fe697c6d249e0e7@openbios.org> References: <060.d4934ecb9e5bc6a67fe697c6d249e0e7@openbios.org> Message-ID: <069.726ebee23b9e22bd51165e71c779c7bb@openbios.org> #9: Do not hardcode iasl path -----------------------------------+---------------------------------------- Reporter: uwe | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: | Keywords: Due_close: | Include_gantt: 1 Dependencies: | Due_assign: Patchstatus: patch needs review | -----------------------------------+---------------------------------------- Changes (by uwe): * patchstatus: => patch needs review -- Ticket URL: LinuxBIOS From svn at openbios.org Mon Nov 6 00:19:40 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 23:19:40 -0000 Subject: [LinuxBIOS] #30: Support for VIA VT82C686 in flashrom In-Reply-To: <060.b7bf006a0db81bb4230b08879c9216f8@openbios.org> References: <060.b7bf006a0db81bb4230b08879c9216f8@openbios.org> Message-ID: <069.20b6bbcce50b249239aae45583dcfe0b@openbios.org> #30: Support for VIA VT82C686 in flashrom -----------------------------------+---------------------------------------- Reporter: stepan | Owner: stepan Type: enhancement | Status: assigned Priority: minor | Milestone: Enhance the flashrom utility Component: flashrom | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: patch needs review | -----------------------------------+---------------------------------------- Changes (by uwe): * patchstatus: => patch needs review -- Ticket URL: LinuxBIOS From svn at openbios.org Mon Nov 6 00:20:02 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 23:20:02 -0000 Subject: [LinuxBIOS] #32: New motherboard IEI NOVA4899R In-Reply-To: <060.c3a3c2f45e93a6296863c1cd84d73236@openbios.org> References: <060.c3a3c2f45e93a6296863c1cd84d73236@openbios.org> Message-ID: <069.37e4f5d393c13327845e6b1e2f714cef@openbios.org> #32: New motherboard IEI NOVA4899R --------------------------------------------------------+------------------- Reporter: Luis Correia | Owner: somebody Type: enhancement | Status: new Priority: trivial | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: patch needs review | --------------------------------------------------------+------------------- Changes (by uwe): * patchstatus: => patch needs review -- Ticket URL: LinuxBIOS From svn at openbios.org Mon Nov 6 00:21:45 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 05 Nov 2006 23:21:45 -0000 Subject: [LinuxBIOS] #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M In-Reply-To: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> References: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> Message-ID: <069.e53852cc713d9964805549d9606cbac4@openbios.org> #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M ---------------------------------+------------------------------------------ Reporter: uwe | Owner: uwe Type: enhancement | Status: reopened Priority: major | Milestone: Enhance the flashrom utility Component: flashrom | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: patch needs work | ---------------------------------+------------------------------------------ Changes (by uwe): * status: closed => reopened * patchstatus: => patch needs work * resolution: fixed => -- Ticket URL: LinuxBIOS From segher at kernel.crashing.org Mon Nov 6 00:26:11 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Mon, 6 Nov 2006 00:26:11 +0100 Subject: [LinuxBIOS] Using trac In-Reply-To: <20061105210434.GA10587@coresystems.de> References: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> <454E4F9E.6030201@gmail.com> <20061105210434.GA10587@coresystems.de> Message-ID: >> Although it does keep things together its a much larger PITA to work >> with. And I find it cumbersome to find the stuff I'm looking for >> unless >> I just happen to remember the Trac ID#. > > The search function is not worse than searching the mailing list.. Sure it is. I have my mail archive, nicely sorted and tagged, exactly as _I_ want it and I can easily drag out any mail I want. Having to use a separate application (and web-based too of all things) to access a fraction of the information universe I'm dealing with doesn't scale too well. >> Finding/implementing some sort of trac<->mailing list gateway >> would be >> ideal. > > Ok. So what should the gateway look like? > > I am pretty unreligious about which system to use, but we should stay > with what we decided to use at least until we find a better > solution or > we just fix the solution we have. But this is only possible if > there's a > common sense about the requirements. Well here's some of my thoughts to kick this off then, please discuss: 1) All developers should be aware of all patches; they can just press delete if they don't like the subject ==> All patches should be sent to the mailing list. 2) It should be as easy as possible to discuss patches, in free form, mixing patch snippets with prose (and flames and general silliness). When a patch author thinks he's had enough comments, he sends a new patch with some fixes and/or changes and perhaps an Acked-by: line. ==> All patches should be discussed on the mailing list; patches should preferably be sent inline (or if you really can only send attachments without getting mangled or word-wrapped patches, at least make sure the attachments are type text/plain and hopefully not encoded with binhex or quoted-unreadable or whatever). 3) No patches should go into a SCM tree without agreement from the tree's maintainer. ==> When a maintainer thinks a patch is good enough (after waiting a bit for discussion, perhaps), he signs off on the patch and either commits it or tells the author it's okay to commit. People read the SCM reflector to know when things went in (there are smallish delays often), and also to see what patches went in that they themselves didn't read (or participate in) (all of) the discussion for, but might be interesting for them nevertheless ["reading the changelog"]; when people are caught checking in stuff unauthorised (and they _will_ be caught) we can scramble their ssh key or force them to work from dialup or whatnot. 3) There is no need to keep all proposed patches in a tracker of any kind: software archeologists can go dig in the mailing list archives; for everyone else, all that matters is _what did actually change_ in the master repository and _why_, and the actual patches and check-in comments in the SCM tell that story. For people with short-term memory loss, there is this wonderful invention called the "threading mailer". ==> A tracker is a very useful tool for combined SCM monitoring, problem report handling, keeping track of the road map, etc.; it is *not* a good tool to organise people's personal code development (I prefer git and quilt, thanks), and certainly not a good tool for cooperative development. We need to work _closer_ together, in a sometimes non-linear or slightly ad-hoc fashion; communicate, and communicate freely; we don't need to be forced to sort and organise every little piece of work we do into millions of little boxes. Use the tracker for what it's good for: keeping track of the end result (the SCM, the problem database, the "big picture" of the current state of affairs). We don't need some unrelated tool to ordain how we should conduct or day-to-day business processes. 4) For accountability or just a paper trail, we have the Signed-off-by: lines, and those should stay with the patches at all time or they become meaningless. ==> The tracker can _track_ the sign-offs, that's fine; but it shouldn't be the main repository of-em (the SCM is for merged patches; all patches proposed to be applied but still in flight carry them inline with the patch). I hope this wasn't too long :-) > As always: He who sends a working patch usually wins. Nah, whoever gets the Signed-off-by: stamp-of-approval on his patch wins :-) Segher From segher at kernel.crashing.org Mon Nov 6 00:49:32 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Mon, 6 Nov 2006 00:49:32 +0100 Subject: [LinuxBIOS] #31: Do proper checking for flash erase for SST FWH parts In-Reply-To: <20061105210946.GA17340@coresystems.de> References: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> <20061105205741.GA1578@coresystems.de> <454E51B0.70505@gmail.com> <20061105210946.GA17340@coresystems.de> Message-ID: <34485247-3715-40F2-A16A-DF74393F08C7@kernel.crashing.org> >> The Linux Kernel guys seem to think otherwise. > > 1. There are _lots_ of people hired full time to check no patches > get lost. They're not lost, they are still in people's inboxes (unless they deleted them) and in the ML archive. There is only one guy working fulltime taking care of all orphan Linux patches (well not fulltime really, even), FWIW. > 2. Patches still get lost or stay ignored pretty often. If the author still cares, he can ping the patches after some certain period of time (don't be too impatient). If really everyone is too busy or just no one cares, well, tough luck, that has nothing to do with what tools they use to run their business. Of course it helps for a huge project like Linux that someone like MM regularly sweeps up all (small) patches that look good enough to him and/or whoever reviewed them on the list, to have those patches simmer in his experimental tree for a while. At the other side of the spectrum, there are projects like GCC, where patches frequently are ignored or at least not reviewed for a month or more. Most such patches are huge invasive patches requiring in-depth specialistic knowledge of what that patch is touching. Does that mean such patches should then just be "let in" without review? Does it mean that we should keep a subset (namely, the new patch contents) of our development mailing list in a separate database (the tracker)? Would that really be harder to ignore (for the "bad guys") or easier to keep up with (for the "good guys")? Segher From svn at openbios.org Mon Nov 6 01:04:00 2006 From: svn at openbios.org (LinuxBIOS) Date: Mon, 06 Nov 2006 00:04:00 -0000 Subject: [LinuxBIOS] #31: Do proper checking for flash erase for SST FWH parts In-Reply-To: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> References: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> Message-ID: <069.d85931ba1787d1fb124afb2e04c6dc06@openbios.org> #31: Do proper checking for flash erase for SST FWH parts -----------------------------------+---------------------------------------- Reporter: stepan | Owner: stepan Type: defect | Status: assigned Priority: minor | Milestone: Enhance the flashrom utility Component: flashrom | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: patch needs review | -----------------------------------+---------------------------------------- Comment (by segher): Every patch needs review, unless it already got it, and then it's either back to the drawing table, or that patch get's checked in :-) If total_size is indeed the size of flash that got erased, it looks good to me. But Stefan himself knows best, he should just go ahead and apply the patch if no one complains soon (like, wait for tomorrow morning or something like that). Segher -- Ticket URL: LinuxBIOS From segher at kernel.crashing.org Mon Nov 6 02:40:37 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Mon, 6 Nov 2006 02:40:37 +0100 Subject: [LinuxBIOS] Support for IEI Nova4899R [1] In-Reply-To: <454E6D29.70908@lfcorreia.dyndns.org> References: <454CFA15.3080501@lfcorreia.dyndns.org> <13426df10611041640o2008c16fj21ccfb55fe0c8929@mail.gmail.com> <454E6D29.70908@lfcorreia.dyndns.org> Message-ID: <2FE1F59D-356A-42CE-83D3-B28D434EA321@kernel.crashing.org> > Following this, i changed the irq_tables.c file to be like this: Did you fix the table's headers too, to read the correct number of entries, and the right checksum? The table you derived yours from had only two devices entries, and your results are sort-of consistent with that. > Nonetheless, the kernel assumes some strange things, let's keep in > mind that > the kernel i'm using is an old 2.4.20, which may or may not treat > this IRQ > assignments correctly. Using pci=biosirq makes no change. A newer kernel might help for sure. > These are the IRQ's the kernel assigns: > > USB IRQ9 > eth0 IRQ10 > eth1 IRQ11 > eth2 IRQ9 Can you show us all kernel boot messages about IRQ routing? Or just *all* boot messages ;-) Segher From segher at kernel.crashing.org Mon Nov 6 02:52:49 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Mon, 6 Nov 2006 02:52:49 +0100 Subject: [LinuxBIOS] Fwd: Hello, I have a problem to put the linuxbios on my mainboard ms6163. References: <20061106013939.84658.qmail@web56009.mail.re3.yahoo.com> Message-ID: <8C4BFC4B-A107-4EF9-B420-0494BEE823F0@kernel.crashing.org> [Forwarding to the list, I guess Li pressed a wrong button.] Li, please use "reply to all". Begin forwarded message: > From: Li Haiqiang > Date: 6 november 2006 2:39:39 GMT+01:00 > To: Segher Boessenkool > Subject: Re: [LinuxBIOS] Hello, I have a problem to put the > linuxbios on my mainboard ms6163. > > Yes, I have only one memory module. > > The lspci -xxx output: > 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX > Host bridge (rev 03) > 00: 86 80 90 71 06 00 10 22 03 00 00 06 00 40 00 00 > 10: 08 00 00 e0 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 a0 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: 0c 8a 00 ff 00 00 00 09 03 10 11 01 00 00 00 00 > 60: 08 10 10 10 10 10 10 10 00 0f c0 00 00 8a 00 00 > 70: 20 1f 0a 38 05 00 03 01 26 ff 10 38 00 00 00 00 > 80: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 90: 98 22 00 00 04 61 00 00 00 05 00 00 00 00 00 00 > a0: 02 00 10 00 03 02 00 1f 00 00 00 00 00 00 00 00 > b0: 80 20 00 00 30 00 00 00 00 00 ef 07 20 10 00 00 > c0: 00 00 00 00 00 00 00 00 18 0c ff ff 67 00 00 00 > d0: 00 00 00 00 00 00 00 00 0c 00 00 00 00 00 00 00 > e0: 4c ad ff bb 8a 3e 00 80 2c d3 f7 cf 9d 3e 00 00 > f0: 40 01 00 00 00 f8 00 60 20 0f 00 00 00 00 00 00 > > > > And the LinuxBIOS serial output: > PCI: 00:00.00 > 00: 86 80 90 71 06 00 10 22 03 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 a0 00 00 00 00 00 00 00 00 00 00 00 > 40: 00 00 00 00 00 00 00 00 00 00 0 > 50: 04 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 > 60: 01 01 01 01 01 01 01 01 00 00 00 00 00 00 00 00 > 70: 00 1f 02 38 00 00 00 00 00 00 00 38 00 00 00 00 > 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 90: 80 00 00 00 04 61 00 00 00 05 00 00 00 00 00 00 > a0: 02 00 10 00 03 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 00 00 00 00 00 00 00 18 0c 00 00 00 00 00 00 > d0: 00 00 00 00 00 00 00 00 0c 00 00 00 00 00 00 00 > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 f8 00 00 20 0f 00 00 00 00 00 00 > > > > > ----- Original Message ---- > From: Segher Boessenkool > To: Stefan Reinauer > Cc: Li Haiqiang ; linuxbios at linuxbios.org > Sent: Monday, November 6, 2006 2:45:19 AM > Subject: Re: [LinuxBIOS] Hello, I have a problem to put the > linuxbios on my mainboard ms6163. > > > You need to run > > dump_pci_devices(); > > > > as last command in auto.c > > > >> lspci -xxx: > > If you resend this lspci output with the dump_pci_devices() > output (and please do!), use lspci -xxx -s0:0 or just > cut'n'paste only device 0 ("Host Bridge"), the rest isn't > interesting. > > Did you send the SPD contents dump already? I didn't see > it yet -- if you didn't send it to the list, please do. > > Oh and answer Stefan's question: > > >> Ok. Its reading 1 SPD-ROM. Do you have 1 memory module > >> installed? If yes: Everything is fine here. If you have more, > >> we need to find out where they are. > > > > Segher > > > From smithbone at gmail.com Mon Nov 6 03:12:57 2006 From: smithbone at gmail.com (Richard Smith) Date: Sun, 05 Nov 2006 20:12:57 -0600 Subject: [LinuxBIOS] Fwd: Hello, I have a problem to put the linuxbios on my mainboard ms6163. In-Reply-To: <8C4BFC4B-A107-4EF9-B420-0494BEE823F0@kernel.crashing.org> References: <20061106013939.84658.qmail@web56009.mail.re3.yahoo.com> <8C4BFC4B-A107-4EF9-B420-0494BEE823F0@kernel.crashing.org> Message-ID: <454E9A29.10505@gmail.com> >> From: Li Haiqiang >> Date: 6 november 2006 2:39:39 GMT+01:00 >> To: Segher Boessenkool >> Subject: Re: [LinuxBIOS] Hello, I have a problem to put the >> linuxbios on my mainboard ms6163. >> >> Yes, I have only one memory module. Li, See my mail earlier today on 44bx. That outlines what you have to do to make 440bx work. -- Richard A. Smith From haiqiang2linux at yahoo.com Mon Nov 6 04:44:15 2006 From: haiqiang2linux at yahoo.com (Li Haiqiang) Date: Sun, 5 Nov 2006 19:44:15 -0800 (PST) Subject: [LinuxBIOS] Fwd: Hello, I have a problem to put the linuxbios on my mainboard ms6163. Message-ID: <20061106034415.28757.qmail@web56009.mail.re3.yahoo.com> I even don't know how to . Can you help me? ----- Original Message ---- From: Richard Smith To: Li Haiqiang Cc: LinuxBIOS mailinglist Sent: Monday, November 6, 2006 10:12:57 AM Subject: Re: [LinuxBIOS] Fwd: Hello, I have a problem to put the linuxbios on my mainboard ms6163. >> From: Li Haiqiang >> Date: 6 november 2006 2:39:39 GMT+01:00 >> To: Segher Boessenkool >> Subject: Re: [LinuxBIOS] Hello, I have a problem to put the >> linuxbios on my mainboard ms6163. >> >> Yes, I have only one memory module. Li, See my mail earlier today on 44bx. That outlines what you have to do to make 440bx work. -- Richard A. Smith -------------- next part -------------- An HTML attachment was scrubbed... URL: From haiqiang2linux at yahoo.com Mon Nov 6 04:58:44 2006 From: haiqiang2linux at yahoo.com (Li Haiqiang) Date: Sun, 5 Nov 2006 19:58:44 -0800 (PST) Subject: [LinuxBIOS] Fwd: Hello, I have a problem to put the linuxbios on my mainboard ms6163. Message-ID: <20061106035844.61375.qmail@web56008.mail.re3.yahoo.com> What does debug code 0xf9 mean? It stopped here. ----- Original Message ---- From: Richard Smith To: Li Haiqiang Cc: LinuxBIOS mailinglist Sent: Monday, November 6, 2006 10:12:57 AM Subject: Re: [LinuxBIOS] Fwd: Hello, I have a problem to put the linuxbios on my mainboard ms6163. >> From: Li Haiqiang >> Date: 6 november 2006 2:39:39 GMT+01:00 >> To: Segher Boessenkool >> Subject: Re: [LinuxBIOS] Hello, I have a problem to put the >> linuxbios on my mainboard ms6163. >> >> Yes, I have only one memory module. Li, See my mail earlier today on 44bx. That outlines what you have to do to make 440bx work. -- Richard A. Smith -------------- next part -------------- An HTML attachment was scrubbed... URL: From smithbone at gmail.com Mon Nov 6 05:25:38 2006 From: smithbone at gmail.com (Richard Smith) Date: Sun, 05 Nov 2006 22:25:38 -0600 Subject: [LinuxBIOS] Fwd: Hello, I have a problem to put the linuxbios on my mainboard ms6163. In-Reply-To: <20061106035844.61375.qmail@web56008.mail.re3.yahoo.com> References: <20061106035844.61375.qmail@web56008.mail.re3.yahoo.com> Message-ID: <454EB942.1050409@gmail.com> Li Haiqiang wrote: > What does debug code 0xf9 mean? > It stopped here. Li, The 440bx is NOT COMPLETE. It will NOT function. It is BROKEN. The port is not finished. Its does not enable RAM. Hopefully, one of those translates correctly. Do you understand? To make it work you need to add a lot of code. My earlier email talks about the necessary steps to get 440bx into a working shape. -- Richard A. Smith From haiqiang2linux at yahoo.com Mon Nov 6 05:45:53 2006 From: haiqiang2linux at yahoo.com (Li Haiqiang) Date: Sun, 5 Nov 2006 20:45:53 -0800 (PST) Subject: [LinuxBIOS] Fwd: Hello, I have a problem to put the linuxbios on my mainboard ms6163. Message-ID: <20061106044553.19198.qmail@web56011.mail.re3.yahoo.com> I write the 'ls -xxx' results to the PCI config registers. Can it work? ----- Original Message ---- From: Richard Smith To: Li Haiqiang Cc: LinuxBIOS mailinglist Sent: Monday, November 6, 2006 12:25:38 PM Subject: Re: [LinuxBIOS] Fwd: Hello, I have a problem to put the linuxbios on my mainboard ms6163. Li Haiqiang wrote: > What does debug code 0xf9 mean? > It stopped here. Li, The 440bx is NOT COMPLETE. It will NOT function. It is BROKEN. The port is not finished. Its does not enable RAM. Hopefully, one of those translates correctly. Do you understand? To make it work you need to add a lot of code. My earlier email talks about the necessary steps to get 440bx into a working shape. -- Richard A. Smith -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfcorreia at lfcorreia.dyndns.org Mon Nov 6 08:54:08 2006 From: lfcorreia at lfcorreia.dyndns.org (Luis Correia) Date: Mon, 06 Nov 2006 07:54:08 +0000 Subject: [LinuxBIOS] Support for IEI Nova4899R [1] In-Reply-To: <2FE1F59D-356A-42CE-83D3-B28D434EA321@kernel.crashing.org> References: <454CFA15.3080501@lfcorreia.dyndns.org> <13426df10611041640o2008c16fj21ccfb55fe0c8929@mail.gmail.com> <454E6D29.70908@lfcorreia.dyndns.org> <2FE1F59D-356A-42CE-83D3-B28D434EA321@kernel.crashing.org> Message-ID: <454EEA20.6000904@lfcorreia.dyndns.org> Segher Boessenkool wrote: >> Following this, i changed the irq_tables.c file to be like this: > > Did you fix the table's headers too, to read the correct > number of entries, and the right checksum? The table you > derived yours from had only two devices entries, and your > results are sort-of consistent with that. > Yes, see attached file. >> Nonetheless, the kernel assumes some strange things, let's keep in >> mind that >> the kernel i'm using is an old 2.4.20, which may or may not treat >> this IRQ >> assignments correctly. Using pci=biosirq makes no change. > > A newer kernel might help for sure. > I tried to use a current Fedora or CentOS distro, but both refused this processor. I don't have the stamina to brew my own kernel right now. >> These are the IRQ's the kernel assigns: >> >> USB IRQ9 >> eth0 IRQ10 >> eth1 IRQ11 >> eth2 IRQ9 > > Can you show us all kernel boot messages about IRQ routing? > Or just *all* boot messages ;-) > > > Segher > Your wish is my command :) All boot messages and the current irq table are attached. p.s. don't CC me, i'm on the list. Luis Correia -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------- next part -------------- A non-text attachment was scrubbed... Name: 20061106.tar.gz Type: application/gzip Size: 3702 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: irq_tables.tar.gz Type: application/gzip Size: 840 bytes Desc: not available URL: From svn at openbios.org Mon Nov 6 10:10:34 2006 From: svn at openbios.org (LinuxBIOS) Date: Mon, 06 Nov 2006 09:10:34 -0000 Subject: [LinuxBIOS] #34: flashrom: Fix PIIX4/PIIX4E/PIIX4M code comments Message-ID: <060.9abad48f9c5061c9df763f3bf540d407@openbios.org> #34: flashrom: Fix PIIX4/PIIX4E/PIIX4M code comments ----------------------------+----------------------------------------------- Reporter: uwe | Owner: uwe Type: defect | Status: new Priority: minor | Milestone: Enhance the flashrom utility Component: flashrom | Version: v2 Keywords: | Due_close: MM/DD/YYYY Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Patchstatus: there is no patch ----------------------------+----------------------------------------------- Fix some code comments of the Intel PIIX4/PIIX4E/PIIX4M code. Add detailed instructions on how and where to get the datasheet, its name, and order number. Signed-off-by: Uwe Hermann -- Ticket URL: LinuxBIOS From svn at openbios.org Mon Nov 6 10:11:59 2006 From: svn at openbios.org (LinuxBIOS) Date: Mon, 06 Nov 2006 09:11:59 -0000 Subject: [LinuxBIOS] #34: flashrom: Fix PIIX4/PIIX4E/PIIX4M code comments In-Reply-To: <060.9abad48f9c5061c9df763f3bf540d407@openbios.org> References: <060.9abad48f9c5061c9df763f3bf540d407@openbios.org> Message-ID: <069.fc54e9144916e664f862b2714c12ce39@openbios.org> #34: flashrom: Fix PIIX4/PIIX4E/PIIX4M code comments -----------------------------------+---------------------------------------- Reporter: uwe | Owner: uwe Type: defect | Status: assigned Priority: minor | Milestone: Enhance the flashrom utility Component: flashrom | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: patch needs review | -----------------------------------+---------------------------------------- Changes (by uwe): * status: new => assigned * patchstatus: there is no patch => patch needs review -- Ticket URL: LinuxBIOS From svn at openbios.org Mon Nov 6 10:21:01 2006 From: svn at openbios.org (LinuxBIOS) Date: Mon, 06 Nov 2006 09:21:01 -0000 Subject: [LinuxBIOS] #31: Do proper checking for flash erase for SST FWH parts In-Reply-To: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> References: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> Message-ID: <069.b580e67923a5a26645ff50cf4ac9d730@openbios.org> #31: Do proper checking for flash erase for SST FWH parts -----------------------------------+---------------------------------------- Reporter: stepan | Owner: stepan Type: defect | Status: assigned Priority: minor | Milestone: Enhance the flashrom utility Component: flashrom | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: patch needs review | -----------------------------------+---------------------------------------- Comment (by uwe): Replying to [comment:3 segher]: > Every patch needs review, unless it already got it, and then > it's either back to the drawing table, or that patch get's > checked in :-) Sure, but we need a state which tells us that there is a patch at all (not all tickets have a patch), and in which state it is (has it already been reviewed? does it need more work? is it ready to be comitted?) etc. This is mostly used for the shiny new "Patch Queue" I created yesterday: http://tracker.linuxbios.org/trac/LinuxBIOS/report/9 (or click View Tickets -> Patch Queue) That should make it easier to track which tickets have patches and in which state. Reviewers or people who want to commit patches which have been approved can simply work on the patch queue and make it smaller. > If total_size is indeed the size of flash that got erased, > it looks good to me. But Stefan himself knows best, he > should just go ahead and apply the patch if no one complains > soon (like, wait for tomorrow morning or something like that). Add an Acked-by: if it looks good to you. One important part of the sign- off procedure is that we have sort of a group-review, i.e. at least one other developer has to review the patch and give it his/her ACK (the other important part is copyright and authorship tracking, of course). -- Ticket URL: LinuxBIOS From svn at openbios.org Mon Nov 6 10:23:23 2006 From: svn at openbios.org (LinuxBIOS) Date: Mon, 06 Nov 2006 09:23:23 -0000 Subject: [LinuxBIOS] #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M In-Reply-To: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> References: <060.b45a23743d08092b1c8b08ecd6d866e1@openbios.org> Message-ID: <069.74e4f340fdbdb16c53edf0753c1c1415@openbios.org> #26: flashrom: Support for PIIX4/PIIX4E/PIIX4M -----------------------------------------+---------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: closed Priority: major | Milestone: Enhance the flashrom utility Component: flashrom | Version: v2 Resolution: fixed | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: patch has been committed | -----------------------------------------+---------------------------------- Changes (by uwe): * status: reopened => closed * patchstatus: patch needs work => patch has been committed * resolution: => fixed Comment: Lets close this. Another patch which fixes some related issues is in #34 now. -- Ticket URL: LinuxBIOS From stepan at coresystems.de Mon Nov 6 11:27:11 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 6 Nov 2006 11:27:11 +0100 Subject: [LinuxBIOS] Fwd: Hello, I have a problem to put the linuxbios on my mainboard ms6163. In-Reply-To: <20061106044553.19198.qmail@web56011.mail.re3.yahoo.com> References: <20061106044553.19198.qmail@web56011.mail.re3.yahoo.com> Message-ID: <20061106102711.GA16467@coresystems.de> * Li Haiqiang [061106 05:45]: > I write the 'ls -xxx' results to the PCI config registers. > Can it work? As a first step this is worth a try, yes. But you need to find out which are relevant, and the order plays a big role. Grab yourself a datasheet for the 440BX northbridge... Otherwise it will break as soon as you put in another DIMM module. -- 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 a1426z at gawab.com Mon Nov 6 11:30:03 2006 From: a1426z at gawab.com (Al Boldi) Date: Mon, 6 Nov 2006 13:30:03 +0300 Subject: [LinuxBIOS] Support for IEI Nova4899R [1] In-Reply-To: <454EEA20.6000904@lfcorreia.dyndns.org> References: <454CFA15.3080501@lfcorreia.dyndns.org> <2FE1F59D-356A-42CE-83D3-B28D434EA321@kernel.crashing.org> <454EEA20.6000904@lfcorreia.dyndns.org> Message-ID: <200611061330.03318.a1426z@gawab.com> Luis Correia wrote: > Segher Boessenkool wrote: > > Can you show us all kernel boot messages about IRQ routing? > > Or just *all* boot messages ;-) > > Your wish is my command :) > > All boot messages and the current irq table are attached. From the log: hm, page 00000000 reserved twice. Can someone explain what this means? I get this with Filo 0.5, even on a 16bit factory installed AwardBIOS. Does Filo do something fishy? Thanks! -- Al From svn at openbios.org Mon Nov 6 11:51:17 2006 From: svn at openbios.org (svn at openbios.org) Date: Mon, 06 Nov 2006 10:51:17 -0000 Subject: [LinuxBIOS] r2491 - trunk/LinuxBIOSv2/util/abuild Message-ID: Author: uwe Date: 2006-11-06 11:51:15 +0100 (Mon, 06 Nov 2006) New Revision: 2491 Modified: trunk/LinuxBIOSv2/util/abuild/abuild Log: Fix bug in 'sed' invocation in abuild, which causes build errors in certain situations (Closes #22, refs #14). Signed-off-by: Uwe Hermann Acked-by: Stefan Reinauer Modified: trunk/LinuxBIOSv2/util/abuild/abuild =================================================================== --- trunk/LinuxBIOSv2/util/abuild/abuild 2006-11-05 18:50:49 UTC (rev 2490) +++ trunk/LinuxBIOSv2/util/abuild/abuild 2006-11-06 10:51:15 UTC (rev 2491) @@ -163,7 +163,7 @@ sed -i.pre -e s,VENDOR,$VENDOR,g \ -e s,MAINBOARD,$MAINBOARD,g \ - -e s,PAYLOAD,$PAYLOAD,g \ + -e s,payload\ PAYLOAD,payload\ $PAYLOAD,g \ -e s,CROSSCC,"$CC",g \ -e s,CROSS_PREFIX,"$CROSS_COMPILE",g \ -e s,CROSS_HOSTCC,"$HOSTCC",g \ From svn at openbios.org Mon Nov 6 11:51:46 2006 From: svn at openbios.org (LinuxBIOS) Date: Mon, 06 Nov 2006 10:51:46 -0000 Subject: [LinuxBIOS] #22: sed error in abuild In-Reply-To: <060.5c46f9c57a78cecc432ab4e830a2d4dc@openbios.org> References: <060.5c46f9c57a78cecc432ab4e830a2d4dc@openbios.org> Message-ID: <069.488eccd4ade749cd6dd0cbdba8a99f51@openbios.org> #22: sed error in abuild -----------------------------------------+---------------------------------- Reporter: uwe | Owner: uwe Type: defect | Status: closed Priority: critical | Milestone: Component: testsystem | Version: v2 Resolution: fixed | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: patch has been committed | -----------------------------------------+---------------------------------- Changes (by uwe): * patchstatus: patch is ready to be committed => patch has been committed -- Ticket URL: LinuxBIOS From smithbone at gmail.com Mon Nov 6 11:53:52 2006 From: smithbone at gmail.com (Richard Smith) Date: Mon, 06 Nov 2006 04:53:52 -0600 Subject: [LinuxBIOS] Fwd: Hello, I have a problem to put the linuxbios on my mainboard ms6163. In-Reply-To: <20061106102711.GA16467@coresystems.de> References: <20061106044553.19198.qmail@web56011.mail.re3.yahoo.com> <20061106102711.GA16467@coresystems.de> Message-ID: <454F1440.7080104@gmail.com> Stefan Reinauer wrote: > * Li Haiqiang [061106 05:45]: >> I write the 'ls -xxx' results to the PCI config registers. >> Can it work? > > As a first step this is worth a try, yes. > > But you need to find out which are relevant, and the order plays a big > role. Grab yourself a datasheet for the 440BX northbridge... Otherwise > it will break as soon as you put in another DIMM module. I think there is slightly more than zero chance this will work. The ram init routines in that code are for VIA. None of the ram commands are correct. -- Richard A. Smith From svn at openbios.org Mon Nov 6 11:56:12 2006 From: svn at openbios.org (LinuxBIOS) Date: Mon, 06 Nov 2006 10:56:12 -0000 Subject: [LinuxBIOS] #14: Rename "stream" to "payload" In-Reply-To: <060.7ce253b9ecf6e23e1d409c7624ff96d8@openbios.org> References: <060.7ce253b9ecf6e23e1d409c7624ff96d8@openbios.org> Message-ID: <069.1bd8f954932e47955094bf0d88c2d8f7@openbios.org> #14: Rename "stream" to "payload" ----------------------------------+----------------------------------------- Reporter: uwe | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: | Keywords: Due_close: DD/MM/YYYY | Include_gantt: 0 Dependencies: #22 | Due_assign: DD/MM/YYYY Patchstatus: there is no patch | ----------------------------------+----------------------------------------- Changes (by uwe): * patchstatus: => there is no patch -- Ticket URL: LinuxBIOS From stepan at coresystems.de Mon Nov 6 12:00:11 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 6 Nov 2006 12:00:11 +0100 Subject: [LinuxBIOS] Fwd: Hello, I have a problem to put the linuxbios on my mainboard ms6163. In-Reply-To: <454F1440.7080104@gmail.com> References: <20061106044553.19198.qmail@web56011.mail.re3.yahoo.com> <20061106102711.GA16467@coresystems.de> <454F1440.7080104@gmail.com> Message-ID: <20061106110011.GA29210@coresystems.de> * Richard Smith [061106 11:53]: > Stefan Reinauer wrote: > > * Li Haiqiang [061106 05:45]: > >> I write the 'ls -xxx' results to the PCI config registers. > >> Can it work? > > > > As a first step this is worth a try, yes. > > > > But you need to find out which are relevant, and the order plays a big > > role. Grab yourself a datasheet for the 440BX northbridge... Otherwise > > it will break as soon as you put in another DIMM module. > > I think there is slightly more than zero chance this will work. The ram > init routines in that code are for VIA. None of the ram commands are > correct. Ah, I understood he wants to omit the ram init code and just poke the lspci -xxx values into the northbridge. This might work for a start, right? At least thats how we started working on the k8 port -- 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 Mon Nov 6 16:32:23 2006 From: rminnich at gmail.com (ron minnich) Date: Mon, 6 Nov 2006 08:32:23 -0700 Subject: [LinuxBIOS] Support for IEI Nova4899R [1] In-Reply-To: <200611061330.03318.a1426z@gawab.com> References: <454CFA15.3080501@lfcorreia.dyndns.org> <2FE1F59D-356A-42CE-83D3-B28D434EA321@kernel.crashing.org> <454EEA20.6000904@lfcorreia.dyndns.org> <200611061330.03318.a1426z@gawab.com> Message-ID: <13426df10611060732w3f32d4e6r7db9f60608995af8@mail.gmail.com> On 11/6/06, Al Boldi wrote: > > > > hm, page 00000000 reserved twice. > > Can someone explain what this means? it's been happening for years, I forget what it means, word is 'don't fret'. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From segher at kernel.crashing.org Mon Nov 6 17:38:08 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Mon, 6 Nov 2006 17:38:08 +0100 Subject: [LinuxBIOS] Support for IEI Nova4899R [1] In-Reply-To: <454EEA20.6000904@lfcorreia.dyndns.org> References: <454CFA15.3080501@lfcorreia.dyndns.org> <13426df10611041640o2008c16fj21ccfb55fe0c8929@mail.gmail.com> <454E6D29.70908@lfcorreia.dyndns.org> <2FE1F59D-356A-42CE-83D3-B28D434EA321@kernel.crashing.org> <454EEA20.6000904@lfcorreia.dyndns.org> Message-ID: <138B23D3-CEEF-45EE-9DE0-47B47F9A3911@kernel.crashing.org> > Checking IRQ routing table consistency... > Inconsistent IRQ routing table size (0x90/0x70) That looks bad, not sure where it came from. You didn't show us all boot messages, only the messages at your default kernel log level. Try "dmesg -s999999". Anyway, this looks related: > 0xe00, /* IRQs devoted exclusively to PCI usage */ and sure enough, the interrupts that got assigned were 9, 10, 11, 9 (in the order of your irq_table). Dunno why no non-exclusively-PCI IRQs were used by Linux. Segher From myles at pel.cs.byu.edu Mon Nov 6 18:37:17 2006 From: myles at pel.cs.byu.edu (Myles Watson) Date: Mon, 06 Nov 2006 10:37:17 -0700 Subject: [LinuxBIOS] Disabled device help In-Reply-To: <5986589C150B2F49A46483AC44C7BCA413067A@ssvlexmb2.amd.com> Message-ID: <01M98M01KAEY8YT0D9@EMAIL1.BYU.EDU> Thanks a lot! It worked fine, except it missed the last 4GB of the allocation. This is an ugly way of getting it back. I'm not sure what the elegant way would be. The lower 32-bits need to be filled with ones in order for the space to be allocated correctly. Otherwise a 4GB allocation would show up as a one byte allocation. Now /proc/iomem shows my device at 8000000000-bfffffffff Myles --- drivers/pci/probe.c 2006-11-06 09:23:03.000000000 -0700 +++ drivers/pci/probe_new.c 2006-11-06 10:17:08.000000000 -0700 @@ -203,7 +203,7 @@ res->end = res->start + sz; if (szhi) { /* This BAR needs > 4GB? Wow. */ - res->end |= (unsigned long)szhi<<32; + res->end |= ((unsigned long)szhi<<32|0xffffffffUL); } #else if (szhi) { >Please check the patch. >YH >The Kernel pci_read_bases in drivers/pci/probe.c. has problem when size >if bigger than 4G. >It will first check the 32 bit SPACE_ADDRESS, and pci_size will return >0, So it will skip that resource. And the pre-set values is ignored. >And later, it will try to allocate the value. It will fail. >I will produce one patch for you. >YH >>My large device gets disabled somewhere in LinuxBIOS or the kernel. This >>is the encouraging line from LinuxBIOS telling me that the registers are >>indeed set correctly. >>PCI: 05:01.0 18 <- [8000000000 - bfffffffff] prefmem64 >>Unfortunately, Linux sees something different and fails to allocate this >>region because it sees it at 00000080-000000bf and that conflicts with >>other things. >>Does anyone have a pointer to where I should look for this problem? Has >>anyone else had problems with devices larger than 4GB? >>Thanks, >>Myles From yinghai.lu at amd.com Mon Nov 6 19:43:29 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Mon, 6 Nov 2006 10:43:29 -0800 Subject: [LinuxBIOS] Disabled device help Message-ID: <5986589C150B2F49A46483AC44C7BCA4907191@ssvlexmb2.amd.com> That should be fine. YH -----Original Message----- From: Myles Watson [mailto:myles at mouselemur.cs.byu.edu] Sent: Monday, November 06, 2006 9:37 AM To: Lu, Yinghai; linuxbios at linuxbios.org Subject: RE: [LinuxBIOS] Disabled device help Thanks a lot! It worked fine, except it missed the last 4GB of the allocation. This is an ugly way of getting it back. I'm not sure what the elegant way would be. The lower 32-bits need to be filled with ones in order for the space to be allocated correctly. Otherwise a 4GB allocation would show up as a one byte allocation. Now /proc/iomem shows my device at 8000000000-bfffffffff Myles --- drivers/pci/probe.c 2006-11-06 09:23:03.000000000 -0700 +++ drivers/pci/probe_new.c 2006-11-06 10:17:08.000000000 -0700 @@ -203,7 +203,7 @@ res->end = res->start + sz; if (szhi) { /* This BAR needs > 4GB? Wow. */ - res->end |= (unsigned long)szhi<<32; + res->end |= ((unsigned long)szhi<<32|0xffffffffUL); } #else if (szhi) { >Please check the patch. >YH >The Kernel pci_read_bases in drivers/pci/probe.c. has problem when size >if bigger than 4G. >It will first check the 32 bit SPACE_ADDRESS, and pci_size will return >0, So it will skip that resource. And the pre-set values is ignored. >And later, it will try to allocate the value. It will fail. >I will produce one patch for you. >YH >>My large device gets disabled somewhere in LinuxBIOS or the kernel. This >>is the encouraging line from LinuxBIOS telling me that the registers are >>indeed set correctly. >>PCI: 05:01.0 18 <- [8000000000 - bfffffffff] prefmem64 >>Unfortunately, Linux sees something different and fails to allocate this >>region because it sees it at 00000080-000000bf and that conflicts with >>other things. >>Does anyone have a pointer to where I should look for this problem? Has >>anyone else had problems with devices larger than 4GB? >>Thanks, >>Myles From uwe at hermann-uwe.de Mon Nov 6 21:27:17 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Mon, 6 Nov 2006 21:27:17 +0100 Subject: [LinuxBIOS] #31: Do proper checking for flash erase for SST FWH parts In-Reply-To: <20061105232241.7688.qmail@cdy.org> References: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> <20061105223902.GB10831@greenwood> <20061105232241.7688.qmail@cdy.org> Message-ID: <20061106202717.GA27396@greenwood> On Mon, Nov 06, 2006 at 12:22:41AM +0100, Peter Stuge wrote: > On Sun, Nov 05, 2006 at 11:39:03PM +0100, Uwe Hermann wrote: > > Well, that's a matter of taste. I have to delete whole _threads_ of > > duplicated mails all the time, just because I replied to a single mail > > in that thread. WTF? I'm subscribed, I _already_ get all the emails, > > why should I be CC'd explicitly all the time? > > You can configure Mailman to not send you another copy if it sees > your subscribed address among the recipients. Aah, much better now :) Thanks, I didn't know about that option. 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 yinghai.lu at amd.com Mon Nov 6 22:27:58 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Mon, 6 Nov 2006 13:27:58 -0800 Subject: [LinuxBIOS] Tyan s2892 the OLPC way Message-ID: <5986589C150B2F49A46483AC44C7BCA4907199@ssvlexmb2.amd.com> Any reason for using kernel in flash: Target system only have usb keyboard installed. YH From ward at pong.be Mon Nov 6 22:58:40 2006 From: ward at pong.be (Ward Vandewege) Date: Mon, 6 Nov 2006 16:58:40 -0500 Subject: [LinuxBIOS] asus A8N-VM CSM In-Reply-To: <20061016152124.GB30002@countzero.vandewege.net> References: <20061012191823.GA26747@countzero.vandewege.net> <20061013170150.GA26546@coresystems.de> <20061013180532.GA2753@countzero.vandewege.net> <20061013182455.GA7539@coresystems.de> <20061013183736.GA3167@countzero.vandewege.net> <20061013193212.GA16158@coresystems.de> <20061013211057.GA4051@countzero.vandewege.net> <20061013220130.GB24103@coresystems.de> <20061013224206.GA6474@coresystems.de> <20061016152124.GB30002@countzero.vandewege.net> Message-ID: <20061106215840.GB10707@countzero.vandewege.net> Hi Stefan, Any other suggestions to get flashrom to work on this board? Things I could try? Thanks, Ward. On Mon, Oct 16, 2006 at 11:21:24AM -0400, Ward Vandewege wrote: > On Sat, Oct 14, 2006 at 12:42:06AM +0200, Stefan Reinauer wrote: > > * Stefan Reinauer [061014 00:01]: > > > And maybe try the attached patch, maybe play a little with the delay,... > > > > > > *10,*100,*500,*1000 > > OK; with 200 microseconds, no difference: > > Pm49FL004 found at physical address: 0xfff80000 > Flash part is Pm49FL004 (512 KB) > Flash image seems to be a legacy BIOS. Disabling checks. > Programming Page: 000007 at address: 0x00070000 > Verifying flash address: 0x00000008 - FAILED > > Same thing with 10, 100, 500, 1000. > > Thanks, > Ward. > > -- > Ward Vandewege > Free Software Foundation - Senior System Administrator > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > > > !DSPAM:4533a49051261293511683! > Ward Vandewege. -- Pong.be -( "Parts that don't exist can't break." -- Russell Nelson )- Virtual hosting -( )- http://pong.be -( )- GnuPG public key: http://gpg.dtype.org From rminnich at gmail.com Tue Nov 7 04:25:40 2006 From: rminnich at gmail.com (ron minnich) Date: Mon, 6 Nov 2006 20:25:40 -0700 Subject: [LinuxBIOS] booting XP Message-ID: <13426df10611061925v5935b044iad42051d8754fafe@mail.gmail.com> The issue of booting XP just will not go away. So, there are two options I see, in order of preference: 1. find some way, using kexec etc., to boot XP under Linux, then put Linux in FLASH; done 2. revive ADLO there have been a number of suggestions for how to do the first one. 1. freeldr (vapor?) 2. tinyldr (vapor?) any non-vaporous ones out there? This note is an attempt to start a discussion and discovery on this subject. thanks ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From segher at kernel.crashing.org Mon Nov 6 19:26:15 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Mon, 6 Nov 2006 19:26:15 +0100 Subject: [LinuxBIOS] Disabled device help In-Reply-To: <01M98M01KAEY8YT0D9@EMAIL1.BYU.EDU> References: <01M98M01KAEY8YT0D9@EMAIL1.BYU.EDU> Message-ID: <7B27E87E-B03A-4F31-AC25-30A4F6A2BE89@kernel.crashing.org> > - res->end |= (unsigned long)szhi<<32; > + res->end |= ((unsigned > long)szhi<<32|0xffffffffUL); Should read res->end |= ((uint64_t)szhi << 32) | 0xffffffff; ("long" is 32-bits on many platforms). Segher From stepan at coresystems.de Tue Nov 7 08:53:10 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 7 Nov 2006 08:53:10 +0100 Subject: [LinuxBIOS] booting XP In-Reply-To: <13426df10611061925v5935b044iad42051d8754fafe@mail.gmail.com> References: <13426df10611061925v5935b044iad42051d8754fafe@mail.gmail.com> Message-ID: <20061107075310.GA11103@coresystems.de> * ron minnich [061107 04:25]: > So, there are two options I see, in order of preference: > 1. find some way, using kexec etc., to boot XP under Linux, then put Linux in > FLASH; done > 2. revive ADLO Maybe be can join 1 and 2, and run (parts of) ADLO on top of Linux, together with kexec. > there have been a number of suggestions for how to do the first one. > 1. freeldr (vapor?) > 2. tinyldr (vapor?) Any of these might be obsolete with Windows Vista, as it uses "winload.exe" instead of NTLDR The ugly thing with all Windows booting approaches is that the boot loader has a whole lot of intelligence, it is doing device enumeration, and, a lot worse: It is also loading device drivers. :-( I found a little bit of information about the boot configuration data provided by the boot loader to NTOSKERNL.EXE (Vista version) http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/BCD.doc Microsoft also has an online reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/BCD/bcd/portal.asp?frame=true Also there's nice information about the XP boot process: http://www.geocities.com/asoke_dasgupta/boot-xp.html Wikipedia knows: http://en.wikipedia.org/wiki/Windows_XP_Startup_Process -- 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 Nov 7 09:33:20 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 7 Nov 2006 09:33:20 +0100 Subject: [LinuxBIOS] booting XP In-Reply-To: <13426df10611061925v5935b044iad42051d8754fafe@mail.gmail.com> References: <13426df10611061925v5935b044iad42051d8754fafe@mail.gmail.com> Message-ID: <20061107083320.GA17723@coresystems.de> * ron minnich [061107 04:25]: > The issue of booting XP just will not go away. > > So, there are two options I see, in order of preference: > 1. find some way, using kexec etc., to boot XP under Linux, then put Linux in > FLASH; done > 2. revive ADLO > > there have been a number of suggestions for how to do the first one. > 1. freeldr (vapor?) > 2. tinyldr (vapor?) I had a quick chat about tinyldr this morning with Alex Ionescu, the author of tinykernl. It seems we can actually use most of NTLDR without any change. The only component we actually have to provide seems to be "startup.com" which is an abstracted interface doing all the bios callbacks. I consider this really great news. He sent me this URL: http://svn.tinykrnl.org/svn/tinykrnl/base/boot/tbx86/ TBX86 is his version of startup.com. Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From segher at kernel.crashing.org Tue Nov 7 10:16:57 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Tue, 7 Nov 2006 10:16:57 +0100 Subject: [LinuxBIOS] booting XP In-Reply-To: <20061107083320.GA17723@coresystems.de> References: <13426df10611061925v5935b044iad42051d8754fafe@mail.gmail.com> <20061107083320.GA17723@coresystems.de> Message-ID: <1B564613-A6FF-459D-9E3C-E2D161C695B1@kernel.crashing.org> > It seems we can actually use most of NTLDR without any change. > The only component we actually have to provide seems to be > "startup.com" > which is an abstracted interface doing all the bios callbacks. > > I consider this really great news. If you care about mswindows at all, it sure is. Does this work for vista too though? Segher From lfcorreia at lfcorreia.dyndns.org Tue Nov 7 10:39:27 2006 From: lfcorreia at lfcorreia.dyndns.org (Luis Correia) Date: Tue, 07 Nov 2006 09:39:27 +0000 Subject: [LinuxBIOS] Support for IEI Nova4899R [1] In-Reply-To: <20061105021200.GA5020@coresystems.de> References: <454CFA15.3080501@lfcorreia.dyndns.org> <13426df10611041640o2008c16fj21ccfb55fe0c8929@mail.gmail.com> <454D395A.3020205@lfcorreia.dyndns.org> <20061105021200.GA5020@coresystems.de> Message-ID: <4550544F.1070808@lfcorreia.dyndns.org> Stefan Reinauer wrote: > * Luis Correia [061105 02:07]: > >> I've managed to reduce the overall size of the bios and added the original >> VGA bios rom. But my guess (from reading the archives) that VSA is still >> not supported and such, my hopes of seeing any image on teh VGA screen are >> now even more reduced... >> > > VSA is supported since the OLPC. > > I looked into OLPC configuration options and could not figure out how to enable VSA for my board. The factory BIOS has a 32k Elpin systems vga rom and a 128k block with no visible strings that seems to be just code. I'm assuming this is the VSA code block. I have now reduced LinuxBIOS and FILO payload footprint in order to fit inside the remaining 96k in the BIOS. Attached you'll see a bootlog until FILO boots. This will give an idea of how the devices were initialized. We can see thatthe 32k vga bios is copied to the correct place, but nothing is done to the VSA portion, it is true that this VSA code does not have the standard BIOS start values (0x55aa). p.s. today i'm not complaining about IRQ's :) p.s.2. the actual console, ie keyboard and mouse appear to be working, at least the keyboard reacts on ctrl-alt-del. Luis Correia -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------- next part -------------- A non-text attachment was scrubbed... Name: 20061107.tar.gz Type: application/gzip Size: 2787 bytes Desc: not available URL: From bario2004 at yahoo.com Tue Nov 7 10:43:33 2006 From: bario2004 at yahoo.com (Corey) Date: Tue, 7 Nov 2006 01:43:33 -0800 (PST) Subject: [LinuxBIOS] 440bx stuff Message-ID: <20061107094333.62602.qmail@web30708.mail.mud.yahoo.com> Okay, I know you guy probably thought you got rid of me, but I'm still around. I'm currently trudging through everything I can find for docs on both the 440zx-66 and 440bx chipsets, and looking what's currently there for code and what exactly needs to be implemented. I still have the 440zx mobo (bios mod never worked out), and in the morning I should be able to get a 440bx, one that hopefully has a removable bios chip. I'm curious, is there any way to test the code through software, without a flash? Also, as far as POST cards go, any one thats better than the rest? Or just the cheapest thing I can find will work? Corey Osgood ----- Original Message ---- From: Richard Smith To: Uwe Hermann Cc: LinuxBIOS Sent: Sunday, November 5, 2006 2:06:40 PM Subject: Re: [LinuxBIOS] 440bx stuff Uwe Hermann wrote: >> This has been done. It's now i82371eb. > > Why not 82371eb (that's the official name AFAIK)? Is there some > requirement that directories have to start with a letter? Its a C thing. You can't start a variable with a number. That allows you to match the directory name to the struct statements in the code. > I think I'll have a look at this in the next few days. But I might use > the 855pm code (derived from e7501) as a basis, that looks even better. the e7501 datasheet has a date on it thats almost a full year earlier than the 855pm. I think the register names and operation may be closer to the 440bx. But feel free to use whatever. Its mostly about framework. -- Richard A. Smith -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios From svn at openbios.org Tue Nov 7 11:22:21 2006 From: svn at openbios.org (svn at openbios.org) Date: Tue, 07 Nov 2006 10:22:21 -0000 Subject: [LinuxBIOS] r2492 - trunk/LinuxBIOSv2/util/flashrom Message-ID: Author: stepan Date: 2006-11-07 11:22:20 +0100 (Tue, 07 Nov 2006) New Revision: 2492 Modified: trunk/LinuxBIOSv2/util/flashrom/flash_enable.c Log: Support for VIA VT82C686 in flashrom utility (trivial) closes #30 Signed-off-by: Stefan Reinauer Acked-by: Stefan Reinauer Modified: trunk/LinuxBIOSv2/util/flashrom/flash_enable.c =================================================================== --- trunk/LinuxBIOSv2/util/flashrom/flash_enable.c 2006-11-06 10:51:15 UTC (rev 2491) +++ trunk/LinuxBIOSv2/util/flashrom/flash_enable.c 2006-11-07 10:22:20 UTC (rev 2492) @@ -414,6 +414,7 @@ {0x1106, 0x8231, "VT8231", enable_flash_vt8231}, {0x1106, 0x3177, "VT8235", enable_flash_vt8235}, {0x1106, 0x3227, "VT8237", enable_flash_vt8231}, + {0x1106, 0x0686, "VT82C686", enable_flash_amd8111}, {0x1078, 0x0100, "CS5530", enable_flash_cs5530}, {0x100b, 0x0510, "SC1100", enable_flash_sc1100}, {0x1039, 0x0008, "SIS5595", enable_flash_sis5595}, From svn at openbios.org Tue Nov 7 11:25:03 2006 From: svn at openbios.org (LinuxBIOS) Date: Tue, 07 Nov 2006 10:25:03 -0000 Subject: [LinuxBIOS] #34: flashrom: Fix PIIX4/PIIX4E/PIIX4M code comments In-Reply-To: <060.9abad48f9c5061c9df763f3bf540d407@openbios.org> References: <060.9abad48f9c5061c9df763f3bf540d407@openbios.org> Message-ID: <069.9720f3934adce3272b1659713b1d1899@openbios.org> #34: flashrom: Fix PIIX4/PIIX4E/PIIX4M code comments -----------------------------------+---------------------------------------- Reporter: uwe | Owner: uwe Type: defect | Status: assigned Priority: minor | Milestone: Enhance the flashrom utility Component: flashrom | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: patch needs review | -----------------------------------+---------------------------------------- Comment (by stepan): There's a - missing. Otherwise this patch is fine. (means Acked-By) the lower 64-Kbyte BIOS block (E0000?EFFFF) at the top should read the lower 64-Kbyte BIOS block (E0000-?EFFFF) at the top -- Ticket URL: LinuxBIOS From stepan at coresystems.de Tue Nov 7 11:58:07 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 7 Nov 2006 11:58:07 +0100 Subject: [LinuxBIOS] booting XP In-Reply-To: <1B564613-A6FF-459D-9E3C-E2D161C695B1@kernel.crashing.org> References: <13426df10611061925v5935b044iad42051d8754fafe@mail.gmail.com> <20061107083320.GA17723@coresystems.de> <1B564613-A6FF-459D-9E3C-E2D161C695B1@kernel.crashing.org> Message-ID: <20061107105807.GA9500@coresystems.de> * Segher Boessenkool [061107 10:16]: > If you care about mswindows at all, it sure is. according to OSnews.com as well as http://www.w3schools.com/browsers/browsers_stats.asp Windows has a market share of about 90% in the PC market. If LinuxBIOS is at all aiming at becoming an alternative firmware for PCs, really nobody would assume we can afford not to care. Given that we can only keep up with supporting new server chipsets if we have a user base worth mentioning, there is no way around targeting the PC market as well. > Does this work for vista too though? We will need to find out by trying. There is no single future proof path or optimal solution unfortunately. - The "16bit bios callback approach" Using ADLO or something similar will help for Windows Vista, but it would need work on the built-in IDE driver, plus it would need work to get int13 plugin cards working. The strength of this approach is that by using a 16bit legacy interface cleanly encapsulated, we might be able to boot from any PCI plugin card, such as SCSI adapters. The weakness is clearly that we need to stick with 16bit legacy code (which we already do for vga init anyways) It sounds somewhat weird that we need to go ancient to support newer systems than what is there today, but this might indeed be the case. - The patchwork approach We create clean 32bit loaders for the operating systems we want to boot. Or we modify or enhance existing loaders to do so. The strength of this approach is we might be able to use Linux for booting from flash, gaining from Linux' good driver support. The weakness of this approach is we need to reflash the BIOS if we plug in a new SCSI adapter because the old one died. All SCSI drivers in Linux require about 5MB space, 1.3 for all ide devices, 1.5 for Infiniband. Even with pretty good compression, how are we going to plug this, plus a kernel, plus a bootloader plus LinuxBIOS in 1MB flash? Even though I am sure almost all people on this list compile their own kernels, this is not the usual case for people using Linux anymore. _Requiring_ to recompile your _BIOS_ to support booting from a new PCI card will not make us a lot of friends. So here we go. That's quite some of the misery along the mainstream path. Solutions, anyone? -- 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 Nov 7 12:04:04 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 7 Nov 2006 12:04:04 +0100 Subject: [LinuxBIOS] 440bx stuff In-Reply-To: <20061107094333.62602.qmail@web30708.mail.mud.yahoo.com> References: <20061107094333.62602.qmail@web30708.mail.mud.yahoo.com> Message-ID: <20061107110404.GC12958@coresystems.de> * Corey [061107 10:43]: > Okay, I know you guy probably thought you got rid of me, but I'm still > around. Glad you are. We never intended to get rid of (potential) contributors. ;-) > I'm currently trudging through everything I can find for docs > on both the 440zx-66 and 440bx chipsets, and looking what's currently > there for code and what exactly needs to be implemented. I still have > the 440zx mobo (bios mod never worked out), and in the morning I > should be able to get a 440bx, one that hopefully has a removable bios > chip. great. > I'm curious, is there any way to test the code through software, > without a flash? Not for this part of the code. Software emulations dont emulate the chipset well enough to find out whether your code does the right thing. Unless you are using SimNow to simulate an AMD system. Dont know if something like this exists for Intel CPUs though. > Also, as far as POST cards go, any one thats better > than the rest? Or just the cheapest thing I can find will work? Get yourself a serial null modem cable attached to a second box... its far more useful than a post card. getting serial output is not too hard. -- 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 Tue Nov 7 12:16:25 2006 From: svn at openbios.org (svn at openbios.org) Date: Tue, 07 Nov 2006 11:16:25 -0000 Subject: [LinuxBIOS] r2493 - trunk/LinuxBIOSv2/util/flashrom Message-ID: Author: uwe Date: 2006-11-07 12:16:21 +0100 (Tue, 07 Nov 2006) New Revision: 2493 Modified: trunk/LinuxBIOSv2/util/flashrom/flash_enable.c Log: Fix some code comments of the Intel PIIX4/PIIX4E/PIIX4M code. Add detailed instructions on how and where to get the datasheet, its name, and order number (Closes #34). Signed-off-by: Uwe Hermann Acked-by: Stefan Reinauer Modified: trunk/LinuxBIOSv2/util/flashrom/flash_enable.c =================================================================== --- trunk/LinuxBIOSv2/util/flashrom/flash_enable.c 2006-11-07 10:22:20 UTC (rev 2492) +++ trunk/LinuxBIOSv2/util/flashrom/flash_enable.c 2006-11-07 11:16:21 UTC (rev 2493) @@ -77,7 +77,12 @@ return 0; } -/* Datasheet: http://www.intel.com/design/intarch/datashts/290562.htm */ +/* Datasheet: + * - Name: 82371AB PCI-TO-ISA / IDE XCELERATOR (PIIX4) + * - URL: http://www.intel.com/design/intarch/datashts/290562.htm + * - PDF: http://www.intel.com/design/intarch/datashts/29056201.pdf + * - Order Number: 290562-001 + */ static int enable_flash_piix4(struct pci_dev *dev, char *name) { uint16_t old, new; @@ -90,10 +95,11 @@ Set bit 7: Extended BIOS Enable (PCI master accesses to FFF80000-FFFDFFFF are forwarded to ISA). Set bit 6: Lower BIOS Enable (PCI master, or ISA master accesses to - the lower 64-Kbyte BIOS block (E00000?EFFFF) at the top + the lower 64-Kbyte BIOS block (E0000-EFFFF) at the top of 1 Mbyte, or the aliases at the top of 4 Gbyte - (FFFE0000-FFFEFFF) result in the generation of BIOSCS#. - Set bit 2: BIOSCS# Write Protect Enable (1=enable, 0=disable). */ + (FFFE0000-FFFEFFFF) result in the generation of BIOSCS#. + Note: Accesses to FFFF0000-FFFFFFFF are always forwarded to ISA. + Set bit 2: BIOSCS# Write Enable (1=enable, 0=disable). */ new = old | 0x2c4; if (new == old) From svn at openbios.org Tue Nov 7 12:21:12 2006 From: svn at openbios.org (LinuxBIOS) Date: Tue, 07 Nov 2006 11:21:12 -0000 Subject: [LinuxBIOS] #34: flashrom: Fix PIIX4/PIIX4E/PIIX4M code comments In-Reply-To: <060.9abad48f9c5061c9df763f3bf540d407@openbios.org> References: <060.9abad48f9c5061c9df763f3bf540d407@openbios.org> Message-ID: <069.5c84253d0ad0f41e8b2ba80e9b953d00@openbios.org> #34: flashrom: Fix PIIX4/PIIX4E/PIIX4M code comments -----------------------------------------+---------------------------------- Reporter: uwe | Owner: uwe Type: defect | Status: closed Priority: minor | Milestone: Enhance the flashrom utility Component: flashrom | Version: v2 Resolution: fixed | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: patch has been committed | -----------------------------------------+---------------------------------- Changes (by uwe): * patchstatus: patch needs review => patch has been committed -- Ticket URL: LinuxBIOS From svn at openbios.org Tue Nov 7 12:23:39 2006 From: svn at openbios.org (LinuxBIOS) Date: Tue, 07 Nov 2006 11:23:39 -0000 Subject: [LinuxBIOS] #30: Support for VIA VT82C686 in flashrom In-Reply-To: <060.b7bf006a0db81bb4230b08879c9216f8@openbios.org> References: <060.b7bf006a0db81bb4230b08879c9216f8@openbios.org> Message-ID: <069.4902afd02c6fa25c23d2967b4594bbcb@openbios.org> #30: Support for VIA VT82C686 in flashrom -----------------------------------------+---------------------------------- Reporter: stepan | Owner: stepan Type: enhancement | Status: closed Priority: minor | Milestone: Enhance the flashrom utility Component: flashrom | Version: v2 Resolution: fixed | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: patch has been committed | -----------------------------------------+---------------------------------- Changes (by uwe): * patchstatus: patch needs review => patch has been committed -- Ticket URL: LinuxBIOS From svn at openbios.org Tue Nov 7 12:24:12 2006 From: svn at openbios.org (LinuxBIOS) Date: Tue, 07 Nov 2006 11:24:12 -0000 Subject: [LinuxBIOS] #20: Cleanup of all CHIP_NAME() entries In-Reply-To: <060.68503be5d6132cbfcbc83dcf54946a9a@openbios.org> References: <060.68503be5d6132cbfcbc83dcf54946a9a@openbios.org> Message-ID: <069.1f11cf46a34a32666d968eeb05e701e3@openbios.org> #20: Cleanup of all CHIP_NAME() entries -----------------------------------------+---------------------------------- Reporter: uwe | Owner: uwe Type: defect | Status: closed Priority: minor | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: fixed | Keywords: Due_close: DD/MM/YYYY | Include_gantt: 0 Dependencies: | Due_assign: DD/MM/YYYY Patchstatus: patch has been committed | -----------------------------------------+---------------------------------- Changes (by uwe): * patchstatus: => patch has been committed -- Ticket URL: LinuxBIOS From svn at openbios.org Tue Nov 7 12:24:24 2006 From: svn at openbios.org (LinuxBIOS) Date: Tue, 07 Nov 2006 11:24:24 -0000 Subject: [LinuxBIOS] #27: Minor typo In-Reply-To: <060.a9aa5063cefa73c1bcdec6d6b963b3c4@openbios.org> References: <060.a9aa5063cefa73c1bcdec6d6b963b3c4@openbios.org> Message-ID: <069.ba1294ccb079170ddc0a78126a464476@openbios.org> #27: Minor typo --------------------------------------------------------+------------------- Reporter: Luis Correia | Owner: somebody Type: enhancement | Status: closed Priority: trivial | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: fixed | Keywords: typo fix Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: patch has been committed | --------------------------------------------------------+------------------- Changes (by uwe): * patchstatus: => patch has been committed -- Ticket URL: LinuxBIOS From svn at openbios.org Tue Nov 7 12:24:47 2006 From: svn at openbios.org (LinuxBIOS) Date: Tue, 07 Nov 2006 11:24:47 -0000 Subject: [LinuxBIOS] #19: Remove useless #includes from mainboard.c files In-Reply-To: <060.90c6a1724c0dfb20c8eff5a14aefe6ab@openbios.org> References: <060.90c6a1724c0dfb20c8eff5a14aefe6ab@openbios.org> Message-ID: <069.2230216ceefa2a6c325d1824e119040b@openbios.org> #19: Remove useless #includes from mainboard.c files -----------------------------------------+---------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: closed Priority: minor | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: fixed | Keywords: Due_close: DD/MM/YYYY | Include_gantt: 0 Dependencies: | Due_assign: DD/MM/YYYY Patchstatus: patch has been committed | -----------------------------------------+---------------------------------- Changes (by uwe): * patchstatus: => patch has been committed -- Ticket URL: LinuxBIOS From svn at openbios.org Tue Nov 7 12:25:17 2006 From: svn at openbios.org (LinuxBIOS) Date: Tue, 07 Nov 2006 11:25:17 -0000 Subject: [LinuxBIOS] #3: connect abuild to the automated test system In-Reply-To: <060.93f271d0a06e710127a6af5e9827ec97@openbios.org> References: <060.93f271d0a06e710127a6af5e9827ec97@openbios.org> Message-ID: <069.d0803c7e85e974b5882bbc3aac0891cb@openbios.org> #3: connect abuild to the automated test system -----------------------------------------+---------------------------------- Reporter: stepan | Owner: stepan Type: enhancement | Status: closed Priority: major | Milestone: Component: code | Version: v2 Resolution: fixed | Keywords: abuild, testsystem Due_close: | Include_gantt: 1 Dependencies: | Due_assign: Patchstatus: patch has been committed | -----------------------------------------+---------------------------------- Changes (by uwe): * patchstatus: => patch has been committed -- Ticket URL: LinuxBIOS From svn at openbios.org Tue Nov 7 12:47:04 2006 From: svn at openbios.org (LinuxBIOS) Date: Tue, 07 Nov 2006 11:47:04 -0000 Subject: [LinuxBIOS] #32: New motherboard IEI NOVA4899R In-Reply-To: <060.c3a3c2f45e93a6296863c1cd84d73236@openbios.org> References: <060.c3a3c2f45e93a6296863c1cd84d73236@openbios.org> Message-ID: <069.8ddf60437a2693f215e02d46ffdbd091@openbios.org> #32: New motherboard IEI NOVA4899R --------------------------------------------------------+------------------- Reporter: Luis Correia | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: patch needs review | --------------------------------------------------------+------------------- Changes (by uwe): * priority: trivial => major Comment: Replying to [comment:1 Luis Correia ]: > This fileset is loosely based on the eaglelion 5bcm mainboard, as it was one that shared most components to this board. Please add the common license header to all files. See http://www.linuxbios.org/Development_Guidelines#Common_License_Header for details. For most files this is easy as you wrote them (mostly) from scratch or they are trivial -- just insert yourself as copyright owner. For files which were copied you'll have to dig in the svn logs a bit to find the original author. I can help with that if needed, just let me know. Another thing: Please make {{{ CHIP_NAME("IEI nova4899r mainboard") }}} in mainbaord.c read {{{ CHIP_NAME("IEI NOVA-4899R Mainboard") }}} instead. -- Ticket URL: LinuxBIOS From svn at openbios.org Tue Nov 7 13:00:48 2006 From: svn at openbios.org (LinuxBIOS) Date: Tue, 07 Nov 2006 12:00:48 -0000 Subject: [LinuxBIOS] #35: Make it possible to boot Windows using LinuxBIOS Message-ID: <060.dc2079fe853ee48ce5e969ec6cef481f@openbios.org> #35: Make it possible to boot Windows using LinuxBIOS -----------------------------+---------------------------------------------- Reporter: uwe | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Going mainstream Component: code | Version: v2 Keywords: | Due_close: MM/DD/YYYY Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Patchstatus: there is no patch -----------------------------+---------------------------------------------- From http://www.linuxbios.org/pipermail/linuxbios/2006-November/016793.html: {{{ The issue of booting XP just will not go away. So, there are two options I see, in order of preference: 1. find some way, using kexec etc., to boot XP under Linux, then put Linux in FLASH; done 2. revive ADLO there have been a number of suggestions for how to do the first one. 1. freeldr (vapor?) 2. tinyldr (vapor?) any non-vaporous ones out there? This note is an attempt to start a discussion and discovery on this subject. }}} -- Ticket URL: LinuxBIOS From svn at openbios.org Tue Nov 7 13:16:56 2006 From: svn at openbios.org (LinuxBIOS) Date: Tue, 07 Nov 2006 12:16:56 -0000 Subject: [LinuxBIOS] #31: Do proper checking for flash erase for SST FWH parts In-Reply-To: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> References: <060.060a33a96e1603c014b04df61cd238c0@openbios.org> Message-ID: <069.c0cd31c7cca51aec7f5fcdf3c3c96ecd@openbios.org> #31: Do proper checking for flash erase for SST FWH parts -----------------------------------------------+---------------------------- Reporter: stepan | Owner: stepan Type: defect | Status: assigned Priority: minor | Milestone: Enhance the flashrom utility Component: flashrom | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: patch is ready to be committed | -----------------------------------------------+---------------------------- Changes (by uwe): * patchstatus: patch needs review => patch is ready to be committed Comment: Acked-by: Uwe Hermann Untested, but the patch looks good to me. -- Ticket URL: LinuxBIOS From jrydberg at gnu.org Tue Nov 7 14:28:05 2006 From: jrydberg at gnu.org (Johan Rydberg) Date: Tue, 07 Nov 2006 14:28:05 +0100 Subject: [LinuxBIOS] 440bx stuff References: <20061107094333.62602.qmail@web30708.mail.mud.yahoo.com> <20061107110404.GC12958@coresystems.de> Message-ID: <87velrmlne.fsf@gnu.org> Stefan Reinauer writes: >> I'm curious, is there any way to test the code through software, >> without a flash? > > Not for this part of the code. Software emulations dont emulate the > chipset well enough to find out whether your code does the right thing. > Unless you are using SimNow to simulate an AMD system. Dont know if > something like this exists for Intel CPUs though. I would say that this is a shame. We really need a top-notch full system simulator. But doing complete and correct simulation of chipsets is hard, error prone and quite boring. Therefor emulators like QEMU take the short path, and put in a "phony" BIOS and more or less do not implement a northbridge at all. What we need is a full-system simulator with the following characteristics; * correct, * deterministic, * visible device state, * visible cpu state, * scriptable, * and pluggable (for profiling and coverage tools) Note that I have not put "fast" on the list. I think that is secondary for our use case. ~j -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From svn at openbios.org Tue Nov 7 14:48:48 2006 From: svn at openbios.org (svn at openbios.org) Date: Tue, 07 Nov 2006 13:48:48 -0000 Subject: [LinuxBIOS] r2494 - trunk/LinuxBIOSv2/util/flashrom Message-ID: Author: stepan Date: 2006-11-07 14:48:46 +0100 (Tue, 07 Nov 2006) New Revision: 2494 Modified: trunk/LinuxBIOSv2/util/flashrom/sst_fwhub.c Log: Instead of checking the first byte only, the whole part is checked now. This will detect any improper erase, closes #31 Signed-off-by: Stefan Reinauer Acked-by: Uwe Hermann Modified: trunk/LinuxBIOSv2/util/flashrom/sst_fwhub.c =================================================================== --- trunk/LinuxBIOSv2/util/flashrom/sst_fwhub.c 2006-11-07 11:16:21 UTC (rev 2493) +++ trunk/LinuxBIOSv2/util/flashrom/sst_fwhub.c 2006-11-07 13:48:46 UTC (rev 2494) @@ -95,14 +95,17 @@ flash->page_size; volatile uint8_t *bios = flash->virt_addr; - // Do we want block wide erase? + // FIXME: We want block wide erase instead of ironing the whole chip erase_sst_fwhub(flash); - // FIXME: This test is not sufficient! - if (*bios != 0xff) { - printf("ERASE FAILED\n"); - return -1; + // dumb check if erase was successful. + for (i=0; i < total_size; i++) { + if (bios[i] != 0xff) { + printf("ERASE FAILED\n"); + return -1; + } } + printf("Programming Page: "); for (i = 0; i < total_size / page_size; i++) { printf("%04d at address: 0x%08x", i, i * page_size); From stepan at coresystems.de Tue Nov 7 15:10:38 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 7 Nov 2006 15:10:38 +0100 Subject: [LinuxBIOS] 440bx stuff In-Reply-To: <87velrmlne.fsf@gnu.org> References: <20061107094333.62602.qmail@web30708.mail.mud.yahoo.com> <20061107110404.GC12958@coresystems.de> <87velrmlne.fsf@gnu.org> Message-ID: <20061107141037.GA32087@coresystems.de> * Johan Rydberg [061107 14:28]: > I would say that this is a shame. We really need a top-notch full > system simulator. But doing complete and correct simulation of > chipsets is hard, error prone and quite boring. Therefor emulators > like QEMU take the short path, and put in a "phony" BIOS and more or > less do not implement a northbridge at all. I know SimNow can theoretically do it, and it can be enhanced by Plugins for CPU, northbridge, southbridge, other bridges, other pci devices But I doubt AMD is going to add Intel CPU plugins to it ;-) Can Simics to that stuff? > What we need is a full-system simulator with the following > characteristics; > > * correct, > * deterministic, > * visible device state, > * visible cpu state, > * scriptable, > * and pluggable (for profiling and coverage tools) > > Note that I have not put "fast" on the list. I think that is > secondary for our use case. For this simulator to be done, a whole lot of understanding of the hardware components is required, maybe including their errata. Adding support for a new component for such a simulator _might_ be more work than writing a bios for the same chipset. But no doubt this would be great to have. 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 jrydberg at gnu.org Tue Nov 7 15:44:30 2006 From: jrydberg at gnu.org (Johan Rydberg) Date: Tue, 07 Nov 2006 15:44:30 +0100 Subject: [LinuxBIOS] 440bx stuff In-Reply-To: <20061107141037.GA32087@coresystems.de> (Stefan Reinauer's message of "Tue, 7 Nov 2006 15:10:38 +0100") References: <20061107094333.62602.qmail@web30708.mail.mud.yahoo.com> <20061107110404.GC12958@coresystems.de> <87velrmlne.fsf@gnu.org> <20061107141037.GA32087@coresystems.de> Message-ID: <87r6wfmi41.fsf@gnu.org> Stefan Reinauer writes: > But I doubt AMD is going to add Intel CPU plugins to it ;-) > > Can Simics to that stuff? Yes, it can. Simics is more or less a set of connected components, that is glued together by a set of scripts that builds the system configuration. I know LinuxBIOS has been run on some of the models. >> What we need is a full-system simulator with the following >> characteristics; >> [...] > > For this simulator to be done, a whole lot of understanding of the > hardware components is required, maybe including their errata. Adding > support for a new component for such a simulator _might_ be more work > than writing a bios for the same chipset. Yeah. I didn't say _we_ should implement a simulator just to run LinuxBIOS on it. Other projects should gain from a simulator, but LinuxBIOS might benefit the most from having one. Lets just hope someone identifies the need outside this project. ~j -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From rminnich at gmail.com Tue Nov 7 15:42:59 2006 From: rminnich at gmail.com (ron minnich) Date: Tue, 7 Nov 2006 07:42:59 -0700 Subject: [LinuxBIOS] booting XP In-Reply-To: <20061107105807.GA9500@coresystems.de> References: <13426df10611061925v5935b044iad42051d8754fafe@mail.gmail.com> <20061107083320.GA17723@coresystems.de> <1B564613-A6FF-459D-9E3C-E2D161C695B1@kernel.crashing.org> <20061107105807.GA9500@coresystems.de> Message-ID: <13426df10611070642p32936325x23c021e91da743d9@mail.gmail.com> for now, let's get adlo back to the point that we can use it? That includes documentation, and possibly setting up a buildrom target for it. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From svn at openbios.org Tue Nov 7 16:08:22 2006 From: svn at openbios.org (LinuxBIOS) Date: Tue, 07 Nov 2006 15:08:22 -0000 Subject: [LinuxBIOS] #28: Finish Intel 440BX port In-Reply-To: <060.01473e4e80de4582a0ff0c94985dda64@openbios.org> References: <060.01473e4e80de4582a0ff0c94985dda64@openbios.org> Message-ID: <069.14d3d8a3c66ffb58490242766e4b212f@openbios.org> #28: Finish Intel 440BX port ----------------------------------+----------------------------------------- Reporter: uwe | Owner: somebody Type: task | Status: new Priority: critical | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: there is no patch | ----------------------------------+----------------------------------------- Changes (by uwe): * patchstatus: => there is no patch Comment: A related thread in the mailing list has started here: http://www.linuxbios.org/pipermail/linuxbios/2006-November/016799.html -- Ticket URL: LinuxBIOS From smithbone at gmail.com Tue Nov 7 16:17:08 2006 From: smithbone at gmail.com (Richard Smith) Date: Tue, 07 Nov 2006 09:17:08 -0600 Subject: [LinuxBIOS] 440bx stuff In-Reply-To: <20061107110404.GC12958@coresystems.de> References: <20061107094333.62602.qmail@web30708.mail.mud.yahoo.com> <20061107110404.GC12958@coresystems.de> Message-ID: <4550A374.9080903@gmail.com> Stefan Reinauer wrote: >> there for code and what exactly needs to be implemented. I still have >> the 440zx mobo (bios mod never worked out), and in the morning I >> should be able to get a 440bx, one that hopefully has a removable bios >> chip. Yeah! A developer to the rescue. >> Also, as far as POST cards go, any one thats better >> than the rest? Or just the cheapest thing I can find will work? > > Get yourself a serial null modem cable attached to a second box... > its far more useful than a post card. getting serial output is not too > hard. +1 And depending on your superIO it might already "Just Work" -- Richard A. Smith From smithbone at gmail.com Tue Nov 7 16:27:07 2006 From: smithbone at gmail.com (Richard Smith) Date: Tue, 07 Nov 2006 09:27:07 -0600 Subject: [LinuxBIOS] 440bx stuff In-Reply-To: <87r6wfmi41.fsf@gnu.org> References: <20061107094333.62602.qmail@web30708.mail.mud.yahoo.com> <20061107110404.GC12958@coresystems.de> <87velrmlne.fsf@gnu.org> <20061107141037.GA32087@coresystems.de> <87r6wfmi41.fsf@gnu.org> Message-ID: <4550A5CB.7000907@gmail.com> Johan Rydberg wrote: >> For this simulator to be done, a whole lot of understanding of the >> hardware components is required, maybe including their errata. Adding >> support for a new component for such a simulator _might_ be more work >> than writing a bios for the same chipset. > > Yeah. I didn't say _we_ should implement a simulator just to run > LinuxBIOS on it. Other projects should gain from a simulator, but > LinuxBIOS might benefit the most from having one. Lets just hope > someone identifies the need outside this project. The only people who can do this are the people who have the hardware description info (the VHDL or whatever). I'm quite sure Intel has sme sort of tool like SimNow internally but they just aren't talking or its only released under NDA. -- Richard A. Smith From rminnich at gmail.com Tue Nov 7 16:36:52 2006 From: rminnich at gmail.com (ron minnich) Date: Tue, 7 Nov 2006 08:36:52 -0700 Subject: [LinuxBIOS] so who can revive adlo Message-ID: <13426df10611070736u37b82781w60a0d70a59461025@mail.gmail.com> anybody built it lately? I forget how it all goes together. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From smithbone at gmail.com Tue Nov 7 16:47:00 2006 From: smithbone at gmail.com (Richard Smith) Date: Tue, 07 Nov 2006 09:47:00 -0600 Subject: [LinuxBIOS] so who can revive adlo In-Reply-To: <13426df10611070736u37b82781w60a0d70a59461025@mail.gmail.com> References: <13426df10611070736u37b82781w60a0d70a59461025@mail.gmail.com> Message-ID: <4550AA74.5000701@gmail.com> ron minnich wrote: > anybody built it lately? I forget how it all goes together. Check the archives.. A patch was sent about 4 months ago that ports it to V2.. -- Richard A. Smith From rminnich at gmail.com Tue Nov 7 16:47:33 2006 From: rminnich at gmail.com (ron minnich) Date: Tue, 7 Nov 2006 08:47:33 -0700 Subject: [LinuxBIOS] booting XP In-Reply-To: <13426df10611070642p32936325x23c021e91da743d9@mail.gmail.com> References: <13426df10611061925v5935b044iad42051d8754fafe@mail.gmail.com> <20061107083320.GA17723@coresystems.de> <1B564613-A6FF-459D-9E3C-E2D161C695B1@kernel.crashing.org> <20061107105807.GA9500@coresystems.de> <13426df10611070642p32936325x23c021e91da743d9@mail.gmail.com> Message-ID: <13426df10611070747r3979399cl89831d65aec33cb4@mail.gmail.com> wow, looking at ADLO, this will be a bit of work, but worth it. What's the accepted way to bulid 16-bit code nowadays? Still bcc? as86 loader.s is easy: convert and junk as86. I assume that vista will boot on legacy pc with 16-bit bios, right? ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Tue Nov 7 16:48:09 2006 From: rminnich at gmail.com (ron minnich) Date: Tue, 7 Nov 2006 08:48:09 -0700 Subject: [LinuxBIOS] so who can revive adlo In-Reply-To: <4550AA74.5000701@gmail.com> References: <13426df10611070736u37b82781w60a0d70a59461025@mail.gmail.com> <4550AA74.5000701@gmail.com> Message-ID: <13426df10611070748n1a9d51d3q70f886d4a525c9f2@mail.gmail.com> you just made the case for Trak :-) ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From stepan at coresystems.de Tue Nov 7 16:49:35 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 7 Nov 2006 16:49:35 +0100 Subject: [LinuxBIOS] booting XP In-Reply-To: <13426df10611070747r3979399cl89831d65aec33cb4@mail.gmail.com> References: <13426df10611061925v5935b044iad42051d8754fafe@mail.gmail.com> <20061107083320.GA17723@coresystems.de> <1B564613-A6FF-459D-9E3C-E2D161C695B1@kernel.crashing.org> <20061107105807.GA9500@coresystems.de> <13426df10611070642p32936325x23c021e91da743d9@mail.gmail.com> <13426df10611070747r3979399cl89831d65aec33cb4@mail.gmail.com> Message-ID: <20061107154935.GA23151@coresystems.de> * ron minnich [061107 16:47]: > wow, looking at ADLO, this will be a bit of work, but worth it. > > What's the accepted way to bulid 16-bit code nowadays? Still bcc? > > as86 loader.s is easy: convert and junk as86. > > I assume that vista will boot on legacy pc with 16-bit bios, right? and only with that. They refused to put EFI support in there. Funny, but Microsoft is a little bit on our side ;-) -- 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 Tue Nov 7 16:53:50 2006 From: rminnich at gmail.com (ron minnich) Date: Tue, 7 Nov 2006 08:53:50 -0700 Subject: [LinuxBIOS] booting XP In-Reply-To: <20061107154935.GA23151@coresystems.de> References: <13426df10611061925v5935b044iad42051d8754fafe@mail.gmail.com> <20061107083320.GA17723@coresystems.de> <1B564613-A6FF-459D-9E3C-E2D161C695B1@kernel.crashing.org> <20061107105807.GA9500@coresystems.de> <13426df10611070642p32936325x23c021e91da743d9@mail.gmail.com> <13426df10611070747r3979399cl89831d65aec33cb4@mail.gmail.com> <20061107154935.GA23151@coresystems.de> Message-ID: <13426df10611070753o61665807x5412b13952acc67b@mail.gmail.com> Challenge to the list: find that port patch Richard mentioned. I have to go to a meeting. If someone can find it, I'll check it out and commit it. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From smithbone at gmail.com Tue Nov 7 17:00:53 2006 From: smithbone at gmail.com (Richard Smith) Date: Tue, 07 Nov 2006 10:00:53 -0600 Subject: [LinuxBIOS] so who can revive adlo In-Reply-To: <13426df10611070748n1a9d51d3q70f886d4a525c9f2@mail.gmail.com> References: <13426df10611070736u37b82781w60a0d70a59461025@mail.gmail.com> <4550AA74.5000701@gmail.com> <13426df10611070748n1a9d51d3q70f886d4a525c9f2@mail.gmail.com> Message-ID: <4550ADB5.2060302@gmail.com> ron minnich wrote: The link btw. http://www.linuxbios.org/pipermail/linuxbios/2006-July/015051.html > you just made the case for Trak :-) I don't deny that some sort of patch management is not useful and necessary even. I just don't like _having_ to do all things Trac as its not near as easy as mail. It also means you have to be on-line. I found that patch in my mail folders in about 2 seconds without having to fire up a browser to look for it. I knew the patch was there and its on my TODO. So its not like it got lost or anything. I just don't have a working machine to test it on. Its on the list right after make 440bx work. :) -- Richard A. Smith From stepan at coresystems.de Tue Nov 7 17:05:27 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 7 Nov 2006 17:05:27 +0100 Subject: [LinuxBIOS] booting XP In-Reply-To: <13426df10611070753o61665807x5412b13952acc67b@mail.gmail.com> References: <13426df10611061925v5935b044iad42051d8754fafe@mail.gmail.com> <20061107083320.GA17723@coresystems.de> <1B564613-A6FF-459D-9E3C-E2D161C695B1@kernel.crashing.org> <20061107105807.GA9500@coresystems.de> <13426df10611070642p32936325x23c021e91da743d9@mail.gmail.com> <13426df10611070747r3979399cl89831d65aec33cb4@mail.gmail.com> <20061107154935.GA23151@coresystems.de> <13426df10611070753o61665807x5412b13952acc67b@mail.gmail.com> Message-ID: <20061107160527.GA26850@coresystems.de> * ron minnich [061107 16:53]: > Challenge to the list: find that port patch Richard mentioned. I have to go to > a meeting. If someone can find it, I'll check it out and commit it. The full source is here (sent around by YhLu) LinuxBIOSv2/util/ADLO Added in r2457 (found using the search engine on qa.linuxbios.org) http://snapshots.linuxbios.org/stats/commit-LinuxBIOSv2-2457.log -- 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 Tue Nov 7 17:10:15 2006 From: svn at openbios.org (LinuxBIOS) Date: Tue, 07 Nov 2006 16:10:15 -0000 Subject: [LinuxBIOS] #36: Make the mailing list archive searchable Message-ID: <060.310e1ce9ac350c87801b63e0c3140a12@openbios.org> #36: Make the mailing list archive searchable -------------------------------+-------------------------------------------- Reporter: rsmith | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: documentation | Version: v2 Keywords: | Due_close: MM/DD/YYYY Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Patchstatus: there is no patch -------------------------------+-------------------------------------------- "Challenge to the list: find that port patch Richard mentioned. I have to go to a meeting. If someone can find it, I'll check it out and commit it. -ron" Nuff said. The list archives need to be searchable. -- Ticket URL: LinuxBIOS From smithbone at gmail.com Tue Nov 7 17:11:45 2006 From: smithbone at gmail.com (Richard Smith) Date: Tue, 07 Nov 2006 10:11:45 -0600 Subject: [LinuxBIOS] 440bx stuff In-Reply-To: <20061107110404.GC12958@coresystems.de> References: <20061107094333.62602.qmail@web30708.mail.mud.yahoo.com> <20061107110404.GC12958@coresystems.de> Message-ID: <4550B041.70403@gmail.com> Stefan Reinauer wrote: >> there for code and what exactly needs to be implemented. I still have >> the 440zx mobo (bios mod never worked out), and in the morning I >> should be able to get a 440bx, one that hopefully has a removable bios >> chip. Yeah! A developer to the rescue. Go! man Go! >> Also, as far as POST cards go, any one thats better >> than the rest? Or just the cheapest thing I can find will work? > > Get yourself a serial null modem cable attached to a second box... > its far more useful than a post card. getting serial output is not too > hard. And depending on your superIO it might already "Just Work" -- Richard A. Smith From smithbone at gmail.com Tue Nov 7 17:13:01 2006 From: smithbone at gmail.com (Richard Smith) Date: Tue, 07 Nov 2006 10:13:01 -0600 Subject: [LinuxBIOS] booting XP In-Reply-To: <20061107160527.GA26850@coresystems.de> References: <13426df10611061925v5935b044iad42051d8754fafe@mail.gmail.com> <20061107083320.GA17723@coresystems.de> <1B564613-A6FF-459D-9E3C-E2D161C695B1@kernel.crashing.org> <20061107105807.GA9500@coresystems.de> <13426df10611070642p32936325x23c021e91da743d9@mail.gmail.com> <13426df10611070747r3979399cl89831d65aec33cb4@mail.gmail.com> <20061107154935.GA23151@coresystems.de> <13426df10611070753o61665807x5412b13952acc67b@mail.gmail.com> <20061107160527.GA26850@coresystems.de> Message-ID: <4550B08D.4050006@gmail.com> Stefan Reinauer wrote: > * ron minnich [061107 16:53]: >> Challenge to the list: find that port patch Richard mentioned. I have to go to >> a meeting. If someone can find it, I'll check it out and commit it. > > The full source is here (sent around by YhLu) > LinuxBIOSv2/util/ADLO > > Added in r2457 (found using the search engine on qa.linuxbios.org) Now. that I did miss.. -- Richard A. Smith From svn at openbios.org Tue Nov 7 17:27:33 2006 From: svn at openbios.org (LinuxBIOS) Date: Tue, 07 Nov 2006 16:27:33 -0000 Subject: [LinuxBIOS] #36: Make the mailing list archive searchable In-Reply-To: <060.310e1ce9ac350c87801b63e0c3140a12@openbios.org> References: <060.310e1ce9ac350c87801b63e0c3140a12@openbios.org> Message-ID: <069.0c93a3cdfe906b21793433a38ad187bc@openbios.org> #36: Make the mailing list archive searchable ----------------------------------+----------------------------------------- Reporter: rsmith | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: documentation | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: there is no patch | ----------------------------------+----------------------------------------- Comment (by uwe): You can use Google. Example: http://www.google.com/search?hl=en&lr=&as_qdr=all&q=440bx+site%3Ahttp%3A%2F%2Fwww.linuxbios.org%2F&btnG=Search It might not have all mails, though. -- Ticket URL: LinuxBIOS From segher at kernel.crashing.org Tue Nov 7 17:41:59 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Tue, 7 Nov 2006 17:41:59 +0100 Subject: [LinuxBIOS] so who can revive adlo In-Reply-To: <4550ADB5.2060302@gmail.com> References: <13426df10611070736u37b82781w60a0d70a59461025@mail.gmail.com> <4550AA74.5000701@gmail.com> <13426df10611070748n1a9d51d3q70f886d4a525c9f2@mail.gmail.com> <4550ADB5.2060302@gmail.com> Message-ID: > http://www.linuxbios.org/pipermail/linuxbios/2006-July/015051.html > >> you just made the case for Trak :-) > > I don't deny that some sort of patch management is not useful and > necessary even. I just don't like _having_ to do all things Trac > as its > not near as easy as mail. It also means you have to be on-line. Fully agreed all three times. > I found that patch in my mail folders in about 2 seconds without > having > to fire up a browser to look for it. > > I knew the patch was there and its on my TODO. So its not like it got > lost or anything. But longer-time things like this _should_ be tracked (in Trac). Same goes for patches that we can't decide what to do with (or that we can't handle right now). Stuff that's actively being discussed is handled way more efficient (and easier) on the mailing lists though. Everyone is free to move any issue or patch to Trac of course. It's just pointless and non-trivial work (it all adds up, you see) to put *everything* we deal with in Trac. Cheers, Segher From yinghailu at gmail.com Tue Nov 7 17:43:03 2006 From: yinghailu at gmail.com (yhlu) Date: Tue, 7 Nov 2006 08:43:03 -0800 Subject: [LinuxBIOS] booting XP In-Reply-To: <20061107160527.GA26850@coresystems.de> References: <13426df10611061925v5935b044iad42051d8754fafe@mail.gmail.com> <20061107083320.GA17723@coresystems.de> <1B564613-A6FF-459D-9E3C-E2D161C695B1@kernel.crashing.org> <20061107105807.GA9500@coresystems.de> <13426df10611070642p32936325x23c021e91da743d9@mail.gmail.com> <13426df10611070747r3979399cl89831d65aec33cb4@mail.gmail.com> <20061107154935.GA23151@coresystems.de> <13426df10611070753o61665807x5412b13952acc67b@mail.gmail.com> <20061107160527.GA26850@coresystems.de> Message-ID: <2ea3fae10611070843x66bb6e1eg4f3cf025d1771422@mail.gmail.com> I have one idea about. I assume all new system will be dual way or dual cores. So I let first core run at 16 bit to provide 16 bit interface, and second core runing as 32 bit with Linux kernel as service. YH On 11/7/06, Stefan Reinauer wrote: > * ron minnich [061107 16:53]: > > Challenge to the list: find that port patch Richard mentioned. I have to go to > > a meeting. If someone can find it, I'll check it out and commit it. > > The full source is here (sent around by YhLu) > LinuxBIOSv2/util/ADLO > > Added in r2457 (found using the search engine on qa.linuxbios.org) > > http://snapshots.linuxbios.org/stats/commit-LinuxBIOSv2-2457.log > > -- > 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/ > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios From jrydberg at gnu.org Tue Nov 7 17:47:47 2006 From: jrydberg at gnu.org (Johan Rydberg) Date: Tue, 07 Nov 2006 17:47:47 +0100 Subject: [LinuxBIOS] booting XP References: <13426df10611061925v5935b044iad42051d8754fafe@mail.gmail.com> <20061107083320.GA17723@coresystems.de> <1B564613-A6FF-459D-9E3C-E2D161C695B1@kernel.crashing.org> <20061107105807.GA9500@coresystems.de> <13426df10611070642p32936325x23c021e91da743d9@mail.gmail.com> <13426df10611070747r3979399cl89831d65aec33cb4@mail.gmail.com> <20061107154935.GA23151@coresystems.de> Message-ID: <87mz73mcek.fsf@gnu.org> Stefan Reinauer writes: >> What's the accepted way to bulid 16-bit code nowadays? Still bcc? >> >> as86 loader.s is easy: convert and junk as86. >> >> I assume that vista will boot on legacy pc with 16-bit bios, right? > > and only with that. They refused to put EFI support in there. Funny, but > Microsoft is a little bit on our side ;-) There will be EFI support for 64-bit hostss, IIRC. They just rejected it for 32-bit hosts. ~j -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From svn at openbios.org Tue Nov 7 17:56:57 2006 From: svn at openbios.org (LinuxBIOS) Date: Tue, 07 Nov 2006 16:56:57 -0000 Subject: [LinuxBIOS] #37: Send tracker mails with attachments Message-ID: <060.6366dff97d798e0fba12b679b0559b88@openbios.org> #37: Send tracker mails with attachments ------------------------------+--------------------------------------------- Reporter: stepan | Owner: somebody Type: task | Status: new Priority: critical | Milestone: Component: wiki/website | Version: v2 Keywords: | Due_close: 12/31/2006 Include_gantt: 1 | Dependencies: Due_assign: 11/15/2006 | Patchstatus: there is no patch ------------------------------+--------------------------------------------- The tracker is not sending any attachments (patches etc). This needs to be implemented to make the tracker fully usable via email. -- Ticket URL: LinuxBIOS From svn at openbios.org Tue Nov 7 17:57:31 2006 From: svn at openbios.org (LinuxBIOS) Date: Tue, 07 Nov 2006 16:57:31 -0000 Subject: [LinuxBIOS] #33: Signed-off-by in trac is meaningless In-Reply-To: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> References: <060.ace7b5af00deebf5a2a5fd1c8f7c9775@openbios.org> Message-ID: <069.b6d29a93907fad2d3a34327fcbfcd9b0@openbios.org> #33: Signed-off-by in trac is meaningless ----------------------------------+----------------------------------------- Reporter: segher | Owner: somebody Type: defect | Status: new Priority: critical | Milestone: Component: misc | Version: Resolution: | Keywords: trac Due_close: MM/DD/YYYY | Include_gantt: 1 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: there is no patch | ----------------------------------+----------------------------------------- Changes (by stepan): * patchstatus: => there is no patch * milestone: Resolve license issues => -- Ticket URL: LinuxBIOS From jrydberg at gnu.org Tue Nov 7 18:08:37 2006 From: jrydberg at gnu.org (Johan Rydberg) Date: Tue, 07 Nov 2006 18:08:37 +0100 Subject: [LinuxBIOS] so who can revive adlo References: <13426df10611070736u37b82781w60a0d70a59461025@mail.gmail.com> <4550AA74.5000701@gmail.com> <13426df10611070748n1a9d51d3q70f886d4a525c9f2@mail.gmail.com> <4550ADB5.2060302@gmail.com> Message-ID: <87irhrmbfu.fsf@gnu.org> Richard Smith writes: > http://www.linuxbios.org/pipermail/linuxbios/2006-July/015051.html > >> you just made the case for Trak :-) It's 'Trac' btw. > I don't deny that some sort of patch management is not useful and > necessary even. I just don't like _having_ to do all things Trac as its > not near as easy as mail. It also means you have to be on-line. There is also patchwork [1]. And example of it in action can be seen here [2]. Don't get me wrong, I like Trac. ~j [1] http://ozlabs.org/~jk/projects/patchwork/ [2] http://patchwork.ozlabs.org/bazaar-ng/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From stepan at coresystems.de Tue Nov 7 18:25:52 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 7 Nov 2006 18:25:52 +0100 Subject: [LinuxBIOS] booting XP In-Reply-To: <2ea3fae10611070843x66bb6e1eg4f3cf025d1771422@mail.gmail.com> References: <13426df10611061925v5935b044iad42051d8754fafe@mail.gmail.com> <20061107083320.GA17723@coresystems.de> <1B564613-A6FF-459D-9E3C-E2D161C695B1@kernel.crashing.org> <20061107105807.GA9500@coresystems.de> <13426df10611070642p32936325x23c021e91da743d9@mail.gmail.com> <13426df10611070747r3979399cl89831d65aec33cb4@mail.gmail.com> <20061107154935.GA23151@coresystems.de> <13426df10611070753o61665807x5412b13952acc67b@mail.gmail.com> <20061107160527.GA26850@coresystems.de> <2ea3fae10611070843x66bb6e1eg4f3cf025d1771422@mail.gmail.com> Message-ID: <20061107172552.GA12079@coresystems.de> * yhlu [061107 17:43]: > I have one idea about. > I assume all new system will be dual way or dual cores. > > So I let first core run at 16 bit to provide 16 bit interface, and > second core runing as 32 bit with Linux kernel as service. Asynchronous Multi Processing? :-) -- 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 Nov 7 18:26:53 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 7 Nov 2006 18:26:53 +0100 Subject: [LinuxBIOS] booting XP In-Reply-To: <87mz73mcek.fsf@gnu.org> References: <13426df10611061925v5935b044iad42051d8754fafe@mail.gmail.com> <20061107083320.GA17723@coresystems.de> <1B564613-A6FF-459D-9E3C-E2D161C695B1@kernel.crashing.org> <20061107105807.GA9500@coresystems.de> <13426df10611070642p32936325x23c021e91da743d9@mail.gmail.com> <13426df10611070747r3979399cl89831d65aec33cb4@mail.gmail.com> <20061107154935.GA23151@coresystems.de> <87mz73mcek.fsf@gnu.org> Message-ID: <20061107172653.GB12079@coresystems.de> * Johan Rydberg [061107 17:47]: > > There will be EFI support for 64-bit hostss, IIRC. They just rejected > it for 32-bit hosts. So we can run Windows on 64bit using GNUFI soon? ;-) -- 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 ward at gnu.org Tue Nov 7 18:30:41 2006 From: ward at gnu.org (Ward Vandewege) Date: Tue, 7 Nov 2006 12:30:41 -0500 Subject: [LinuxBIOS] tyan b3992? Message-ID: <20061107173041.GA8019@countzero.vandewege.net> Hi there, We're about to buy another box to replace our venerable shell server (fencepost), thanks to a generous donation. I know there is AMD Socket F support in LinuxBIOS nowadays. We'd like to get a Socket F board because that would give us hardware virtualization. If we get a Tyan B3992-based chassis (e.g. this one http://www.tyan.com/products/html/gt24b3992.html), how hard would it be to get LinuxBIOS working for that board? None of the new Tyan Socket-F boards are currently in the tree; is it realistic that this will happen in the (near) future? I'd be happy to test and shake out bugs to get this board supported, but we'd have to rely on someone else to do the heavy lifting involved in getting the board supported - I just don't know enough (yet?) about this stuff to be able to do it myself. Anyone interested to work on this board? We've also looked at the new MSI board, but can't find any systems that use that yet... Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From yinghai.lu at amd.com Tue Nov 7 18:37:07 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 7 Nov 2006 09:37:07 -0800 Subject: [LinuxBIOS] booting XP Message-ID: <5986589C150B2F49A46483AC44C7BCA49071A9@ssvlexmb2.amd.com> What is GNUFI? YH -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Stefan Reinauer Sent: Tuesday, November 07, 2006 9:27 AM To: Johan Rydberg Cc: linuxbios at openbios.org Subject: Re: [LinuxBIOS] booting XP * Johan Rydberg [061107 17:47]: > > There will be EFI support for 64-bit hostss, IIRC. They just rejected > it for 32-bit hosts. So we can run Windows on 64bit using GNUFI soon? ;-) -- 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/ -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios From yinghai.lu at amd.com Tue Nov 7 18:40:55 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 7 Nov 2006 09:40:55 -0800 Subject: [LinuxBIOS] tyan b3992? Message-ID: <5986589C150B2F49A46483AC44C7BCA49071AA@ssvlexmb2.amd.com> You can start from MSI 9182?. Same CPU, chipset, superio. So only need to adjust some entries in mptable.c YH From rminnich at gmail.com Tue Nov 7 18:55:03 2006 From: rminnich at gmail.com (ron minnich) Date: Tue, 7 Nov 2006 10:55:03 -0700 Subject: [LinuxBIOS] 440bx stuff In-Reply-To: <4550B041.70403@gmail.com> References: <20061107094333.62602.qmail@web30708.mail.mud.yahoo.com> <20061107110404.GC12958@coresystems.de> <4550B041.70403@gmail.com> Message-ID: <13426df10611070955m421e399bj4e0b703681aa8b10@mail.gmail.com> btw, the digitallogic/smartcore-p3 in v1 is a 440-bx based board. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Tue Nov 7 18:52:32 2006 From: rminnich at gmail.com (ron minnich) Date: Tue, 7 Nov 2006 10:52:32 -0700 Subject: [LinuxBIOS] so who can revive adlo In-Reply-To: <4550ADB5.2060302@gmail.com> References: <13426df10611070736u37b82781w60a0d70a59461025@mail.gmail.com> <4550AA74.5000701@gmail.com> <13426df10611070748n1a9d51d3q70f886d4a525c9f2@mail.gmail.com> <4550ADB5.2060302@gmail.com> Message-ID: <13426df10611070952g79f45fcap8da78608dc5357f3@mail.gmail.com> so, is the LinuxBIOSv2 tree version of adlo the latest and greatest, no patches needed to get it into the state that people are using it in? I'm just trying to get a baseline. thanks ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinghai.lu at amd.com Tue Nov 7 19:05:51 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 7 Nov 2006 10:05:51 -0800 Subject: [LinuxBIOS] so who can revive adlo Message-ID: <5986589C150B2F49A46483AC44C7BCA49071AC@ssvlexmb2.amd.com> I tried with Serengeti_cheetah, it said unknown HDD. Same ADLO can work with qemu, and xen ( as virtual FW). YH ________________________________ From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of ron minnich Sent: Tuesday, November 07, 2006 9:53 AM To: Richard Smith Cc: LinuxBIOS Subject: Re: [LinuxBIOS] so who can revive adlo so, is the LinuxBIOSv2 tree version of adlo the latest and greatest, no patches needed to get it into the state that people are using it in? I'm just trying to get a baseline. thanks ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From ward at gnu.org Tue Nov 7 19:08:55 2006 From: ward at gnu.org (Ward Vandewege) Date: Tue, 7 Nov 2006 13:08:55 -0500 Subject: [LinuxBIOS] tyan b3992? In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49071AA@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49071AA@ssvlexmb2.amd.com> Message-ID: <20061107180855.GA8332@countzero.vandewege.net> On Tue, Nov 07, 2006 at 09:40:55AM -0800, Lu, Yinghai wrote: > You can start from MSI 9182?. > > Same CPU, chipset, superio. So only need to adjust some entries in > mptable.c We don't have the board yet; if we do get that machine, would you be willing to help me to get it going? We'll order today if so :) Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From yinghai.lu at amd.com Tue Nov 7 19:13:16 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 7 Nov 2006 10:13:16 -0800 Subject: [LinuxBIOS] tyan b3992? Message-ID: <5986589C150B2F49A46483AC44C7BCA49071AD@ssvlexmb2.amd.com> OK. -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Ward Vandewege Sent: Tuesday, November 07, 2006 10:09 AM To: linuxbios at linuxbios.org Subject: Re: [LinuxBIOS] tyan b3992? On Tue, Nov 07, 2006 at 09:40:55AM -0800, Lu, Yinghai wrote: > You can start from MSI 9182?. > > Same CPU, chipset, superio. So only need to adjust some entries in > mptable.c We don't have the board yet; if we do get that machine, would you be willing to help me to get it going? We'll order today if so :) Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios From rminnich at gmail.com Tue Nov 7 19:17:43 2006 From: rminnich at gmail.com (ron minnich) Date: Tue, 7 Nov 2006 11:17:43 -0700 Subject: [LinuxBIOS] so who can revive adlo In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49071AC@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49071AC@ssvlexmb2.amd.com> Message-ID: <13426df10611071017s4d6cacd3r9a3c7e52535afd90@mail.gmail.com> On 11/7/06, Lu, Yinghai wrote: > > I tried with Serengeti_cheetah, it said unknown HDD. > > > > Same ADLO can work with qemu, and xen ( as virtual FW). > > > > YH > ok, so adlo in the tree, with the right tools (as86, bcc) works on qemu. Tha'ts all I need to know. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From acassis at gmail.com Tue Nov 7 19:31:59 2006 From: acassis at gmail.com (Alan Carvalho de Assis) Date: Tue, 7 Nov 2006 18:31:59 +0000 Subject: [LinuxBIOS] booting XP In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49071A9@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49071A9@ssvlexmb2.amd.com> Message-ID: <37367b3a0611071031m6cbdb524kd202312966d5cd77@mail.gmail.com> Hi Lu, On 11/7/06, Lu, Yinghai wrote: > What is GNUFI? > "GNUFI is an open source EFI implementation" > YH > Alan From svn at openbios.org Tue Nov 7 19:43:18 2006 From: svn at openbios.org (LinuxBIOS) Date: Tue, 07 Nov 2006 18:43:18 -0000 Subject: [LinuxBIOS] #36: Make the mailing list archive searchable In-Reply-To: <060.310e1ce9ac350c87801b63e0c3140a12@openbios.org> References: <060.310e1ce9ac350c87801b63e0c3140a12@openbios.org> Message-ID: <069.7d7471b0e79d824f7c84a68e540b04de@openbios.org> #36: Make the mailing list archive searchable ----------------------------------+----------------------------------------- Reporter: rsmith | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: documentation | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: there is no patch | ----------------------------------+----------------------------------------- Comment (by rsmith): Replying to [comment:1 uwe]: > You can use Google. Example: > http://www.google.com/search?hl=en&lr=&as_qdr=all&q=440bx+site%3Ahttp%3A%2F%2Fwww.linuxbios.org%2F&btnG=Search > That's allmost useable.. Can you flip the date order so that most recient come first? -- Ticket URL: LinuxBIOS From stepan at coresystems.de Tue Nov 7 19:46:18 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 7 Nov 2006 19:46:18 +0100 Subject: [LinuxBIOS] so who can revive adlo In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49071AC@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49071AC@ssvlexmb2.amd.com> Message-ID: <20061107184618.GA28744@coresystems.de> * Lu, Yinghai [061107 19:05]: > I tried with Serengeti_cheetah, it said unknown HDD. it found the HDD, but could not identify it? SATA? IDE? > Same ADLO can work with qemu, and xen ( as virtual FW). 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 Tue Nov 7 19:49:28 2006 From: svn at openbios.org (LinuxBIOS) Date: Tue, 07 Nov 2006 18:49:28 -0000 Subject: [LinuxBIOS] #36: Make the mailing list archive searchable In-Reply-To: <060.310e1ce9ac350c87801b63e0c3140a12@openbios.org> References: <060.310e1ce9ac350c87801b63e0c3140a12@openbios.org> Message-ID: <069.3082da6a88077f14f480c9ce599198b1@openbios.org> #36: Make the mailing list archive searchable ----------------------------------+----------------------------------------- Reporter: rsmith | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: documentation | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: there is no patch | ----------------------------------+----------------------------------------- Comment (by stepan): Is someone can offer a good way to put a search engine on top of Mailman without a lot of fiddling, I'll give it a try. I wonder why there is no standard option to do that. Actually I was hoping for the next major Mailman release which was supposed to be released these weeks -- Ticket URL: LinuxBIOS From yinghai.lu at amd.com Tue Nov 7 19:47:18 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 7 Nov 2006 10:47:18 -0800 Subject: [LinuxBIOS] so who can revive adlo Message-ID: <5986589C150B2F49A46483AC44C7BCA49071AE@ssvlexmb2.amd.com> IDE... I have tried IDE for ancient to modern... YH -----Original Message----- From: Stefan Reinauer [mailto:stepan at coresystems.de] Sent: Tuesday, November 07, 2006 10:46 AM To: Lu, Yinghai Cc: LinuxBIOS Subject: Re: [LinuxBIOS] so who can revive adlo * Lu, Yinghai [061107 19:05]: > I tried with Serengeti_cheetah, it said unknown HDD. it found the HDD, but could not identify it? SATA? IDE? > Same ADLO can work with qemu, and xen ( as virtual FW). Stefan -- coresystems GmbH * Brahmsstr. 16 * D-79104 Freiburg i. Br. Tel.: +49 761 7668825 * Fax: +49 761 7664613 Email: info at coresystems.de * http://www.coresystems.de/ From smithbone at gmail.com Tue Nov 7 20:40:10 2006 From: smithbone at gmail.com (Richard Smith) Date: Tue, 07 Nov 2006 13:40:10 -0600 Subject: [LinuxBIOS] booting XP In-Reply-To: <2ea3fae10611070843x66bb6e1eg4f3cf025d1771422@mail.gmail.com> References: <13426df10611061925v5935b044iad42051d8754fafe@mail.gmail.com> <20061107083320.GA17723@coresystems.de> <1B564613-A6FF-459D-9E3C-E2D161C695B1@kernel.crashing.org> <20061107105807.GA9500@coresystems.de> <13426df10611070642p32936325x23c021e91da743d9@mail.gmail.com> <13426df10611070747r3979399cl89831d65aec33cb4@mail.gmail.com> <20061107154935.GA23151@coresystems.de> <13426df10611070753o61665807x5412b13952acc67b@mail.gmail.com> <20061107160527.GA26850@coresystems.de> <2ea3fae10611070843x66bb6e1eg4f3cf025d1771422@mail.gmail.com> Message-ID: <4550E11A.8020402@gmail.com> Here's a novel idea: How about we ask the original author Adam Sulmicki what he thinks needs to be done to boot XP? I believe he still reads the list but I've cc'ed him just in case. -- Richard A. Smith From jrydberg at gnu.org Tue Nov 7 21:04:07 2006 From: jrydberg at gnu.org (Johan Rydberg) Date: Tue, 07 Nov 2006 21:04:07 +0100 Subject: [LinuxBIOS] booting XP In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49071A9@ssvlexmb2.amd.com> (Yinghai Lu's message of "Tue, 7 Nov 2006 09:37:07 -0800") References: <5986589C150B2F49A46483AC44C7BCA49071A9@ssvlexmb2.amd.com> Message-ID: <87ejsfm3bc.fsf@gnu.org> "Lu, Yinghai" writes: > What is GNUFI? GNUFI is my implementation of the UEFI specification. It is hopefully "soon to be released". As a short status report; it can load GRUB2 with bulk EFI-support and GRUB2 can in turn load and boot GNU/Linux. When I get the time I'll try other free EFI loaders (elilo, refi, ...). While googleing the other day I found OSXP, which seems to be a XP loader which runs on EFI: http://daemons.net/~clay/OSXP/ . I have yet to look closer at it. ~j -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From a1426z at gawab.com Tue Nov 7 21:05:18 2006 From: a1426z at gawab.com (Al Boldi) Date: Tue, 7 Nov 2006 23:05:18 +0300 Subject: [LinuxBIOS] 440bx stuff In-Reply-To: <13426df10611070955m421e399bj4e0b703681aa8b10@mail.gmail.com> References: <20061107094333.62602.qmail@web30708.mail.mud.yahoo.com> <4550B041.70403@gmail.com> <13426df10611070955m421e399bj4e0b703681aa8b10@mail.gmail.com> Message-ID: <200611072305.18143.a1426z@gawab.com> ron minnich wrote: > btw, the digitallogic/smartcore-p3 in v1 is a 440-bx based board. If it is of any help, I could try this on my i440bx board. Just point me to the tar-ball. Thanks! -- Al From svn at openbios.org Tue Nov 7 21:16:29 2006 From: svn at openbios.org (LinuxBIOS) Date: Tue, 07 Nov 2006 20:16:29 -0000 Subject: [LinuxBIOS] #38: Improved spd.h Message-ID: <060.d65e12e7bbf3fa2c00ba97d4a94d5a7e@openbios.org> #38: Improved spd.h -----------------------------+---------------------------------------------- Reporter: uwe | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Cosmetic fixes Component: code | Version: v2 Keywords: | Due_close: MM/DD/YYYY Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Patchstatus: patch needs review -----------------------------+---------------------------------------------- Update of the src/include/spd.h file with the following improvements: * Added information on the relevant datasheet(s) and where to get them. * Added missing #defines for some other config bytes. * Documented all config bytes a bit better. * Renamed some #defines to hopefully make their names clearer. Signed-off-by: Uwe Hermann --- I've been reading stuff about SPD and RAM init in order to get the 440BX going soon. Please check the names of the #defines, some might not have a very good name; suggestions for improvements welcome. -- Ticket URL: LinuxBIOS From bario2004 at yahoo.com Tue Nov 7 21:25:32 2006 From: bario2004 at yahoo.com (Corey) Date: Tue, 7 Nov 2006 12:25:32 -0800 (PST) Subject: [LinuxBIOS] 440bx stuff Message-ID: <20061107202533.96463.qmail@web30715.mail.mud.yahoo.com> If I understand the layout of the repository correctly, this should work -> http://www.openbios.org/viewvc/trunk/LinuxBIOSv1/src/mainboard/digitallogic/smartcore-p3.tar.gz?view=tar . I will have a 440bx-baseed board of my own, some generic gateway model, in a few hours, but it has a sodiered-on pll, anyone know where I can get a socket for this cheap? I'm in Bangor, Maine, if anyone lives around here and knows. Also, thanks for all the info, and I already have a null serial modem cable. Corey Osgood ----- Original Message ---- From: Al Boldi To: linuxbios at linuxbios.org Sent: Tuesday, November 7, 2006 3:05:18 PM Subject: Re: [LinuxBIOS] 440bx stuff ron minnich wrote: > btw, the digitallogic/smartcore-p3 in v1 is a 440-bx based board. If it is of any help, I could try this on my i440bx board. Just point me to the tar-ball. Thanks! -- Al -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios From smithbone at gmail.com Tue Nov 7 21:34:49 2006 From: smithbone at gmail.com (Richard Smith) Date: Tue, 07 Nov 2006 14:34:49 -0600 Subject: [LinuxBIOS] 440bx stuff In-Reply-To: <20061107202533.96463.qmail@web30715.mail.mud.yahoo.com> References: <20061107202533.96463.qmail@web30715.mail.mud.yahoo.com> Message-ID: <4550EDE9.4000302@gmail.com> Corey wrote: > If I understand the layout of the repository correctly, this should > work -> > http://www.openbios.org/viewvc/trunk/LinuxBIOSv1/src/mainboard/digitallogic/smartcore-p3.tar.gz?view=tar > . I will have a 440bx-baseed board of my own, some generic gateway model, in a few hours, but it has a sodiered-on pll, anyone know where I can get a socket for this cheap? I'm in Bangor, Maine, if anyone lives around here and knows. Also, thanks for all the info, and I already have a null serial modem cable. There is not much point in messing with V1, unless you just want to see it boot. It works fine in V1. The issue is V2. The V1 stuff is just for reference on porting to V2. -- Richard A. Smith From svn at openbios.org Tue Nov 7 21:45:48 2006 From: svn at openbios.org (LinuxBIOS) Date: Tue, 07 Nov 2006 20:45:48 -0000 Subject: [LinuxBIOS] #38: Improved spd.h In-Reply-To: <060.d65e12e7bbf3fa2c00ba97d4a94d5a7e@openbios.org> References: <060.d65e12e7bbf3fa2c00ba97d4a94d5a7e@openbios.org> Message-ID: <069.8b46a24243a1f54dd3215304863b56f2@openbios.org> #38: Improved spd.h -----------------------------------------------+---------------------------- Reporter: uwe | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: patch is ready to be committed | -----------------------------------------------+---------------------------- Changes (by rsmith): * patchstatus: patch needs review => patch is ready to be committed Comment: Replying to [ticket:38 uwe]: > Update of the src/include/spd.h file with the following improvements: > > * Added information on the relevant datasheet(s) and where to get them. > * Added missing #defines for some other config bytes. > * Documented all config bytes a bit better. > * Renamed some #defines to hopefully make their names clearer. > > Signed-off-by: Uwe Hermann > > --- > > I've been reading stuff about SPD and RAM init in order to get the 440BX going soon. > > Please check the names of the #defines, some might not have a very good name; suggestions for improvements welcome. Excellent.. Go man Go!. Acked-by: Richard A. Smith Oh and btw. Until we fix the Trac to send the patches to the mailing list can you cc: the mailing list? -- Ticket URL: LinuxBIOS From a1426z at gawab.com Tue Nov 7 21:52:34 2006 From: a1426z at gawab.com (Al Boldi) Date: Tue, 7 Nov 2006 23:52:34 +0300 Subject: [LinuxBIOS] 440bx stuff In-Reply-To: <4550EDE9.4000302@gmail.com> References: <20061107202533.96463.qmail@web30715.mail.mud.yahoo.com> <4550EDE9.4000302@gmail.com> Message-ID: <200611072352.34721.a1426z@gawab.com> Richard Smith wrote: > Corey wrote: > > If I understand the layout of the repository correctly, this should > > work -> > > http://www.openbios.org/viewvc/trunk/LinuxBIOSv1/src/mainboard/digitallo > >gic/smartcore-p3.tar.gz?view=tar . I will have a 440bx-baseed board of my > > own, some generic gateway model, in a few hours, but it has a > > sodiered-on pll, anyone know where I can get a socket for this cheap? > > I'm in Bangor, Maine, if anyone lives around here and knows. Also, > > thanks for all the info, and I already have a null serial modem cable. > > There is not much point in messing with V1, unless you just want to see > it boot. It works fine in V1. > > The issue is V2. The V1 stuff is just for reference on porting to V2. So what's V1 missing that only V2 has? Thanks! -- Al From smithbone at gmail.com Tue Nov 7 21:56:12 2006 From: smithbone at gmail.com (Richard Smith) Date: Tue, 07 Nov 2006 14:56:12 -0600 Subject: [LinuxBIOS] 440bx stuff In-Reply-To: <200611072352.34721.a1426z@gawab.com> References: <20061107202533.96463.qmail@web30715.mail.mud.yahoo.com> <4550EDE9.4000302@gmail.com> <200611072352.34721.a1426z@gawab.com> Message-ID: <4550F2EC.20508@gmail.com> Al Boldi wrote: >> The issue is V2. The V1 stuff is just for reference on porting to V2. > > So what's V1 missing that only V2 has? Our help. V1 is dead and unsupported. -- Richard A. Smith From rminnich at gmail.com Tue Nov 7 22:16:45 2006 From: rminnich at gmail.com (ron minnich) Date: Tue, 7 Nov 2006 14:16:45 -0700 Subject: [LinuxBIOS] 440bx stuff In-Reply-To: <4550F2EC.20508@gmail.com> References: <20061107202533.96463.qmail@web30715.mail.mud.yahoo.com> <4550EDE9.4000302@gmail.com> <200611072352.34721.a1426z@gawab.com> <4550F2EC.20508@gmail.com> Message-ID: <13426df10611071316p26af056kd4a68c76f43f6f74@mail.gmail.com> I was only mentioning this board as a reference source. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From smithbone at gmail.com Tue Nov 7 22:31:13 2006 From: smithbone at gmail.com (Richard Smith) Date: Tue, 07 Nov 2006 15:31:13 -0600 Subject: [LinuxBIOS] 440bx stuff In-Reply-To: <13426df10611071316p26af056kd4a68c76f43f6f74@mail.gmail.com> References: <20061107202533.96463.qmail@web30715.mail.mud.yahoo.com> <4550EDE9.4000302@gmail.com> <200611072352.34721.a1426z@gawab.com> <4550F2EC.20508@gmail.com> <13426df10611071316p26af056kd4a68c76f43f6f74@mail.gmail.com> Message-ID: <4550FB21.2060507@gmail.com> ron minnich wrote: > I was only mentioning this board as a reference source. For reference I think the bitworks/ims is probably better. Fundamentally they are the same but I remember doing a lot of tweaking. Been a while though so its hazy.. -- Richard A. Smith From stepan at coresystems.de Tue Nov 7 22:34:18 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 7 Nov 2006 22:34:18 +0100 Subject: [LinuxBIOS] booting XP In-Reply-To: <87ejsfm3bc.fsf@gnu.org> References: <5986589C150B2F49A46483AC44C7BCA49071A9@ssvlexmb2.amd.com> <87ejsfm3bc.fsf@gnu.org> Message-ID: <20061107213418.GA25497@coresystems.de> * Johan Rydberg [061107 21:04]: > While googleing the other day I found OSXP, which seems to be a XP > loader which runs on EFI: http://daemons.net/~clay/OSXP/ . I have yet > to look closer at it. with some explanation: http://daemons.net/~clay/index.php/2006/03/15/dual-booting-windows-xp-and-mac-os-x-on-intel-macs/ -- 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 bario2004 at yahoo.com Tue Nov 7 22:42:33 2006 From: bario2004 at yahoo.com (Corey) Date: Tue, 7 Nov 2006 13:42:33 -0800 (PST) Subject: [LinuxBIOS] 440bx stuff In-Reply-To: <13426df10611071316p26af056kd4a68c76f43f6f74@mail.gmail.com> Message-ID: <20061107214233.84997.qmail@web30707.mail.mud.yahoo.com> Right, but I figured it might help to know if it worked completely. I meant to mention that it was V1 tho, just forgot. Just got the gateway motherboard, and it's not a plcc, it's another tsop that was hiding behind the video card...i suspected this at first, because afaik, intel makes gateways goods, but I just couldn't find it, so I assumed it was the plcc. I'm currently looking right now at a few different boards on ebay, mainly an ASUS P3B for dirt cheap (~$6 shipped). This really makes me wish I hadn't trashed my old abit bh-6...I'll look at the code more later (I'm still working out how exactly it works, I've never done anything like this before), for now, I'm off to vote and then work. Corey Osgood --- ron minnich wrote: > I was only mentioning this board as a reference source. > > ron > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios ____________________________________________________________________________________ Sponsored Link Mortgage rates near historic lows: $150,000 loan as low as $579/mo. Intro-*Terms https://www2.nextag.com/ From svn at openbios.org Wed Nov 8 01:14:06 2006 From: svn at openbios.org (LinuxBIOS) Date: Wed, 08 Nov 2006 00:14:06 -0000 Subject: [LinuxBIOS] #36: Make the mailing list archive searchable In-Reply-To: <060.310e1ce9ac350c87801b63e0c3140a12@openbios.org> References: <060.310e1ce9ac350c87801b63e0c3140a12@openbios.org> Message-ID: <069.96e10237b0cc27ca72aaa895b911686c@openbios.org> #36: Make the mailing list archive searchable ----------------------------------+----------------------------------------- Reporter: rsmith | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: documentation | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: there is no patch | ----------------------------------+----------------------------------------- Comment (by bxshi ): I don't know why and how all our mail sent to the list can be found here http://blog.gmane.org/gmane.linux.bios and there is a search engine, and I always search here . bxshi -- Ticket URL: LinuxBIOS From yinghai.lu at amd.com Wed Nov 8 03:01:37 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 7 Nov 2006 18:01:37 -0800 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage Message-ID: <5986589C150B2F49A46483AC44C7BCA49071B2@ssvlexmb2.amd.com> Please check the updated patch. It will check e_entry and p_paddr to decide if need to switch 64 bit in convert. Current status: I have forced it switch to 64 bit and use startup_64 in kernel directly, it will restart instead of boot the kernel. YH -------------- next part -------------- A non-text attachment was scrubbed... Name: mkelfImage_2.7_amd64.patch Type: application/octet-stream Size: 16204 bytes Desc: mkelfImage_2.7_amd64.patch URL: From svn at openbios.org Wed Nov 8 13:17:09 2006 From: svn at openbios.org (LinuxBIOS) Date: Wed, 08 Nov 2006 12:17:09 -0000 Subject: [LinuxBIOS] #38: Improved spd.h In-Reply-To: <060.d65e12e7bbf3fa2c00ba97d4a94d5a7e@openbios.org> References: <060.d65e12e7bbf3fa2c00ba97d4a94d5a7e@openbios.org> Message-ID: <069.a4f837200abdedb6e7736ec99d0a03b8@openbios.org> #38: Improved spd.h -----------------------------------+---------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: assigned Priority: major | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: patch needs review | -----------------------------------+---------------------------------------- Changes (by uwe): * owner: somebody => uwe * status: new => assigned * patchstatus: patch is ready to be committed => patch needs review Comment: Update of the src/include/spd.h file with the following improvements: * Added information on the relevant datasheet(s) and where to get them. * Added missing #defines for some other config bytes. * Documented all config bytes a bit better. * Renamed some #defines to hopefully make their names clearer. Signed-off-by: Uwe Hermann --- Lets test whether we can just inline patches into Trac comments... Here's an updated patch which removes most TODO items, and adds all other missing bytes I know of. I guess all formatting and/or TABs etc. will break, but it's worth a try... {{{ Index: src/include/spd.h =================================================================== --- src/include/spd.h (Revision 2494) +++ src/include/spd.h (Arbeitskopie) @@ -1,8 +1,8 @@ /* - * spd.h: Definitions for Serial Presence Detect (SPD) data - * stored on SDRAM modules + * This file is part of the LinuxBIOS project. * * Copyright (C) 2005 Digital Design Corporation + * Copyright (C) 2006 Uwe Hermann * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -16,66 +16,117 @@ * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ -#ifndef __SPD_H_DEFINED -#define __SPD_H_DEFINED +/* + * Serial Presence Detect (SPD) data stored on SDRAM modules. + * + * Datasheet: + * - Name: PC SDRAM Serial Presence Detect (SPD) Specification + * Revision 1.2A, December, 1997 + * - PDF: http://www.intel.com/design/chipsets/memory/spdsd12a.pdf + * + * Datasheet (alternative): + * - Name: SERIAL PRESENCE DETECT STANDARD, General Standard + * JEDEC Standard No. 21??C + * - PDF: http://www.jedec.org/download/search/4_01_02_00R9.PDF + */ -// Byte numbers -#define SPD_MEMORY_TYPE 2 -#define SPD_NUM_ROWS 3 -#define SPD_NUM_COLUMNS 4 -#define SPD_NUM_DIMM_BANKS 5 -#define SPD_MODULE_DATA_WIDTH_LSB 6 -#define SPD_MODULE_DATA_WIDTH_MSB 7 -#define SPD_MODULE_VOLTAGE 8 -#define SPD_MIN_CYCLE_TIME_AT_CAS_MAX 9 -#define SPD_DIMM_CONFIG_TYPE 11 -#define SPD_REFRESH 12 -#define SPD_PRIMARY_DRAM_WIDTH 13 -#define SPD_SUPPORTED_BURST_LENGTHS 16 -#define SPD_NUM_BANKS_PER_DRAM 17 -#define SPD_ACCEPTABLE_CAS_LATENCIES 18 -#define SPD_MODULE_ATTRIBUTES 21 -#define SPD_MIN_CYCLE_TIME_AT_CAS_REDUCED_05 23 -#define SPD_MIN_CYCLE_TIME_AT_CAS_REDUCED_10 25 -#define SPD_MIN_ROW_PRECHARGE_TIME 27 -#define SPD_MIN_RAS_TO_CAS_DELAY 29 -#define SPD_MIN_ACTIVE_TO_PRECHARGE_DELAY 30 -#define SPD_ADDRESS_CMD_HOLD 33 +#ifndef _SPD_H_ +#define _SPD_H_ +/* Byte numbers. */ +#define SPD_NUM_MANUFACTURER_BYTES 0 /* Number of bytes used by module manufacturer */ +#define SPD_TOTAL_SPD_MEMORY_SIZE 1 /* Total SPD memory size */ +#define SPD_MEMORY_TYPE 2 /* (Fundamental) memory type */ +#define SPD_NUM_ROWS 3 /* Number of row address bits */ +#define SPD_NUM_COLUMNS 4 /* Number of column address bits */ +#define SPD_NUM_DIMM_BANKS 5 /* Number of module rows (banks) */ +#define SPD_MODULE_DATA_WIDTH_LSB 6 /* Module data width (LSB) */ +#define SPD_MODULE_DATA_WIDTH_MSB 7 /* Module data width (MSB) */ +#define SPD_MODULE_VOLTAGE 8 /* Module interface signal levels */ +#define SPD_MIN_CYCLE_TIME_AT_CAS_MAX 9 /* SDRAM cycle time (highest CAS latency), RAS access time (tRAC) */ +#define SPD_ACCESS_TIME_FROM_CLOCK 10 /* SDRAM access time from clock (highest CAS latency), CAS access time (Tac, tCAC) */ +#define SPD_DIMM_CONFIG_TYPE 11 /* Module configuration type */ +#define SPD_REFRESH 12 /* Refresh rate/type */ +#define SPD_PRIMARY_SDRAM_WIDTH 13 /* SDRAM width (primary SDRAM) */ +#define SPD_ERROR_CHECKING_SDRAM_WIDTH 14 /* Error checking SDRAM (data) width */ +#define SPD_MIN_CLOCK_DELAY_B2B_RAND_COLUMN 15 /* SDRAM device attributes, minimum clock delay for back to back random column */ +#define SPD_SUPPORTED_BURST_LENGTHS 16 /* SDRAM device attributes, burst lengths supported */ +#define SPD_NUM_BANKS_PER_SDRAM 17 /* SDRAM device attributes, number of banks on SDRAM device */ +#define SPD_ACCEPTABLE_CAS_LATENCIES 18 /* SDRAM device attributes, CAS latency */ +#define SPD_CS_LATENCY 19 /* SDRAM device attributes, CS latency */ +#define SPD_WE_LATENCY 20 /* SDRAM device attributes, WE latency */ +#define SPD_MODULE_ATTRIBUTES 21 /* SDRAM module attributes */ +#define SPD_DEVICE_ATTRIBUTES_GENERAL 22 /* SDRAM device attributes, general */ +#define SPD_SDRAM_CYCLE_TIME_2ND 23 /* SDRAM cycle time (2nd highest CAS latency) */ +#define SPD_ACCESS_TIME_FROM_CLOCK_2ND 24 /* SDRAM access from clock (2nd highest CAS latency) */ +#define SPD_SDRAM_CYCLE_TIME_3RD 25 /* SDRAM cycle time (3rd highest CAS latency) */ +#define SPD_ACCESS_TIME_FROM_CLOCK_3RD 26 /* SDRAM access from clock (3rd highest CAS latency) */ +#define SPD_MIN_ROW_PRECHARGE_TIME 27 /* Minimum row precharge time (Trp) */ +#define SPD_MIN_ROWACTIVE_TO_ROWACTIVE 28 /* Minimum row active to row active (Trrd) */ +#define SPD_MIN_RAS_TO_CAS_DELAY 29 /* Minimum RAS to CAS delay (Trcd) */ +#define SPD_MIN_ACTIVE_TO_PRECHARGE_DELAY 30 /* Minimum RAS pulse width (Tras) */ +#define SPD_DENSITY_OF_EACH_ROW_ON_MODULE 31 /* Density of each row on module */ +#define SPD_CMD_SIGNAL_INPUT_SETUP_TIME 32 /* Command and address signal input setup time */ +#define SPD_CMD_SIGNAL_INPUT_HOLD_TIME 33 /* Command and address signal input hold time */ +#define SPD_DATA_SIGNAL_INPUT_SETUP_TIME 34 /* Data signal input setup time */ +#define SPD_DATA_SIGNAL_INPUT_HOLD_TIME 35 /* Data signal input hold time */ +#define SPD_SPD_DATA_REVISION_CODE 62 /* SPD data revision code */ +#define SPD_CHECKSUM_FOR_BYTES_0_TO_62 63 /* Checksum for bytes 0-62 */ +#define SPD_MANUFACTURER_JEDEC_ID_CODE 64 /* Manufacturer's JEDEC ID code, per EIA/JEP106 (bytes 64-71) */ +#define SPD_MANUFACTURING_LOCATION 72 /* Manufacturing location */ +#define SPD_MANUFACTURER_PART_NUMBER 73 /* Manufacturer's part number, in 6??bit ASCII (bytes 73-90) */ +#define SPD_REVISION_CODE 91 /* Revision code (bytes 91-92) */ +#define SPD_MANUFACTURING_DATE 93 /* Manufacturing date (byte 93: year, byte 94: week) */ +#define SPD_ASSEMBLY_SERIAL_NUMBER 95 /* Assembly serial number (bytes 95-98) */ +#define SPD_MANUFACTURER_SPECIFIC_DATA 99 /* Manufacturer specific data (bytes 99-125) */ +#define SPD_INTEL_SPEC_FOR_FREQUENCY 126 /* Intel specification for frequency */ +#define SPD_INTEL_SPEC_100_MHZ 127 /* Intel specification details for 100MHz support */ -// SPD_MEMORY_TYPE values -#define MEMORY_TYPE_SDRAM_DDR 7 +/* SPD_MEMORY_TYPE values. */ +#define SPD_MEMORY_TYPE_FPM_DRAM 1 +#define SPD_MEMORY_TYPE_EDO 2 +#define SPD_MEMORY_TYPE_PIPELINED_NIBBLE 3 +#define SPD_MEMORY_TYPE_SDRAM 4 +#define SPD_MEMORY_TYPE_MULTIPLEXED_ROM 5 +#define SPD_MEMORY_TYPE_SGRAM_DDR 6 +#define SPD_MEMORY_TYPE_SDRAM_DDR 7 +#define SPD_MEMORY_TYPE_SDRAM_DDR2 8 -// SPD_MODULE_VOLTAGE values -#define SPD_VOLTAGE_SSTL2 4 +/* SPD_MODULE_VOLTAGE values. */ +#define SPD_VOLTAGE_TTL 0 /* 5.0 Volt/TTL */ +#define SPD_VOLTAGE_LVTTL 1 /* LVTTL */ +#define SPD_VOLTAGE_HSTL 2 /* HSTL 1.5 */ +#define SPD_VOLTAGE_SSTL3 3 /* SSTL 3.3 */ +#define SPD_VOLTAGE_SSTL2 4 /* SSTL 2.5 */ -// SPD_DIMM_CONFIG_TYPE values -#define ERROR_SCHEME_NONE 0 -#define ERROR_SCHEME_PARITY 1 -#define ERROR_SCHEME_ECC 2 +/* SPD_DIMM_CONFIG_TYPE values. */ +#define ERROR_SCHEME_NONE 0 +#define ERROR_SCHEME_PARITY 1 +#define ERROR_SCHEME_ECC 2 -// SPD_ACCEPTABLE_CAS_LATENCIES values -#define SPD_CAS_LATENCY_1_0 0x01 -#define SPD_CAS_LATENCY_1_5 0x02 -#define SPD_CAS_LATENCY_2_0 0x04 -#define SPD_CAS_LATENCY_2_5 0x08 -#define SPD_CAS_LATENCY_3_0 0x10 -#define SPD_CAS_LATENCY_3_5 0x20 -#define SPD_CAS_LATENCY_4_0 0x40 +/* SPD_ACCEPTABLE_CAS_LATENCIES values. */ +// TODO: Check values. +#define SPD_CAS_LATENCY_1_0 0x01 +#define SPD_CAS_LATENCY_1_5 0x02 +#define SPD_CAS_LATENCY_2_0 0x04 +#define SPD_CAS_LATENCY_2_5 0x08 +#define SPD_CAS_LATENCY_3_0 0x10 +#define SPD_CAS_LATENCY_3_5 0x20 +#define SPD_CAS_LATENCY_4_0 0x40 -// SPD_SUPPORTED_BURST_LENGTHS values -#define SPD_BURST_LENGTH_1 1 -#define SPD_BURST_LENGTH_2 2 -#define SPD_BURST_LENGTH_4 4 -#define SPD_BURST_LENGTH_8 8 -#define SPD_BURST_LENGTH_PAGE (1<<7) +/* SPD_SUPPORTED_BURST_LENGTHS values. */ +#define SPD_BURST_LENGTH_1 1 +#define SPD_BURST_LENGTH_2 2 +#define SPD_BURST_LENGTH_4 4 +#define SPD_BURST_LENGTH_8 8 +#define SPD_BURST_LENGTH_PAGE (1 << 7) +/* SPD_MODULE_ATTRIBUTES values. */ +#define MODULE_BUFFERED 1 +#define MODULE_REGISTERED 2 -// SPD_MODULE_ATTRIBUTES values -#define MODULE_BUFFERED 1 -#define MODULE_REGISTERED 2 +#endif /* _SPD_H_ */ -#endif // __SPD_H_DEFINED Index: src/northbridge/intel/e7501/raminit.c =================================================================== --- src/northbridge/intel/e7501/raminit.c (Revision 2494) +++ src/northbridge/intel/e7501/raminit.c (Arbeitskopie) @@ -94,7 +94,7 @@ SPD_NUM_ROWS, SPD_NUM_DIMM_BANKS, SPD_PRIMARY_DRAM_WIDTH, - SPD_NUM_BANKS_PER_DRAM + SPD_NUM_BANKS_PER_SDRAM }; /* @@ -625,7 +625,7 @@ sz.side2 += value; // Symmetric } - value = spd_read_byte(dimm_socket_address, SPD_NUM_BANKS_PER_DRAM); + value = spd_read_byte(dimm_socket_address, SPD_NUM_BANKS_PER_SDRAM); die_on_spd_error(value); value = log2(value); @@ -701,7 +701,7 @@ if (channel0_dimm == 0) continue; // No such socket on this mainboard - if (spd_read_byte(channel0_dimm, SPD_MEMORY_TYPE) != MEMORY_TYPE_SDRAM_DDR) + if (spd_read_byte(channel0_dimm, SPD_MEMORY_TYPE) != SPD_MEMORY_TYPE_SDRAM_DDR) continue; #ifdef VALIDATE_DIMM_COMPATIBILITY @@ -1325,7 +1325,7 @@ current_cas_latency >>= 1; if (current_cas_latency != 0) { - value = spd_read_byte(dimm_socket_address, SPD_MIN_CYCLE_TIME_AT_CAS_REDUCED_05); + value = spd_read_byte(dimm_socket_address, SPD_SDRAM_CYCLE_TIME_2ND); if(value < 0 ) goto hw_err; if(value > 0x75) dimm_compatible_cas_latencies &= ~current_cas_latency; @@ -1334,7 +1334,7 @@ // Can we support the next-highest CAS# latency (max - 1.0)? current_cas_latency >>= 1; if (current_cas_latency != 0) { - value = spd_read_byte(dimm_socket_address, SPD_MIN_CYCLE_TIME_AT_CAS_REDUCED_10); + value = spd_read_byte(dimm_socket_address, SPD_SDRAM_CYCLE_TIME_3RD); if(value < 0 ) goto hw_err; if(value > 0x75) dimm_compatible_cas_latencies &= ~current_cas_latency; @@ -1489,11 +1489,11 @@ #ifdef SUSPICIOUS_LOOKING_CODE // SJM NOTE: This code doesn't look right. SPD values are an order of magnitude smaller // than the clock period of the memory controller. Also, no other northbridge -// looks at SPD_ADDRESS_CMD_HOLD. +// looks at SPD_CMD_SIGNAL_INPUT_HOLD_TIME. // Switch to 2 clocks for address/command if required by any one of the DIMMs // NOTE: At 133 MHz, 1 clock == 7.52 ns - value = spd_read_byte(dimm_socket_address, SPD_ADDRESS_CMD_HOLD); + value = spd_read_byte(dimm_socket_address, SPD_CMD_SIGNAL_INPUT_HOLD_TIME); die_on_spd_error(value); if(value >= 0xa0) { /* At 133MHz this constant should be 0x75 */ controller_mode &= ~(1<<16); /* Use two clock cyles instead of one */ @@ -1984,4 +1984,4 @@ /*^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^*/ /* PUBLIC INTERFACE */ -/**********************************************************************************/ \ Kein Zeilenvorschub am Ende der Datei +/**********************************************************************************/ }}} -- Ticket URL: LinuxBIOS From svn at openbios.org Wed Nov 8 13:46:39 2006 From: svn at openbios.org (LinuxBIOS) Date: Wed, 08 Nov 2006 12:46:39 -0000 Subject: [LinuxBIOS] #38: Improved spd.h In-Reply-To: <060.d65e12e7bbf3fa2c00ba97d4a94d5a7e@openbios.org> References: <060.d65e12e7bbf3fa2c00ba97d4a94d5a7e@openbios.org> Message-ID: <069.5f0c644bb671befc1a3992dc5a4024ae@openbios.org> #38: Improved spd.h -----------------------------------+---------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: assigned Priority: major | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: patch needs review | -----------------------------------+---------------------------------------- Comment (by uwe): OK, probably not a good idea. Looks ugly in Trac, and is broken in the notification email. I'll attach the patch the "normal" way in Trac now. This is yet another update which removes some stray UTF-8 characters. I also fixed a bug (wrong #define name) which caused a build breakage. Note: I changed some *_DRAM_* #defines to *_SDRAM_* for consistency. Is this ok, or was that really meant to be DRAM (not SDRAM) there? -- Ticket URL: LinuxBIOS From yinghai.lu at amd.com Wed Nov 8 21:42:23 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Wed, 8 Nov 2006 12:42:23 -0800 Subject: [LinuxBIOS] Patch for vmlinux amd64 with mkelfImage Message-ID: <5986589C150B2F49A46483AC44C7BCA49071B8@ssvlexmb2.amd.com> Please check the attached patch. It works now. It will use entry point for vmlinux in elf64 format. YH -------------- next part -------------- A non-text attachment was scrubbed... Name: mkelfImage_2.7_amd64_1108.patch Type: application/octet-stream Size: 16752 bytes Desc: mkelfImage_2.7_amd64_1108.patch URL: From dave at lab6.com Thu Nov 9 12:14:45 2006 From: dave at lab6.com (Dave Crossland) Date: Thu, 9 Nov 2006 11:14:45 +0000 Subject: [LinuxBIOS] Advice for buying a new and not-obsolete workstation? Message-ID: <2285a9d20611090314l4fee8e64g6691ff51f40afb92@mail.gmail.com> Hi, I'm in the UK and would like to buy a workstation that can be 100% Free Software, using gNewSense and a Free Software BIOS - ie, LinuxBIOS - and am not sure where to turn. Any idea? :-) ---------- Forwarded message ---------- From: lee at dnuk.com Date: 09-Nov-2006 09:44 Subject: Re: http://linuxbios.org To: Dave Crossland Thursday, November 9, 2006, 1:31:53 AM, you wrote: > Hi, > I would like to buy a workstation that supports 100% Free Software, > including a Free Software BIOS. That is, something listed as fully > supported on http://linuxbios.org/Supported_Motherboards > I could not see an easy way to tell this from your website. Hello Dave, I've checked that list and you'll find all those boards are quite old, i.e. socket 754, 940 and 604 which have been replaced some time ago. None of our motherboards support the BIOS and we don't plan to offer systems with this support. Regards, Lee ____________________________________________________________________ Digital Networks United Kingdom www.dnuk.com Linux workstations, servers and storage info at dnuk.com -- Regards, Dave -- Regards, Dave From dhbarr at gozelle.com Thu Nov 9 14:51:30 2006 From: dhbarr at gozelle.com (David H. Barr) Date: Thu, 9 Nov 2006 07:51:30 -0600 Subject: [LinuxBIOS] Advice for buying a new and not-obsolete workstation? In-Reply-To: <2285a9d20611090314l4fee8e64g6691ff51f40afb92@mail.gmail.com> References: <2285a9d20611090314l4fee8e64g6691ff51f40afb92@mail.gmail.com> Message-ID: On 11/9/06, Dave Crossland wrote: > I'm in the UK and would like to buy a workstation that can be 100% > Free Software, using gNewSense and a Free Software BIOS - ie, > LinuxBIOS - and am not sure where to turn. Dave, This is, as LB topics go, a "hot" one right now. From the linixuxbios.org/desktops page: "Currently there is not much support for cheap, mainstream desktop mainboards in LinuxBIOS. We intend to change that" Specifically, some of us right now are trying to figure out which board meets the following characteristics: - Socket AM2 - nVidia MCP 500 series - Widely available - Inexpensive I personally think we will have this nailed in the MSI K9N Neo-F "Real Soon Now"; waiting for a certain package to arrive in the mail. There's also talk on the lists (http://linuxbios.org/Mailinglist , check archive) of a few other boards with similar characteristics. Nothing concrete and working as yet, though. HTH, -dhb. From stepan at coresystems.de Thu Nov 9 15:21:58 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 9 Nov 2006 15:21:58 +0100 Subject: [LinuxBIOS] Advice for buying a new and not-obsolete workstation? In-Reply-To: <2285a9d20611090314l4fee8e64g6691ff51f40afb92@mail.gmail.com> References: <2285a9d20611090314l4fee8e64g6691ff51f40afb92@mail.gmail.com> Message-ID: <20061109142158.GB1177@coresystems.de> * Dave Crossland [061109 12:14]: > Hi, > > I'm in the UK and would like to buy a workstation that can be 100% > Free Software, using gNewSense and a Free Software BIOS - ie, > LinuxBIOS - and am not sure where to turn. Yeah, there are plenty of good workstation boards supported by LinuBIOS. The latest and greatest is definitely the MSI K9SD Master-S2R (MS-9185) Other than that there is a list available here: http://www.linuxbios.org/Supported_Motherboards 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 kurtandre at gmail.com Thu Nov 9 15:42:20 2006 From: kurtandre at gmail.com (=?ISO-8859-1?Q?Kurt_Andr=E9_Selbach?=) Date: Thu, 9 Nov 2006 15:42:20 +0100 Subject: [LinuxBIOS] Via epia-m2 difficulties Message-ID: <17cbe10f0611090642v5f8cbd54kc74712ea3d1aa530@mail.gmail.com> Hi! I'm trying to get a working linuxbios on my Via epia m2 12000, with 1200mhz processor and 512mb ram. The goal is to boot linux from a usbstick (guess i will be using filo and boot the device a uda1) I've managed to extract my videobios image with awardeco and that gave me a videobios file which was exactly 57344byte, how can i apply this to my linuxbios.rom file? The issue is the linuxbios.rom file is allready 256kb, Where would i change the size of this built "rom file" and what should i set it to: I tried setting this: option ROM_SIZE=256*1024 to: option ROM_SIZE=200*1024 Then doing: buildtarget via/epia-m cd via/epia-m/via_epia-m make This gives me this: ... ./buildrom linuxbios.strip linuxbios.rom payload 0x10000 0x12000 payload (41187) + linuxbios (65536) size larger than ROM (73728) size! make[1]: *** [linuxbios.rom] Error 1 ... Any suggestions would be welcome. From dave at lab6.com Thu Nov 9 16:10:24 2006 From: dave at lab6.com (Dave Crossland) Date: Thu, 9 Nov 2006 15:10:24 +0000 Subject: [LinuxBIOS] Advice for buying a new and not-obsolete workstation? In-Reply-To: References: <2285a9d20611090314l4fee8e64g6691ff51f40afb92@mail.gmail.com> Message-ID: <2285a9d20611090710j17e0c0c0sd4916b85f859567d@mail.gmail.com> On 09/11/06, David H. Barr wrote: > > I personally think we will have this nailed in the MSI K9N Neo-F "Real > Soon Now"; waiting for a certain package to arrive in the mail. What are the chances for Intel boards, since Intel are the only graphics card vendor with Free drivers at the moment? I guess I'll get a cheapo P4 Dell with i950 graphics for now, and stay turned for my next upgrade. -- Regards, Dave From dave at lab6.com Thu Nov 9 16:11:26 2006 From: dave at lab6.com (Dave Crossland) Date: Thu, 9 Nov 2006 15:11:26 +0000 Subject: [LinuxBIOS] Advice for buying a new and not-obsolete workstation? In-Reply-To: <20061109142158.GB1177@coresystems.de> References: <2285a9d20611090314l4fee8e64g6691ff51f40afb92@mail.gmail.com> <20061109142158.GB1177@coresystems.de> Message-ID: <2285a9d20611090711n69e3e39bv827513c7818fcd21@mail.gmail.com> On 09/11/06, Stefan Reinauer wrote: > > Yeah, there are plenty of good workstation boards supported by > LinuBIOS. The latest and greatest is definitely the > MSI K9SD Master-S2R (MS-9185) Okay awesome - I'll make enquiries at my local custom built PC shop. Whats the recommend 3d graphics card with Free drivers for such a motherboard? -- Regards, Dave From c-d.hailfinger.devel.2006 at gmx.net Thu Nov 9 16:28:38 2006 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 09 Nov 2006 16:28:38 +0100 Subject: [LinuxBIOS] MSI K9N Neo support for LinuxBIOS? Message-ID: <45534926.3060909@gmx.net> Hi bxshi, would you help us port LinuxBIOS to the MSI K9N Neo? http://cweb.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID=733 http://www.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID=733 It is a good and cheap board and a few of us will buy it to port LinuxBIOS to it, but we need your support. Regards, Carl-Daniel From dhbarr at gozelle.com Thu Nov 9 17:07:38 2006 From: dhbarr at gozelle.com (David H. Barr) Date: Thu, 9 Nov 2006 10:07:38 -0600 Subject: [LinuxBIOS] MSI K9N Neo support for LinuxBIOS? In-Reply-To: <45534926.3060909@gmx.net> References: <45534926.3060909@gmx.net> Message-ID: On 11/9/06, Carl-Daniel Hailfinger wrote: > would you help us port LinuxBIOS to the MSI K9N Neo? > > It is a good and cheap board and a few of us will buy it > to port LinuxBIOS to it, but we need your support. This is also the board I'd hoped to have YH-Lu's AM2 / MCP 550 help on... the only thing I see on there that concerns me is "Vitesse VSC8601" for the Gbit ethernet. I'll keep the list updated -- UPS should be bringing me two of these in a couple of hours, and I fully intend to get some hi-res images of various bits online ASAP. Regards, -dhb. From c-d.hailfinger.devel.2006 at gmx.net Thu Nov 9 18:23:48 2006 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 09 Nov 2006 18:23:48 +0100 Subject: [LinuxBIOS] MSI K9N Neo support for LinuxBIOS? In-Reply-To: References: <45534926.3060909@gmx.net> Message-ID: <45536424.2040703@gmx.net> David H. Barr wrote: > On 11/9/06, Carl-Daniel Hailfinger wrote: >> would you help us port LinuxBIOS to the MSI K9N Neo? >> >> It is a good and cheap board and a few of us will buy it >> to port LinuxBIOS to it, but we need your support. > > This is also the board I'd hoped to have YH-Lu's AM2 / MCP 550 help > on... the only thing I see on there that concerns me is "Vitesse > VSC8601" for the Gbit ethernet. Try skge, sky2 or forcedeth as drivers (in that order). I expect skge will be the driver which works for the Vitesse ethernet and forcedeth for the Nvidia ethernet. Regards, Carl-Daniel -- http://www.hailfinger.org/ From stuge-linuxbios at cdy.org Thu Nov 9 18:37:08 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Thu, 9 Nov 2006 18:37:08 +0100 Subject: [LinuxBIOS] Via epia-m2 difficulties In-Reply-To: <17cbe10f0611090642v5f8cbd54kc74712ea3d1aa530@mail.gmail.com> References: <17cbe10f0611090642v5f8cbd54kc74712ea3d1aa530@mail.gmail.com> Message-ID: <20061109173708.19995.qmail@cdy.org> On Thu, Nov 09, 2006 at 03:42:20PM +0100, Kurt Andr? Selbach wrote: > Hi! > > I'm trying to get a working linuxbios on my Via epia m2 12000, > with 1200mhz processor and 512mb ram. > > The goal is to boot linux from a usbstick (guess i will be using > filo and boot the device a uda1) Yep. I haven't tried that on my board, but from IDE works just fine. > I've managed to extract my videobios image with awardeco and that > gave me a videobios file which was exactly 57344byte, how can i > apply this to my linuxbios.rom file? Hm, this may not be the correct image. I'd suggest dumping the VGA BIOS from when the board is running Linux under the factor BIOS thusly: dd if=/dev/mem of=/tmp/vgabios.bin bs=1k count=64 skip=768 See also http://linuxbios.org/VGA_support > The issue is the linuxbios.rom file is allready 256kb, Where would i > change the size of this built "rom file" and what should i set it to: > > I tried setting this: > option ROM_SIZE=256*1024 > to: > option ROM_SIZE=200*1024 > Then doing: > > buildtarget via/epia-m > cd via/epia-m/via_epia-m > make > > This gives me this: > > ... > ./buildrom linuxbios.strip linuxbios.rom payload 0x10000 0x12000 > payload (41187) + linuxbios (65536) size larger than ROM (73728) size! > make[1]: *** [linuxbios.rom] Error 1 > ... > > Any suggestions would be welcome. After the above dd command try these settings in your config: option ROM_SIZE=192*1024 option ROM_SECTION_OFFSET=0x10000 It looks like the latter is 0 now. This is all horribly unintuitive but should improve in v3. If it still doesn't work you could try just inserting your image right at the start of your 256kb linuxbios.rom like this: dd if=vga56k.bin of=linuxbios.rom bs=56k count=1 conv=notrunc But please try the other way first, I think it should work better. //Peter From smithbone at gmail.com Thu Nov 9 22:40:04 2006 From: smithbone at gmail.com (Richard Smith) Date: Thu, 09 Nov 2006 15:40:04 -0600 Subject: [LinuxBIOS] Via epia-m2 difficulties In-Reply-To: <17cbe10f0611090642v5f8cbd54kc74712ea3d1aa530@mail.gmail.com> References: <17cbe10f0611090642v5f8cbd54kc74712ea3d1aa530@mail.gmail.com> Message-ID: <4553A034.4070907@gmail.com> Kurt Andre' Selbach wrote: > The issue is the linuxbios.rom file is allready 256kb, Where would i > change the size of this built "rom file" and what should i set it to: Try this: Snap your video bios image to 64KiB with dd option ROM_SIZE=(256-64)*1024 option FALLBACK_SIZE=128*1024 romimage "fallback" option USE_FALLBACK_IMAGE=1 option ROM_IMAGE_SIZE=33*1024 option LINUXBIOS_EXTRA_VERSION=".0Fallback" payload /tmp/filo.elf end buildrom ./linuxbios.rom ROM_SIZE "fallback" -- Richard A. Smith From svn at openbios.org Thu Nov 9 23:06:21 2006 From: svn at openbios.org (LinuxBIOS) Date: Thu, 09 Nov 2006 22:06:21 -0000 Subject: [LinuxBIOS] #39: 440BX header file with register definitions Message-ID: <060.d5463e386027faf0cdaabe43619b5b42@openbios.org> #39: 440BX header file with register definitions -----------------------------+---------------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: new Priority: major | Milestone: Going mainstream Component: code | Version: v2 Keywords: | Due_close: MM/DD/YYYY Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Patchstatus: patch needs review -----------------------------+---------------------------------------------- Add an include file which contains the register definitions for the Intel 440BX northbridge. Signed-off-by: Uwe Hermann --- Soon to be used in the 440BX port. -- Ticket URL: LinuxBIOS From svn at openbios.org Thu Nov 9 23:11:04 2006 From: svn at openbios.org (LinuxBIOS) Date: Thu, 09 Nov 2006 22:11:04 -0000 Subject: [LinuxBIOS] #40: Decide on common header #ifndef names or standards for usage Message-ID: <060.56bce4d768d5e23552af66d42262ab6c@openbios.org> #40: Decide on common header #ifndef names or standards for usage -----------------------------+---------------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: new Priority: minor | Milestone: Cosmetic fixes Component: code | Version: v2 Keywords: | Due_close: MM/DD/YYYY Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Patchstatus: there is no patch -----------------------------+---------------------------------------------- We have lots of variations for "include guards" in the code: {{{ _FOO _FOO_H __FOO_H __FOO_H__ _FOO_H_ __FOO_DEFINED ... }}} Is there a special convention or agreement on when to use which? If yes, it should be documented. If no, we should standardize on one format and use it consistently. -- Ticket URL: LinuxBIOS From uwe at hermann-uwe.de Thu Nov 9 23:13:16 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 9 Nov 2006 23:13:16 +0100 Subject: [LinuxBIOS] #39: 440BX header file with register definitions In-Reply-To: <060.d5463e386027faf0cdaabe43619b5b42@openbios.org> References: <060.d5463e386027faf0cdaabe43619b5b42@openbios.org> Message-ID: <20061109221316.GA2545@greenwood> CC of the patch for the mailing list, as long as Trac doesn't send it. On Thu, Nov 09, 2006 at 10:06:21PM -0000, LinuxBIOS wrote: > #39: 440BX header file with register definitions > -----------------------------+---------------------------------------------- > Reporter: uwe | Owner: uwe > Type: enhancement | Status: new > Priority: major | Milestone: Going mainstream > Component: code | Version: v2 > Keywords: | Due_close: MM/DD/YYYY > Include_gantt: 0 | Dependencies: > Due_assign: MM/DD/YYYY | Patchstatus: patch needs review > -----------------------------+---------------------------------------------- > Add an include file which contains the register definitions for the Intel > 440BX northbridge. > > Signed-off-by: Uwe Hermann > > --- > > Soon to be used in the 440BX port. > > -- > Ticket URL: > LinuxBIOS > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- Index: src/northbridge/intel/i440bx/i440bx.h =================================================================== --- src/northbridge/intel/i440bx/i440bx.h (Revision 0) +++ src/northbridge/intel/i440bx/i440bx.h (Revision 0) @@ -0,0 +1,81 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/* + * Datasheet: + * - Name: Intel 440BX AGPset: 82443BX Host Bridge/Controller + * - URL: http://www.intel.com/design/chipsets/datashts/290633.htm + * - PDF: http://www.intel.com/design/chipsets/datashts/29063301.pdf + * - Order Number: 290633-001 + */ + +/* + * Host-to-PCI Bridge Registers. + * The values in parenthesis are the default values as per datasheet. + * Any addresses between 0x00 and 0xff not listed below are either + * Reserved or Intel Reserved and should not be touched. + */ +#define VID 0x00 /* Vendor Identification (0x8086). */ +#define DID 0x02 /* Device Identification (0x7190/0x7192). */ +#define PCICMD 0x04 /* PCI Command Register (0x006). */ +#define PCISTS 0x06 /* PCI Status Register (0x0210/0x0200). */ +#define RID 0x08 /* Revision Identification (0x00/0x01/0x02). */ +#define SUBC 0x0a /* Sub-Class Code (0x00). */ +#define BCC 0x0b /* Base Class Code (0x06). */ +#define MLT 0x0d /* Master Latency Timer (0x00). */ +#define HDR 0x0e /* Header Type (0x00). */ +#define APBASE 0x10 /* Aperture Base Configuration (0x00000008). */ +#define SVID 0x2c /* Subsystem Vendor Identification (0x0000). */ +#define SID 0x2e /* Subsystem Identification (0x0000). */ +#define CAPPTR 0x34 /* Capabilities Pointer (0xa0/0x00. */ +#define NBXCFG 0x50 /* 440BX Configuration (0x0000:00S0_0000_000S_0S00b). */ +#define DRAMC 0x57 /* DRAM Control (00S0_0000b). */ +#define DRAMT 0x58 /* DRAM Timing (0x03). */ +#define PAM 0x59 /* Programmable Attribute Map, 7 registers (0x00). */ +#define DRB 0x60 /* DRAM Row Boundary, 8 registers (0x01). */ +#define FDHC 0x68 /* Fixed SDRAM Hole Control (0x00). */ +#define MBSC 0x69 /* Memory Buffer Strength Control (0x0000-0000-0000). */ +#define SMRAM 0x72 /* System Management RAM Control (0x02). */ +#define ESMRAMC 0x73 /* Extended System Management RAM Control (0x38). */ +#define RPS 0x74 /* SDRAM Row Page Size (0x0000). */ +#define SDRAMC 0x76 /* SDRAM Control Register (0x0000). */ +#define PGPOL 0x78 /* Paging Policy Register (0x00). */ +#define PMCR 0x7a /* Power Management Control Register (0000_S0S0b). */ +#define SCRR 0x7b /* Suspend CBR Refresh Rate Register (0x0038). */ +#define EAP 0x80 /* Error Address Pointer Register (0x00000000). */ +#define ERRCMD 0x90 /* Error Command Register (0x80). */ +#define ERRSTS 0x91 /* Error Status (0x0000). */ +// TODO: AGP stuff. +#define MBFS 0xca /* Memory Buffer Frequency Select (0x000000). */ +#define BSPAD 0xd0 /* BIOS Scratch Pad (0x000..000). */ +#define DWTC 0xe0 /* DRAM Write Thermal Throttling Control (0x000..000). */ +#define DRTC 0xe8 /* DRAM Read Thermal Throttling Control (0x000..000). */ +#define BUFFC 0xf0 /* Buffer Control Register (0x0000). */ + +/* For convenience: */ +#define DRB0 0x60 +#define DRB1 0x61 +#define DRB2 0x62 +#define DRB3 0x63 +#define DRB4 0x64 +#define DRB5 0x65 +#define DRB6 0x66 +#define DRB7 0x67 + -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From stepan at coresystems.de Fri Nov 10 00:12:15 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 10 Nov 2006 00:12:15 +0100 Subject: [LinuxBIOS] Support for IEI Nova4899R [1] In-Reply-To: <4550544F.1070808@lfcorreia.dyndns.org> References: <454CFA15.3080501@lfcorreia.dyndns.org> <13426df10611041640o2008c16fj21ccfb55fe0c8929@mail.gmail.com> <454D395A.3020205@lfcorreia.dyndns.org> <20061105021200.GA5020@coresystems.de> <4550544F.1070808@lfcorreia.dyndns.org> Message-ID: <20061109231215.GA32140@coresystems.de> * Luis Correia [061107 10:39]: > We can see thatthe 32k vga bios is copied to the correct place, but > nothing is done to the VSA portion, it is true that this VSA code > does not have the standard BIOS start values (0x55aa). Yes, vsa is not an option rom, hence no 55aa. VSA needs to be called in 16bit mode, GX2 and LX do that in northbridge.c Check out src/cpu/amd/model_gx2/vsmsetup.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 svn at openbios.org Fri Nov 10 00:33:57 2006 From: svn at openbios.org (LinuxBIOS) Date: Thu, 09 Nov 2006 23:33:57 -0000 Subject: [LinuxBIOS] #39: 440BX header file with register definitions In-Reply-To: <060.d5463e386027faf0cdaabe43619b5b42@openbios.org> References: <060.d5463e386027faf0cdaabe43619b5b42@openbios.org> Message-ID: <069.44f861a7f9ec9063c1d0eccc9867c998@openbios.org> #39: 440BX header file with register definitions -----------------------------------+---------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: new Priority: major | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: patch needs review | -----------------------------------+---------------------------------------- Comment (by anonymous): Replying to [ticket:39 uwe]: > Add an include file which contains the register definitions for the Intel 440BX northbridge. > > Signed-off-by: Uwe Hermann Acked-By: Richard Smith -- Ticket URL: LinuxBIOS From smithbone at gmail.com Fri Nov 10 00:45:23 2006 From: smithbone at gmail.com (Richard Smith) Date: Thu, 09 Nov 2006 17:45:23 -0600 Subject: [LinuxBIOS] Advice for buying a new and not-obsolete workstation? In-Reply-To: <2285a9d20611090710j17e0c0c0sd4916b85f859567d@mail.gmail.com> References: <2285a9d20611090314l4fee8e64g6691ff51f40afb92@mail.gmail.com> <2285a9d20611090710j17e0c0c0sd4916b85f859567d@mail.gmail.com> Message-ID: <4553BD93.6000005@gmail.com> Dave Crossland wrote: > What are the chances for Intel boards, since Intel are the only Very low... > graphics card vendor with Free drivers at the moment? > Intel graphics drivers are not free. The are just more free than AIT and Nvidia. -- Richard A. Smith From c-d.hailfinger.devel.2006 at gmx.net Fri Nov 10 01:00:48 2006 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 10 Nov 2006 01:00:48 +0100 Subject: [LinuxBIOS] Advice for buying a new and not-obsolete workstation? In-Reply-To: <4553BD93.6000005@gmail.com> References: <2285a9d20611090314l4fee8e64g6691ff51f40afb92@mail.gmail.com> <2285a9d20611090710j17e0c0c0sd4916b85f859567d@mail.gmail.com> <4553BD93.6000005@gmail.com> Message-ID: <4553C130.8090107@gmx.net> Richard Smith wrote: > Dave Crossland wrote: > >> What are the chances for Intel boards, since Intel are the only > > Very low... > >> graphics card vendor with Free drivers at the moment? > > Intel graphics drivers are not free. The are just more free than AIT and > Nvidia. The open source ATI radeon r200 and r300 drivers have remarkable quality, although r300 was the product of reverse engineering. The r300 series cards are fast enough for anything you might want to run and they are still available in stores. See http://en.wikipedia.org/wiki/Radeon_R300 for a list of adapters of this family. Regards, Carl-Daniel From dave at lab6.com Fri Nov 10 01:46:47 2006 From: dave at lab6.com (Dave Crossland) Date: Fri, 10 Nov 2006 00:46:47 +0000 Subject: [LinuxBIOS] Advice for buying a new and not-obsolete workstation? In-Reply-To: <4553BD93.6000005@gmail.com> References: <2285a9d20611090314l4fee8e64g6691ff51f40afb92@mail.gmail.com> <2285a9d20611090710j17e0c0c0sd4916b85f859567d@mail.gmail.com> <4553BD93.6000005@gmail.com> Message-ID: <2285a9d20611091646l33dbde05g89f2fc81b2539c54@mail.gmail.com> On 09/11/06, Richard Smith wrote: > Dave Crossland wrote: > > > What are the chances for Intel boards, since Intel are the only > > Very low... :-( > > graphics card vendor with Free drivers at the moment? > > Intel graphics drivers are not free. The are just more free than AIT and > Nvidia. http://intellinuxgraphics.org/license.html says its all "GPL and additional rights" and "X.org MIT license". Whats not free about this? -- Regards, Dave From dave at lab6.com Fri Nov 10 01:47:19 2006 From: dave at lab6.com (Dave Crossland) Date: Fri, 10 Nov 2006 00:47:19 +0000 Subject: [LinuxBIOS] Advice for buying a new and not-obsolete workstation? In-Reply-To: <4553C130.8090107@gmx.net> References: <2285a9d20611090314l4fee8e64g6691ff51f40afb92@mail.gmail.com> <2285a9d20611090710j17e0c0c0sd4916b85f859567d@mail.gmail.com> <4553BD93.6000005@gmail.com> <4553C130.8090107@gmx.net> Message-ID: <2285a9d20611091647g1f4409bbyf91deabdeadfdd15@mail.gmail.com> On 10/11/06, Carl-Daniel Hailfinger wrote: > > >> graphics card vendor with Free drivers at the moment? > > The open source ATI radeon r200 and r300 drivers have remarkable quality, > although r300 was the product of reverse engineering. The r300 series > cards are fast enough for anything you might want to run and they are > still available in stores. See http://en.wikipedia.org/wiki/Radeon_R300 > for a list of adapters of this family. Okay great - thank you! -- Regards, Dave From smithbone at gmail.com Fri Nov 10 01:58:33 2006 From: smithbone at gmail.com (Richard Smith) Date: Thu, 09 Nov 2006 18:58:33 -0600 Subject: [LinuxBIOS] Advice for buying a new and not-obsolete workstation? In-Reply-To: <2285a9d20611091646l33dbde05g89f2fc81b2539c54@mail.gmail.com> References: <2285a9d20611090314l4fee8e64g6691ff51f40afb92@mail.gmail.com> <2285a9d20611090710j17e0c0c0sd4916b85f859567d@mail.gmail.com> <4553BD93.6000005@gmail.com> <2285a9d20611091646l33dbde05g89f2fc81b2539c54@mail.gmail.com> Message-ID: <4553CEB9.2050704@gmail.com> Dave Crossland wrote: >> Intel graphics drivers are not free. The are just more free than AIT and >> Nvidia. > > http://intellinuxgraphics.org/license.html says its all "GPL and > additional rights" and "X.org MIT license". Whats not free about this? > Sorry bad choice of words on my part.. I meant not fully open source and not totally free of binary cruft. http://marc.theaimsgroup.com/?l=linux-kernel&m=115536806403908&w=2 -- Richard A. Smith From dave at lab6.com Fri Nov 10 02:10:44 2006 From: dave at lab6.com (Dave Crossland) Date: Fri, 10 Nov 2006 01:10:44 +0000 Subject: [LinuxBIOS] Advice for buying a new and not-obsolete workstation? In-Reply-To: <4553CEB9.2050704@gmail.com> References: <2285a9d20611090314l4fee8e64g6691ff51f40afb92@mail.gmail.com> <2285a9d20611090710j17e0c0c0sd4916b85f859567d@mail.gmail.com> <4553BD93.6000005@gmail.com> <2285a9d20611091646l33dbde05g89f2fc81b2539c54@mail.gmail.com> <4553CEB9.2050704@gmail.com> Message-ID: <2285a9d20611091710u57215e75he5f1df90ff97b5e4@mail.gmail.com> On 10/11/06, Richard Smith wrote: > > Sorry bad choice of words on my part.. I meant not fully open source and > not totally free of binary cruft. > > http://marc.theaimsgroup.com/?l=linux-kernel&m=115536806403908&w=2 Ouch. When he says, "The driver remains completely functional in the absense of the binary piece", surely some functionality is missing - what is this? I don't understand enough (yet) to know from that post :-( Also, my local PC builder says: -- 8< -- I cannot find any seller of the motherboard, it may be obselete, or even not released in the UK yet Looking at the spec of the board it is a dual cpu board of very high spec. Boards of this Spec we have used in the past have been ?300-?400 2 Cpus will be in the region of ?500 I don't really consider this to be a workstation setup. Do you want to go to this VERY high spec? -- 8< -- Any suggestions? :-) -- Regards, Dave From kurtandre at gmail.com Fri Nov 10 04:32:43 2006 From: kurtandre at gmail.com (=?ISO-8859-1?Q?Kurt_Andr=E9_Selbach?=) Date: Fri, 10 Nov 2006 04:32:43 +0100 Subject: [LinuxBIOS] Via epia-m2 difficulties Message-ID: <17cbe10f0611091932v4e341605u5bd70875415b992c@mail.gmail.com> Thanks, for the answers, i managed to get the vgabios running when i inserted the extracted vgabios (from awardeco) and inserted it with the dd command. My next problem is trying to boot from my usb device using FILO version 0.5 from this "link" svn://openbios.org/filo/trunk/filo-0.5 "FILO version 0.5 (root at powertron) Fri Nov 10 02:05:10 CET 2006 Press for default boot, or for boot prompt... 1mlinuz root=/dev/sda1 console=tty0 console=ttyS0nd UHCI at 1800 uhc_reset: Resetting UHCI uhc_init: uhc_init setting framelist to: 1decb9f0 uhc_start: Starting UHCI dump_uhci: HCI at 00001800 uhc_init: Found UHCI at 1820 uhc_reset: Resetting UHCI" The computer now "hangs" no boot nothing. Using the filo from ehterboot, it get's to the "LinuxLabs USB bootloader" and that's as far as it goes. Stock award bios managed to boot from this usbstick, What could be wrong, any suggestions?! Thanks in advance Best regards Kurt. From smithbone at gmail.com Fri Nov 10 04:35:37 2006 From: smithbone at gmail.com (Richard Smith) Date: Thu, 09 Nov 2006 21:35:37 -0600 Subject: [LinuxBIOS] Via epia-m2 difficulties In-Reply-To: <17cbe10f0611091930r6f5eaa9rcf6d29fbc4956254@mail.gmail.com> References: <17cbe10f0611090642v5f8cbd54kc74712ea3d1aa530@mail.gmail.com> <4553A034.4070907@gmail.com> <17cbe10f0611091930r6f5eaa9rcf6d29fbc4956254@mail.gmail.com> Message-ID: <4553F389.5030000@gmail.com> Kurt Andr? Selbach wrote: > uhc_init: uhc_init setting framelist to: 1decb9f0 > uhc_start: Starting UHCI > dump_uhci: HCI at 00001800 > uhc_init: Found UHCI at 1820 > uhc_reset: Resetting UHCI" > > The computer now "hangs" no boot nothing. > > Using the filo from ehterboot, it get's to the "LinuxLabs USB > bootloader" and that's as far as it goes. > > Stock award bios managed to boot from this usbstick, > What could be wrong, any suggestions?! Run the memtest86 payload and make sure your RAM is solid. -- Richard A. Smith From corey_osgood at verizon.net Fri Nov 10 06:48:02 2006 From: corey_osgood at verizon.net (Corey) Date: Fri, 10 Nov 2006 00:48:02 -0500 Subject: [LinuxBIOS] i440bx Message-ID: <1163137682.30157.10.camel@ampfs.soundroom> Okay, I'm forced to admit that I'm a bit overwhelmed by the source code...I've made some progress towards understanding how exactly everything works and where changes need to be made, but I won't have the hardware to toy around with for a few more days. In the meantime, would it cause issue if I were to statically set the value of the ram to a trivial minimal value (such as 8mb), as a fallback should the SPD return 0? Both of the 440bx boards I have here now were freebies, so it's no real loss if I brick them, but it'd be nice to know in advance. BTW (if anyone cares), I have changed my email address (needed one that would let me use a real mail program), this is my new one. Corey Osgood From bxshi at msik.com.cn Fri Nov 10 07:23:58 2006 From: bxshi at msik.com.cn (bxshi at msik.com.cn) Date: Fri, 10 Nov 2006 14:23:58 +0800 Subject: [LinuxBIOS] =?gb2312?b?tPC4tDogTVNJIEs5TiBOZW8gc3VwcG9ydCBmb3Ig?= =?gb2312?b?TGludXhCSU9TPw==?= Message-ID: Dear Owen , There are several experts from all of world are planning to port it . I will introduce you to them . I think when they are porting ,they may need some datasheet.etc. I may not be able to port it myself ,because I am busy with MS-9182 linuxbios porting. More detail please see www.linuxbios.org Dear carl-Daniel ,Stefan ,Yinghai,ron,uwe, Owen is our Desktop BIOS manager , if you need some help of MSI K9N Nero ,you can contact with him .He is preparing help . Thanks bxshi -----????----- ???: owenchen [mailto:owenchen at msik.com.cn] ????: 2006?11?10? 14:04 ???: bxshi(???=??) ??: 'Carl-Daniel Hailfinger' ??: RE: MSI K9N Neo support for LinuxBIOS? Dear BxShi What I can do a favor to you? And tell me the K9N Neo model's name? thanks -----Original Message----- From: bxshi [mailto:bxshi at msik.com.cn] Sent: Friday, November 10, 2006 10:46 AM To: owenchen(???=??) Cc: 'Carl-Daniel Hailfinger' Subject: ??: MSI K9N Neo support for LinuxBIOS? Dear Owen , Linuxbios Community is interested in MSI K9N Neo, and they are planning to port linuxbios for it .could you please give them some help ? Many people are like this board if it has linuxbios support. -----????----- ???: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006 at gmx.net] ????: 2006?11?9? 23:29 ???: bxshi at msik.com.cn ??: LinuxBIOS ??: MSI K9N Neo support for LinuxBIOS? Hi bxshi, would you help us port LinuxBIOS to the MSI K9N Neo? http://cweb.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID =733 http://www.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID= 733 It is a good and cheap board and a few of us will buy it to port LinuxBIOS to it, but we need your support. Regards, Carl-Daniel *****CONFIDENTIAL INFORMATION***** This email is intended only for the use of the person or entity to whom it is addressed and contains information that may be subject to and/or may be restricted from disclosure by contract or applicable law. If you are not the intended recipient of this email, be advised that any disclosure, copy, distribution or use of the contents of this message is strictly prohibited. If you are not the intended recipient of this email, please notify the sender that you have received this in error by replying to this message. Then, please delete it from your system. Thank you. From bxshi at msik.com.cn Fri Nov 10 07:25:59 2006 From: bxshi at msik.com.cn (bxshi at msik.com.cn) Date: Fri, 10 Nov 2006 14:25:59 +0800 Subject: [LinuxBIOS] =?gb2312?b?tPC4tDogTVNJIEs5TiBOZW8gc3VwcG9ydCBmb3Ig?= =?gb2312?b?TGludXhCSU9TPw==?= Message-ID: Dear Owen , There are several experts from all of world are planning to port it . I will introduce you to them . I think when they are porting ,they may need some datasheet.etc. I may not be able to port it myself ,because I am busy with MS-9182 linuxbios porting. More detail please see www.linuxbios.org Dear carl-Daniel ,Stefan ,Yinghai,ron,uwe: Owen is our Desktop BIOS manager , if you need some help of MSI K9N Nero ,you can contact with him .He is preparing help . Thanks bxshi -----????----- ???: owenchen [mailto:owenchen at msik.com.cn] ????: 2006?11?10? 14:04 ???: bxshi(???=??) ??: 'Carl-Daniel Hailfinger' ??: RE: MSI K9N Neo support for LinuxBIOS? Dear BxShi What I can do a favor to you? And tell me the K9N Neo model's name? thanks -----Original Message----- From: bxshi [mailto:bxshi at msik.com.cn] Sent: Friday, November 10, 2006 10:46 AM To: owenchen(???=??) Cc: 'Carl-Daniel Hailfinger' Subject: ??: MSI K9N Neo support for LinuxBIOS? Dear Owen , Linuxbios Community is interested in MSI K9N Neo, and they are planning to port linuxbios for it .could you please give them some help ? Many people are like this board if it has linuxbios support. -----????----- ???: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006 at gmx.net] ????: 2006?11?9? 23:29 ???: bxshi at msik.com.cn ??: LinuxBIOS ??: MSI K9N Neo support for LinuxBIOS? Hi bxshi, would you help us port LinuxBIOS to the MSI K9N Neo? http://cweb.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID =733 http://www.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID= 733 It is a good and cheap board and a few of us will buy it to port LinuxBIOS to it, but we need your support. Regards, Carl-Daniel *****CONFIDENTIAL INFORMATION***** This email is intended only for the use of the person or entity to whom it is addressed and contains information that may be subject to and/or may be restricted from disclosure by contract or applicable law. If you are not the intended recipient of this email, be advised that any disclosure, copy, distribution or use of the contents of this message is strictly prohibited. If you are not the intended recipient of this email, please notify the sender that you have received this in error by replying to this message. Then, please delete it from your system. Thank you. From bxshi at msik.com.cn Fri Nov 10 08:03:20 2006 From: bxshi at msik.com.cn (bxshi at msik.com.cn) Date: Fri, 10 Nov 2006 15:03:20 +0800 Subject: [LinuxBIOS] =?gb2312?b?tPC4tDogTVNJIEs5TiBOZW8gc3VwcG9ydCBmb3Ig?= =?gb2312?b?TGludXhCSU9TPw==?= Message-ID: Dear all, Sorry . please contact their PM andrewchang at msi.com.tw laurayan at msik.com.cn bxshi -----????----- ???: bxshi(???=??) ????: 2006?11?10? 14:24 ???: owenchen(???=??) ??: 'Carl-Daniel Hailfinger'; 'rminnich at gmail.com'; 'yinghai.lu at amd.com'; 'stepan at coresystems.de'; 'uwe at hermann-uwe.de'; 'linuxbios at linuxbios.org' ??: ??: MSI K9N Neo support for LinuxBIOS? Dear Owen , There are several experts from all of world are planning to port it . I will introduce you to them . I think when they are porting ,they may need some datasheet.etc. I may not be able to port it myself ,because I am busy with MS-9182 linuxbios porting. More detail please see www.linuxbios.org Dear carl-Daniel ,Stefan ,Yinghai,ron,uwe, Owen is our Desktop BIOS manager , if you need some help of MSI K9N Nero ,you can contact with him .He is preparing help . Thanks bxshi -----????----- ???: owenchen [mailto:owenchen at msik.com.cn] ????: 2006?11?10? 14:04 ???: bxshi(???=??) ??: 'Carl-Daniel Hailfinger' ??: RE: MSI K9N Neo support for LinuxBIOS? Dear BxShi What I can do a favor to you? And tell me the K9N Neo model's name? thanks -----Original Message----- From: bxshi [mailto:bxshi at msik.com.cn] Sent: Friday, November 10, 2006 10:46 AM To: owenchen(???=??) Cc: 'Carl-Daniel Hailfinger' Subject: ??: MSI K9N Neo support for LinuxBIOS? Dear Owen , Linuxbios Community is interested in MSI K9N Neo, and they are planning to port linuxbios for it .could you please give them some help ? Many people are like this board if it has linuxbios support. -----????----- ???: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006 at gmx.net] ????: 2006?11?9? 23:29 ???: bxshi at msik.com.cn ??: LinuxBIOS ??: MSI K9N Neo support for LinuxBIOS? Hi bxshi, would you help us port LinuxBIOS to the MSI K9N Neo? http://cweb.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID =733 http://www.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID= 733 It is a good and cheap board and a few of us will buy it to port LinuxBIOS to it, but we need your support. Regards, Carl-Daniel *****CONFIDENTIAL INFORMATION***** This email is intended only for the use of the person or entity to whom it is addressed and contains information that may be subject to and/or may be restricted from disclosure by contract or applicable law. If you are not the intended recipient of this email, be advised that any disclosure, copy, distribution or use of the contents of this message is strictly prohibited. If you are not the intended recipient of this email, please notify the sender that you have received this in error by replying to this message. Then, please delete it from your system. Thank you. From svn at openbios.org Fri Nov 10 10:04:14 2006 From: svn at openbios.org (svn at openbios.org) Date: Fri, 10 Nov 2006 09:04:14 -0000 Subject: [LinuxBIOS] r2495 - trunk/LinuxBIOSv2/src/northbridge/intel/i440bx Message-ID: Author: uwe Date: 2006-11-10 10:04:12 +0100 (Fri, 10 Nov 2006) New Revision: 2495 Added: trunk/LinuxBIOSv2/src/northbridge/intel/i440bx/i440bx.h Log: Add an include file which contains the register definitions for the Intel 440BX northbridge (Closes #39). Signed-off-by: Uwe Hermann Acked-by: Richard Smith Added: trunk/LinuxBIOSv2/src/northbridge/intel/i440bx/i440bx.h =================================================================== --- trunk/LinuxBIOSv2/src/northbridge/intel/i440bx/i440bx.h (rev 0) +++ trunk/LinuxBIOSv2/src/northbridge/intel/i440bx/i440bx.h 2006-11-10 09:04:12 UTC (rev 2495) @@ -0,0 +1,81 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 Uwe Hermann + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/* + * Datasheet: + * - Name: Intel 440BX AGPset: 82443BX Host Bridge/Controller + * - URL: http://www.intel.com/design/chipsets/datashts/290633.htm + * - PDF: http://www.intel.com/design/chipsets/datashts/29063301.pdf + * - Order Number: 290633-001 + */ + +/* + * Host-to-PCI Bridge Registers. + * The values in parenthesis are the default values as per datasheet. + * Any addresses between 0x00 and 0xff not listed below are either + * Reserved or Intel Reserved and should not be touched. + */ +#define VID 0x00 /* Vendor Identification (0x8086). */ +#define DID 0x02 /* Device Identification (0x7190/0x7192). */ +#define PCICMD 0x04 /* PCI Command Register (0x006). */ +#define PCISTS 0x06 /* PCI Status Register (0x0210/0x0200). */ +#define RID 0x08 /* Revision Identification (0x00/0x01/0x02). */ +#define SUBC 0x0a /* Sub-Class Code (0x00). */ +#define BCC 0x0b /* Base Class Code (0x06). */ +#define MLT 0x0d /* Master Latency Timer (0x00). */ +#define HDR 0x0e /* Header Type (0x00). */ +#define APBASE 0x10 /* Aperture Base Configuration (0x00000008). */ +#define SVID 0x2c /* Subsystem Vendor Identification (0x0000). */ +#define SID 0x2e /* Subsystem Identification (0x0000). */ +#define CAPPTR 0x34 /* Capabilities Pointer (0xa0/0x00. */ +#define NBXCFG 0x50 /* 440BX Configuration (0x0000:00S0_0000_000S_0S00b). */ +#define DRAMC 0x57 /* DRAM Control (00S0_0000b). */ +#define DRAMT 0x58 /* DRAM Timing (0x03). */ +#define PAM 0x59 /* Programmable Attribute Map, 7 registers (0x00). */ +#define DRB 0x60 /* DRAM Row Boundary, 8 registers (0x01). */ +#define FDHC 0x68 /* Fixed SDRAM Hole Control (0x00). */ +#define MBSC 0x69 /* Memory Buffer Strength Control (0x0000-0000-0000). */ +#define SMRAM 0x72 /* System Management RAM Control (0x02). */ +#define ESMRAMC 0x73 /* Extended System Management RAM Control (0x38). */ +#define RPS 0x74 /* SDRAM Row Page Size (0x0000). */ +#define SDRAMC 0x76 /* SDRAM Control Register (0x0000). */ +#define PGPOL 0x78 /* Paging Policy Register (0x00). */ +#define PMCR 0x7a /* Power Management Control Register (0000_S0S0b). */ +#define SCRR 0x7b /* Suspend CBR Refresh Rate Register (0x0038). */ +#define EAP 0x80 /* Error Address Pointer Register (0x00000000). */ +#define ERRCMD 0x90 /* Error Command Register (0x80). */ +#define ERRSTS 0x91 /* Error Status (0x0000). */ +// TODO: AGP stuff. +#define MBFS 0xca /* Memory Buffer Frequency Select (0x000000). */ +#define BSPAD 0xd0 /* BIOS Scratch Pad (0x000..000). */ +#define DWTC 0xe0 /* DRAM Write Thermal Throttling Control (0x000..000). */ +#define DRTC 0xe8 /* DRAM Read Thermal Throttling Control (0x000..000). */ +#define BUFFC 0xf0 /* Buffer Control Register (0x0000). */ + +/* For convenience: */ +#define DRB0 0x60 +#define DRB1 0x61 +#define DRB2 0x62 +#define DRB3 0x63 +#define DRB4 0x64 +#define DRB5 0x65 +#define DRB6 0x66 +#define DRB7 0x67 + From info at coresystems.de Fri Nov 10 10:07:06 2006 From: info at coresystems.de (LinuxBIOS information) Date: Fri, 10 Nov 2006 10:07:06 +0100 Subject: [LinuxBIOS] r2495 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2495 to the LinuxBIOS source repository and caused the following changes: Change Log: Add an include file which contains the register definitions for the Intel 440BX northbridge (Closes #39). Signed-off-by: Uwe Hermann Acked-by: Richard Smith Build Log: Configuration of agami:aruma has been broken Configuration of amd:quartet has been broken Configuration of amd:rumba has been broken Configuration of amd:serenade has been broken Configuration of amd:serengeti_cheetah has been broken Configuration of amd:serengeti_leopard has been broken Configuration of amd:solo has been broken Configuration of arima:hdama has been broken Configuration of artecgroup:dbe61 has been broken Configuration of asus:p2b has been broken Configuration of bitworks:ims has been broken Configuration of broadcom:blast has been broken Configuration of dell:s1850 has been broken Configuration of densitron:dpx114 has been broken Configuration of digitallogic:adl855pc has been broken Configuration of digitallogic:msm800sev has been broken Configuration of eaglelion:5bcm has been broken Configuration of embeddedplanet:ep405pc has been broken Configuration of emulation:qemu-i386 has been broken Configuration of ibm:e325 has been broken Configuration of ibm:e326 has been broken Configuration of intel:jarrell has been broken Configuration of intel:xe7501devkit has been broken Configuration of iwill:dk8_htx has been broken Configuration of iwill:dk8s2 has been broken Configuration of iwill:dk8x has been broken Configuration of lippert:frontrunner has been broken Configuration of motorola:sandpointx3_altimus_mpc7410 has been broken Configuration of msi:ms9185 has been broken Configuration of newisys:khepri has been broken Configuration of olpc:btest has been broken Configuration of olpc:rev_a has been broken Configuration of sunw:ultra40 has been broken Configuration of supermicro:x6dai_g has been broken Configuration of supermicro:x6dhe_g has been broken Configuration of supermicro:x6dhe_g2 has been broken Configuration of supermicro:x6dhr_ig has been broken Configuration of supermicro:x6dhr_ig2 has been broken Configuration of totalimpact:briq has been broken Configuration of tyan:s2735 has been broken Configuration of tyan:s2850 has been broken Configuration of tyan:s2875 has been broken Configuration of tyan:s2880 has been broken Configuration of tyan:s2881 has been broken Configuration of tyan:s2882 has been broken Configuration of tyan:s2885 has been broken Configuration of tyan:s2891 has been broken Configuration of tyan:s2892 has been broken Configuration of tyan:s2895 has been broken Configuration of tyan:s4880 has been broken Configuration of tyan:s4882 has been broken Configuration of via:epia has been broken 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 will be backed out. Yours truely, LinuxBIOS automatic build system From stepan at coresystems.de Fri Nov 10 10:11:57 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 10 Nov 2006 10:11:57 +0100 Subject: [LinuxBIOS] r2495 build service In-Reply-To: References: Message-ID: <20061110091157.GA12174@coresystems.de> My fault, I changed the build system. I am fixing it. * LinuxBIOS information [061110 10:07]: > Dear LinuxBIOS readers! > > This is the automated build check service of LinuxBIOS. > > The developer "uwe" checked in revision 2495 to > the LinuxBIOS source repository and caused the following > changes: > > Change Log: > Add an include file which contains the register definitions for the > Intel 440BX northbridge (Closes #39). > > Signed-off-by: Uwe Hermann > Acked-by: Richard Smith > > > > Build Log: > Configuration of agami:aruma has been broken > Configuration of amd:quartet has been broken > Configuration of amd:rumba has been broken > Configuration of amd:serenade has been broken > Configuration of amd:serengeti_cheetah has been broken > Configuration of amd:serengeti_leopard has been broken > Configuration of amd:solo has been broken > Configuration of arima:hdama has been broken > Configuration of artecgroup:dbe61 has been broken > Configuration of asus:p2b has been broken > Configuration of bitworks:ims has been broken > Configuration of broadcom:blast has been broken > Configuration of dell:s1850 has been broken > Configuration of densitron:dpx114 has been broken > Configuration of digitallogic:adl855pc has been broken > Configuration of digitallogic:msm800sev has been broken > Configuration of eaglelion:5bcm has been broken > Configuration of embeddedplanet:ep405pc has been broken > Configuration of emulation:qemu-i386 has been broken > Configuration of ibm:e325 has been broken > Configuration of ibm:e326 has been broken > Configuration of intel:jarrell has been broken > Configuration of intel:xe7501devkit has been broken > Configuration of iwill:dk8_htx has been broken > Configuration of iwill:dk8s2 has been broken > Configuration of iwill:dk8x has been broken > Configuration of lippert:frontrunner has been broken > Configuration of motorola:sandpointx3_altimus_mpc7410 has been broken > Configuration of msi:ms9185 has been broken > Configuration of newisys:khepri has been broken > Configuration of olpc:btest has been broken > Configuration of olpc:rev_a has been broken > Configuration of sunw:ultra40 has been broken > Configuration of supermicro:x6dai_g has been broken > Configuration of supermicro:x6dhe_g has been broken > Configuration of supermicro:x6dhe_g2 has been broken > Configuration of supermicro:x6dhr_ig has been broken > Configuration of supermicro:x6dhr_ig2 has been broken > Configuration of totalimpact:briq has been broken > Configuration of tyan:s2735 has been broken > Configuration of tyan:s2850 has been broken > Configuration of tyan:s2875 has been broken > Configuration of tyan:s2880 has been broken > Configuration of tyan:s2881 has been broken > Configuration of tyan:s2882 has been broken > Configuration of tyan:s2885 has been broken > Configuration of tyan:s2891 has been broken > Configuration of tyan:s2892 has been broken > Configuration of tyan:s2895 has been broken > Configuration of tyan:s4880 has been broken > Configuration of tyan:s4882 has been broken > Configuration of via:epia has been broken > > > 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 will > be backed out. > > Yours truely, > LinuxBIOS automatic build system > > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.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/ From svn at openbios.org Fri Nov 10 10:15:29 2006 From: svn at openbios.org (LinuxBIOS) Date: Fri, 10 Nov 2006 09:15:29 -0000 Subject: [LinuxBIOS] #38: Improved spd.h In-Reply-To: <060.d65e12e7bbf3fa2c00ba97d4a94d5a7e@openbios.org> References: <060.d65e12e7bbf3fa2c00ba97d4a94d5a7e@openbios.org> Message-ID: <069.dc74ad61d05dc50ae9466c81cac146da@openbios.org> #38: Improved spd.h -----------------------------------+---------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: assigned Priority: major | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: patch needs review | -----------------------------------+---------------------------------------- Comment (by uwe): Can I commit this, or does it need another Ack? -- Ticket URL: LinuxBIOS From info at coresystems.de Fri Nov 10 11:04:38 2006 From: info at coresystems.de (LinuxBIOS information) Date: Fri, 10 Nov 2006 11:04:38 +0100 Subject: [LinuxBIOS] r2495 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2495 to the LinuxBIOS source repository and caused the following changes: Change Log: Add an include file which contains the register definitions for the Intel 440BX northbridge (Closes #39). Signed-off-by: Uwe Hermann Acked-by: Richard Smith Build Log: Compilation of amd:rumba has been broken Compilation of artecgroup:dbe61 has been broken Compilation of asus:p2b has been broken Compilation of bitworks:ims has been broken Compilation of dell:s1850 has been broken Compilation of densitron:dpx114 has been broken Compilation of digitallogic:adl855pc has been broken Compilation of digitallogic:msm800sev has been broken Compilation of eaglelion:5bcm has been broken Compilation of intel:jarrell has been broken Compilation of intel:xe7501devkit has been broken Compilation of iwill:dk8x has been broken Compilation of lippert:frontrunner has been broken Compilation of olpc:btest has been broken Compilation of olpc:rev_a has been broken Compilation of supermicro:x6dai_g has been broken Compilation of supermicro:x6dhe_g has been broken Compilation of supermicro:x6dhe_g2 has been broken Compilation of supermicro:x6dhr_ig has been broken Compilation of supermicro:x6dhr_ig2 has been broken Compilation of tyan:s2735 has been broken Compilation of via:epia has been 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 will be backed out. Yours truely, LinuxBIOS automatic build system From a1426z at gawab.com Fri Nov 10 12:10:32 2006 From: a1426z at gawab.com (Al Boldi) Date: Fri, 10 Nov 2006 14:10:32 +0300 Subject: [LinuxBIOS] Via epia-m2 difficulties In-Reply-To: <17cbe10f0611091932v4e341605u5bd70875415b992c@mail.gmail.com> References: <17cbe10f0611091932v4e341605u5bd70875415b992c@mail.gmail.com> Message-ID: <200611101410.32452.a1426z@gawab.com> Kurt Andr? Selbach wrote: > Thanks, for the answers, i managed to get the vgabios running when i > inserted the extracted vgabios (from awardeco) and inserted it with > the dd command. > > My next problem is trying to boot from my usb device using FILO version > 0.5 from this "link" svn://openbios.org/filo/trunk/filo-0.5 > > "FILO version 0.5 (root at powertron) Fri Nov 10 02:05:10 CET 2006 > Press for default boot, or for boot prompt... 1mlinuz > root=/dev/sda1 console=tty0 console=ttyS0nd UHCI at 1800 > uhc_reset: Resetting UHCI > uhc_init: uhc_init setting framelist to: 1decb9f0 > uhc_start: Starting UHCI > dump_uhci: HCI at 00001800 > uhc_init: Found UHCI at 1820 > uhc_reset: Resetting UHCI" > > The computer now "hangs" no boot nothing. > > Using the filo from ehterboot, it get's to the "LinuxLabs USB > bootloader" and that's as far as it goes. > > Stock award bios managed to boot from this usbstick, > What could be wrong, any suggestions?! yhlu once pointed me to this http://www.linuxbios.org/index.php/Etherboot Thanks! -- Al From a1426z at gawab.com Fri Nov 10 12:10:50 2006 From: a1426z at gawab.com (Al Boldi) Date: Fri, 10 Nov 2006 14:10:50 +0300 Subject: [LinuxBIOS] Advice for buying a new and not-obsolete workstation? In-Reply-To: <2285a9d20611091710u57215e75he5f1df90ff97b5e4@mail.gmail.com> References: <2285a9d20611090314l4fee8e64g6691ff51f40afb92@mail.gmail.com> <4553CEB9.2050704@gmail.com> <2285a9d20611091710u57215e75he5f1df90ff97b5e4@mail.gmail.com> Message-ID: <200611101410.50826.a1426z@gawab.com> Dave Crossland wrote: > On 10/11/06, Richard Smith wrote: > > Sorry bad choice of words on my part.. I meant not fully open source and > > not totally free of binary cruft. > > > > http://marc.theaimsgroup.com/?l=linux-kernel&m=115536806403908&w=2 > > Ouch. When he says, "The driver remains completely functional in the > absense of the binary piece", surely some functionality is missing - > what is this? I don't understand enough (yet) to know from that post It means that you get basic access to the device w/o being able to take advantage of the more advanced features. Probably due to them subcontracting a third-party to do the advanced stuff. Thanks! -- Al From ward at pong.be Fri Nov 10 14:01:48 2006 From: ward at pong.be (Ward Vandewege) Date: Fri, 10 Nov 2006 08:01:48 -0500 Subject: [LinuxBIOS] i440bx In-Reply-To: <1163137682.30157.10.camel@ampfs.soundroom> References: <1163137682.30157.10.camel@ampfs.soundroom> Message-ID: <20061110130148.GA6560@countzero.vandewege.net> On Fri, Nov 10, 2006 at 12:48:02AM -0500, Corey wrote: > BTW (if anyone cares), I have changed my email address (needed one that > would let me use a real mail program), this is my new one. For the record - you'll probably have problems receiving e-mail (from non-US mailservers). Verizon's e-mail servers are pretty much the worst ones out there; they've decided to blacklist half the internet on multiple (http://www.theinquirer.net/default.aspx?article=21095) occasions (http://arstechnica.com/news.ars/post/20050122-4546.html). My advice: if you actually want to receive e-mail, stay clear of Verizon and their overzealous spam filtering. Open a Gmail account if you want a free POP3 account. Odds are you will get this message through the list, but probably not the copy I sent you seperately. Good luck! Ward. -- Pong.be -( Linux: Your Brain - Windows: Your brain on drugs )- Virtual hosting -( )- http://pong.be -( )- GnuPG public key: http://gpg.dtype.org From ward at gnu.org Fri Nov 10 14:05:20 2006 From: ward at gnu.org (Ward Vandewege) Date: Fri, 10 Nov 2006 08:05:20 -0500 Subject: [LinuxBIOS] Advice for buying a new and not-obsolete workstation? In-Reply-To: <200611101410.50826.a1426z@gawab.com> References: <2285a9d20611090314l4fee8e64g6691ff51f40afb92@mail.gmail.com> <4553CEB9.2050704@gmail.com> <2285a9d20611091710u57215e75he5f1df90ff97b5e4@mail.gmail.com> <200611101410.50826.a1426z@gawab.com> Message-ID: <20061110130520.GC6560@countzero.vandewege.net> On Fri, Nov 10, 2006 at 02:10:50PM +0300, Al Boldi wrote: > Dave Crossland wrote: > > On 10/11/06, Richard Smith wrote: > > > Sorry bad choice of words on my part.. I meant not fully open source and > > > not totally free of binary cruft. > > > > > > http://marc.theaimsgroup.com/?l=linux-kernel&m=115536806403908&w=2 > > > > Ouch. When he says, "The driver remains completely functional in the > > absense of the binary piece", surely some functionality is missing - > > what is this? I don't understand enough (yet) to know from that post > > It means that you get basic access to the device w/o being able to take > advantage of the more advanced features. Probably due to them > subcontracting a third-party to do the advanced stuff. Anyone know what exactly the advanced stuff is? Thanks, Ward. From svn at openbios.org Fri Nov 10 14:30:32 2006 From: svn at openbios.org (svn at openbios.org) Date: Fri, 10 Nov 2006 13:30:32 -0000 Subject: [LinuxBIOS] r2496 - in trunk/LinuxBIOSv2: src/mainboard/agami/aruma src/mainboard/amd/quartet src/mainboard/amd/rumba src/mainboard/amd/serenade src/mainboard/amd/serengeti_cheetah src/mainboard/amd/serengeti_leopard src/mainboard/amd/solo src/mainboard/arima/hdama src/mainboard/artecgroup/dbe61 src/mainboard/asus/p2b src/mainboard/bitworks/ims src/mainboard/broadcom/blast src/mainboard/dell/s1850 src/mainboard/densitron/dpx114 src/mainboard/digitallogic/adl855pc src/mainboard/digitallogic/msm586seg src/mainboard/digitallogic/msm800sev src/mainboard/eaglelion/5bcm src/mainboard/embeddedplanet/ep405pc src/mainboard/ibm/e325 src/mainboard/ibm/e326 src/mainboard/intel/jarrell src/mainboard/intel/xe7501devkit src/mainboard/iwill/dk8_htx src/mainboard/iwill/dk8s2 src/mainboard/iwill/dk8x src/mainboard/lippert/frontrunner src/mainboard/motorola/sandpointx3_altimus_mpc7410 src/mainboard/msi/ms9185 src/mainboard/newisys/khepri src/mainboard/sunw/ultra40 src/mainboard/supermicro/x6dai_g src/mainboard/supermicro/x6dhe_g src/mainboard/supermicro/x6dhe_g2 src/mainboard/supermicro/x6dhr_ig src/mainboard/supermicro/x6dhr_ig2 src/mainboard/technologic/ts5300 src/mainboard/totalimpact/briq src/mainboard/tyan/s2735 src/mainboard/tyan/s2850 src/mainboard/tyan/s2875 src/mainboard/tyan/s2880 src/mainboard/tyan/s2881 src/mainboard/tyan/s2882 src/mainboard/tyan/s2885 src/mainboard/tyan/s2891 src/mainboard/tyan/s2892 src/mainboard/tyan/s2895 src/mainboard/tyan/s4880 src/mainboard/tyan/s4882 src/mainboard/via/epia src/mainboard/via/epia-m targets/amd/quartet targets/amd/serengeti_cheetah targets/arima/hdama targets/digitallogic/msm586seg targets/emulation/qemu-i386 targets/ibm targets/ibm/e326 targets/technologic/ts5300 targets/via/epia-m util/abuild Message-ID: Author: stepan Date: 2006-11-10 14:30:28 +0100 (Fri, 10 Nov 2006) New Revision: 2496 Added: trunk/LinuxBIOSv2/targets/amd/quartet/Config-abuild.lb trunk/LinuxBIOSv2/targets/amd/serengeti_cheetah/Config-abuild.lb trunk/LinuxBIOSv2/targets/arima/hdama/Config-abuild.lb trunk/LinuxBIOSv2/targets/ibm/e326/ trunk/LinuxBIOSv2/targets/ibm/e326/Config-abuild.lb Modified: trunk/LinuxBIOSv2/src/mainboard/agami/aruma/Options.lb trunk/LinuxBIOSv2/src/mainboard/amd/quartet/Options.lb trunk/LinuxBIOSv2/src/mainboard/amd/rumba/Options.lb trunk/LinuxBIOSv2/src/mainboard/amd/serenade/Options.lb trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/Options.lb trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/Options.lb trunk/LinuxBIOSv2/src/mainboard/amd/solo/Options.lb trunk/LinuxBIOSv2/src/mainboard/arima/hdama/Options.lb trunk/LinuxBIOSv2/src/mainboard/artecgroup/dbe61/Options.lb trunk/LinuxBIOSv2/src/mainboard/asus/p2b/Options.lb trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/Options.lb trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/Options.lb trunk/LinuxBIOSv2/src/mainboard/dell/s1850/Options.lb trunk/LinuxBIOSv2/src/mainboard/densitron/dpx114/Options.lb trunk/LinuxBIOSv2/src/mainboard/digitallogic/adl855pc/Options.lb trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm586seg/Options.lb trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm800sev/Options.lb trunk/LinuxBIOSv2/src/mainboard/eaglelion/5bcm/Options.lb trunk/LinuxBIOSv2/src/mainboard/embeddedplanet/ep405pc/Options.lb trunk/LinuxBIOSv2/src/mainboard/ibm/e325/Options.lb trunk/LinuxBIOSv2/src/mainboard/ibm/e326/Options.lb trunk/LinuxBIOSv2/src/mainboard/intel/jarrell/Options.lb trunk/LinuxBIOSv2/src/mainboard/intel/xe7501devkit/Options.lb trunk/LinuxBIOSv2/src/mainboard/iwill/dk8_htx/Options.lb trunk/LinuxBIOSv2/src/mainboard/iwill/dk8s2/Options.lb trunk/LinuxBIOSv2/src/mainboard/iwill/dk8x/Options.lb trunk/LinuxBIOSv2/src/mainboard/lippert/frontrunner/Options.lb trunk/LinuxBIOSv2/src/mainboard/motorola/sandpointx3_altimus_mpc7410/Options.lb trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/Options.lb trunk/LinuxBIOSv2/src/mainboard/newisys/khepri/Options.lb trunk/LinuxBIOSv2/src/mainboard/sunw/ultra40/Options.lb trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dai_g/Options.lb trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g/Options.lb trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g2/Options.lb trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig/Options.lb trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig2/Options.lb trunk/LinuxBIOSv2/src/mainboard/technologic/ts5300/Options.lb trunk/LinuxBIOSv2/src/mainboard/totalimpact/briq/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2735/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2850/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2875/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2880/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2881/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2882/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2885/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2891/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2892/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s2895/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s4880/Options.lb trunk/LinuxBIOSv2/src/mainboard/tyan/s4882/Options.lb trunk/LinuxBIOSv2/src/mainboard/via/epia-m/Options.lb trunk/LinuxBIOSv2/src/mainboard/via/epia/Options.lb trunk/LinuxBIOSv2/targets/digitallogic/msm586seg/Config-abuild.lb trunk/LinuxBIOSv2/targets/emulation/qemu-i386/Config-abuild.lb trunk/LinuxBIOSv2/targets/technologic/ts5300/Config-abuild.lb trunk/LinuxBIOSv2/targets/via/epia-m/Config-abuild.lb trunk/LinuxBIOSv2/util/abuild/abuild Log: * fix the automatic build system by compressing payloads if possible and leaving enough room for a real payload (not /dev/null) This is a wonderful example why "uses" sucks. * add Config-abuild.lb for those boards that dont build with the default settings and a real payload: arima/hdama, amd/quartet, amd/serengeti_cheetah, ibm/e326 * if lzma is installed and a real payload is used, try compressing it. * fix a small bug in "abuild --help" This patch is acked by me because its due to infrastructural changes only. Flames welcome. Signed-off-by: Stefan Reinauer Acked-by: Stefan Reinauer Modified: trunk/LinuxBIOSv2/src/mainboard/agami/aruma/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/agami/aruma/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/agami/aruma/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -20,6 +20,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/amd/quartet/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/quartet/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/amd/quartet/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -17,6 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/amd/rumba/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/rumba/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/amd/rumba/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -21,7 +21,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_NRV2B +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/amd/serenade/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/serenade/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/amd/serenade/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -17,6 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_cheetah/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -23,7 +23,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE @@ -267,8 +267,6 @@ ## default CONFIG_ROM_STREAM = 1 -#default CONFIG_COMPRESSED_ROM_STREAM = 1 - ### ### Defaults of options that you may want to override in the target config file ### Modified: trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/amd/serengeti_leopard/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -23,6 +23,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/amd/solo/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/amd/solo/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/amd/solo/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -18,6 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/arima/hdama/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/arima/hdama/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/arima/hdama/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -17,6 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/artecgroup/dbe61/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/artecgroup/dbe61/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/artecgroup/dbe61/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -21,7 +21,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_NRV2B +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/asus/p2b/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/asus/p2b/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/asus/p2b/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -21,6 +21,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/bitworks/ims/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -21,6 +21,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/broadcom/blast/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -19,6 +19,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/dell/s1850/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/dell/s1850/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/dell/s1850/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -17,6 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/densitron/dpx114/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/densitron/dpx114/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/densitron/dpx114/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -21,6 +21,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/digitallogic/adl855pc/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/digitallogic/adl855pc/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/digitallogic/adl855pc/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -22,6 +22,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm586seg/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm586seg/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm586seg/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -23,6 +23,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm800sev/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm800sev/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm800sev/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -21,7 +21,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_NRV2B +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/eaglelion/5bcm/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/eaglelion/5bcm/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/eaglelion/5bcm/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -21,6 +21,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/embeddedplanet/ep405pc/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/embeddedplanet/ep405pc/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/embeddedplanet/ep405pc/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -24,6 +24,7 @@ uses CONFIG_FS_EXT2 uses CONFIG_FS_ISO9660 uses CONFIG_FS_FAT +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses AUTOBOOT_CMDLINE uses CONFIG_SYS_CLK_FREQ uses IDE_BOOT_DRIVE Modified: trunk/LinuxBIOSv2/src/mainboard/ibm/e325/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/ibm/e325/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/ibm/e325/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -17,6 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/ibm/e326/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/ibm/e326/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/ibm/e326/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -17,6 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/intel/jarrell/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/intel/jarrell/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/intel/jarrell/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -17,6 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/intel/xe7501devkit/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/intel/xe7501devkit/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/intel/xe7501devkit/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -10,6 +10,7 @@ uses CONFIG_IOAPIC uses CONFIG_SMP uses CONFIG_ROM_STREAM +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses STACK_SIZE uses HEAP_SIZE uses USE_OPTION_TABLE Modified: trunk/LinuxBIOSv2/src/mainboard/iwill/dk8_htx/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/iwill/dk8_htx/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/iwill/dk8_htx/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -23,7 +23,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE @@ -266,8 +266,6 @@ ## default CONFIG_ROM_STREAM = 1 -#default CONFIG_COMPRESSED_ROM_STREAM = 1 - ### ### Defaults of options that you may want to override in the target config file ### Modified: trunk/LinuxBIOSv2/src/mainboard/iwill/dk8s2/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/iwill/dk8s2/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/iwill/dk8s2/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -17,6 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/iwill/dk8x/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/iwill/dk8x/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/iwill/dk8x/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -17,6 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/lippert/frontrunner/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/lippert/frontrunner/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/lippert/frontrunner/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -21,6 +21,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/motorola/sandpointx3_altimus_mpc7410/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/motorola/sandpointx3_altimus_mpc7410/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/motorola/sandpointx3_altimus_mpc7410/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -21,6 +21,7 @@ uses CONFIG_FS_EXT2 uses CONFIG_FS_ISO9660 uses CONFIG_FS_FAT +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses AUTOBOOT_CMDLINE uses PAYLOAD_SIZE uses ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/msi/ms9185/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -44,6 +44,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/newisys/khepri/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/newisys/khepri/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/newisys/khepri/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -17,6 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/sunw/ultra40/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/sunw/ultra40/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/sunw/ultra40/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -18,6 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dai_g/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dai_g/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dai_g/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -17,6 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -17,6 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g2/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g2/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhe_g2/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -17,6 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -17,6 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig2/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig2/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/supermicro/x6dhr_ig2/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -17,6 +17,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/technologic/ts5300/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/technologic/ts5300/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/technologic/ts5300/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -6,7 +6,6 @@ uses HAVE_OPTION_TABLE uses USE_OPTION_TABLE uses CONFIG_COMPRESS -uses CONFIG_COMPRESSED_ROM_STREAM_NRV2B uses CONFIG_ROM_STREAM uses CONFIG_USE_INIT uses IRQ_SLOT_COUNT @@ -24,6 +23,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE @@ -134,7 +134,6 @@ default _RAMBASE = 0x00004000 -default CONFIG_COMPRESSED_ROM_STREAM_NRV2B = 1 default CONFIG_ROM_STREAM = 1 ## Modified: trunk/LinuxBIOSv2/src/mainboard/totalimpact/briq/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/totalimpact/briq/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/totalimpact/briq/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -19,6 +19,7 @@ uses NO_POST uses CONFIG_CONSOLE_SERIAL8250 uses CONFIG_IDE_STREAM +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses IDE_BOOT_DRIVE uses IDE_SWAB IDE_OFFSET uses ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2735/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2735/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2735/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -19,6 +19,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2850/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2850/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2850/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -18,6 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2875/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2875/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2875/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -18,6 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2880/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2880/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2880/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -18,6 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2881/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2881/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2881/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -18,6 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2882/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2882/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2882/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -18,6 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2885/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2885/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2885/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -18,6 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2891/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2891/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2891/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -18,6 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2892/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2892/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2892/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -18,6 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s2895/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s2895/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s2895/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -21,6 +21,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s4880/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s4880/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s4880/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -18,6 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s4882/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/tyan/s4882/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/tyan/s4882/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -18,6 +18,7 @@ uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses XIP_ROM_SIZE Modified: trunk/LinuxBIOSv2/src/mainboard/via/epia/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/via/epia/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/via/epia/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -29,6 +29,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Modified: trunk/LinuxBIOSv2/src/mainboard/via/epia-m/Options.lb =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/via/epia-m/Options.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/src/mainboard/via/epia-m/Options.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -21,7 +21,7 @@ uses ROM_SECTION_SIZE uses ROM_SECTION_OFFSET uses CONFIG_ROM_STREAM_START -uses CONFIG_COMPRESSED_ROM_STREAM_NRV2B +uses CONFIG_COMPRESSED_ROM_STREAM_LZMA uses PAYLOAD_SIZE uses _ROMBASE uses _RAMBASE Added: trunk/LinuxBIOSv2/targets/amd/quartet/Config-abuild.lb =================================================================== --- trunk/LinuxBIOSv2/targets/amd/quartet/Config-abuild.lb (rev 0) +++ trunk/LinuxBIOSv2/targets/amd/quartet/Config-abuild.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -0,0 +1,28 @@ +# This will make a target directory of ./VENDOR_MAINBOARD + +target VENDOR_MAINBOARD +mainboard VENDOR/MAINBOARD + +option CC="CROSSCC" +option CROSS_COMPILE="CROSS_PREFIX" +option HOSTCC="CROSS_HOSTCC" + +__COMPRESSION__ + +option ROM_SIZE=512*1024 + + +romimage "normal" + option USE_FALLBACK_IMAGE=0 + option ROM_IMAGE_SIZE=0x20000 + option LINUXBIOS_EXTRA_VERSION=".0-normal" + payload PAYLOAD +end + +romimage "fallback" + option USE_FALLBACK_IMAGE=1 + option ROM_IMAGE_SIZE=0x20000 + option LINUXBIOS_EXTRA_VERSION=".0-fallback" + payload PAYLOAD +end +buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" Added: trunk/LinuxBIOSv2/targets/amd/serengeti_cheetah/Config-abuild.lb =================================================================== --- trunk/LinuxBIOSv2/targets/amd/serengeti_cheetah/Config-abuild.lb (rev 0) +++ trunk/LinuxBIOSv2/targets/amd/serengeti_cheetah/Config-abuild.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -0,0 +1,27 @@ +# This will make a target directory of ./VENDOR_MAINBOARD + +target VENDOR_MAINBOARD +mainboard VENDOR/MAINBOARD + +option CC="CROSSCC" +option CROSS_COMPILE="CROSS_PREFIX" +option HOSTCC="CROSS_HOSTCC" + +__COMPRESSION__ + +option ROM_SIZE=512*1024 + +romimage "normal" + option USE_FALLBACK_IMAGE=0 + option ROM_IMAGE_SIZE=0x20000 + option LINUXBIOS_EXTRA_VERSION=".0-normal" + payload PAYLOAD +end + +romimage "fallback" + option USE_FALLBACK_IMAGE=1 + option ROM_IMAGE_SIZE=0x20000 + option LINUXBIOS_EXTRA_VERSION=".0-fallback" + payload PAYLOAD +end +buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" Added: trunk/LinuxBIOSv2/targets/arima/hdama/Config-abuild.lb =================================================================== --- trunk/LinuxBIOSv2/targets/arima/hdama/Config-abuild.lb (rev 0) +++ trunk/LinuxBIOSv2/targets/arima/hdama/Config-abuild.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -0,0 +1,27 @@ +# This will make a target directory of ./VENDOR_MAINBOARD + +target VENDOR_MAINBOARD +mainboard VENDOR/MAINBOARD + +option CC="CROSSCC" +option CROSS_COMPILE="CROSS_PREFIX" +option HOSTCC="CROSS_HOSTCC" + +__COMPRESSION__ + +option ROM_SIZE=512*1024 + +romimage "normal" + option USE_FALLBACK_IMAGE=0 + option ROM_IMAGE_SIZE=0x20000 + option LINUXBIOS_EXTRA_VERSION=".0-normal" + payload PAYLOAD +end + +romimage "fallback" + option USE_FALLBACK_IMAGE=1 + option ROM_IMAGE_SIZE=0x20000 + option LINUXBIOS_EXTRA_VERSION=".0-fallback" + payload PAYLOAD +end +buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" Modified: trunk/LinuxBIOSv2/targets/digitallogic/msm586seg/Config-abuild.lb =================================================================== --- trunk/LinuxBIOSv2/targets/digitallogic/msm586seg/Config-abuild.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/targets/digitallogic/msm586seg/Config-abuild.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -7,15 +7,10 @@ option MAXIMUM_CONSOLE_LOGLEVEL=10 option CONFIG_COMPRESS=0 +__COMPRESSION__ + option CONFIG_CONSOLE_VGA=1 -#romimage "normal" -# option USE_FALLBACK_IMAGE=0 -# option ROM_IMAGE_SIZE=0x10000 -# option LINUXBIOS_EXTRA_VERSION=".0Normal" -# payload /etc/hosts -#end - romimage "fallback" option FALLBACK_SIZE = 256 * 1024 # option ROM_SIZE=512*1024 @@ -25,7 +20,7 @@ option ROM_IMAGE_SIZE=128 * 1024 # 0x10000 # option ROM_IMAGE_SIZE=512 * 1024 # 0x10000 option LINUXBIOS_EXTRA_VERSION=".0Fallback" - payload /dev/null + payload PAYLOAD end buildrom ./linuxbios.rom ROM_SIZE "fallback" Modified: trunk/LinuxBIOSv2/targets/emulation/qemu-i386/Config-abuild.lb =================================================================== --- trunk/LinuxBIOSv2/targets/emulation/qemu-i386/Config-abuild.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/targets/emulation/qemu-i386/Config-abuild.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -3,6 +3,8 @@ target emulation_qemu-i386 mainboard emulation/qemu-i386 +__COMPRESSION__ + option ROM_SIZE=256*1024 option CC="gcc -m32" Added: trunk/LinuxBIOSv2/targets/ibm/e326/Config-abuild.lb =================================================================== --- trunk/LinuxBIOSv2/targets/ibm/e326/Config-abuild.lb (rev 0) +++ trunk/LinuxBIOSv2/targets/ibm/e326/Config-abuild.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -0,0 +1,27 @@ +# This will make a target directory of ./VENDOR_MAINBOARD + +target VENDOR_MAINBOARD +mainboard VENDOR/MAINBOARD + +option CC="CROSSCC" +option CROSS_COMPILE="CROSS_PREFIX" +option HOSTCC="CROSS_HOSTCC" + +__COMPRESSION__ + +option ROM_SIZE=512*1024 + +romimage "normal" + option USE_FALLBACK_IMAGE=0 + option ROM_IMAGE_SIZE=0x20000 + option LINUXBIOS_EXTRA_VERSION=".0-normal" + payload PAYLOAD +end + +romimage "fallback" + option USE_FALLBACK_IMAGE=1 + option ROM_IMAGE_SIZE=0x20000 + option LINUXBIOS_EXTRA_VERSION=".0-fallback" + payload PAYLOAD +end +buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" Modified: trunk/LinuxBIOSv2/targets/technologic/ts5300/Config-abuild.lb =================================================================== --- trunk/LinuxBIOSv2/targets/technologic/ts5300/Config-abuild.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/targets/technologic/ts5300/Config-abuild.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -1,21 +1,14 @@ target technologic_ts5300 mainboard technologic/ts5300 - - option DEFAULT_CONSOLE_LOGLEVEL=10 option MAXIMUM_CONSOLE_LOGLEVEL=10 option CONFIG_COMPRESS=0 +__COMPRESSION__ + option CONFIG_CONSOLE_VGA=1 -#romimage "normal" -# option USE_FALLBACK_IMAGE=0 -# option ROM_IMAGE_SIZE=0x10000 -# option LINUXBIOS_EXTRA_VERSION=".0Normal" -# payload /etc/hosts -#end - romimage "fallback" option FALLBACK_SIZE = 256 * 1024 # option ROM_SIZE=512*1024 @@ -23,9 +16,8 @@ option USE_FALLBACK_IMAGE=1 # option ROM_IMAGE_SIZE=32 * 1024 # 0x8000 option ROM_IMAGE_SIZE=128 * 1024 # 0x10000 -# option ROM_IMAGE_SIZE=512 * 1024 # 0x10000 option LINUXBIOS_EXTRA_VERSION=".0Fallback" - payload /dev/null + payload PAYLOAD end buildrom ./linuxbios.rom ROM_SIZE "fallback" Modified: trunk/LinuxBIOSv2/targets/via/epia-m/Config-abuild.lb =================================================================== --- trunk/LinuxBIOSv2/targets/via/epia-m/Config-abuild.lb 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/targets/via/epia-m/Config-abuild.lb 2006-11-10 13:30:28 UTC (rev 2496) @@ -7,6 +7,8 @@ option DEFAULT_CONSOLE_LOGLEVEL=8 option CONFIG_CONSOLE_SERIAL8250=1 +__COMPRESSION__ + option ROM_SIZE=256*1024 option HAVE_OPTION_TABLE=1 Modified: trunk/LinuxBIOSv2/util/abuild/abuild =================================================================== --- trunk/LinuxBIOSv2/util/abuild/abuild 2006-11-10 09:04:12 UTC (rev 2495) +++ trunk/LinuxBIOSv2/util/abuild/abuild 2006-11-10 13:30:28 UTC (rev 2496) @@ -105,10 +105,14 @@ TARGCONFIG=$LBROOT/targets/$VENDOR/$MAINBOARD/Config-abuild.lb # get a working payload for the board if we have one. + # the --payload option expects a directory containing + # an executable shell script payload.sh + # Usage: payload.sh [VENDOR] [DEVICE] + # the script returns an absolute path to the payload binary. if [ -x $payloads/payload.sh ]; then PAYLOAD=`$payloads/payload.sh $VENDOR $MAINBOARD` - printf "Using custom payload $PAYLOAD\n" + printf "Using payload $PAYLOAD\n" fi mkdir -p $TARGET @@ -131,19 +135,21 @@ option CROSS_COMPILE="CROSS_PREFIX" option HOSTCC="CROSS_HOSTCC" +__COMPRESSION__ + EOF if [ "$TARCH" == i386 ] ; then cat < $TARGET/Config-${VENDOR}_${MAINBOARD}.lb fi + if [ "`which lzma`" != "" -a "$PAYLOAD" != /dev/null ]; then + COMPRESSION="option CONFIG_COMPRESSED_ROM_STREAM_LZMA=1" + else + COMPRESSION="# no compression" + fi + sed -i.pre -e s,VENDOR,$VENDOR,g \ -e s,MAINBOARD,$MAINBOARD,g \ -e s,payload\ PAYLOAD,payload\ $PAYLOAD,g \ -e s,CROSSCC,"$CC",g \ -e s,CROSS_PREFIX,"$CROSS_COMPILE",g \ -e s,CROSS_HOSTCC,"$HOSTCC",g \ + -e s,__COMPRESSION__,"$COMPRESSION",g \ $TARGET/Config-${VENDOR}_${MAINBOARD}.lb - printf " ok\n" } @@ -422,8 +434,8 @@ { printf "Usage: $0 [-v] [-a] [-b] [-t ] [-p ] [lbroot]\n" printf " $0 [-V|--version]\n" - printf " $0 [-h|--help]\n" - printf + printf " $0 [-h|--help]\n\n" + printf "Options:\n" printf " [-v|--verbose] print more messages\n" printf " [-a|--all] build previously succeeded ports as well\n" From stepan at coresystems.de Fri Nov 10 14:46:18 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 10 Nov 2006 14:46:18 +0100 Subject: [LinuxBIOS] Advice for buying a new and not-obsolete workstation? In-Reply-To: <20061110130520.GC6560@countzero.vandewege.net> References: <2285a9d20611090314l4fee8e64g6691ff51f40afb92@mail.gmail.com> <4553CEB9.2050704@gmail.com> <2285a9d20611091710u57215e75he5f1df90ff97b5e4@mail.gmail.com> <200611101410.50826.a1426z@gawab.com> <20061110130520.GC6560@countzero.vandewege.net> Message-ID: <20061110134618.GA2785@coresystems.de> * Ward Vandewege [061110 14:05]: > > It means that you get basic access to the device w/o being able to take > > advantage of the more advanced features. Probably due to them > > subcontracting a third-party to do the advanced stuff. > > Anyone know what exactly the advanced stuff is? Macrovision registers. That's DRM. And "other trade secrets" -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From segher at kernel.crashing.org Fri Nov 10 14:51:09 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Fri, 10 Nov 2006 14:51:09 +0100 Subject: [LinuxBIOS] Advice for buying a new and not-obsolete workstation? In-Reply-To: <20061110130520.GC6560@countzero.vandewege.net> References: <2285a9d20611090314l4fee8e64g6691ff51f40afb92@mail.gmail.com> <4553CEB9.2050704@gmail.com> <2285a9d20611091710u57215e75he5f1df90ff97b5e4@mail.gmail.com> <200611101410.50826.a1426z@gawab.com> <20061110130520.GC6560@countzero.vandewege.net> Message-ID: <784A2B80-C093-48B8-9365-F2BC1A5A86EE@kernel.crashing.org> >>> Ouch. When he says, "The driver remains completely functional in the >>> absense of the binary piece", surely some functionality is missing - >>> what is this? I don't understand enough (yet) to know from that post >> >> It means that you get basic access to the device w/o being able to >> take >> advantage of the more advanced features. Probably due to them >> subcontracting a third-party to do the advanced stuff. > > Anyone know what exactly the advanced stuff is? Macrovision DRM amongst others. The Intel drivers also still need a binary BIOS for modesetting, at least on some chips. Segher From info at coresystems.de Fri Nov 10 15:09:34 2006 From: info at coresystems.de (LinuxBIOS information) Date: Fri, 10 Nov 2006 15:09:34 +0100 Subject: [LinuxBIOS] r2496 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "stepan" checked in revision 2496 to the LinuxBIOS source repository and caused the following changes: Change Log: * fix the automatic build system by compressing payloads if possible and leaving enough room for a real payload (not /dev/null) This is a wonderful example why "uses" sucks. * add Config-abuild.lb for those boards that dont build with the default settings and a real payload: arima/hdama, amd/quartet, amd/serengeti_cheetah, ibm/e326 * if lzma is installed and a real payload is used, try compressing it. * fix a small bug in "abuild --help" This patch is acked by me because its due to infrastructural changes only. Flames welcome. Signed-off-by: Stefan Reinauer Acked-by: Stefan Reinauer Build Log: Compilation of amd:rumba has been fixed Compilation of artecgroup:dbe61 has been fixed Compilation of asus:p2b has been fixed Compilation of bitworks:ims has been fixed Compilation of dell:s1850 has been fixed Compilation of densitron:dpx114 has been fixed Compilation of digitallogic:adl855pc has been fixed Compilation of digitallogic:msm800sev has been fixed Compilation of eaglelion:5bcm has been fixed Compilation of intel:jarrell has been fixed Compilation of intel:xe7501devkit has been fixed Compilation of iwill:dk8x has been fixed Compilation of lippert:frontrunner has been fixed Compilation of olpc:btest has been fixed Compilation of olpc:rev_a has been fixed Compilation of supermicro:x6dai_g has been fixed Compilation of supermicro:x6dhe_g has been fixed Compilation of supermicro:x6dhe_g2 has been fixed Compilation of supermicro:x6dhr_ig has been fixed Compilation of supermicro:x6dhr_ig2 has been fixed Compilation of tyan:s2735 has been fixed Compilation of via:epia has been fixed If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision will be backed out. Yours truely, LinuxBIOS automatic build system From dave at lab6.com Fri Nov 10 15:09:44 2006 From: dave at lab6.com (Dave Crossland) Date: Fri, 10 Nov 2006 14:09:44 +0000 Subject: [LinuxBIOS] Advice for buying a new and not-obsolete workstation? In-Reply-To: References: <2285a9d20611090314l4fee8e64g6691ff51f40afb92@mail.gmail.com> <2285a9d20611090710j17e0c0c0sd4916b85f859567d@mail.gmail.com> <4553BD93.6000005@gmail.com> <2285a9d20611091646l33dbde05g89f2fc81b2539c54@mail.gmail.com> <4553CEB9.2050704@gmail.com> <2285a9d20611091710u57215e75he5f1df90ff97b5e4@mail.gmail.com> Message-ID: <2285a9d20611100609t76894607gbbd9e451b6c72c4@mail.gmail.com> On 10/11/06, David H. Barr wrote: > On 11/9/06, Dave Crossland wrote: > > > Ouch. When he says, "The driver remains completely functional in the > > absense of the binary piece", surely some functionality is missing - > > what is this? I don't understand enough (yet) to know from that post > > :-( > > I would guess, since he specifically mentions MacroVision, that it's all > that "protected media" stuff, AKA DRM. Maybe the part that would let an > Intel device authenticate itself as a "trusted" pathway? Okay that makes sense - part of the "High-bandwith Digital Content Protection" stuff I suppose, based on my limited understanding of it from http://fuckbluray.com Not functionality I'm interested in, I suppose, as I'll just rip BlueRay discs to TheoraOGG to watch them anyway :-) > Well, you -did- say workstation, which generally signifies (to > me, at least) dual socket and ECC. Yes, ECC for sure, and dual socket or dualcore is fine. > The MSI Workstation board is definitely NOT > obsolete; I'd go with "not widely available in the UK yet". Okay, that's really what I wanted to hear! :-) > What spec are you looking for? That is to say, what level of machine? I'm basing my ideas of what I want mainly from http://cr.yp.to/hardware/build-20060107.html -- Regards, Dave From stepan at coresystems.de Fri Nov 10 16:33:17 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 10 Nov 2006 16:33:17 +0100 Subject: [LinuxBIOS] r2495 build service In-Reply-To: <20061110091157.GA12174@coresystems.de> References: <20061110091157.GA12174@coresystems.de> Message-ID: <20061110153317.GA12561@coresystems.de> * Stefan Reinauer [061110 10:11]: > My fault, I changed the build system. I am fixing it. 2496 is fine 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 svn at openbios.org Fri Nov 10 18:18:23 2006 From: svn at openbios.org (LinuxBIOS) Date: Fri, 10 Nov 2006 17:18:23 -0000 Subject: [LinuxBIOS] #42: Disable SMM on K8 platforms Message-ID: <060.793f29e02f0920b19d501d68be2a2761@openbios.org> #42: Disable SMM on K8 platforms ----------------------------+----------------------------------------------- Reporter: stepan | Owner: stepan Type: defect | Status: new Priority: major | Milestone: Going mainstream Component: code | Version: v2 Keywords: SMM | Due_close: MM/DD/YYYY Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Patchstatus: there is no patch ----------------------------+----------------------------------------------- This was a while ago, but it got forgotten. Lo?c Duflot, security engineer and researcher for the scientific division of the french Central Directorate for Information Systems Security ("french version of the NSA"), gives some insight on fun that can be had with the system management mode (SMM) of x86 CPUs. See http://www.securityfocus.com/print/columnists/402 for more information. While, as Lo?c writes later in his article, the whole issue of exploiting SMM is pretty pointless in Linux as the super user can conquer ring 0 without further effort, the idea of fixing what we can fix on the bios level seems worthwhile. If something seems as simple as setting the D_LCK bit of SMM, we should definitely do it.. It will at least be a marketable feature against other upcoming firmware implementations. Carl-Daniel Hailfinger said: {{{ I believe that setting D_LCK will mitigate a few attacks but I strongly doubt that it cannot be cleared during system operation. Yes, the manual specifies it, but manuals have been underspecified before. Since we don't use SMM for anything, we might as well * clear D_OPEN * set D_CLOSE * clear "Enable" * set D_LCK. So, by all means, do it now. Until somebody figures out a way to disable D_LCK again we offer a much higher degree of security than everybody else. }}} Ok, D_LCK/D_OPEN/D_CLOSE is intel vocabulary. There is no such thing on AMD. They call it SMMLOCK in their BKDG: 6.11.6 Locking SMM The SMM registers can be locked by setting the SMMLOCK (HWCR, bit 0). Once set, the SMM_BASE, the SMM_ADDR, all but the two close bits of SMM_MASK and the RSMSPCYCDIS, SMISPCYCDIS, and SMMLOCK bits of HWCR are locked and cannot be changed. The only way to unlock the SMM registers is to assert reset. This provides security to the SMM mechanism. The BIOS can lock the SMM environment after setting it up so that it can not be tampered with. So I propose the following patch for LinuxBIOS to fix the SMM problem for all supported AMD K8 mainboards: {{{ Set SMMLOCK on K8 to avoid exploits messing with SMM Signed-off-by: Stefan Reinauer Index: src/cpu/amd/model_fxx/model_fxx_init.c =================================================================== --- src/cpu/amd/model_fxx/model_fxx_init.c (revision 2302) +++ src/cpu/amd/model_fxx/model_fxx_init.c (working copy) @@ -454,6 +454,12 @@ k8_errata(); + /* Set SMMLOCK to avoid exploits messing with SMM */ + msr = rdmsr(HWCR_MSR); + msr.lo |= (1 << 0); + wrmsr(HWCR_MSR, msr); + + enable_cache(); /* Enable the local cpu apics */ }}} -- Ticket URL: LinuxBIOS From svn at openbios.org Fri Nov 10 18:21:58 2006 From: svn at openbios.org (LinuxBIOS) Date: Fri, 10 Nov 2006 17:21:58 -0000 Subject: [LinuxBIOS] #43: Add graphics memory hole to e820 map Message-ID: <060.8f5726ff9d4d3aac0a57504de94d6621@openbios.org> #43: Add graphics memory hole to e820 map ----------------------------+----------------------------------------------- Reporter: stepan | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Keywords: | Due_close: MM/DD/YYYY Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Patchstatus: there is no patch ----------------------------+----------------------------------------------- Memtest86 is reporting memory errors because it is trying to use the a0000 area in LinuxBIOS. This area should be marked as unusable or reserved in the e820 map. Erm,.. where's the e820 map created? ;) -- Ticket URL: LinuxBIOS From svn at openbios.org Fri Nov 10 18:47:42 2006 From: svn at openbios.org (LinuxBIOS) Date: Fri, 10 Nov 2006 17:47:42 -0000 Subject: [LinuxBIOS] #42: Disable SMM on K8 platforms In-Reply-To: <060.793f29e02f0920b19d501d68be2a2761@openbios.org> References: <060.793f29e02f0920b19d501d68be2a2761@openbios.org> Message-ID: <069.7a83fbe236e93c5691d1fd8605e61eb5@openbios.org> #42: Disable SMM on K8 platforms ----------------------------------+----------------------------------------- Reporter: stepan | Owner: stepan Type: defect | Status: new Priority: major | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: SMM Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: there is no patch | ----------------------------------+----------------------------------------- Comment (by segher): You'll need to lock SMM on the chipset too, if you don't already. It's amazing how much fun can be had there otherwise :-) -- Ticket URL: LinuxBIOS From svn at openbios.org Fri Nov 10 19:01:29 2006 From: svn at openbios.org (LinuxBIOS) Date: Fri, 10 Nov 2006 18:01:29 -0000 Subject: [LinuxBIOS] #42: Disable SMM on K8 platforms In-Reply-To: <060.793f29e02f0920b19d501d68be2a2761@openbios.org> References: <060.793f29e02f0920b19d501d68be2a2761@openbios.org> Message-ID: <069.e415c1193332a8b55f1414bd858b4a57@openbios.org> #42: Disable SMM on K8 platforms ----------------------------------+----------------------------------------- Reporter: stepan | Owner: stepan Type: defect | Status: new Priority: major | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: SMM Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: there is no patch | ----------------------------------+----------------------------------------- Comment (by Carl-Daniel Hailfinger ): What settings for SMM_BASE, the SMM_ADDR, RSMSPCYCDIS, SMISPCYCDIS do we need? Not specifiying them probably leaves them at default values and I don't know whether the default settings leave some exploits unfixed. -- Ticket URL: LinuxBIOS From svn at openbios.org Fri Nov 10 19:31:18 2006 From: svn at openbios.org (LinuxBIOS) Date: Fri, 10 Nov 2006 18:31:18 -0000 Subject: [LinuxBIOS] #42: Disable SMM on K8 platforms In-Reply-To: <060.793f29e02f0920b19d501d68be2a2761@openbios.org> References: <060.793f29e02f0920b19d501d68be2a2761@openbios.org> Message-ID: <069.fbf9a12e380dba861ba4f4192d166381@openbios.org> #42: Disable SMM on K8 platforms ----------------------------------+----------------------------------------- Reporter: stepan | Owner: stepan Type: defect | Status: new Priority: major | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: SMM, security Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: there is no patch | ----------------------------------+----------------------------------------- Changes (by uwe): * keywords: SMM => SMM, security Comment: This is great stuff! I'd definately make this a Kconfig option in LBv3 with a good help text... -- Ticket URL: LinuxBIOS From svn at openbios.org Fri Nov 10 19:41:06 2006 From: svn at openbios.org (LinuxBIOS) Date: Fri, 10 Nov 2006 18:41:06 -0000 Subject: [LinuxBIOS] #42: Disable SMM on K8 platforms In-Reply-To: <060.793f29e02f0920b19d501d68be2a2761@openbios.org> References: <060.793f29e02f0920b19d501d68be2a2761@openbios.org> Message-ID: <069.eeff53d7c55219bf75ebf1abdfbd3bbb@openbios.org> #42: Disable SMM on K8 platforms ----------------------------------+----------------------------------------- Reporter: stepan | Owner: stepan Type: defect | Status: assigned Priority: major | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: SMM, security Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: there is no patch | ----------------------------------+----------------------------------------- Changes (by stepan): * status: new => assigned Comment: SMM is a CPU/Northbridge thing on AMD64 processors. No need to do anything with the chipset. Check out chapter 6 of the the BKDG at http://www.amd.com/us- en/assets/content_type/white_papers_and_tech_docs/26094.PDF What we _might_ want do though is add a small SMM handler at 38000 but that is a completely different issue. SMM_BASE register holds the base of the system management memory region, and its default value is 30000h. The first SMI handler instruction is fetched at SMM_BASE + 8000h. -- Ticket URL: LinuxBIOS From svn at openbios.org Fri Nov 10 19:55:24 2006 From: svn at openbios.org (LinuxBIOS) Date: Fri, 10 Nov 2006 18:55:24 -0000 Subject: [LinuxBIOS] #42: Disable SMM on K8 platforms In-Reply-To: <060.793f29e02f0920b19d501d68be2a2761@openbios.org> References: <060.793f29e02f0920b19d501d68be2a2761@openbios.org> Message-ID: <069.743933a0212c123dec45e90c7270368c@openbios.org> #42: Disable SMM on K8 platforms ----------------------------------+----------------------------------------- Reporter: stepan | Owner: stepan Type: defect | Status: assigned Priority: major | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: SMM, security Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: there is no patch | ----------------------------------+----------------------------------------- Comment (by segher): Replying to [comment:4 stepan]: > SMM is a CPU/Northbridge thing on AMD64 processors. No need to do anything with the chipset. Well you need to make sure that SMI (and SCI) are correctly handled, so they cannot hang the system. It's not obvious to me that this is automatically the case, but you know this stuff better I'm sure :-) The other thing the chipset can do is disable certain regions of memory while not in SMM, but that's not too interesting if you don't do SMM at all :-) Segher -- Ticket URL: LinuxBIOS From svn at openbios.org Fri Nov 10 20:03:44 2006 From: svn at openbios.org (LinuxBIOS) Date: Fri, 10 Nov 2006 19:03:44 -0000 Subject: [LinuxBIOS] #42: Disable SMM on K8 platforms In-Reply-To: <060.793f29e02f0920b19d501d68be2a2761@openbios.org> References: <060.793f29e02f0920b19d501d68be2a2761@openbios.org> Message-ID: <069.36c237dfafc9a7e935c81a341d08c22c@openbios.org> #42: Disable SMM on K8 platforms ----------------------------------+----------------------------------------- Reporter: stepan | Owner: stepan Type: defect | Status: assigned Priority: major | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: SMM, security Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: there is no patch | ----------------------------------+----------------------------------------- Comment (by nemesis at icequake.net): Most BIOSes relocate SMBASE to 0xA0000 so as to map it into the VGA framebuffer area instead of on top of memory. -- Ticket URL: LinuxBIOS From stuge-linuxbios at cdy.org Fri Nov 10 21:02:31 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 10 Nov 2006 21:02:31 +0100 Subject: [LinuxBIOS] r2496 - in trunk/LinuxBIOSv2: src/mainboard/agami/aruma src/mainboard/amd/quartet src/mainboard/amd/rumba src/mainboard/amd/serenade src/mainboard/amd/serengeti_cheetah src/mainboard/amd/serengeti_leopard src/mainboard/amd/solo src/mainboard/arima/hdama src/mainboard/artecgroup/dbe61 src/mainboard/asus/p2b src/mainboard/bitworks/ims src/mainboard/broadcom/blast src/mainboard/dell/s1850 src/mainboard/densitron/dpx114 src/mainboard/digitallogic/adl855pc src/mainboard/digitallogic/msm586seg src/mainboard/digitallogic/msm800sev src/mainboard/eaglelion/5bcm src/mainboard/embeddedplanet/ep405pc src/mainboard/ibm/e325 src/mainboard/ibm/e326 src/mainboard/intel/jarrell src/mainboard/intel/xe7501devkit src/mainboard/iwill/dk8_htx src/mainboard/iwill/dk8s2 src/mainboard/iwill/dk8x src/mainboard/lippert/frontrunner src/mainboard/motorola/sandpointx3_altimus_mpc7410 src/mainboard/msi/ms9185 src/mainboard/newisys/khepri src/mainboard/sunw/ultra40 src/mainboard/supermicro/x6dai_g src/mainboard/supermicro/x6dhe_g src/mainboard/supermicro/x6dhe_g2 src/mainboard/supermicro/x6dhr_ig src/mainboard/supermicro/x6dhr_ig2 src/mainboard/technologic/ts5300 src/mainboard/totalimpact/briq src/mainboard/tyan/s2735 src/mainboard/tyan/s2850 src/mainboard/tyan/s2875 src/mainboard/tyan/s2880 src/mainboard/tyan/s2881 src/mainboard/tyan/s2882 src/mainboard/tyan/s2885 src/mainboard/tyan/s2891 src/mainboard/tyan/s2892 src/mainboard/tyan/s2895 src/mainboard/tyan/s4880 src/mainboard/tyan/s4882 src/mainboard/via/epia src/mainboard/via/epia-m targets/amd/quartet targets/amd/serengeti_cheetah targets/arima/hdama targets/digitallogic/msm586seg targets/emulation/qemu-i386 targets/ibm targets/ibm/e326 targets/technologic/ts5300 targets/via/epia-m util/abuild Message-ID: <20061110200231.8894.qmail@cdy.org> On Fri, Nov 10, 2006 at 01:45:42PM +0000, svn at openbios.org wrote: > * if lzma is installed and a real payload is used, try compressing > it. Should it compress unless asked to? //Peter From lfcorreia at lfcorreia.dyndns.org Sat Nov 11 00:22:38 2006 From: lfcorreia at lfcorreia.dyndns.org (Luis Correia) Date: Fri, 10 Nov 2006 23:22:38 +0000 Subject: [LinuxBIOS] Support for IEI Nova4899R [1] In-Reply-To: <20061109231215.GA32140@coresystems.de> References: <454CFA15.3080501@lfcorreia.dyndns.org> <13426df10611041640o2008c16fj21ccfb55fe0c8929@mail.gmail.com> <454D395A.3020205@lfcorreia.dyndns.org> <20061105021200.GA5020@coresystems.de> <4550544F.1070808@lfcorreia.dyndns.org> <20061109231215.GA32140@coresystems.de> Message-ID: <455509BE.9050908@lfcorreia.dyndns.org> Stefan Reinauer wrote: > * Luis Correia [061107 10:39]: >> We can see thatthe 32k vga bios is copied to the correct place, but >> nothing is done to the VSA portion, it is true that this VSA code >> does not have the standard BIOS start values (0x55aa). > > Yes, vsa is not an option rom, hence no 55aa. > > VSA needs to be called in 16bit mode, GX2 and LX do that in > northbridge.c > > Check out src/cpu/amd/model_gx2/vsmsetup.c > This is a very tricky business! The VSM code hooks up in lots of places. If I manage to get this going for my GX1 board, is is possible that it would break other configurations. And i'm not too confortable with it. I'm still very rough regarding the creation of a proper CONFIG_VSA option, that seems to me to be the best way to provide VSA services to future devices. It seems that the VSA was made to work only for the OLPC gx2 powered mainboard. > Stefan I will try to do my best with it :) Luis -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From stepan at coresystems.de Sat Nov 11 01:20:11 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 11 Nov 2006 01:20:11 +0100 Subject: [LinuxBIOS] Support for IEI Nova4899R [1] In-Reply-To: <455509BE.9050908@lfcorreia.dyndns.org> References: <454CFA15.3080501@lfcorreia.dyndns.org> <13426df10611041640o2008c16fj21ccfb55fe0c8929@mail.gmail.com> <454D395A.3020205@lfcorreia.dyndns.org> <20061105021200.GA5020@coresystems.de> <4550544F.1070808@lfcorreia.dyndns.org> <20061109231215.GA32140@coresystems.de> <455509BE.9050908@lfcorreia.dyndns.org> Message-ID: <20061111002011.GA22166@coresystems.de> * Luis Correia [061111 00:22]: > The VSM code hooks up in lots of places. If I manage to get this > going for my GX1 board, is is possible that it would break other > configurations. And i'm not too confortable with it. If you can just give it a try. > It seems that the VSA was made to work only for the OLPC gx2 powered > mainboard. Its part of the CPU specific code for the GX2, yes. The Geode LX cpu code has support for it, too. Only Geode CPU where LinuxBIOS does not know about VSA is the GX1. > I will try to do my best with it :) Good Luck. -- 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 Sat Nov 11 05:16:39 2006 From: rminnich at gmail.com (ron minnich) Date: Fri, 10 Nov 2006 21:16:39 -0700 Subject: [LinuxBIOS] Support for IEI Nova4899R [1] In-Reply-To: <455509BE.9050908@lfcorreia.dyndns.org> References: <454CFA15.3080501@lfcorreia.dyndns.org> <13426df10611041640o2008c16fj21ccfb55fe0c8929@mail.gmail.com> <454D395A.3020205@lfcorreia.dyndns.org> <20061105021200.GA5020@coresystems.de> <4550544F.1070808@lfcorreia.dyndns.org> <20061109231215.GA32140@coresystems.de> <455509BE.9050908@lfcorreia.dyndns.org> Message-ID: <13426df10611102016k28185074r406aba14b0d487df@mail.gmail.com> On 11/10/06, Luis Correia wrote: > It seems that the VSA was made to work only for the OLPC gx2 powered it works on several gx2 boards, not just OLPC; and it works on LX. I don't see a reason it would not work with gx1. ron From uwe at hermann-uwe.de Sat Nov 11 11:25:55 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 11 Nov 2006 11:25:55 +0100 Subject: [LinuxBIOS] RAM controller breakage? Message-ID: <20061111102555.GB21784@greenwood> Hi, I'm just a bit curious - are there settings/registers in northbridges which can seriously brick a mainboard and/or RAM (physically) if abused properly? I'll start testing my 440BX code soon, so I'd like to know what I have to expect... 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 lfcorreia at lfcorreia.dyndns.org Sat Nov 11 11:29:10 2006 From: lfcorreia at lfcorreia.dyndns.org (Luis Correia) Date: Sat, 11 Nov 2006 10:29:10 +0000 Subject: [LinuxBIOS] Support for IEI Nova4899R [1] In-Reply-To: <13426df10611102016k28185074r406aba14b0d487df@mail.gmail.com> References: <454CFA15.3080501@lfcorreia.dyndns.org> <13426df10611041640o2008c16fj21ccfb55fe0c8929@mail.gmail.com> <454D395A.3020205@lfcorreia.dyndns.org> <20061105021200.GA5020@coresystems.de> <4550544F.1070808@lfcorreia.dyndns.org> <20061109231215.GA32140@coresystems.de> <455509BE.9050908@lfcorreia.dyndns.org> <13426df10611102016k28185074r406aba14b0d487df@mail.gmail.com> Message-ID: <4555A5F6.3090208@lfcorreia.dyndns.org> ron minnich wrote: > On 11/10/06, Luis Correia wrote: > >> It seems that the VSA was made to work only for the OLPC gx2 powered > > it works on several gx2 boards, not just OLPC; and it works on LX. > > I don't see a reason it would not work with gx1. > In that case, can I assume that my work on VSA for the GX1 will benefit all other GX1 based boards (if any)? > ron > Luis -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From corey_osgood at verizon.net Sat Nov 11 14:12:17 2006 From: corey_osgood at verizon.net (Corey Osgood) Date: Sat, 11 Nov 2006 08:12:17 -0500 Subject: [LinuxBIOS] RAM controller breakage? In-Reply-To: <20061111102555.GB21784@greenwood> References: <20061111102555.GB21784@greenwood> Message-ID: <4555CC31.1010807@verizon.net> Uwe Hermann wrote: > Hi, > > I'm just a bit curious - are there settings/registers in northbridges > which can seriously brick a mainboard and/or RAM (physically) if abused > properly? > > I'll start testing my 440BX code soon, so I'd like to know what I have > to expect... > > > Uwe. > Well, from what I can tell, this chipset is fairly idiot-proof, as long as you don't go messing around with anything not in the docs. The only real show stoppers would be setting the timings too tight, or setting the ram type to the wrong type, but I don't even know if that would burn hardware. BTW, if you want a hand with testing anything, send me an email, I'm curious to see how you've gotten it to work, and I've got a test rig installing gentoo right now. I've spent a few hours pouring over the docs, but haven't gotten the time to make anything from it. Corey Osgood From stepan at coresystems.de Sat Nov 11 14:15:24 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 11 Nov 2006 14:15:24 +0100 Subject: [LinuxBIOS] Support for IEI Nova4899R [1] In-Reply-To: <4555A5F6.3090208@lfcorreia.dyndns.org> References: <454CFA15.3080501@lfcorreia.dyndns.org> <13426df10611041640o2008c16fj21ccfb55fe0c8929@mail.gmail.com> <454D395A.3020205@lfcorreia.dyndns.org> <20061105021200.GA5020@coresystems.de> <4550544F.1070808@lfcorreia.dyndns.org> <20061109231215.GA32140@coresystems.de> <455509BE.9050908@lfcorreia.dyndns.org> <13426df10611102016k28185074r406aba14b0d487df@mail.gmail.com> <4555A5F6.3090208@lfcorreia.dyndns.org> Message-ID: <20061111131524.GA22155@coresystems.de> * Luis Correia [061111 11:29]: > ron minnich wrote: > > it works on several gx2 boards, not just OLPC; and it works on LX. > > > > I don't see a reason it would not work with gx1. > > > In that case, can I assume that my work on VSA for the GX1 will > benefit all other GX1 based boards (if any)? yes. -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From rminnich at gmail.com Sat Nov 11 16:15:25 2006 From: rminnich at gmail.com (ron minnich) Date: Sat, 11 Nov 2006 08:15:25 -0700 Subject: [LinuxBIOS] RAM controller breakage? In-Reply-To: <20061111102555.GB21784@greenwood> References: <20061111102555.GB21784@greenwood> Message-ID: <13426df10611110715r2bd7f8kd245179d9a5bd943@mail.gmail.com> On 11/11/06, Uwe Hermann wrote: > Hi, > > I'm just a bit curious - are there settings/registers in northbridges > which can seriously brick a mainboard and/or RAM (physically) if abused > properly? > > I'll start testing my 440BX code soon, so I'd like to know what I have > to expect... > I don't think you can. I have over the years tried a lot of wrong ram settings, and only ever seen temporary failures. We have in 7 1/2 years never seen anything that looked like damage due to bad ram programming. thanks ron From corey_osgood at verizon.net Sat Nov 11 16:54:49 2006 From: corey_osgood at verizon.net (Corey Osgood) Date: Sat, 11 Nov 2006 10:54:49 -0500 Subject: [LinuxBIOS] RAM controller breakage? In-Reply-To: <20061111102555.GB21784@greenwood> References: <20061111102555.GB21784@greenwood> Message-ID: <4555F249.20901@verizon.net> Uwe Hermann wrote: > Hi, > > I'm just a bit curious - are there settings/registers in northbridges > which can seriously brick a mainboard and/or RAM (physically) if abused > properly? > > I'll start testing my 440BX code soon, so I'd like to know what I have > to expect... > > > Uwe. > Don't mean to bug you or anything, but I've got a couple more questions, if you have the time: did you have to do anything with the southbridge code, or is that all set? And did you start from scratch, or modify the code that was already there? And a final question for anyone, if I were to do a flash and it not go well, do failsafes like key combonations to pull a bios off a floppy still work, or are those stored in the BIOS? Corey Osgood From rminnich at gmail.com Sat Nov 11 17:07:44 2006 From: rminnich at gmail.com (ron minnich) Date: Sat, 11 Nov 2006 09:07:44 -0700 Subject: [LinuxBIOS] RAM controller breakage? In-Reply-To: <4555F249.20901@verizon.net> References: <20061111102555.GB21784@greenwood> <4555F249.20901@verizon.net> Message-ID: <13426df10611110807p2d624eafxd175120e7043f169@mail.gmail.com> On 11/11/06, Corey Osgood wrote: > And a final question for anyone, if I were to do a flash and it not go > well, do failsafes like key combonations to pull a bios off a floppy > still work, or are those stored in the BIOS? Those are part of the BIOS. Your only safe way to do this is to have duplicate flash parts. I do this: 1. clone the fuctory bios. 2. make sure the CLONE boots. 3. put the ORIGINAL flash part in a bag, on a shelf, where I can not touch it. 4. use hot swap to program linuxbios. Always work with the CLONE part for fuctory. Why always work with the CLONE? because if you use the clone, that ensures that your flash programming is working. This way, WHEN, not IF, but WHEN I make a mistake and put linuxbios in over the fuctory bios, I have a fallback position: that part on the shelf. And, WHEN I make this mistake, FIRST thing I do is make another fuctory BIOS copy. This procedure developed after some really serious, stupid mistakes wiping out BIOSes. thanks ron From tsylla at gmail.com Sat Nov 11 18:03:07 2006 From: tsylla at gmail.com (Tom Sylla) Date: Sat, 11 Nov 2006 12:03:07 -0500 Subject: [LinuxBIOS] Support for IEI Nova4899R [1] In-Reply-To: <13426df10611102016k28185074r406aba14b0d487df@mail.gmail.com> References: <454CFA15.3080501@lfcorreia.dyndns.org> <13426df10611041640o2008c16fj21ccfb55fe0c8929@mail.gmail.com> <454D395A.3020205@lfcorreia.dyndns.org> <20061105021200.GA5020@coresystems.de> <4550544F.1070808@lfcorreia.dyndns.org> <20061109231215.GA32140@coresystems.de> <455509BE.9050908@lfcorreia.dyndns.org> <13426df10611102016k28185074r406aba14b0d487df@mail.gmail.com> Message-ID: <4556024B.6050900@gmail.com> ron minnich wrote: > On 11/10/06, Luis Correia wrote: > >> It seems that the VSA was made to work only for the OLPC gx2 powered > > it works on several gx2 boards, not just OLPC; and it works on LX. > > I don't see a reason it would not work with gx1. Be wary here. GX1 VSA was very very different architecturally than GX/LX VSA. In GX1, it was much more insidious to the system. GX/LX was architected better to keep things divided and cleaner. There is no reason it should not work without enough effort, but just realize that GX1 VSA is a bit of a different beast than GX/LX VSA. > > ron > From tsylla at gmail.com Sat Nov 11 18:06:19 2006 From: tsylla at gmail.com (Tom Sylla) Date: Sat, 11 Nov 2006 12:06:19 -0500 Subject: [LinuxBIOS] RAM controller breakage? In-Reply-To: <20061111102555.GB21784@greenwood> References: <20061111102555.GB21784@greenwood> Message-ID: <4556030B.7080506@gmail.com> Uwe Hermann wrote: > Hi, > > I'm just a bit curious - are there settings/registers in northbridges > which can seriously brick a mainboard and/or RAM (physically) if abused > properly? There is nothing you can do from software to physically harm SDR, DDR, or DDR2 devices. From uwe at hermann-uwe.de Sat Nov 11 18:28:53 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 11 Nov 2006 18:28:53 +0100 Subject: [LinuxBIOS] RAM controller breakage? In-Reply-To: <4555CC31.1010807@verizon.net> References: <20061111102555.GB21784@greenwood> <4555CC31.1010807@verizon.net> Message-ID: <20061111172853.GB29518@greenwood> Hi, On Sat, Nov 11, 2006 at 08:12:17AM -0500, Corey Osgood wrote: > BTW, if you want a hand with testing anything, send me an > email, I'm curious to see how you've gotten it to work, I don't have working code, yet. I'll post a patch as soon as I have (might take a few more days)... I'm currently building the code infrastructure, comparing the v1 code to the datasheet and the E7501 code which I (partially) reuse... Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From uwe at hermann-uwe.de Sat Nov 11 18:29:04 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 11 Nov 2006 18:29:04 +0100 Subject: [LinuxBIOS] RAM controller breakage? In-Reply-To: <4555F249.20901@verizon.net> References: <20061111102555.GB21784@greenwood> <4555F249.20901@verizon.net> Message-ID: <20061111172904.GC29518@greenwood> On Sat, Nov 11, 2006 at 10:54:49AM -0500, Corey Osgood wrote: > Don't mean to bug you or anything, but I've got a couple more questions, > if you have the time: did you have to do anything with the southbridge > code, or is that all set? I haven't touched the southbridge code yet, but it seems to be supported already. And please note, I'm merely writing code currently, I haven't yet actually _tested_ anything... > And did you start from scratch, or modify the > code that was already there? Both, partly. I don't want to do further cut'n'paste programming, there's enough of that in the tree already. I started mostly from scratch and tried to properly document the code. Some parts I'll reuse from the E7501 I guess, and the real know-how is in the V1 440BX code (which is working fine for me on my hardware, btw). > And a final question for anyone, if I were to do a flash and it not go > well, do failsafes like key combonations to pull a bios off a floppy > still work, or are those stored in the BIOS? Won't work, see Ron's post. I have a local svn repository where I checkin all my proprietary BIOS images, so I won't lose them no matter how much I mess up. And I put one or more backups of them on real physical chips, of course. 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 Nov 11 19:46:40 2006 From: svn at openbios.org (svn at openbios.org) Date: Sat, 11 Nov 2006 18:46:40 -0000 Subject: [LinuxBIOS] r2497 - trunk/LinuxBIOSv2/src/northbridge/intel/i440bx Message-ID: Author: uwe Date: 2006-11-11 19:46:38 +0100 (Sat, 11 Nov 2006) New Revision: 2497 Modified: trunk/LinuxBIOSv2/src/northbridge/intel/i440bx/i440bx.h Log: Add missing bracket in comment, and fix whitespace (trivial). Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Modified: trunk/LinuxBIOSv2/src/northbridge/intel/i440bx/i440bx.h =================================================================== --- trunk/LinuxBIOSv2/src/northbridge/intel/i440bx/i440bx.h 2006-11-10 13:30:28 UTC (rev 2496) +++ trunk/LinuxBIOSv2/src/northbridge/intel/i440bx/i440bx.h 2006-11-11 18:46:38 UTC (rev 2497) @@ -18,7 +18,7 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ -/* +/* * Datasheet: * - Name: Intel 440BX AGPset: 82443BX Host Bridge/Controller * - URL: http://www.intel.com/design/chipsets/datashts/290633.htm @@ -31,7 +31,7 @@ * The values in parenthesis are the default values as per datasheet. * Any addresses between 0x00 and 0xff not listed below are either * Reserved or Intel Reserved and should not be touched. - */ + */ #define VID 0x00 /* Vendor Identification (0x8086). */ #define DID 0x02 /* Device Identification (0x7190/0x7192). */ #define PCICMD 0x04 /* PCI Command Register (0x006). */ @@ -44,7 +44,7 @@ #define APBASE 0x10 /* Aperture Base Configuration (0x00000008). */ #define SVID 0x2c /* Subsystem Vendor Identification (0x0000). */ #define SID 0x2e /* Subsystem Identification (0x0000). */ -#define CAPPTR 0x34 /* Capabilities Pointer (0xa0/0x00. */ +#define CAPPTR 0x34 /* Capabilities Pointer (0xa0/0x00). */ #define NBXCFG 0x50 /* 440BX Configuration (0x0000:00S0_0000_000S_0S00b). */ #define DRAMC 0x57 /* DRAM Control (00S0_0000b). */ #define DRAMT 0x58 /* DRAM Timing (0x03). */ From corey_osgood at verizon.net Sat Nov 11 19:50:52 2006 From: corey_osgood at verizon.net (Corey Osgood) Date: Sat, 11 Nov 2006 13:50:52 -0500 Subject: [LinuxBIOS] RAM controller breakage? In-Reply-To: <20061111172904.GC29518@greenwood> References: <20061111102555.GB21784@greenwood> <4555F249.20901@verizon.net> <20061111172904.GC29518@greenwood> Message-ID: <45561B8C.9010400@verizon.net> Uwe Hermann wrote: > I haven't touched the southbridge code yet, but it seems to be supported > already. > > And please note, I'm merely writing code currently, I haven't yet > actually _tested_ anything... > Sorry, guess I got a little over-excited. I had the same thought on the southbridge code, although I didn't see any other models using it, but at the very least it looks clean. > Won't work, see Ron's post. I have a local svn repository where I > checkin all my proprietary BIOS images, so I won't lose them no matter > how much I mess up. > And I put one or more backups of them on real physical chips, of course. > > > Uwe. > Alright, I thought as much, but it was worth a shot. It doesn't really matter anyways, both of the boards I have here now were rescued from the dumpster, so they're no real loss if I kill them, and I should have an asus board on the way monday, along with a bios savior. Corey From smithbone at gmail.com Sat Nov 11 21:22:29 2006 From: smithbone at gmail.com (Richard Smith) Date: Sat, 11 Nov 2006 14:22:29 -0600 Subject: [LinuxBIOS] RAM controller breakage? In-Reply-To: <4556030B.7080506@gmail.com> References: <20061111102555.GB21784@greenwood> <4556030B.7080506@gmail.com> Message-ID: <45563105.8070205@gmail.com> Tom Sylla wrote: >> I'm just a bit curious - are there settings/registers in northbridges >> which can seriously brick a mainboard and/or RAM (physically) if abused >> properly? > > There is nothing you can do from software to physically harm SDR, DDR, > or DDR2 devices. 100% agree with Tom. I suppose if you somehow tickle some crazy bug to make the controller output the wrong voltage you could do something bad to the rams but the chances of that are so low they aren't even worth considering. Remember thats a really mature chipset. I've put all manner of wrong settings in those chips and during the development of the Bitworks/IMS board we did all sorts of "Bad" things to the ram and it kept on plugging. So I think you are safe. Thinking about this brings back a few memories. 1) I found in my testing that you can do things to the north bridge that will crash it in such a way that a reset does not fully fix. It's very sneaky, things just start behaving really weird and your code just seems to start failing for no good reason. But not so bad as to suspect that its hardware. Especially if you are doinking with the register settings at the time. The only fix is to _remove_ power from the board. And on the ASUS I seem to remember having to remove the CMOS battery as well. (Bitworks/IMS had no battery) So I recommend you remove the battery and power cycle frequently. 2) The 66Mhz/100Mhz operation of the front side bus is controlled via a jumper. The Bitworks board however was never qualified to run at 100Mhz. So all the settings are for 66Mhz. If you run with the 66Mhz drive settings yet have the jumper set to 100Mhz you are in for a lot of frustration. Just depends on the quality of your ram and the board layout. I recommend that you do all you development with 66Mhz and then work out the 100Mhz settings after you have the code working. I can't help much with the 100Mhz settings. You will need to dump a Factory BIOS set to 100Mhz and compare how they setup the drive settings. -- Richard A. Smith From smithbone at gmail.com Sat Nov 11 21:29:44 2006 From: smithbone at gmail.com (Richard Smith) Date: Sat, 11 Nov 2006 14:29:44 -0600 Subject: [LinuxBIOS] RAM controller breakage? In-Reply-To: <20061111172904.GC29518@greenwood> References: <20061111102555.GB21784@greenwood> <4555F249.20901@verizon.net> <20061111172904.GC29518@greenwood> Message-ID: <455632B8.6050802@gmail.com> Uwe Hermann wrote: > Both, partly. I don't want to do further cut'n'paste programming, > there's enough of that in the tree already. I started mostly from > scratch and tried to properly document the code. Some parts I'll reuse from > the E7501 Rock on. \m/ You the man. Go Uwe Go! > I guess, and the real know-how is in the V1 440BX code > (which is working fine for me on my hardware, btw). It worked for you out-of-the-box? Wow. I always had to hardcode one of the settings to the ram that V1 never quite got right on my Asus P2B but worked fine for the Bitworks/IMS. The boards I have are slightly different revs. ZX vs BX I think. -- Richard A. Smith From c-d.hailfinger.devel.2006 at gmx.net Sun Nov 12 02:10:49 2006 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 12 Nov 2006 02:10:49 +0100 Subject: [LinuxBIOS] MSI K9N Neo support for LinuxBIOS? In-Reply-To: References: Message-ID: <45567499.7070003@gmx.net> Dear Andrew, dear Laura, we would like to port LinuxBIOS to the MSI K9N Neo-F (Part No. MS-7260-010) and we may need access to some documentation and data sheets. We already have some code for the chipset and expect to get it running soon. BxShi from the MSI server division has already ported LinuxBIOS to MS-9185 and is working on MS-9182. He suggested we ask you for help. For details about LinuxBIOS, see www.linuxbios.org Key features are: * No licensing costs * Free to modify (GPL license) * Extremely fast booting (3 seconds) * Full 32/64 bit code in BIOS * BIOS written in C and not assembly * No legacy 16 bit code (optional support for 16 bit graphics BIOS) Could you please give us some help in porting LinuxBIOS to your fine mainboard? Thanks! Carl-Daniel Hailfinger bxshi at msik.com.cn wrote: > Dear all, > Sorry . please contact their PM > andrewchang at msi.com.tw > laurayan at msik.com.cn > > bxshi > > > -----????----- > ???: bxshi(???=??) > ????: 2006?11?10? 14:24 > ???: owenchen(???=??) > ??: 'Carl-Daniel Hailfinger'; 'rminnich at gmail.com'; 'yinghai.lu at amd.com'; 'stepan at coresystems.de'; 'uwe at hermann-uwe.de'; 'linuxbios at linuxbios.org' > ??: ??: MSI K9N Neo support for LinuxBIOS? > > Dear Owen , > There are several experts from all of world are planning to port it . I will introduce you to them . I think when they are porting ,they may need some datasheet.etc. I may not be able to port it myself ,because I am busy with MS-9182 linuxbios porting. > More detail please see www.linuxbios.org > > Dear carl-Daniel ,Stefan ,Yinghai,ron,uwe, > Owen is our Desktop BIOS manager , if you need some help of MSI K9N Nero ,you can contact with him .He is preparing help . > > Thanks > bxshi > > -----????----- > ???: owenchen [mailto:owenchen at msik.com.cn] > ????: 2006?11?10? 14:04 > ???: bxshi(???=??) > ??: 'Carl-Daniel Hailfinger' > ??: RE: MSI K9N Neo support for LinuxBIOS? > > Dear BxShi > What I can do a favor to you? And tell me the K9N Neo model's name? > thanks > > -----Original Message----- > From: bxshi [mailto:bxshi at msik.com.cn] > Sent: Friday, November 10, 2006 10:46 AM > To: owenchen(???=??) > Cc: 'Carl-Daniel Hailfinger' > Subject: ??: MSI K9N Neo support for LinuxBIOS? > > Dear Owen , > Linuxbios Community is interested in MSI K9N Neo, and they are planning to > port linuxbios for it .could you please give them some help ? Many people > are like this board if it has linuxbios support. > > > -----????----- > ???: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006 at gmx.net] > ????: 2006?11?9? 23:29 > ???: bxshi at msik.com.cn > ??: LinuxBIOS > ??: MSI K9N Neo support for LinuxBIOS? > > Hi bxshi, > > would you help us port LinuxBIOS to the MSI K9N Neo? > > http://cweb.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID > =733 > http://www.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID= > 733 > > It is a good and cheap board and a few of us will buy it > to port LinuxBIOS to it, but we need your support. > > Regards, > Carl-Daniel > > > *****CONFIDENTIAL INFORMATION***** > > This email is intended only for the use of the person or entity to whom it is addressed and contains information that may be subject to and/or may be restricted from disclosure by contract or applicable law. If you are not the intended recipient of this email, be advised that any disclosure, copy, distribution or use of the contents of this message is strictly prohibited. If you are not the intended recipient of this email, please notify the sender that you have received this in error by replying to this message. Then, please delete it from your system. Thank you. > > -- http://www.hailfinger.org/ From corey_osgood at verizon.net Sat Nov 11 21:43:12 2006 From: corey_osgood at verizon.net (Corey Osgood) Date: Sat, 11 Nov 2006 15:43:12 -0500 Subject: [LinuxBIOS] glue, anyone? Message-ID: <455635E0.7020206@verizon.net> Anyone have any experience with controlling FSB controlled by a Glue Logic chip? I can't seem to find any code for it in LinuxBIOS, but maybe *fingers crossed here* it detects and configures the CPU all on its own. Thanks Richard for reminding me about that. Corey From segher at kernel.crashing.org Sun Nov 12 00:54:19 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 12 Nov 2006 00:54:19 +0100 Subject: [LinuxBIOS] RAM controller breakage? In-Reply-To: <45563105.8070205@gmail.com> References: <20061111102555.GB21784@greenwood> <4556030B.7080506@gmail.com> <45563105.8070205@gmail.com> Message-ID: <0BDCBD9E-BFDE-41C5-B3B6-487D5022C86E@kernel.crashing.org> > 1) I found in my testing that you can do things to the north bridge > that > will crash it in such a way that a reset does not fully fix. It's > very > sneaky, things just start behaving really weird and your code just > seems > to start failing for no good reason. But not so bad as to suspect > that > its hardware. Especially if you are doinking with the register > settings > at the time. > > The only fix is to _remove_ power from the board. Many chips have debug registers (often not documented in public literature) that seriously change the behaviour of the chip; and such debug registers are often not reset by a simple chip reset (which is a good thing really). Most shipping hardware (esp. "B" or later revs) doesn't need programming any of those registers for proper operation. Segher From segher at kernel.crashing.org Sun Nov 12 00:48:02 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 12 Nov 2006 00:48:02 +0100 Subject: [LinuxBIOS] RAM controller breakage? In-Reply-To: <13426df10611110715r2bd7f8kd245179d9a5bd943@mail.gmail.com> References: <20061111102555.GB21784@greenwood> <13426df10611110715r2bd7f8kd245179d9a5bd943@mail.gmail.com> Message-ID: <70B4091D-C6F7-4F67-A494-2491EA4327C6@kernel.crashing.org> >> I'm just a bit curious - are there settings/registers in northbridges >> which can seriously brick a mainboard and/or RAM (physically) if >> abused >> properly? >> >> I'll start testing my 440BX code soon, so I'd like to know what I >> have >> to expect... >> > > I don't think you can. I have over the years tried a lot of wrong ram > settings, and only ever seen temporary failures. We have in 7 1/2 > years never seen anything that looked like damage due to bad ram > programming. Have you ever seen any damage from programming something else incorrectly though? It's a typical programming mistake to write to the wrong register ;-) That said, on modern hardware, it's almost impossible to damage the hardware by software alone (for example, if you accidentally turn off the fans (or don't turn them on), most chips will automatically shut off). Segher p.s. Be careful with high-power voltage regulators though ;-) From corey_osgood at verizon.net Sun Nov 12 06:34:29 2006 From: corey_osgood at verizon.net (Corey Osgood) Date: Sun, 12 Nov 2006 00:34:29 -0500 Subject: [LinuxBIOS] SMSC FDC37B80x & FDC37M707 code Message-ID: <4556B265.8000504@verizon.net> If anyone needs code for either of these two SuperIOs, let me know, I've ported the lpc47b397 code and it should work fine, but I don't want to go submitting it until it's tested, and the only boards I have with these chips are 440bx based. BTW, have there been any requests for Slot A Athlon support, namely the AMD 751 northbridge and Via 686a southbridge chips? I'm seriously considering working on all 3 of these, just acquired a board (FIC SPII) and a couple extra BIOS chips that I'm sure can be forced to work, although the DOS flasher doesn't like them. From svn at openbios.org Sun Nov 12 11:24:51 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 12 Nov 2006 10:24:51 -0000 Subject: [LinuxBIOS] #44: ACPI collides with smbus/ide on i82801ca southbridge Message-ID: <060.fc34b4994817bf37b64beee69e99412c@openbios.org> #44: ACPI collides with smbus/ide on i82801ca southbridge ----------------------------------+----------------------------------------- Reporter: chn at virtutech.se | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: code | Version: v2 Keywords: | Due_close: MM/DD/YYYY Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Patchstatus: there is no patch ----------------------------------+----------------------------------------- In src/southbridge/intel/i82801ca, first the smbus registers are mapped at i/o space offset 0x1000, and later is the acpi registers also mapped at 0x1000. I had to apply the attached patch to get it to work. Note: It is not tested on real h/w, just in a simulator. -- Ticket URL: LinuxBIOS From shaddamcorrinoiv at gmail.com Sun Nov 12 15:14:25 2006 From: shaddamcorrinoiv at gmail.com (Shaddam Corrino IV) Date: Sun, 12 Nov 2006 15:14:25 +0100 Subject: [LinuxBIOS] Intel 440bx Message-ID: Hello folks, Ideally in few weeks I would like to use 440bx. It is my impression that it is not working right now quite right. Am I screwed? What I would need is LB+VGA bios (so that I can use working vesafb in linux). # lspci 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 02) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 02) 00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02) 00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02) 00:0a.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01) 00:0c.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) 01:00.0 VGA compatible controller: S3 Inc. ViRGE/GX2 (rev 06) Thanks, Shaddam -------------- next part -------------- An HTML attachment was scrubbed... URL: From moses_r at Commex-technologies.com Sun Nov 12 18:26:46 2006 From: moses_r at Commex-technologies.com (Moses Reuben) Date: Sun, 12 Nov 2006 19:26:46 +0200 Subject: [LinuxBIOS] How to add support to a Hyper Transport card Message-ID: <42BD91E60E3CAE4CAB3E30EA6A6036F8A37879@exrad3.ad.rad.co.il> Hi all I have a HT nic (this is a new card) and i want the bios to support it what should i change in the code && configuration . I have a Iwill/dk8_htx board. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey_osgood at verizon.net Sun Nov 12 19:30:40 2006 From: corey_osgood at verizon.net (Corey Osgood) Date: Sun, 12 Nov 2006 13:30:40 -0500 Subject: [LinuxBIOS] Intel 440bx In-Reply-To: References: Message-ID: <45576850.6040002@verizon.net> Shaddam Corrino IV wrote: > Hello folks, > > Ideally in few weeks I would like to use 440bx. > It is my impression that it is not working right now quite right. > Am I screwed? > > What I would need is LB+VGA bios (so that I can use working vesafb in > linux). > > # lspci > 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX > Host bridge (rev 02) > 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP > bridge (rev 02) > 00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02) > 00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) > 00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) > 00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02) > 00:0a.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01) > 00:0c.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) > 01:00.0 VGA compatible controller: S3 Inc. ViRGE/GX2 (rev 06) > > > Thanks, > Shaddam > One of the developers is working on it now, we should have some code to play with soon. In the meantime, what's the SuperI/O on your motherboard? -Corey From shaddamcorrinoiv at gmail.com Sun Nov 12 19:56:45 2006 From: shaddamcorrinoiv at gmail.com (Shaddam Corrino IV) Date: Sun, 12 Nov 2006 19:56:45 +0100 Subject: [LinuxBIOS] Intel 440bx In-Reply-To: <45576850.6040002@verizon.net> References: <45576850.6040002@verizon.net> Message-ID: On 11/12/06, Corey Osgood wrote: > > Shaddam Corrino IV wrote: > > > 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX > > 00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02) > > 01:00.0 VGA compatible controller: S3 Inc. ViRGE/GX2 (rev 06) One of the developers is working on it now, we should have some code to > play with soon. In the meantime, what's the SuperI/O on your motherboard? Heh, thought it would be part of the NorthBridge. It is : Winbond W83977TF-AW. At the time I also do not have any extra EEPROMs so I'll have to pick something and buy. Preferably cheap. http://www.baber.com/baber/411/atrendatc6220.htm http://www.baber.com/baber/gifs/411gifs/atc6220large.jpg http://www.watch.impress.co.jp/Akiba/hotline/980418/image/atc1.jpg -- Thanks! Shaddam IV Padishah Emperor of The Known Universe -------------- next part -------------- An HTML attachment was scrubbed... URL: From uwe at hermann-uwe.de Sun Nov 12 22:09:24 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 12 Nov 2006 22:09:24 +0100 Subject: [LinuxBIOS] SMSC FDC37B80x & FDC37M707 code In-Reply-To: <4556B265.8000504@verizon.net> References: <4556B265.8000504@verizon.net> Message-ID: <20061112210924.GD17380@greenwood> On Sun, Nov 12, 2006 at 12:34:29AM -0500, Corey Osgood wrote: > If anyone needs code for either of these two SuperIOs, let me know, I've > ported the lpc47b397 code and it should work fine, but I don't want to > go submitting it until it's tested, and the only boards I have with > these chips are 440bx based. In case you're waiting for my 440BX code here - that's not needed. The Super I/O stuff will work fine even before RAM init. Just use the current bitworks/ims code and replace the Super I/O stuff there for testing the serial console... > BTW, have there been any requests for Slot > A Athlon support, namely the AMD 751 northbridge and Via 686a > southbridge chips? I'm seriously considering working on all 3 of these, That would be great! We're happy about any patches you can provide :) 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 Sun Nov 12 22:38:12 2006 From: yinghailu at gmail.com (yhlu) Date: Sun, 12 Nov 2006 13:38:12 -0800 Subject: [LinuxBIOS] How to add support to a Hyper Transport card In-Reply-To: <42BD91E60E3CAE4CAB3E30EA6A6036F8A37879@exrad3.ad.rad.co.il> References: <42BD91E60E3CAE4CAB3E30EA6A6036F8A37879@exrad3.ad.rad.co.il> Message-ID: <2ea3fae10611121338pca5454cm59d42fbc69e0e686@mail.gmail.com> The htx support is in the tree. Just try it and let me know the status. I have tested one HTX card with it. YH On 11/12/06, Moses Reuben wrote: > > > Hi all > > I have a HT nic (this is a new card) and i want the bios to support it what > should i change in the code && configuration . I have a Iwill/dk8_htx > board. > > Thanks > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > > From uwe at hermann-uwe.de Sun Nov 12 22:50:12 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 12 Nov 2006 22:50:12 +0100 Subject: [LinuxBIOS] RAM controller breakage? In-Reply-To: <200611120745.29099.a1426z@gawab.com> References: <20061111102555.GB21784@greenwood> <4555F249.20901@verizon.net> <20061111172904.GC29518@greenwood> <200611120745.29099.a1426z@gawab.com> Message-ID: <20061112215012.GC19781@greenwood> Hi, [I suppose this was meant to go to the mailing list, forwarding...] On Sun, Nov 12, 2006 at 07:45:29AM +0300, Al Boldi wrote: > Uwe Hermann wrote: > > On Sat, Nov 11, 2006 at 10:54:49AM -0500, Corey Osgood wrote: > > > And did you start from scratch, or modify the > > > code that was already there? > > > > Both, partly. I don't want to do further cut'n'paste programming, > > there's enough of that in the tree already. I started mostly from > > scratch and tried to properly document the code. Some parts I'll reuse > > from the E7501 I guess, and the real know-how is in the V1 440BX code > > (which is working fine for me on my hardware, btw). > > I downloaded LBv1, but it doesn't compile out of the box. > > Is there a special setup/config required to compile it? Yeah, the code and build system is quite old. I had to fix a few things in various Makefiles and comment some broken code. Don't remember the details right now. Not sure whether it makes sense to commit more stuff to v1, even if it's just bugfixes... > > > And a final question for anyone, if I were to do a flash and it not go > > > well, do failsafes like key combonations to pull a bios off a floppy > > > still work, or are those stored in the BIOS? > > > > Won't work, see Ron's post. I have a local svn repository where I > > checkin all my proprietary BIOS images, so I won't lose them no matter > > how much I mess up. > > And I put one or more backups of them on real physical chips, of course. > > If it's of any help, I have a DualBIOS i440bx system, which should make it > easy to try any untested code. Sure, the more testers the better. I'll need a few more days to finish the code, though. > Thanks for your outstanding effort! > > -- > Al 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 Nov 12 23:05:54 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 12 Nov 2006 22:05:54 -0000 Subject: [LinuxBIOS] #44: ACPI collides with smbus/ide on i82801ca southbridge In-Reply-To: <060.fc34b4994817bf37b64beee69e99412c@openbios.org> References: <060.fc34b4994817bf37b64beee69e99412c@openbios.org> Message-ID: <069.2805258419ed6bf717b2f148d48dc22a@openbios.org> #44: ACPI collides with smbus/ide on i82801ca southbridge ----------------------------------+----------------------------------------- Reporter: chn at virtutech.se | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: code | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: there is no patch | ----------------------------------+----------------------------------------- -- Ticket URL: LinuxBIOS From svn at openbios.org Sun Nov 12 23:08:22 2006 From: svn at openbios.org (LinuxBIOS) Date: Sun, 12 Nov 2006 22:08:22 -0000 Subject: [LinuxBIOS] #44: ACPI collides with smbus/ide on i82801ca southbridge In-Reply-To: <060.fc34b4994817bf37b64beee69e99412c@openbios.org> References: <060.fc34b4994817bf37b64beee69e99412c@openbios.org> Message-ID: <069.16f3b3d426b4fd2c0e793ae647390df4@openbios.org> #44: ACPI collides with smbus/ide on i82801ca southbridge -----------------------------------+---------------------------------------- Reporter: chn at virtutech.se | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: code | Version: v2 Resolution: | Keywords: Due_close: MM/DD/YYYY | Include_gantt: 0 Dependencies: | Due_assign: MM/DD/YYYY Patchstatus: patch needs review | -----------------------------------+---------------------------------------- Changes (by uwe): * patchstatus: there is no patch => patch needs review -- Ticket URL: LinuxBIOS From stepan at coresystems.de Mon Nov 13 01:36:13 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 13 Nov 2006 01:36:13 +0100 Subject: [LinuxBIOS] RAM controller breakage? In-Reply-To: <20061112215012.GC19781@greenwood> References: <20061111102555.GB21784@greenwood> <4555F249.20901@verizon.net> <20061111172904.GC29518@greenwood> <200611120745.29099.a1426z@gawab.com> <20061112215012.GC19781@greenwood> Message-ID: <20061113003613.GA1980@coresystems.de> * Uwe Hermann [061112 22:50]: > > Is there a special setup/config required to compile it? > > Yeah, the code and build system is quite old. I had to fix a few things > in various Makefiles and comment some broken code. Don't remember the > details right now. > > Not sure whether it makes sense to commit more stuff to v1, even if it's > just bugfixes... Please go ahead, v1 has a lot more boards. It can't be wrong keeping it at least intact with modern toolchains. Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From stuge-linuxbios at cdy.org Mon Nov 13 01:53:01 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Mon, 13 Nov 2006 01:53:01 +0100 Subject: [LinuxBIOS] Intel 440bx In-Reply-To: References: <45576850.6040002@verizon.net> Message-ID: <20061113005301.10231.qmail@cdy.org> On Sun, Nov 12, 2006 at 07:56:45PM +0100, Shaddam Corrino IV wrote: > At the time I also do not have any extra EEPROMs so I'll have to pick > something and buy. Preferably cheap. > > http://www.baber.com/baber/411/atrendatc6220.htm > http://www.baber.com/baber/gifs/411gifs/atc6220large.jpg > http://www.watch.impress.co.jp/Akiba/hotline/980418/image/atc1.jpg That's a DIP-32. Could you peel of the shiny sticker and send the part number, please? Or find the datasheet yourself, of course. The important parameters are voltage and size. I'm not sure there are any non-5V DIP flashes but please check. Size is almost certainly 128kb or 256kb on the board. Older DIP flashes can have funky pin configuration depending on size so you'll want to check the data sheet of your part. If you're not sure how just send us the part number and we'll try to help. Also, do you know any local electronic component stores that have online inventories? Then we could try to find an equivalent for you. //Peter From corey_osgood at verizon.net Mon Nov 13 04:35:40 2006 From: corey_osgood at verizon.net (Corey Osgood) Date: Sun, 12 Nov 2006 22:35:40 -0500 Subject: [LinuxBIOS] SMSC FDC37B80x & FDC37M707 code In-Reply-To: <20061112210924.GD17380@greenwood> References: <4556B265.8000504@verizon.net> <20061112210924.GD17380@greenwood> Message-ID: <4557E80C.8050602@verizon.net> Uwe Hermann wrote: > In case you're waiting for my 440BX code here - that's not needed. The > Super I/O stuff will work fine even before RAM init. > Just use the current bitworks/ims code and replace the Super I/O stuff there > for testing the serial console... Err...the two boards I have with those superio's are the damn intels with the tsops, so they need somewhat of a guarantee of booting (and being able to be reflashed) before I can test them. >> BTW, have there been any requests for Slot >> A Athlon support, namely the AMD 751 northbridge and Via 686a >> southbridge chips? I'm seriously considering working on all 3 of these, >> > > That would be great! We're happy about any patches you can provide :) > Alright, I'm already working on it. This southbridge has an integrated Super I/O, should I be including the Super I/O code in with the southbridge, or seperating them out? Or does it really matter? Seem to me that the first way would be easier, but the second would make it easier to debug, and in case there are other motherboards that use the same southbridge but an off-chip super io (dunno if there are any). I haven't looked yet to see how v1 does it. Anyways, let me know, I can do it either way (currently still working on making sure the CPU works right, these early athlons were a bit funky, from what I've read so far). -Corey From shaddamcorrinoiv at gmail.com Mon Nov 13 05:06:20 2006 From: shaddamcorrinoiv at gmail.com (Shaddam Corrino IV) Date: Mon, 13 Nov 2006 05:06:20 +0100 Subject: [LinuxBIOS] Intel 440bx In-Reply-To: References: <45576850.6040002@verizon.net> Message-ID: [please cc] *Peter Stuge* wrote: > On Sun, Nov 12, 2006 at 07:56:45PM +0100, Shaddam Corrino IV wrote: > >* At the time I also do not have any extra EEPROMs so I'll have to pick > *>* something and buy. Preferably cheap. > *>* > *>* http://www.baber.com/baber/411/atrendatc6220.htm > *>* http://www.baber.com/baber/gifs/411gifs/atc6220large.jpg > *>* http://www.watch.impress.co.jp/Akiba/hotline/980418/image/atc1.jpg > * > That's a DIP-32. Could you peel of the shiny sticker and send the > part number, please? > > Winbond W29C020-90 Or find the datasheet yourself, of course. The important parameters > are voltage and size. > > I found www.romstore.ru/pdf/*W29c020*.pdf btw: does any kind soul has data sheet for s3 86C357 (Virge GX2) I'm not sure there are any non-5V DIP flashes but please check. > Size is almost certainly 128kb or 256kb on the board. > > It seems it is DIP-32 5V 256KiB. > Older DIP flashes can have funky pin configuration depending on size > so you'll want to check the data sheet of your part. If you're not > sure how just send us the part number and we'll try to help. > > Is this one of those funky models? > Also, do you know any local electronic component stores that have > online inventories? Then we could try to find an equivalent for you. > > My idea was to either take (a) the specs of the original chip or (b) list of all equivalent (LB approved) models and visit all nearby electronics stores. Not sure which idea is better. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuge-linuxbios at cdy.org Mon Nov 13 08:15:17 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Mon, 13 Nov 2006 08:15:17 +0100 Subject: [LinuxBIOS] Intel 440bx In-Reply-To: References: <45576850.6040002@verizon.net> Message-ID: <20061113071518.29446.qmail@cdy.org> On Mon, Nov 13, 2006 at 05:06:20AM +0100, Shaddam Corrino IV wrote: > >That's a DIP-32. Could you peel of the shiny sticker and send the > >part number, please? > > Winbond W29C020-90 > > >I'm not sure there are any non-5V DIP flashes but please check. > >Size is almost certainly 128kb or 256kb on the board. > > It seems it is DIP-32 5V 256KiB. Yep, certainly is. > >Older DIP flashes can have funky pin configuration depending on > >size so you'll want to check the data sheet of your part. If > >you're not ure how just send us the part number and we'll try to > > help. > > Is this one of those funky models? Nope, this has the standard pinout. > >Also, do you know any local electronic component stores that have > >online inventories? Then we could try to find an equivalent for you. > > My idea was to either take (a) the specs of the original chip or (b) > list of all equivalent (LB approved) models and visit all nearby > electronics stores. > Not sure which idea is better. Really any 5V 32-pin DIP 256 (probably also 512) kb flash with the same pinout will be compatible. Lots of different chips. The list of "LB approved" chips would be the list of supported chips in the utility flashrom, but that just depends on what has been available to developers since adding a new chip is quite simple with few if any exceptions. Here are the candidates: Am29F040B, At29C040A, Mx29f002, SST29EE020A, SST28SF040A, SST39SF020A, SST39SF040, W29C020C, M29F040B, M29F400BT from AMD, Atmel, Macronix, SST, Winbond and ST. //Peter From moses_r at Commex-technologies.com Mon Nov 13 10:07:55 2006 From: moses_r at Commex-technologies.com (Moses Reuben) Date: Mon, 13 Nov 2006 11:07:55 +0200 Subject: [LinuxBIOS] How to add support to a Hyper Transport card In-Reply-To: <2ea3fae10611121338pca5454cm59d42fbc69e0e686@mail.gmail.com> Message-ID: <42BD91E60E3CAE4CAB3E30EA6A6036F8A3787A@exrad3.ad.rad.co.il> Hi I read somewhere that I need to configure on what ht link the card is . I tried to boot with the card and the bios didn't do no init for it ( on the iwill bios the card boots well ). Thanks -----Original Message----- From: yhlu [mailto:yinghailu at gmail.com] Sent: Sunday, November 12, 2006 23:38 To: Moses Reuben Cc: linuxbios at linuxbios.org Subject: Re: [LinuxBIOS] How to add support to a Hyper Transport card The htx support is in the tree. Just try it and let me know the status. I have tested one HTX card with it. YH On 11/12/06, Moses Reuben wrote: > > > Hi all > > I have a HT nic (this is a new card) and i want the bios to support it > what should i change in the code && configuration . I have a > Iwill/dk8_htx board. > > Thanks > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > > From yinghailu at gmail.com Mon Nov 13 10:24:23 2006 From: yinghailu at gmail.com (yhlu) Date: Mon, 13 Nov 2006 01:24:23 -0800 Subject: [LinuxBIOS] How to add support to a Hyper Transport card In-Reply-To: <42BD91E60E3CAE4CAB3E30EA6A6036F8A3787A@exrad3.ad.rad.co.il> References: <2ea3fae10611121338pca5454cm59d42fbc69e0e686@mail.gmail.com> <42BD91E60E3CAE4CAB3E30EA6A6036F8A3787A@exrad3.ad.rad.co.il> Message-ID: <2ea3fae10611130124y31de6952y1e65b97b09ab4811@mail.gmail.com> On 11/13/06, Moses Reuben wrote: > I read somewhere that I need to configure on what ht link the card is . > I tried to boot with the card and the bios didn't do no init for it ( on > the iwill bios the card boots well ). So LinuxBIOS has problem with your card on the MB? Boot Log? YH From shaddamcorrinoiv at gmail.com Mon Nov 13 17:45:58 2006 From: shaddamcorrinoiv at gmail.com (Shaddam Corrino IV) Date: Mon, 13 Nov 2006 17:45:58 +0100 Subject: [LinuxBIOS] Intel 440bx In-Reply-To: <20061113071518.29446.qmail@cdy.org> References: <45576850.6040002@verizon.net> <20061113071518.29446.qmail@cdy.org> Message-ID: On 11/13/06, Peter Stuge wrote: > > My idea was to either take [...] visit all nearby electronics stores. > > Really any 5V 32-pin DIP 256 (probably also 512) kb flash with the > same pinout will be compatible. Lots of different chips. I was looking around today and all that I could find was "certified pre-owned" 256KiB flash ROMs for around $6 each. Since as I understand 440BX is not ready for testing, I guess I can take time looking around for better deal. I could check out two bazaars this weekend. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsylla at gmail.com Mon Nov 13 22:00:35 2006 From: tsylla at gmail.com (Tom Sylla) Date: Mon, 13 Nov 2006 16:00:35 -0500 Subject: [LinuxBIOS] what is i2cmux2? Message-ID: <57947bf80611131300n798c26ecv7fbc143d88ed1da5@mail.gmail.com> As part of Broadcom Blast, yhlu checked in a new i2c mux file, i2cmux2. I see a one line addition: smbus_write_byte(dev, 0x03, 0); // all output What is this for? Is required for the HT1000? or is it required for the particular mux on the Blast platform? Can that answer be documented somewhere? Is there a better way to do this than to duplicate and stick on a '2'? Thanks From yinghai.lu at amd.com Mon Nov 13 22:12:31 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Mon, 13 Nov 2006 13:12:31 -0800 Subject: [LinuxBIOS] what is i2cmux2? Message-ID: <5986589C150B2F49A46483AC44C7BCA49071F5@ssvlexmb2.amd.com> That is MB related. So normally you don't need i2cmux for 2 way opteron's RAM spd access. The i2c mux has two bits for one link First for: in/out, second is enabling which link. YH -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Tom Sylla Sent: Monday, November 13, 2006 1:01 PM To: yhlu; linuxbios at linuxbios.org Subject: [LinuxBIOS] what is i2cmux2? As part of Broadcom Blast, yhlu checked in a new i2c mux file, i2cmux2. I see a one line addition: smbus_write_byte(dev, 0x03, 0); // all output What is this for? Is required for the HT1000? or is it required for the particular mux on the Blast platform? Can that answer be documented somewhere? Is there a better way to do this than to duplicate and stick on a '2'? Thanks -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios From moses_r at Commex-technologies.com Tue Nov 14 07:05:50 2006 From: moses_r at Commex-technologies.com (Moses Reuben) Date: Tue, 14 Nov 2006 08:05:50 +0200 Subject: [LinuxBIOS] Filo with Sata Message-ID: <42BD91E60E3CAE4CAB3E30EA6A6036F8A3787E@exrad3.ad.rad.co.il> Hi all Can i use filo with sata disk or i must use etherboot? thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey_osgood at verizon.net Tue Nov 14 07:43:13 2006 From: corey_osgood at verizon.net (Corey) Date: Tue, 14 Nov 2006 01:43:13 -0500 Subject: [LinuxBIOS] Intel 440bx In-Reply-To: References: <45576850.6040002@verizon.net> <20061113071518.29446.qmail@cdy.org> Message-ID: <1163486594.13317.8.camel@ampfs.soundroom> On Mon, 2006-11-13 at 17:45 +0100, Shaddam Corrino IV wrote: > > > On 11/13/06, Peter Stuge wrote: > > My idea was to either take [...] visit all nearby > electronics stores. > > Really any 5V 32-pin DIP 256 (probably also 512) kb flash with > the > same pinout will be compatible. Lots of different chips. > > I was looking around today and all that I could find was "certified > pre-owned" 256KiB flash ROMs for around $6 each. > > Since as I understand 440BX is not ready for testing, I guess I can > take time looking around for better deal. > I could check out two bazaars this weekend. I'm in the same situation...I'm looking for them both for the P2-99 (NOT P2B that it was supposed to be, dammit) that I'll be getting soon from fleabay, and the Slot A board that I'm working on now, and possibly even my Intel i815 board once I've messed around with (and messed up) the Slot A. The only local store that might have such a thing pissed me off last time I was in there, so I've turned to the net, but it seems most suppliers are interested in orders larger than 4 chips (2 for each board). Did manage to find out that FrozenCPU.com carries the Bios Saviors, and I've never had a bad experience with them, I've used them several times over the years, and when you figure in shipping, they're quite a bit cheaper than direct from ioss. -Corey From stuge-linuxbios at cdy.org Tue Nov 14 10:32:05 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Tue, 14 Nov 2006 10:32:05 +0100 Subject: [LinuxBIOS] Intel 440bx In-Reply-To: <1163486594.13317.8.camel@ampfs.soundroom> References: <45576850.6040002@verizon.net> <20061113071518.29446.qmail@cdy.org> <1163486594.13317.8.camel@ampfs.soundroom> Message-ID: <20061114093205.28007.qmail@cdy.org> On Tue, Nov 14, 2006 at 01:43:13AM -0500, Corey wrote: > On Mon, 2006-11-13 at 17:45 +0100, Shaddam Corrino IV wrote: > > I was looking around today and all that I could find was "certified > > pre-owned" 256KiB flash ROMs for around $6 each. [..] > board). Did manage to find out that FrozenCPU.com carries the Bios > Saviors, and I've never had a bad experience with them, I've used > them several times over the years, and when you figure in shipping, > they're quite a bit cheaper than direct from ioss. The BIOS savior $25 is definately worthwhile. Zero risk of shorting the mainboard out while hotswapping flash chips then. //Peter From stepan at coresystems.de Tue Nov 14 11:13:01 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 14 Nov 2006 11:13:01 +0100 Subject: [LinuxBIOS] Filo with Sata In-Reply-To: <42BD91E60E3CAE4CAB3E30EA6A6036F8A3787E@exrad3.ad.rad.co.il> References: <42BD91E60E3CAE4CAB3E30EA6A6036F8A3787E@exrad3.ad.rad.co.il> Message-ID: <20061114101301.GA6915@coresystems.de> * Moses Reuben [061114 07:05]: > Hi all > > Can i use filo with sata disk or i must use etherboot? normal FILO should work. Let me know if it does not. -- 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 svante.signell at telia.com Tue Nov 14 11:39:39 2006 From: svante.signell at telia.com (Svante Signell) Date: Tue, 14 Nov 2006 11:39:39 +0100 Subject: [LinuxBIOS] [Fwd: Re: Intel 440bx] Message-ID: <1163500779.1215.0.camel@em2.my.own.domain> -------- Forwarded Message -------- > From: Svante Signell > To: linuxibios at linuxbios.org > Cc: svante.signell at telia.com > Subject: Re: [LinuxBIOS] Intel 440bx > Date: Tue, 14 Nov 2006 11:34:16 +0100 > > I'm very interested in the development for 440BX in V2. I have a Dual > CPU MSI-6120 with overclocked P2 Celerons. Below are some excerpts from > emails exchanged between the list and me in January this year. I also > have at least 2 more boxes with the same chipset if everything works out > OK with the Dual CPU box I would replace the BIOS in these too. BTW: How > to backup the old BIOS to a replacement chip before starting? Is that > supported by flashrom? > > Thanks, > Svante Signell > > On Tue, 2006-11-14 at 10:32 +0100, Peter Stuge wrote: > > On Tue, Nov 14, 2006 at 01:43:13AM -0500, Corey wrote: > > > On Mon, 2006-11-13 at 17:45 +0100, Shaddam Corrino IV wrote: > > > > I was looking around today and all that I could find was "certified > > > > pre-owned" 256KiB flash ROMs for around $6 each. > > > > [..] > > > > > board). Did manage to find out that FrozenCPU.com carries the Bios > > > Saviors, and I've never had a bad experience with them, I've used > > > them several times over the years, and when you figure in shipping, > > > they're quite a bit cheaper than direct from ioss. > > > > The BIOS savior $25 is definately worthwhile. Zero risk of shorting > > the mainboard out while hotswapping flash chips then. > > > > > > //Peter > > > ================================================== > Hello, > > I have been communicating with the Linuxbios mailing list on and off > (mostly off lately). I'm interested to try out the linuxBIOS on my old > dual CPU board MSI-6120. The current MSI/AMI BIOS V2.0 does not support > newer CPUs than Coppermine. > > Currently I have two old PII processors (Mendocino) installed and would > like to upgrade to one Celeron 2 or dual PIIIs (Tualatin) using one or > two "Upgradeware SLOT-T" slot 1 to socket 370 adapters. A 1.3GHz Celeron > 2 boots with this new CPU but runs _extremely_ slow, at around 8MHz > compared to expected 1.3GHz. This has been reported before in the thread > 'Level 2 cache activation code' in late 2003. > > Where can I purchase a replacement BIOS chip? Placed in a socket on the > main board is a 2x16 pin DIL labeled: 686 AMI BIOS 1995 CS 92222. > > lspci shows: > 0000:00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host > bridge (rev 03) > 0000:00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP > bridge (rev 03) > 0000:00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02) > 0000:00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) > 0000:00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev > 01) > 0000:00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02) > 0000:00:0f.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX > [Cyclone] (rev 30) > 0000:00:10.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 > (rev 05) > 0000:00:10.1 Input device controller: Creative Labs SB Live! MIDI/Game > Port (rev 05) > 0000:01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 > AGP (rev 04) > > ======================================================= > On Wed, 2005-01-12 at 18:12 +0100, Peter Stuge wrote: > > On Wed, Jan 12, 2005 at 10:38:57AM +0100, Svante Signell wrote: > > > Where can I purchase a replacement BIOS chip? Placed in a socket on > > > the main board is a 2x16 pin DIL labeled: 686 AMI BIOS 1995 CS > > > 92222. > > > > Please remove the shiny sticker and check how the actual package is > > marked. You're looking for thin letters and numbers "engraved" on > > top of the black plastic. Look for 29F020 or something similar. > > I found the BIOS chip brand and version: Its a Winbond W29C020-90 > (84400M282325601VA). Any suppliers available somehere? > Is it large enough to host LinuxBIOS? > > My dual-CPU MSI-6120 MOBO has on-board dual channel Adaptec 7895 SCSI > support. Does V1 support this? What about the FSB settings avalaible in > the MSI/AMI BIOS v2.0: 100MHz, 103MHz, 112MHz, 133MHz? > It would be nice to run the board at 133MHz, eqipped with an 1.4GHz > Tualatin Celeron 2 or dual PIIIs. (Or VIA C3 1.0-1.4GHz, currently > single CPU, and hopefully soon dual CPU) > > =========================================================== > On Thu, 2005-01-13 at 16:23 -0600, Richard Smith wrote: > ... > > > > > > no idea on the FSB settings -- I think linuxbios always goes with > the > > > fastest :-) > > > > The FSB is set via the clock chip. The clock chip we have is set via > > straps. I'm not sure what your commercial bios is doing but the 440bx > > is not rated for over 100Mhz. So those other settings are > > overclockings. And they will change the speed of your PCI bus as > > well. > > I know about the 100MHz rating for 440BX. However, on the board you can > select 66/100 MHz FSB and the BIOS supports the higher FSB speeds. Also > the board has multiplier settings (3-5) x (66,100) MHz = 200-500 MHz for > CPUs with changable clock multipliers. The board runs today with dual > Celeron (Mendocino, 300MHz, before Intel disabled dual on Celerons) at > 103/66*300MHz = 466MHz stably for many years now. > > BTW: The memories I have installed are all PC133 parts. > > > I suspect your board has a small microcontroller on it with eeprom > > that sets the strap settings on boot and then de-asserts reset. That > > or it boots in 66Mhz and then sets the clock chip after that. > > > > Anybody know what clock chip is on that board? > > Where to look for that chip? > > The board also has a system manager jumper: Selectable between the > SuperIO chip (default) vs. the PIIX4E (southbridge). Wht is the meaning > of this choice? > > I have the board description in pdf-format available if someone is > interested. > -- Svante Signell From stuge-linuxbios at cdy.org Tue Nov 14 12:25:05 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Tue, 14 Nov 2006 12:25:05 +0100 Subject: [LinuxBIOS] [Fwd: Re: Intel 440bx] In-Reply-To: <1163500779.1215.0.camel@em2.my.own.domain> References: <1163500779.1215.0.camel@em2.my.own.domain> Message-ID: <20061114112505.11890.qmail@cdy.org> On Tue, Nov 14, 2006 at 11:39:39AM +0100, Svante Signell wrote: > BTW: How to backup the old BIOS to a replacement chip before > starting? Is that supported by flashrom? Yes. You can use flashrom to read and save your original BIOS, then hotswap the flash chip, then write out your original BIOS to the newly inserted chip. > I found the BIOS chip brand and version: Its a Winbond W29C020-90 > Any suppliers available somehere? Seems it's a bit hard to come by those old DIP packages in Sweden. ELFA and Bejoken only have PLCC or TSOP. Farnell has something: 1201510 Am29F040B-90PD 40.43kr in stock > Is it large enough to host LinuxBIOS? Your original chip is 256kb, LinuxBIOS is typically 16 or 32kb excluding the payload. The Farnell chip is 512kb so unfortunately not enough room for a Linux kernel without quite an effort. :\ Payloads like FILO or Etherboot will fit just fine and leave plenty room for a VGA BIOS. //Peter From ward at gnu.org Tue Nov 14 15:06:23 2006 From: ward at gnu.org (Ward Vandewege) Date: Tue, 14 Nov 2006 09:06:23 -0500 Subject: [LinuxBIOS] Filo with Sata In-Reply-To: <42BD91E60E3CAE4CAB3E30EA6A6036F8A3787E@exrad3.ad.rad.co.il> References: <42BD91E60E3CAE4CAB3E30EA6A6036F8A3787E@exrad3.ad.rad.co.il> Message-ID: <20061114140623.GA7021@countzero.vandewege.net> On Tue, Nov 14, 2006 at 08:05:50AM +0200, Moses Reuben wrote: > Hi all > > Can i use filo with sata disk or i must use etherboot? No need for etherboot, filo supports SATA. It's a bit finicky though; make sure the sata drive you're trying to boot from is connected to the first sata port. Thanks, Ward. From rminnich at gmail.com Tue Nov 14 14:28:05 2006 From: rminnich at gmail.com (ron minnich) Date: Tue, 14 Nov 2006 06:28:05 -0700 Subject: [LinuxBIOS] what is i2cmux2? In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49071F5@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49071F5@ssvlexmb2.amd.com> Message-ID: <13426df10611140528s29b534f1qa89d3fc29f06a0b7@mail.gmail.com> On 11/13/06, Lu, Yinghai wrote: > That is MB related. > > So normally you don't need i2cmux for 2 way opteron's RAM spd access. > > The i2c mux has two bits for one link > First for: in/out, second is enabling which link. these are increasingly common ... ron From dhbarr at gozelle.com Tue Nov 14 23:06:57 2006 From: dhbarr at gozelle.com (David H. Barr) Date: Tue, 14 Nov 2006 16:06:57 -0600 Subject: [LinuxBIOS] google, qa.linuxbios.org Message-ID: From... http://google-code-updates.blogspot.com/2006/11/ google-sponsors-linuxbios-project.html ...by way of... http://www.linuxbios.org/Press "Anyone with a spare board supported by LinuxBIOS is welcome to put it into the automated test system, thus helping the LinuxBIOS project increase their quality on your hardware." More details? Let's say, for instance, that I wanted to donate a test board for one or more of the soon-to-be AM2 desktops; how would I go about accomplishing this? -dhbarr. From svn at openbios.org Tue Nov 14 23:35:58 2006 From: svn at openbios.org (LinuxBIOS) Date: Tue, 14 Nov 2006 22:35:58 -0000 Subject: [LinuxBIOS] #46: Clarify LinuxBIOS vs. OpenBIOS vs. Open Firmware vs. EFI vs. GNUFI etc. Message-ID: <060.6ee43039a33bdaed5ba9db2e759b8ac6@openbios.org> #46: Clarify LinuxBIOS vs. OpenBIOS vs. Open Firmware vs. EFI vs. GNUFI etc. --------------------------------------+------------------------------------- Reporter: uwe | Owner: somebody Type: task | Status: new Priority: critical | Milestone: Going mainstream Component: wiki/website/tracker | Version: v2 Keywords: | Due_close: MM/DD/YYYY Include_gantt: 0 | Dependencies: Due_assign: MM/DD/YYYY | Patchstatus: there is no patch --------------------------------------+------------------------------------- There seems to be a lot of confusion about LinuxBIOS itself in the "general public", but also when it comes to comparing LinuxBIOS to similar projects and systems, e.g. OpenBIOS, Open Firmware, EFI, GNUFI, uboot, etc. etc. We should have an easily understandable (for non-techsavvy people) entry in the FAQ which outlines what all those projects are about, their goals, pros, and cons. -- Ticket URL: LinuxBIOS From ddrake at brontes3d.com Wed Nov 15 23:26:57 2006 From: ddrake at brontes3d.com (Daniel Drake) Date: Wed, 15 Nov 2006 17:26:57 -0500 Subject: [LinuxBIOS] Failure with Tyan K8WE S2895 Message-ID: <1163629617.12302.20.camel@systems03.lan.brontes3d.com> Hi, I just attempted my first LinuxBIOS install and didn't succeed: The system no longer boots. This is a Tyan K8WE motherboard. When I plug the power in, the fans spin and lights come on very briefly, then everything stops and the PC speaker emits 9 beeps. It then pauses, beeps 9 times, pauses, 9 beeps, ... Pressing the power button restarts this cycle (lights and fans come on, then stop, then the beeping cycle restarts) I have connected a serial console no data is being sent out of the serial port at this time. Are problems such as this common? Any ideas for what might have caused it or how it can be diagnosed? I have not yet performed a hotswap reflash fix on another board. Here is the process I used to build and flash the system: Checked out filo from svn. Ran "make", modified Config: USE_GRUB = 0 AUTOBOOT_FILE = "hde1:/vmlinuz root=/dev/sda5" AUTOBOOT_DELAY = 5 Ran "make". Checked out r2497 of LinuxBIOSv2 from SVN. Made this change, as I am compiling on x86-64: > > Index: src/mainboard/tyan/s2895/Options.lb > =================================================================== > --- src/mainboard/tyan/s2895/Options.lb (revision 2497) > +++ src/mainboard/tyan/s2895/Options.lb (working copy) > @@ -234,8 +234,8 @@ > ## > ## The default compiler > ## > -default CC="$(CROSS_COMPILE)gcc-4.0.2 -m32" > -default HOSTCC="gcc-4.0.2" > +default CC="$(CROSS_COMPILE)gcc -m32" > +default HOSTCC="gcc -m32" > > ## > ## Disable the gdb stub by default Modified targets/tyan/Config.lb to point to my filo.elf payload from earlier. cd targets ./buildtarget tyan/s2895 cd tyan/s2895/s2895 make Then, on the target system: ./flashrom -r vendor.rom ./flashrom -c SST49LF080A -V -w linuxbios.rom ./flashrom -c SST49LF080A --force -v linuxbios.rom No errors. At this point I accidently rebooted, and it froze (could this have caused the problem?) I then replugged the power and observed the above results. Thanks! -- Daniel Drake Brontes Technologies, A 3M Company From yinghai.lu at amd.com Wed Nov 15 23:44:03 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Wed, 15 Nov 2006 14:44:03 -0800 Subject: [LinuxBIOS] Failure with Tyan K8WE S2895 Message-ID: <5986589C150B2F49A46483AC44C7BCA4907202@ssvlexmb2.amd.com> 1. Mem size? 2. Linux Kernel version when you are flashing linuxbios.rom? 3. you need to use tiny kernel to boot from SATA. YH From russ at ashlandhome.net Wed Nov 15 17:47:29 2006 From: russ at ashlandhome.net (Russ Whitaker) Date: Wed, 15 Nov 2006 08:47:29 -0800 (PST) Subject: [LinuxBIOS] google, qa.linuxbios.org In-Reply-To: References: Message-ID: Be prepaired for a flood of intrest. Mr. Barr's email is just a start. An article on linuxbios was posted on slashdot ( http://slashdot.org ) this am. And your server got "slashdotted". Russ On Tue, 14 Nov 2006, David H. Barr wrote: > From... > http://google-code-updates.blogspot.com/2006/11/ > google-sponsors-linuxbios-project.html > ...by way of... > http://www.linuxbios.org/Press > From segher at kernel.crashing.org Thu Nov 16 11:34:59 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Thu, 16 Nov 2006 11:34:59 +0100 Subject: [LinuxBIOS] google, qa.linuxbios.org In-Reply-To: References: Message-ID: > And your server got "slashdotted". Really? We hardly noticed ;-) Segher From stepan at coresystems.de Thu Nov 16 12:23:17 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 16 Nov 2006 12:23:17 +0100 Subject: [LinuxBIOS] google, qa.linuxbios.org In-Reply-To: References: Message-ID: <20061116112317.GA12227@coresystems.de> * Segher Boessenkool [061116 11:34]: > > And your server got "slashdotted". > > Really? We hardly noticed ;-) Just as a quick note: The server (2*Opteron 1.8GHz, 2GB RAM) was running at a permanent load of 120 for several hours and was not too responsive during that time. I fixed some of the issues after searching for slashdotting survival hints on the web. So in case this happens again, we should not be experiencing the same break-down in future. As a side node: We've been having 15-20k hits per day on the main page in the last 2 days. And that's only those that got through ;) 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 Thu Nov 16 12:25:23 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 16 Nov 2006 12:25:23 +0100 Subject: [LinuxBIOS] google, qa.linuxbios.org In-Reply-To: References: Message-ID: <20061116112523.GB12227@coresystems.de> * David H. Barr [061114 23:06]: > "Anyone with a spare board supported by LinuxBIOS is welcome to put > it into the automated test system, thus helping the LinuxBIOS project > increase their quality on your hardware." > > More details? Let's say, for instance, that I wanted to donate a test > board for one or more of the soon-to-be AM2 desktops; how would I > go about accomplishing this? I am in the progress of preparing proper documentation on how to get the systems integrated. A little bit of a foretaste is available at http://www.coresystems.de/PDFs/LinuxBIOS-QA.pdf Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From segher at kernel.crashing.org Thu Nov 16 12:37:26 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Thu, 16 Nov 2006 12:37:26 +0100 Subject: [LinuxBIOS] google, qa.linuxbios.org In-Reply-To: <20061116112317.GA12227@coresystems.de> References: <20061116112317.GA12227@coresystems.de> Message-ID: <0B648FA1-75C7-456F-8C59-66A12EA6D9D9@kernel.crashing.org> >>> And your server got "slashdotted". >> >> Really? We hardly noticed ;-) > > Just as a quick note: The server (2*Opteron 1.8GHz, 2GB RAM) > was running at a permanent load of 120 for several hours and > was not too responsive during that time. Sure, but it didn't break down; each and every single request I did still got through. > I fixed some of the issues after searching for slashdotting survival > hints on the web. So in case this happens again, we should not be > experiencing the same break-down in future. Great great, thank you! > As a side node: We've been having 15-20k hits per day on the main page > in the last 2 days. And that's only those that got through ;) That's not so much then ;-) Segher From ddrake at brontes3d.com Thu Nov 16 15:07:32 2006 From: ddrake at brontes3d.com (Daniel Drake) Date: Thu, 16 Nov 2006 09:07:32 -0500 Subject: [LinuxBIOS] Failure with Tyan K8WE S2895 In-Reply-To: <5986589C150B2F49A46483AC44C7BCA4907202@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA4907202@ssvlexmb2.amd.com> Message-ID: <1163686052.27579.1.camel@systems03.lan.brontes3d.com> On Wed, 2006-11-15 at 14:44 -0800, Lu, Yinghai wrote: > 1. Mem size? 2GB > 2. Linux Kernel version when you are flashing linuxbios.rom? 2.6.18.2 > 3. you need to use tiny kernel to boot from SATA. I'm using FILO as a payload, not a kernel directly -- does the size of the kernel still matter? Would a payload/kernel issue really cause this kind of problem? I'd expect more than 0.5 seconds of life from the system anyway, I'd be happy if it gave me a prompt or similar. Thanks! Daniel From myles at pel.cs.byu.edu Thu Nov 16 15:46:54 2006 From: myles at pel.cs.byu.edu (Myles Watson) Date: Thu, 16 Nov 2006 07:46:54 -0700 Subject: [LinuxBIOS] Failure with Tyan K8WE S2895 In-Reply-To: <1163686052.27579.1.camel@systems03.lan.brontes3d.com> Message-ID: <01M9MEYAT0HY8YT7JZ@EMAIL1.BYU.EDU> > I'm using FILO as a payload, not a kernel directly -- does the size of > the kernel still matter? Would a payload/kernel issue really cause this > kind of problem? I'd expect more than 0.5 seconds of life from the > system anyway, I'd be happy if it gave me a prompt or similar. FILO doesn't have the drivers necessary to control the SATA drives on the NVIDIA CK804 chipset. That's why you need a tiny kernel. I ran into the same problem and ended up adding an IDE drive to the system so that I could boot, at least until I could get a tiny kernel into the ROM. My symptoms were different, though. My machine came up to a prompt and then couldn't find the drive. The fact that your machine is beeping seems weird to me. I haven't seen LinuxBIOS beeping for failures. Have you looked up the code to see if your factory BIOS can explain the beep codes? Myles > Thanks! > Daniel From gianci at email.it Wed Nov 15 09:37:36 2006 From: gianci at email.it (Giampiero Giancipoli) Date: Wed, 15 Nov 2006 09:37:36 +0100 Subject: [LinuxBIOS] flashrom: patch for jedec.c Message-ID: <20061115083736.GA9762@fredreggiane.com> Hi to all, I used flashrom to flash the BIOS on a AxiomTek SBC84500, which mounts a Winbond W29C020C. All is recognized fine, but the flashing fails. # flashrom -v -w axiom.bin No LinuxBIOS table found. Enabling flash write on CS5530...OK W29C020C found at physical address: 0xfffc0000 Flash part is S29C51002T (256 KB) Flash image seems to be a legacy BIOS. Disabling checks. Programming Page: 2047 at address: 0x0003ff80 Verifying flash - FAILED. Trying fo find out the cause of the failure I eventually found a grave error in jedec.c, at write_page_write_jedec(). The code: if (*src == 0xFF) continue; *dst++ = *src++; is, of course, wrong. It should be if (*src != 0xFF ) *dst = *src; dst++; src++; I include a patch which fixes this error. But this is not enough. Sector writes sometimes fail, so included a check/rewrite code similar to write_byte_program_jedec(). Maybe this is not the best way to do the task, but at least for me works :) Furthermore, the patch adds support for the SyncMos S29C51002T 256K flash. Tested successfully on a Boser HS-2603. It is high probable that the same configuration would work with all the chips of the same family. # flashrom -v -w boser.bin No LinuxBIOS table found. Enabling flash write on CS5530...OK S29C51002T found at physical address: 0xfffc0000 Flash part is S29C51002T (256 KB) Flash image seems to be a legacy BIOS. Disabling checks. Programming Page: 2047 at address: 0x0003ff80 Verifying flash - VERIFIED That's all. Ciao. -------------- next part -------------- Index: jedec.c =================================================================== --- jedec.c (revision 2497) +++ jedec.c (working copy) @@ -134,23 +134,48 @@ int write_page_write_jedec(volatile uint8_t *bios, uint8_t *src, volatile uint8_t *dst, int page_size) { - int i; + int i, tried = 0, start_index = 0, ok; + volatile uint8_t *d = dst; + uint8_t *s = src; +retry: /* Issue JEDEC Data Unprotect comand */ *(volatile uint8_t *) (bios + 0x5555) = 0xAA; *(volatile uint8_t *) (bios + 0x2AAA) = 0x55; *(volatile uint8_t *) (bios + 0x5555) = 0xA0; /* transfer data from source to destination */ - for (i = 0; i < page_size; i++) { + for (i = start_index; i < page_size; i++) { /* If the data is 0xFF, don't program it */ - if (*src == 0xFF) - continue; - *dst++ = *src++; + if (*src != 0xFF ) + *dst = *src; + dst++; + src++; } toggle_ready_jedec(dst - 1); + dst = d; + src = s; + ok = 1; + for (i = 0; i < page_size; i++) { + if (*src != 0xFF) + if ( *dst != *src ) + { + ok = 0; + break; + } + dst++; + src++; + } + + if (!ok && tried++ < 0x10) { + start_index = i; + goto retry; + } + if (!ok) { + fprintf( stderr, " page %d failed!\n", (d-bios)/page_size ); + } return 0; } Index: flashchips.c =================================================================== --- flashchips.c (revision 2497) +++ flashchips.c (working copy) @@ -114,6 +114,8 @@ #endif {"LHF00L04", SHARP_ID, SHARP_LHF00L04, NULL, 1024, 64 * 1024, probe_lhf00l04, erase_lhf00l04, write_lhf00l04, NULL}, + {"S29C51002T", SM_ID, S29C51002T, NULL, 256, 128, + probe_jedec, erase_chip_jedec, write_49f002, NULL}, {NULL,} }; -------------- 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 Nov 16 21:41:31 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 16 Nov 2006 21:41:31 +0100 Subject: [LinuxBIOS] More payloads? Message-ID: <20061116204131.GK10794@greenwood> Hi, for the wiki: Do we have confirmed boots of any payloads not yet listed in the wiki? E.g. Open Firmware, GNUFI, GRUB2, etc? If yes, they should be added to the front page. 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 Nov 16 21:45:02 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 16 Nov 2006 21:45:02 +0100 Subject: [LinuxBIOS] flashrom: patch for jedec.c In-Reply-To: <20061115083736.GA9762@fredreggiane.com> References: <20061115083736.GA9762@fredreggiane.com> Message-ID: <20061116204502.GL10794@greenwood> Hi, On Wed, Nov 15, 2006 at 09:37:36AM +0100, Giampiero Giancipoli wrote: > + goto retry; Um, do we really want to use GOTOs in userland code? There are some GOTOs in the LinuxBIOS code already, but I'd rather remove those than introduce new ones... Is there a consensus about GOTO usage in LinuxBIOS? Do we allow that? If no, I'll update the development guidelines accordingly... 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 stuge-linuxbios at cdy.org Fri Nov 17 01:41:06 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 17 Nov 2006 01:41:06 +0100 Subject: [LinuxBIOS] coding style: goto good or bad? In-Reply-To: <20061116204502.GL10794@greenwood> References: <20061115083736.GA9762@fredreggiane.com> <20061116204502.GL10794@greenwood> Message-ID: <20061117004106.1410.qmail@cdy.org> On Thu, Nov 16, 2006 at 09:45:02PM +0100, Uwe Hermann wrote: > On Wed, Nov 15, 2006 at 09:37:36AM +0100, Giampiero Giancipoli wrote: > > + goto retry; > > Um, do we really want to use GOTOs in userland code? goto can be good. I was allergic to goto for many years but then I found my cluestick; I really like having fewer indent steps and to use goto for forward references and/or error handling. I think it makes code much simpler to read. Of course the unexperienced programmer will not intuitively know when to avoid goto and when to use them, but I don't think very many work on this project and when they want to we'll just show them how to do it right. :) //Peter From segher at kernel.crashing.org Fri Nov 17 02:49:31 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Fri, 17 Nov 2006 02:49:31 +0100 Subject: [LinuxBIOS] flashrom: patch for jedec.c In-Reply-To: <20061116204502.GL10794@greenwood> References: <20061115083736.GA9762@fredreggiane.com> <20061116204502.GL10794@greenwood> Message-ID: <10D8D66D-A828-4215-8771-B5955E5972D5@kernel.crashing.org> > There are some GOTOs in the LinuxBIOS code already, but I'd rather > remove those than introduce new ones... Is there a consensus about > GOTO > usage in LinuxBIOS? Do we allow that? If no, I'll update the > development > guidelines accordingly... Our CodingStyle (borrowed from Linux) currently says that goto's to an error exit path are allowed (preferred to other solutions, actually). Most other goto's are frowned upon of course. Segher From corey_osgood at verizon.net Fri Nov 17 05:06:43 2006 From: corey_osgood at verizon.net (Corey) Date: Thu, 16 Nov 2006 23:06:43 -0500 Subject: [LinuxBIOS] flashrom: patch for jedec.c In-Reply-To: <10D8D66D-A828-4215-8771-B5955E5972D5@kernel.crashing.org> References: <20061115083736.GA9762@fredreggiane.com> <20061116204502.GL10794@greenwood> <10D8D66D-A828-4215-8771-B5955E5972D5@kernel.crashing.org> Message-ID: <1163736403.16788.6.camel@ampfs.soundroom> On Fri, 2006-11-17 at 02:49 +0100, Segher Boessenkool wrote: > > There are some GOTOs in the LinuxBIOS code already, but I'd rather > > remove those than introduce new ones... Is there a consensus about > > GOTO > > usage in LinuxBIOS? Do we allow that? If no, I'll update the > > development > > guidelines accordingly... > > Our CodingStyle (borrowed from Linux) currently says that goto's > to an error exit path are allowed (preferred to other solutions, > actually). > > Most other goto's are frowned upon of course. Why exactly is this anyways? Pesonally, I agree with Peter that gotos make code much easier to follow, but I always learned that they were frowned upon, my C++ instructer in college refused to even teach about it (although he couldn't tell me why either). Also, you state "CodingStyle" as one word...is there a specific page/doc outlining what the preferred coding style is, or is it just a general consensus deal? -Corey From uwe at hermann-uwe.de Fri Nov 17 09:00:39 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 17 Nov 2006 09:00:39 +0100 Subject: [LinuxBIOS] flashrom: patch for jedec.c In-Reply-To: <1163736403.16788.6.camel@ampfs.soundroom> References: <20061115083736.GA9762@fredreggiane.com> <20061116204502.GL10794@greenwood> <10D8D66D-A828-4215-8771-B5955E5972D5@kernel.crashing.org> <1163736403.16788.6.camel@ampfs.soundroom> Message-ID: <20061117080038.GA31765@greenwood> On Thu, Nov 16, 2006 at 11:06:43PM -0500, Corey wrote: > > Our CodingStyle (borrowed from Linux) currently says that goto's > > to an error exit path are allowed (preferred to other solutions, > > actually). > > > > Most other goto's are frowned upon of course. > > Why exactly is this anyways? Pesonally, I agree with Peter that gotos > make code much easier to follow, but I always learned that they were > frowned upon, my C++ instructer in college refused to even teach about > it (although he couldn't tell me why either). Also, you state > "CodingStyle" as one word...is there a specific page/doc outlining what > the preferred coding style is, or is it just a general consensus deal? I've documented it in the wiki now: http://www.linuxbios.org/Development_Guidelines#Coding_Guidelines We just use the plain Linux coding style currently (or rather: in future; most code in svn doesn't follow the coding style, yet). 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 segher at kernel.crashing.org Fri Nov 17 12:52:07 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Fri, 17 Nov 2006 12:52:07 +0100 Subject: [LinuxBIOS] flashrom: patch for jedec.c In-Reply-To: <1163736403.16788.6.camel@ampfs.soundroom> References: <20061115083736.GA9762@fredreggiane.com> <20061116204502.GL10794@greenwood> <10D8D66D-A828-4215-8771-B5955E5972D5@kernel.crashing.org> <1163736403.16788.6.camel@ampfs.soundroom> Message-ID: <96CC7458-7E45-498F-BDDA-4BE100B68C89@kernel.crashing.org> > Why exactly is this anyways? Pesonally, I agree with Peter that gotos > make code much easier to follow, but I always learned that they were > frowned upon, my C++ instructer in college refused to even teach about > it (although he couldn't tell me why either). Also, you state > "CodingStyle" as one word...is there a specific page/doc outlining > what > the preferred coding style is, or is it just a general consensus deal? At the Hamburg conference, it was decided to generally use the Linux coding style, which is mostly documented in a file called CodingStyle in the Linux source tree. Segher From stepan at coresystems.de Fri Nov 17 12:59:40 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 17 Nov 2006 12:59:40 +0100 Subject: [LinuxBIOS] coding style: goto good or bad? In-Reply-To: <20061117004106.1410.qmail@cdy.org> References: <20061115083736.GA9762@fredreggiane.com> <20061116204502.GL10794@greenwood> <20061117004106.1410.qmail@cdy.org> Message-ID: <20061117115940.GA27595@coresystems.de> * Peter Stuge [061117 01:41]: > > Um, do we really want to use GOTOs in userland code? > > goto can be good. I was allergic to goto for many years but then I > found my cluestick; I really like having fewer indent steps and to > use goto for forward references and/or error handling. I think it > makes code much simpler to read. Yes, goto is the C programmer's exception handling. Describing the exception scenario with additional scopes seems not only less elegant, but also wrong from a design perspective. > Of course the unexperienced programmer will not intuitively know when > to avoid goto and when to use them, but I don't think very many work > on this project and when they want to we'll just show them how to do > it right. :) Yes, I think the rule should be "use goto if you really think you mess up your code otherwise, and await the code review to rend your implementation" -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From stepan at coresystems.de Fri Nov 17 13:12:55 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 17 Nov 2006 13:12:55 +0100 Subject: [LinuxBIOS] flashrom: patch for jedec.c In-Reply-To: <1163736403.16788.6.camel@ampfs.soundroom> References: <20061115083736.GA9762@fredreggiane.com> <20061116204502.GL10794@greenwood> <10D8D66D-A828-4215-8771-B5955E5972D5@kernel.crashing.org> <1163736403.16788.6.camel@ampfs.soundroom> Message-ID: <20061117121255.GB27595@coresystems.de> * Corey [061117 05:06]: > Why exactly is this anyways? Pesonally, I agree with Peter that gotos > make code much easier to follow, but I always learned that they were > frowned upon, my C++ instructer in college refused to even teach about > it (although he couldn't tell me why either). In C++ you are probably supposed to use exceptions to implement that behavior. The initial idea is that the use of goto makes it hard for the compiler to do code flow optimization. In fact, in case of exceptions or errors, this is mostly irrelevant though. > Also, you state > "CodingStyle" as one word...is there a specific page/doc outlining what > the preferred coding style is, or is it just a general consensus deal? We started writing up a cumulative document at http://www.linuxbios.org/Development_Guidelines -- 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 shaddamcorrinoiv at gmail.com Fri Nov 17 13:28:16 2006 From: shaddamcorrinoiv at gmail.com (Shaddam Corrino IV) Date: Fri, 17 Nov 2006 13:28:16 +0100 Subject: [LinuxBIOS] Intel 440bx In-Reply-To: <20061114093205.28007.qmail@cdy.org> References: <45576850.6040002@verizon.net> <20061113071518.29446.qmail@cdy.org> <1163486594.13317.8.camel@ampfs.soundroom> <20061114093205.28007.qmail@cdy.org> Message-ID: Hello, Said MBO has in their BIOS two options (a) support USB keyboard, and (b) power on via hot key. USB keyboard works in bios, and power on via PS/2 keyboard works. But power on via usb keyboard does not seem to work. Is there any chance I'll be able to power on this MBO via usb device using LB? Also where can I find datasheets for Northbridge i82443BX (440BX), and Southbridge i82371AB/EB/MB ? -- Thanks! Shaddam IV -------------- next part -------------- An HTML attachment was scrubbed... URL: From rtphilipson at cox.net Fri Nov 17 17:03:47 2006 From: rtphilipson at cox.net (Randall Philipson) Date: Fri, 17 Nov 2006 10:03:47 -0600 Subject: [LinuxBIOS] =?utf-8?q?MSI_RS482M_=E2=80=93_IL?= Message-ID: <17142682.1163779427815.JavaMail.root@centrmwml05.mgt.cox.net> I would like to develop LinuxBIOS support for the MSI RS482M ? IL motherboard with the following Sempron 3000+ (Rev E), 1.8GHz 512MB DDR1-400 ATI RS482M + SB400 chipset I haven't had any luck finding any datasheets for the ATI chipset, so I'm worried that this may be an uphill battle. I have access to a programmer so I can program BIOS chips to my hearts content, don't have a POST card though, may need to look into that. I don't have the board yet, it should be coming in within the next couple of weeks. I guess what I'm asking is, based on the vast amount of experience in this group, is this a reasonably achievable goal. I've been monitoring this list for a while and despite some fairly decent programming skills I have, LinuxBIOS has me somewhat stumped, so if I go this route there may be a lot of stupid questions hitting the list. Thanks for any guidance, Randy Philipson From yinghailu at gmail.com Fri Nov 17 17:11:55 2006 From: yinghailu at gmail.com (yhlu) Date: Fri, 17 Nov 2006 08:11:55 -0800 Subject: [LinuxBIOS] =?windows-1252?q?MSI_RS482M_=96_IL?= In-Reply-To: <17142682.1163779427815.JavaMail.root@centrmwml05.mgt.cox.net> References: <17142682.1163779427815.JavaMail.root@centrmwml05.mgt.cox.net> Message-ID: <2ea3fae10611170811u6799ea2dy19e15c19bce4e5d8@mail.gmail.com> I am planing to port one MCP55 + AM2 based Deskop MB to LinuxBIOS... YH From uwe at hermann-uwe.de Fri Nov 17 17:15:02 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 17 Nov 2006 17:15:02 +0100 Subject: [LinuxBIOS] Intel 440bx In-Reply-To: References: <45576850.6040002@verizon.net> <20061113071518.29446.qmail@cdy.org> <1163486594.13317.8.camel@ampfs.soundroom> <20061114093205.28007.qmail@cdy.org> Message-ID: <20061117161502.GB6964@greenwood> On Fri, Nov 17, 2006 at 01:28:16PM +0100, Shaddam Corrino IV wrote: > Also where can I find datasheets for Northbridge i82443BX (440BX), and > Southbridge i82371AB/EB/MB ? www.intel.com, just search for the part names... 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 Fri Nov 17 17:22:06 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 17 Nov 2006 17:22:06 +0100 Subject: [LinuxBIOS] flashrom: patch for jedec.c In-Reply-To: <20061117121255.GB27595@coresystems.de> References: <20061115083736.GA9762@fredreggiane.com> <20061116204502.GL10794@greenwood> <10D8D66D-A828-4215-8771-B5955E5972D5@kernel.crashing.org> <1163736403.16788.6.camel@ampfs.soundroom> <20061117121255.GB27595@coresystems.de> Message-ID: <20061117162206.GC6964@greenwood> On Fri, Nov 17, 2006 at 01:12:55PM +0100, Stefan Reinauer wrote: > The initial idea is that the use of goto makes it hard for the compiler > to do code flow optimization. The initial idea why you should _not_ use GOTOs is that GOTOs suck ;-) There was a paper called "Go To Statement Considered Harmful" from Edsger W. Dijkstra (and that man probably knows what he's talking about) in 1968 (!). GOTOs usually produce unreadable, unmaintainable code and should generally not be used. But yeah, in low-level programming it may make sense in certain situations, as the code sometimes gets very ugly otherwise... 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 Fri Nov 17 17:23:13 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 17 Nov 2006 17:23:13 +0100 Subject: [LinuxBIOS] coding style: goto good or bad? In-Reply-To: <20061117115940.GA27595@coresystems.de> References: <20061115083736.GA9762@fredreggiane.com> <20061116204502.GL10794@greenwood> <20061117004106.1410.qmail@cdy.org> <20061117115940.GA27595@coresystems.de> Message-ID: <20061117162313.GD6964@greenwood> > Yes, I think the rule should be "use goto if you really think you mess > up your code otherwise, and await the code review to rend your > implementation" OK then. This should be documented, 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 uwe at hermann-uwe.de Fri Nov 17 17:35:50 2006 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 17 Nov 2006 17:35:50 +0100 Subject: [LinuxBIOS] LinuxBIOSv2/util/flashrom In-Reply-To: References: Message-ID: <20061117163550.GE6964@greenwood> Hi, [please always write to the mailing list, there are more people there who can timely respond] On Wed, Nov 15, 2006 at 01:07:57PM +0000, Idwer Vollering wrote: > (I guess e-mail is more suitable than icq..) > > (http://tracker.linuxbios.org/trac/LinuxBIOS/browser/trunk/LinuxBIOSv2/util/flashrom) > > How do i add code-wise support for several dip-32 flashroms ? Usually you have to add the vendor/device number in flash.h and then some entries in flashchips.c. Depending on your mainboard maybe you also need to add support in flash_enable.c. > Lying in front of me are: > > Intel P28F001-BXT150: > http://pdf1.alldatasheet.com/datasheet-pdf/view/66052/INTEL/P28F001BX-T150/datasheet.pdf > > ST M29F002NT-120P1 -- couldn't find a exact datasheet about this one :( > except http://www.datasheets.org.uk/specsheet.php?part=M29F002T120P1 The vendor should have a datasheet: http://www.st.com Or: http://www.datasheets.org.uk/search.php?q=M29F002NT-90XK6TR&sType=part 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 segher at kernel.crashing.org Fri Nov 17 19:24:07 2006 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Fri, 17 Nov 2006 19:24:07 +0100 Subject: [LinuxBIOS] flashrom: patch for jedec.c In-Reply-To: <20061117162206.GC6964@greenwood> References: <20061115083736.GA9762@fredreggiane.com> <20061116204502.GL10794@greenwood> <10D8D66D-A828-4215-8771-B5955E5972D5@kernel.crashing.org> <1163736403.16788.6.camel@ampfs.soundroom> <20061117121255.GB27595@coresystems.de> <20061117162206.GC6964@greenwood> Message-ID: <190D3B54-AFA0-4B84-AB64-E762208AE011@kernel.crashing.org> > The initial idea why you should _not_ use GOTOs is that GOTOs suck ;-) > There was a paper called "Go To Statement Considered Harmful" from > Edsger W. Dijkstra (and that man probably knows what he's talking > about) > in 1968 (!). GOTOs usually produce unreadable, unmaintainable code and > should generally not be used. Using gotos instead of higher-level control structures is evil. Using such control structures to simulate goto is just as evil. Segher From ebiederman at lnxi.com Fri Nov 17 21:34:12 2006 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri, 17 Nov 2006 13:34:12 -0700 Subject: [LinuxBIOS] flashrom: patch for jedec.c In-Reply-To: <20061117162206.GC6964@greenwood> (Uwe Hermann's message of "Fri, 17 Nov 2006 17:22:06 +0100") References: <20061115083736.GA9762@fredreggiane.com> <20061116204502.GL10794@greenwood> <10D8D66D-A828-4215-8771-B5955E5972D5@kernel.crashing.org> <1163736403.16788.6.camel@ampfs.soundroom> <20061117121255.GB27595@coresystems.de> <20061117162206.GC6964@greenwood> Message-ID: Uwe Hermann writes: > On Fri, Nov 17, 2006 at 01:12:55PM +0100, Stefan Reinauer wrote: >> The initial idea is that the use of goto makes it hard for the compiler >> to do code flow optimization. > > The initial idea why you should _not_ use GOTOs is that GOTOs suck ;-) > There was a paper called "Go To Statement Considered Harmful" from > Edsger W. Dijkstra (and that man probably knows what he's talking about) > in 1968 (!). GOTOs usually produce unreadable, unmaintainable code and > should generally not be used. > > But yeah, in low-level programming it may make sense in certain > situations, as the code sometimes gets very ugly otherwise... To a certain extent the title of that paper is unfortunate. What Dijkstra was arguing for was single points of entry and single points of exit. This makes proofs (and other kinds of understanding) of the code much easier. So the argument was against multiple return statements, continue and break, every much as it was against goto. The core observation was that you can replace any control dependency and with a data dependency and get easier to follow code. (i.e. you can introduce a variable). Stefan point with the compilers is also valid because they have to understand the code they like this style of programming. So the ideal is a single point of entry and a single exit from every block of code. In general using gotos for exception handling improve this situation because they reduce the number of unique exit paths from a piece of code. In that context goto's also leave the code more readable because you don't get lots of extra unnecessary levels of indentation, and it easier to follow what the code is really trying to do. So if you are not doing a formal proof but a human inspection proof the goto certainly helps. I actually suspect Dijkstra might argue against C++ exception handling due to the challenges it places on proving code is correct. The control flow can be completely non-obvious when exceptions are involved. I know there is a lot of C++ that is proof and compilation hostile which makes it a poor choice for low level systems programming. Dijkstra's papers are available online and I challenge any one who wants to understand this better to dig them up and read them. Eric From ebiederman at lnxi.com Fri Nov 17 21:37:47 2006 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri, 17 Nov 2006 13:37:47 -0700 Subject: [LinuxBIOS] flashrom: patch for jedec.c In-Reply-To: <190D3B54-AFA0-4B84-AB64-E762208AE011@kernel.crashing.org> (Segher Boessenkool's message of "Fri, 17 Nov 2006 19:24:07 +0100") References: <20061115083736.GA9762@fredreggiane.com> <20061116204502.GL10794@greenwood> <10D8D66D-A828-4215-8771-B5955E5972D5@kernel.crashing.org> <1163736403.16788.6.camel@ampfs.soundroom> <20061117121255.GB27595@coresystems.de> <20061117162206.GC6964@greenwood> <190D3B54-AFA0-4B84-AB64-E762208AE011@kernel.crashing.org> Message-ID: Segher Boessenkool writes: >> The initial idea why you should _not_ use GOTOs is that GOTOs suck ;-) >> There was a paper called "Go To Statement Considered Harmful" from >> Edsger W. Dijkstra (and that man probably knows what he's talking >> about) >> in 1968 (!). GOTOs usually produce unreadable, unmaintainable code and >> should generally not be used. > > Using gotos instead of higher-level control structures is evil. > Using such control structures to simulate goto is just as evil. You mean you don't like people writing loops with function calls? void loop(int n) { if (n > 0) loop(n); return; } Sorry I couldn't resist. But you certainly have the gist of the Dijkstra's argument. Of course we was slightly biased having introduced several of the higher level constructs if I recall correctly. :) Eric From jon.dufresne at gmail.com Fri Nov 17 23:45:35 2006 From: jon.dufresne at gmail.com (Jon Dufresne) Date: Fri, 17 Nov 2006 17:45:35 -0500 Subject: [LinuxBIOS] My first attempt at linuxbios Message-ID: <376ea3380611171445w434814cy6c58a68ab085cbd@mail.gmail.com> Hello, I am creating an embedded system. Right now I am investigating different custom bioses and am seriously considering LinuxBIOS. Let me give you a rundown of the hardware I am using CPU: Pentium M Mainboard: Custom board based on BCM GT855 Northbridge: Intel 855GME Southbridge: Intel 82801DB SuperIO: ITE IT8712-F In the source tree it looks like there is some level of soupport for all these devices except the mainboard. I am going to attempt to create a mainboard and target to get this setup working. One thing I want to do is build a minimal target and then implement the features incrementally. With this is mind, do I need to create any source code for the initial run or is the entire build defined by the Config.lb and Options.lb? I've read through all the documentation I could find on th website so I think I have a decent idea about how the LinuxBIOS system works. I believe my payload will be FILO. In the end my system will be booting RHEL. I'm willing to put a lot of work into this, but I want to see what others thought about compatibility with this hardware setup. While I'm here, what is the difference between the Config.lb and the Options.lb file. They both look like they set configuations/optoins, but I am not sure what options/configuations go in which file. Thanks for the great soft/firmware and thanks for any feedback. -Jon If you're interested here is the output from lspci -vvvxxx 00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02) Subsystem: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller 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- Reset- FastB2B- 00: 86 80 81 35 07 00 a0 00 02 00 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 20 e0 e0 a0 22 20: c0 fd c0 fd b0 fd b0 fd 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: 00 00 00 00 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 00 00 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 00 00 00 00 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) (prog-if 00 [VGA]) Subsystem: Intel Corporation 82852/855GM Integrated Graphics Device 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- Reset- FastB2B- 00: 86 80 4e 24 07 00 80 80 82 00 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 02 02 20 d0 d0 80 22 20: e0 fd e0 fd d0 fd d0 fd 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: 02 28 20 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 02 74 00 00 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: 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 10 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 01 00 02 00 00 00 c0 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 60 0f 00 00 00 00 52 2c 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Region 1: I/O ports at Region 2: I/O ports at Region 3: I/O ports at Region 4: I/O ports at fb00 [size=16] Region 5: Memory at 48080000 (32-bit, non-prefetchable) [size=1K] 00: 86 80 cb 24 07 00 80 02 02 8a 01 01 00 00 00 00 10: 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 20: 01 fb 00 00 00 00 08 48 00 00 00 00 86 80 c2 24 30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 01 00 00 40: 00 80 07 a3 00 00 00 00 04 00 00 02 00 00 00 00 50: 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00 60: 08 00 00 00 00 00 00 00 08 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 00 00 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 60 0f 00 00 00 00 00 00 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 02) Subsystem: Intel Corporation: Unknown device 24c2 Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR-