From smithbone at gmail.com Mon Jan 1 00:01:42 2007 From: smithbone at gmail.com (Richard Smith) Date: Sun, 31 Dec 2006 18:01:42 -0500 Subject: [LinuxBIOS] Devtreefs patch hits lmkl Message-ID: <45984156.7090003@gmail.com> But its not getting very good marks... I wasn't aware that it requires OFW to be resident during the kernel boot to handle the devtree. So it looks like its usefulness for linuxbios is minimal. The good side is that it appears that a x86 implementation unified with the sparc and powerpc code will be well received. -- Richard. From segher at kernel.crashing.org Mon Jan 1 03:35:54 2007 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Mon, 1 Jan 2007 03:35:54 +0100 Subject: [LinuxBIOS] Devtreefs patch hits lmkl In-Reply-To: <45984156.7090003@gmail.com> References: <45984156.7090003@gmail.com> Message-ID: <24004c522c25fcddae80fd8bc258a6f4@kernel.crashing.org> > But its not getting very good marks... Oh, it's doing fine. It'll need changes before being accepted, that's perfectly normal :-) > I wasn't aware that it requires OFW to be resident during the kernel > boot to handle the devtree. It depends. If all you want is a device tree, you can feed it into the kernel whatever way you want (see the current PowerPC implementation, for example). If you want real services from OF, sure you need it to be there (but not necessarily at "kernel boot" time, it can be a bit earlier, too (a kernel "bootwrapper"). > So it looks like its usefulness for > linuxbios is minimal. Nah, it's fine. > The good side is that it appears that a x86 implementation unified with > the sparc and powerpc code will be well received. There is no way the "OF" part can be easily unified -- but the _filesystem_ part surely can, with some per-architecture (or even more fine-grained) set of accessor routines to the actual device tree. I'll follow up to some of the mails on LKML tomorrow, it's bedtime now ;-) Happy new year, Segher From jon.dufresne at gmail.com Thu Jan 4 03:00:14 2007 From: jon.dufresne at gmail.com (Jon Dufresne) Date: Wed, 3 Jan 2007 21:00:14 -0500 Subject: [LinuxBIOS] Will LinuxBIOS work on my machine? In-Reply-To: <4591F5CA.1080301@verizon.net> References: <869ce1750612252327o15f0fbc3he2ef12cea07a81ea@mail.gmail.com> <4591F5CA.1080301@verizon.net> Message-ID: <376ea3380701031800t68613869vf030059cc8a920f0@mail.gmail.com> > Jon is currently working on 865GPM support, which could probably work > with 865G. ICH5 should work fine, but you will need to create the > motherboard config. Actually I am working on the 855gme chip. This may or may not work well with 865g. It is worth a shot though. From burryme at hotmail.com Tue Jan 2 04:35:05 2007 From: burryme at hotmail.com (Chris Cannon) Date: Mon, 01 Jan 2007 20:35:05 -0700 Subject: [LinuxBIOS] comments about Linux BIOS Message-ID: I was excited to discover this project; it looks like good work. I did have a few comments / questions: On the list of benefits on the front page it says: "Avoids the need for a slow, buggy, proprietary BIOS." I would add to this that it gives the end user freedom from invisible functionality black holes. For example, my laptop BIOS will on only initiate suspend-to-disk on timeout; there is no way for me to invoke it on demand (and there is no way for me to update the existing BIOS to add the needed functionality unless I can reverse engineer the BIOS at great risk to my system). With LinuxBIOS presumably I would have some recourse. I am surprised that the list of payloads is not comprehensive; ie. apparently Linux BIOS doesn't provide a straight boot from MBR. This confused me. If this is not a goal, I would suggest making it a goal. This reflects my own philosophy that end-user interests are best served by compatibility. I would also suggest a feature list on the webpage, so that passers-by like me can see at a glance if you intend to support things like suspend-to-disk (since the trend is to move s4 functionality to the OS). Best regards, Chris _________________________________________________________________ Dave vs. Carl: The Insignificant Championship Series. ?Who will win? http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://davevscarl.spaces.live.com/?icid=T001MSN38C07001 From jsmith at sandel.com Wed Jan 3 01:27:10 2007 From: jsmith at sandel.com (Jeff Smith) Date: Tue, 2 Jan 2007 16:27:10 -0800 Subject: [LinuxBIOS] Intel 945GM Support Message-ID: Is anyone currently working on Intel 945GM chipset support ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From stepan at coresystems.de Mon Jan 8 14:50:21 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 8 Jan 2007 14:50:21 +0100 Subject: [LinuxBIOS] comments about Linux BIOS In-Reply-To: References: Message-ID: <20070108135021.GA19150@coresystems.de> * Chris Cannon [070102 04:35]: > I am surprised that the list of payloads is not comprehensive; ie. > apparently Linux BIOS doesn't provide a straight boot from MBR. This > confused me. If this is not a goal, I would suggest making it a goal. This > reflects my own philosophy that end-user interests are best served by > compatibility. It is somewhat possible with ADLO, but at this time, there is a lot of fiddling involved to get it 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 rminnich at gmail.com Mon Jan 8 15:50:05 2007 From: rminnich at gmail.com (ron minnich) Date: Mon, 8 Jan 2007 07:50:05 -0700 Subject: [LinuxBIOS] comments about Linux BIOS In-Reply-To: <20070108135021.GA19150@coresystems.de> References: <20070108135021.GA19150@coresystems.de> Message-ID: <13426df10701080650nde4295ey9a2f2ba0f5186813@mail.gmail.com> On 1/8/07, Stefan Reinauer wrote: > * Chris Cannon [070102 04:35]: > > I am surprised that the list of payloads is not comprehensive; ie. > > apparently Linux BIOS doesn't provide a straight boot from MBR. This > > confused me. If this is not a goal, I would suggest making it a goal. This > > reflects my own philosophy that end-user interests are best served by > > compatibility. > > It is somewhat possible with ADLO, but at this time, there is a lot of > fiddling involved to get it working. if you're really determined to support this, I think the best way to do it is to build on our emulator. I.e. load the MBR and support its calls via emulation, not direct execution a la ADLO. We've found the emulator to be very solid, and in fact, somebody is working on plugging it in to plan 9 to improve their VESA support. So you would load the MBR, run it under emulation, and take it from there. The best way, in my view, is to boot linux in flash and have linux kexec the actual OS you want to boot. But this is tricky. The advantage is that you can debug such a system completely under Linux, without linuxbios being involved, until you get it figured out. But is it possible to boot Vista under Linux via kexec? That would be interesting. ron From stepan at coresystems.de Mon Jan 8 17:32:20 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 8 Jan 2007 17:32:20 +0100 Subject: [LinuxBIOS] comments about Linux BIOS In-Reply-To: <13426df10701080650nde4295ey9a2f2ba0f5186813@mail.gmail.com> References: <20070108135021.GA19150@coresystems.de> <13426df10701080650nde4295ey9a2f2ba0f5186813@mail.gmail.com> Message-ID: <20070108163220.GA32471@coresystems.de> * ron minnich [070108 15:50]: > if you're really determined to support this, I think the best way to > do it is to build on our emulator. I.e. load the MBR and support its > calls via emulation, not direct execution a la ADLO. And how do you do the transition to native x86 execution? Your scenario would mean to emulate execution of the Windows bootloader, so that it can use bios callbacks. But I have no idea how to find out we're out of the bootloader and in Windows itself. ie. no bios callbacks will follow. > We've found the > emulator to be very solid, and in fact, somebody is working on > plugging it in to plan 9 to improve their VESA support. So you would > load the MBR, run it under emulation, and take it from there. Nothing against the success of the emulator. It is great work, and it helped LinuxBIOS (and I suppose other projects) a lot. But emulating an x86 machine on an x86 seems to have a whiff of a broken design. Not to forget, that it is kind of slow, thus becoming our bottle neck in boot times (which we still call our main advantage over legacy bios) > The best way, in my view, is to boot linux in flash and have linux > kexec the actual OS you want to boot. This is not exactly going to make things faster, in the Windows/MBR case. > But is it possible to boot Vista under Linux via kexec? That would be > interesting. Kexec is Linux specific. It can't do the job for any Windows or BSD, but will just load a Linux kernel. -- 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 Jan 9 02:28:30 2007 From: svn at openbios.org (LinuxBIOS) Date: Tue, 09 Jan 2007 01:28:30 -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.bf138aee7589d292e37df083d194cd67@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: Dependencies: | Patchstatus: there is no patch ------------------------------+--------------------------------------------- Comment (by Billy): helllo I am Billy nice design . best book! Enjoy. 0n79p7 http://clay- aiken-ringtone.hot4buy.org -- Ticket URL: LinuxBIOS From svn at openbios.org Tue Jan 9 02:38:31 2007 From: svn at openbios.org (LinuxBIOS) Date: Tue, 09 Jan 2007 01:38:31 -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.111e6e99a65c138f1e1f090c8560ce06@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: Dependencies: | Patchstatus: there is no patch ------------------------------+--------------------------------------------- Comment (by Billy): helllo I am Billy nice design . best book! Enjoy. 0n79p7 http://clay- aiken-ringtone.hot4buy.org -- Ticket URL: LinuxBIOS From svn at openbios.org Tue Jan 9 05:35:16 2007 From: svn at openbios.org (LinuxBIOS) Date: Tue, 09 Jan 2007 04:35:16 -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.7bf4495cebc14aaf81ff7422dfc5c4ed@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: Dependencies: | Patchstatus: there is no patch ------------------------------+--------------------------------------------- Comment (by sunshine-tutt): http://sunshine-tutt.foruhome.com/index.html sunshine tutt [url=http://sunshine-tutt.foruhome.com/index.html] sunshine tutt [/url] sunshine tutt -- Ticket URL: LinuxBIOS From svn at openbios.org Tue Jan 9 05:49:23 2007 From: svn at openbios.org (LinuxBIOS) Date: Tue, 09 Jan 2007 04:49:23 -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.15de9ba0798e0cafde2e08dd8391a724@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: Dependencies: | Patchstatus: there is no patch ------------------------------+--------------------------------------------- Comment (by sunshine-tutt): http://sunshine-tutt.foruhome.com/index.html sunshine tutt [url=http://sunshine-tutt.foruhome.com/index.html] sunshine tutt [/url] sunshine tutt -- Ticket URL: LinuxBIOS From janek at thenut.eti.pg.gda.pl Tue Jan 9 11:31:02 2007 From: janek at thenut.eti.pg.gda.pl (Janek Kozicki) Date: Tue, 9 Jan 2007 11:31:02 +0100 Subject: [LinuxBIOS] #36: Make the mailing list archive searchable In-Reply-To: <069.bf138aee7589d292e37df083d194cd67@openbios.org> References: <060.310e1ce9ac350c87801b63e0c3140a12@openbios.org> <069.bf138aee7589d292e37df083d194cd67@openbios.org> Message-ID: <20070109113102.62f836b8@absurd> LinuxBIOS said: (by the date of Tue, 09 Jan 2007 01:28:30 -0000) WTF with opening post? > #36: Make the mailing list archive searchable I have just two days ago made mailing list of my project hosted on berlios.de searchable using gmane. It turned out to be pretty easy: You need to add LinuxBIOS mailing list to http://gmane.org/ , then send an email to their support with URL to file with full archive of LinuxBIOS list compressed in mbox format. The gmane automatically subscribes to the mailing list, and automatically keeps them two synchronised. And gives you the search capability. In my case the response from gmane support was instant. They got email about mbox archive of my mailing list, and the next day the archive was imported and everything worked. -- Janek Kozicki From stepan at coresystems.de Tue Jan 9 12:06:18 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 9 Jan 2007 12:06:18 +0100 Subject: [LinuxBIOS] #36: Make the mailing list archive searchable In-Reply-To: <20070109113102.62f836b8@absurd> References: <060.310e1ce9ac350c87801b63e0c3140a12@openbios.org> <069.bf138aee7589d292e37df083d194cd67@openbios.org> <20070109113102.62f836b8@absurd> Message-ID: <20070109110618.GA27972@coresystems.de> * Janek Kozicki [070109 11:31]: > LinuxBIOS said: (by the date of Tue, 09 Jan 2007 01:28:30 -0000) > > WTF with opening post? ? > > #36: Make the mailing list archive searchable > > I have just two days ago made mailing list of my project hosted on > berlios.de searchable using gmane. Yes, our archive is also searchable, via google and gmane. http://news.gmane.org/gmane.linux.bios 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 Jan 9 13:19:03 2007 From: svn at openbios.org (LinuxBIOS) Date: Tue, 09 Jan 2007 12:19:03 -0000 Subject: [LinuxBIOS] #24: Remove all files which have a GPL-incompatible license In-Reply-To: <060.361d3cd3e348e469ea93b75a32ab835a@openbios.org> References: <060.361d3cd3e348e469ea93b75a32ab835a@openbios.org> Message-ID: <069.1b6d02d57a4de2c340c0282a51472dd3@openbios.org> #24: Remove all files which have a GPL-incompatible license ------------------------+--------------------------------------------------- Reporter: uwe | Owner: somebody Type: defect | Status: new Priority: blocker | Milestone: Resolve license issues Component: code | Version: v2 Resolution: | Keywords: Dependencies: | ------------------------+--------------------------------------------------- Comment (by anonymous): Replying to [ticket:24 uwe]: > Obviously, any file in svn which has a license which is GPL-incompatible has to be removed. In such a case we can either live with it, rewrite the file from scratch, or use another implementation which has a proper license (if available). -- Ticket URL: LinuxBIOS From svn at openbios.org Tue Jan 9 13:21:13 2007 From: svn at openbios.org (LinuxBIOS) Date: Tue, 09 Jan 2007 12:21:13 -0000 Subject: [LinuxBIOS] #24: Remove all files which have a GPL-incompatible license In-Reply-To: <060.361d3cd3e348e469ea93b75a32ab835a@openbios.org> References: <060.361d3cd3e348e469ea93b75a32ab835a@openbios.org> Message-ID: <069.0fd34cb1860dbbed93c028fa8d272f52@openbios.org> #24: Remove all files which have a GPL-incompatible license ------------------------+--------------------------------------------------- Reporter: uwe | Owner: somebody Type: defect | Status: new Priority: blocker | Milestone: Resolve license issues Component: code | Version: v2 Resolution: | Keywords: Dependencies: | ------------------------+--------------------------------------------------- Comment (by anonymous): Replying to [ticket:24 uwe]: > Obviously, any file in svn which has a license which is GPL-incompatible has to be removed. In such a case we can either live with it, rewrite the file from scratch, or use another implementation which has a proper license (if available). jhgdjgs -- Ticket URL: LinuxBIOS From stepan at coresystems.de Tue Jan 9 15:23:12 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 9 Jan 2007 15:23:12 +0100 Subject: [LinuxBIOS] linuxbios on an NCR-7456 POS PC In-Reply-To: <200612271349.18508.maciej.grela@gmail.com> References: <200612220117.31682.maciej.grela@gmail.com> <4591F4D9.5070609@verizon.net> <200612271349.18508.maciej.grela@gmail.com> Message-ID: <20070109142312.GA30131@coresystems.de> * Maciej Grela [061227 13:48]: > On ?roda, 27 grudnia 2006 05:21, Corey Osgood wrote: > > > > vt8601 support is already present in linuxbios, and I'm currently > > working on vt82c686 (which should work, but I haven't had a chance to > > test it yet). There are two variants of the 82c686, the a and the b. > > Can you either check the manual to find out which one of these it is, > > or reply with "lspci -n"? Then, beyond that, it's the code for the > > actual motherboard, which usually isn't too hard. Has anyone tested whether the vt8601 code works (again) since the last fix to romcc? Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From stepan at coresystems.de Tue Jan 9 15:37:50 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 9 Jan 2007 15:37:50 +0100 Subject: [LinuxBIOS] SMM in LinuxBIOS In-Reply-To: References: <0556d0490b9cf15ee6977cb972e33938@kernel.crashing.org> Message-ID: <20070109143750.GB30131@coresystems.de> * Arvind Seshadri [061230 05:13]: > BTW, I was looking over the datasheet for the AMD8111 southbridge and > found that several sources can generate an SMI. There are enable bits for > the individual SMI sources as well as a global SMI enable/disable bit. > Given that LinuxBIOS does not currently handle SMI, where is SMI disabled > in the code? I did some grepping around in the code and could not find > anything for the AMD K8. Is it the case that SMI is disabled after reset > and has to explicitly enabled by the BIOS? Global SMI Control Register (PM2C) is initialized with 00, thus disabling all SMI activity in the system. If you want to change this, you need to create an SMM handler, and set those bits you need, for example in the Global SMI Enable Register (PM2A) Unless you do, no SMIs will happen, and that situation is locked to avoid malware messing with SMI. One question: why are you going to need SMI? USB legacy emulation? 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 hansolofalcon at worldnet.att.net Tue Jan 9 18:06:57 2007 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Tue, 9 Jan 2007 12:06:57 -0500 Subject: [LinuxBIOS] #36: Make the mailing list archive searchable In-Reply-To: <20070109113102.62f836b8@absurd> Message-ID: <00df01c73410$97bbb210$6401a8c0@who8> Hello! What you are seeing friend, is an example of what is politely called Wiki spam. That so called ticket is an example of it. It's my guess that the fink responsible did not know that the tickets are configured to report to this list. And besides any Mailman managed list is indeed searchable. Just not as effectively as that firm. Ron, Stefan, when either of you get a few free minutes can you cancel out those fraudulent tickets? -- Gregg C Levine hansolofalcon at worldnet.att.net "The Force will be with you. Always." Obi-Wan Kenobi ? > -----Original Message----- > From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On > Behalf Of Janek Kozicki > Sent: Tuesday, January 09, 2007 5:31 AM > To: linuxbios at linuxbios.org > Subject: Re: [LinuxBIOS] #36: Make the mailing list archive searchable > > LinuxBIOS said: (by the date of Tue, 09 Jan 2007 01:28:30 -0000) > > WTF with opening post? > > > #36: Make the mailing list archive searchable > > I have just two days ago made mailing list of my project hosted on > berlios.de searchable using gmane. > > It turned out to be pretty easy: > > You need to add LinuxBIOS mailing list to http://gmane.org/ , then > send an email to their support with URL to file with full archive of > LinuxBIOS list compressed in mbox format. > > > The gmane automatically subscribes to the mailing list, and > automatically keeps them two synchronised. And gives you the search > capability. > > > In my case the response from gmane support was instant. They got > email about mbox archive of my mailing list, and the next day the > archive was imported and everything worked. > > > -- > Janek Kozicki > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios From rminnich at gmail.com Tue Jan 9 20:27:08 2007 From: rminnich at gmail.com (ron minnich) Date: Tue, 9 Jan 2007 12:27:08 -0700 Subject: [LinuxBIOS] comments about Linux BIOS In-Reply-To: <20070108163220.GA32471@coresystems.de> References: <20070108135021.GA19150@coresystems.de> <13426df10701080650nde4295ey9a2f2ba0f5186813@mail.gmail.com> <20070108163220.GA32471@coresystems.de> Message-ID: <13426df10701091127s57debea3vce89ccd2a8d8543f@mail.gmail.com> On 1/8/07, Stefan Reinauer wrote: > And how do you do the transition to native x86 execution? Your scenario > would mean to emulate execution of the Windows bootloader, so that it > can use bios callbacks. But I have no idea how to find out we're out of > the bootloader and in Windows itself. ie. no bios callbacks will follow. yes, you would need to know what the loader does to start windows, but I don't think this is impossible. > Nothing against the success of the emulator. It is great work, and it > helped LinuxBIOS (and I suppose other projects) a lot. But emulating an > x86 machine on an x86 seems to have a whiff of a broken design. I don't really agree. We used to run x86 binaries directly from expansion roms. There were far more problems than we have had with the emulator. The broken design, really, is the PC. But we can't change that. The emulation approach has proven to be the most reliable -- so reliable, in fact, that someone is looking to replace direct execution in Plan 9 with our emulator. > > The best way, in my view, is to boot linux in flash and have linux > > kexec the actual OS you want to boot. > > This is not exactly going to make things faster, in the Windows/MBR case. I will only agree to that when I measure it being slower. We have seen, here, that Linux, loaded from FLASH and operating as the boot loader, on reasonably modern machines (e.g. 2+ Ghz opteron),is the fastest way to boot, without exception. > > > But is it possible to boot Vista under Linux via kexec? That would be > > interesting. > > Kexec is Linux specific. It can't do the job for any Windows or BSD, > but will just load a Linux kernel. no, kexec will load an arbitrary elf image. I can kexec a plan 9 image. kexec is very powerful. ron From rminnich at gmail.com Wed Jan 10 01:14:13 2007 From: rminnich at gmail.com (ron minnich) Date: Tue, 9 Jan 2007 17:14:13 -0700 Subject: [LinuxBIOS] patch, add support for ST M50FW080 Message-ID: <13426df10701091614y506ea96au6c42152156033937@mail.gmail.com> I keep forgetting this procedure. I hope this is ok. Add support for ST M50FW080 (1 MBYTE firmware hub). Note that it seems to work, but does not program; this is probably due to the board we are on, as this part is advertised as FWH compatible. Approved-by: Ronald G. Minnich Index: flashchips.c =================================================================== --- flashchips.c (revision 2534) +++ flashchips.c (working copy) @@ -106,6 +106,8 @@ probe_82802ab, erase_82802ab, write_82802ab, NULL}, {"82802ac", 137, 172, NULL, 1024, 64 * 1024, probe_82802ab, erase_82802ab, write_82802ab, NULL}, + {"ST M50FW080", 0x20, 0x2d, NULL, 1024, 64 * 1024, + probe_82802ab, erase_82802ab, write_82802ab, NULL}, {"F49B002UA", EMST_ID, EMST_F49B002UA, NULL, 256, 4096, probe_jedec, erase_chip_jedec, write_49f002, NULL}, #ifndef DISABLE_DOC From stepan at coresystems.de Wed Jan 10 02:27:10 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 10 Jan 2007 02:27:10 +0100 Subject: [LinuxBIOS] patch, add support for ST M50FW080 In-Reply-To: <13426df10701091614y506ea96au6c42152156033937@mail.gmail.com> References: <13426df10701091614y506ea96au6c42152156033937@mail.gmail.com> Message-ID: <20070110012710.GA22991@coresystems.de> * ron minnich [070110 01:14]: > I keep forgetting this procedure. I hope this is ok. > Add support for ST M50FW080 (1 MBYTE firmware hub). > Note that it seems to work, but does not program; this is probably due > to the board we are on, as this part is advertised as FWH compatible. > Approved-by: Ronald G. Minnich Almost: http://www.linuxbios.org/Development_Guidelines#How_to_contribute -- 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 Wed Jan 10 09:40:38 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Wed, 10 Jan 2007 09:40:38 +0100 Subject: [LinuxBIOS] #36: Make the mailing list archive searchable In-Reply-To: <00df01c73410$97bbb210$6401a8c0@who8> References: <20070109113102.62f836b8@absurd> <00df01c73410$97bbb210$6401a8c0@who8> Message-ID: <20070110084037.GA31182@greenwood> Hi, On Tue, Jan 09, 2007 at 12:06:57PM -0500, Gregg C Levine wrote: > Ron, Stefan, when either of you get a few free minutes can you cancel out > those fraudulent tickets? I removed the spam yesterday already. 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 arvinds+ at cs.cmu.edu Wed Jan 10 22:28:24 2007 From: arvinds+ at cs.cmu.edu (Arvind Seshadri) Date: Wed, 10 Jan 2007 16:28:24 -0500 (EST) Subject: [LinuxBIOS] SMM in LinuxBIOS In-Reply-To: <20070109143750.GB30131@coresystems.de> Message-ID: Thanks for the clarification! The way SMI is handled in LinuxBIOS suits my purpose very well. I am working on a project called Pioneer, whose goal is to prevent any malware present on a computer from tampering with code execution (details can be found at http://www.cs.cmu.edu/~arvinds/verifiable_code_exec.html). I would like to implement the Pioneer code as an SMI handler to prevent an attacker from using the SMI as an attack vector. My current plan is to generate an SMI to all CPUs on the system via an IPI. Since all SMI sources on the Southbridge as well as CPU local SMI sources seem to be disabled on a system with LinuxBIOS, I do not have to worry about catching SMIs from any sources other than mine. Thanks to you guys for an open source BIOS that makes my life a lot easier! I was wondering how on the earth I was going to reverse engineer a proprietary SMM handler to get my code to play nicely... Best wishes, Arvind On Tue, 9 Jan 2007, Stefan Reinauer wrote: > * Arvind Seshadri [061230 05:13]: > > BTW, I was looking over the datasheet for the AMD8111 southbridge and > > found that several sources can generate an SMI. There are enable bits for > > the individual SMI sources as well as a global SMI enable/disable bit. > > Given that LinuxBIOS does not currently handle SMI, where is SMI disabled > > in the code? I did some grepping around in the code and could not find > > anything for the AMD K8. Is it the case that SMI is disabled after reset > > and has to explicitly enabled by the BIOS? > > Global SMI Control Register (PM2C) is initialized with 00, thus > disabling all SMI activity in the system. If you want to change this, > you need to create an SMM handler, and set those bits you need, for > example in the Global SMI Enable Register (PM2A) > > Unless you do, no SMIs will happen, and that situation is locked to > avoid malware messing with SMI. > > One question: why are you going to need SMI? USB legacy emulation? > > Stefan > > -- > coresystems GmbH ??? Brahmsstr. 16 ??? D-79104 Freiburg i. Br. > Tel.: +49 761 7668825 ??? Fax: +49 761 7664613 > Email: info at coresystems.de ??? http://www.coresystems.de/ > > From c-d.hailfinger.devel.2006 at gmx.net Thu Jan 11 00:12:45 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 11 Jan 2007 00:12:45 +0100 Subject: [LinuxBIOS] SMM in LinuxBIOS In-Reply-To: References: Message-ID: <45A572ED.9000302@gmx.net> Hi Arvind, Arvind Seshadri wrote: > Thanks for the clarification! The way SMI is handled in LinuxBIOS suits my > purpose very well. I am working on a project called Pioneer, whose goal is > to prevent any malware present on a computer from tampering with code > execution (details can be found at > http://www.cs.cmu.edu/~arvinds/verifiable_code_exec.html). It seems you are simply reimplementing SEBOS in a more complicated way. See http://www.missl.cs.umd.edu/sebos.html for details. Regards, Carl-Daniel -- http://www.hailfinger.org/ From rminnich at gmail.com Thu Jan 11 04:21:50 2007 From: rminnich at gmail.com (ron minnich) Date: Wed, 10 Jan 2007 20:21:50 -0700 Subject: [LinuxBIOS] Fwd: 1.1 sec from power on to Linux shell (busybox) prompt In-Reply-To: <45A51277.8020903@atl.lmco.com> References: <45A51277.8020903@atl.lmco.com> Message-ID: <13426df10701101921m36b52859i61414ead046609f5@mail.gmail.com> People are definitely beginning to understand the power of using linux as your bootloader ... From yinghailu at gmail.com Thu Jan 11 06:22:50 2007 From: yinghailu at gmail.com (yhlu) Date: Wed, 10 Jan 2007 21:22:50 -0800 Subject: [LinuxBIOS] Fwd: 1.1 sec from power on to Linux shell (busybox) prompt In-Reply-To: <13426df10701101921m36b52859i61414ead046609f5@mail.gmail.com> References: <45A51277.8020903@atl.lmco.com> <13426df10701101921m36b52859i61414ead046609f5@mail.gmail.com> Message-ID: <2ea3fae10701102122h6217dcf8o2a57b7f9c8940ff2@mail.gmail.com> not very clear. Some kind of kexec? YH From svn at openbios.org Thu Jan 11 15:13:41 2007 From: svn at openbios.org (LinuxBIOS) Date: Thu, 11 Jan 2007 14:13:41 -0000 Subject: [LinuxBIOS] #6: Add support for 10 cheap, mainstream motherboards In-Reply-To: <060.4056def32ed57b9135e2feadecdf45dc@openbios.org> References: <060.4056def32ed57b9135e2feadecdf45dc@openbios.org> Message-ID: <069.cba207904f4b62738b310ee60ffcca1b@openbios.org> #6: Add support for 10 cheap, mainstream motherboards ----------------------+----------------------------------------------------- Reporter: uwe | Owner: somebody Type: task | Status: new Priority: major | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: Dependencies: | ----------------------+----------------------------------------------------- Comment (by ephedrine at hotmail.com): ephedrine http ://ephedrine-pills-on.blogspot.com ephedrine [url=http://ephedrine-pills- on.blogspot.com] ephedrine [/url] -- Ticket URL: LinuxBIOS From rminnich at gmail.com Thu Jan 11 16:39:33 2007 From: rminnich at gmail.com (ron minnich) Date: Thu, 11 Jan 2007 08:39:33 -0700 Subject: [LinuxBIOS] Fwd: 1.1 sec from power on to Linux shell (busybox) prompt In-Reply-To: <2ea3fae10701102122h6217dcf8o2a57b7f9c8940ff2@mail.gmail.com> References: <45A51277.8020903@atl.lmco.com> <13426df10701101921m36b52859i61414ead046609f5@mail.gmail.com> <2ea3fae10701102122h6217dcf8o2a57b7f9c8940ff2@mail.gmail.com> Message-ID: <13426df10701110739m2e9a4225o673c8eac14beba44@mail.gmail.com> On 1/10/07, yhlu wrote: > not very clear. Some kind of kexec? yes indeed, their own implementation. They may not even know about kexec. but their linux is in flash, then can boot a linux. ron From hansolofalcon at worldnet.att.net Thu Jan 11 18:09:12 2007 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Thu, 11 Jan 2007 12:09:12 -0500 Subject: [LinuxBIOS] #6: Add support for 10 cheap, mainstream motherboards In-Reply-To: <069.cba207904f4b62738b310ee60ffcca1b@openbios.org> Message-ID: <001f01c735a3$422d12a0$6401a8c0@who8> Hello! Folks, we've got another one of these fraudulent tickets. Uwe, or someone else who's got the credentials, please delete that one. Also what are the steps to log in and do so myself if possible. -- Gregg C Levine hansolofalcon at worldnet.att.net "The Force will be with you. Always." Obi-Wan Kenobi ? > -----Original Message----- > From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On > Behalf Of LinuxBIOS > Sent: Thursday, January 11, 2007 9:14 AM > Cc: linuxbios at linuxbios.org > Subject: Re: [LinuxBIOS] #6: Add support for 10 cheap, mainstream motherboards > > #6: Add support for 10 cheap, mainstream motherboards > ----------------------+----------------------------------------------------- > Reporter: uwe | Owner: somebody > Type: task | Status: new > Priority: major | Milestone: Going mainstream > Component: code | Version: v2 > Resolution: | Keywords: > Dependencies: | > ----------------------+----------------------------------------------------- > Comment (by ephedrine at hotmail.com): > > ephedrine http > ://ephedrine-pills-on.blogspot.com ephedrine [url=http://ephedrine-pills- > on.blogspot.com] ephedrine [/url] > > -- > Ticket URL: > LinuxBIOS > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios From stepan at coresystems.de Thu Jan 11 18:25:03 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 11 Jan 2007 18:25:03 +0100 Subject: [LinuxBIOS] #6: Add support for 10 cheap, mainstream motherboards In-Reply-To: <001f01c735a3$422d12a0$6401a8c0@who8> References: <069.cba207904f4b62738b310ee60ffcca1b@openbios.org> <001f01c735a3$422d12a0$6401a8c0@who8> Message-ID: <20070111172503.GA32693@coresystems.de> * Gregg C Levine [070111 18:09]: > Hello! > Folks, we've got another one of these fraudulent tickets. Uwe, or someone > else who's got the credentials, please delete that one. No worries, we clean it out as soon as it happens. Trac has a nospam module which would prevent those postings from happening in the first place, but unfortunately it tends to block out all other postings as well, so I had to disable it 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 Thu Jan 11 20:21:12 2007 From: svn at openbios.org (LinuxBIOS) Date: Thu, 11 Jan 2007 19:21:12 -0000 Subject: [LinuxBIOS] #6: Add support for 10 cheap, mainstream motherboards In-Reply-To: <060.4056def32ed57b9135e2feadecdf45dc@openbios.org> References: <060.4056def32ed57b9135e2feadecdf45dc@openbios.org> Message-ID: <069.bac9f906694eda56df5553a09fc75b97@openbios.org> #6: Add support for 10 cheap, mainstream motherboards ----------------------+----------------------------------------------------- Reporter: uwe | Owner: somebody Type: task | Status: new Priority: major | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: Dependencies: | ----------------------+----------------------------------------------------- Comment (by celexa at hotmail.com): celexa http://celexa- pills-on.blogspot.com celexa [url=http://celexa-pills-on.blogspot.com] celexa [/url] -- Ticket URL: LinuxBIOS From anton.borisov at gmail.com Thu Jan 11 21:32:08 2007 From: anton.borisov at gmail.com (Anton) Date: Fri, 12 Jan 2007 04:32:08 +0800 Subject: [LinuxBIOS] Intel 815 In-Reply-To: <20061203030116.24152.qmail@cdy.org> References: <45691A54.8000008@verizon.net> <4571DD9A.7050508@verizon.net> <20061203030116.24152.qmail@cdy.org> Message-ID: <20070112043208.0f90a3bd.anton.borisov@gmail.com> On Sun, 3 Dec 2006 04:01:15 +0100 Peter Stuge wrote: > On Sat, Dec 02, 2006 at 03:10:02PM -0500, Corey Osgood wrote: > > I'm thinking something like this: connect two plcc sockets > > together, back to back, sodiering together all the connectors > > except chip enable and/or power. > > Sure, it will work just fine. I would suggest wiring between the two > PLCC sockets however, since they're keyed and don't handle mirroring > without help. > > Or - make a board for two SMT PLCC sockets. > > > > then, de-sodier those connectors from the existing chip. run wires > > to the motherboard on those lines, and also to a switch, and then > > also to the pair of plcc sockets. > > I would probably let the switch control one of two AND gates per > switched signal, the other input being the signal from mobo and > output going to one socket each. Any chances to make it similar for SPI chips? From svn at openbios.org Fri Jan 12 00:43:13 2007 From: svn at openbios.org (LinuxBIOS) Date: Thu, 11 Jan 2007 23:43:13 -0000 Subject: [LinuxBIOS] #6: Add support for 10 cheap, mainstream motherboards In-Reply-To: <060.4056def32ed57b9135e2feadecdf45dc@openbios.org> References: <060.4056def32ed57b9135e2feadecdf45dc@openbios.org> Message-ID: <069.8d28bc865f1e927c7e5bcbc07a3cc09e@openbios.org> #6: Add support for 10 cheap, mainstream motherboards ----------------------+----------------------------------------------------- Reporter: uwe | Owner: somebody Type: task | Status: new Priority: major | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: Dependencies: | ----------------------+----------------------------------------------------- Comment (by fluoxetine at hotmail.com): fluoxetine http ://fluoxetine-pills-on.blogspot.com fluoxetine [url=http://fluoxetine- pills-on.blogspot.com] fluoxetine [/url] -- Ticket URL: LinuxBIOS From svn at openbios.org Fri Jan 12 00:51:14 2007 From: svn at openbios.org (LinuxBIOS) Date: Thu, 11 Jan 2007 23:51:14 -0000 Subject: [LinuxBIOS] #6: Add support for 10 cheap, mainstream motherboards In-Reply-To: <060.4056def32ed57b9135e2feadecdf45dc@openbios.org> References: <060.4056def32ed57b9135e2feadecdf45dc@openbios.org> Message-ID: <069.e3d2d95fc118ef9a673687ff92a33980@openbios.org> #6: Add support for 10 cheap, mainstream motherboards ----------------------+----------------------------------------------------- Reporter: uwe | Owner: somebody Type: task | Status: new Priority: major | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: Dependencies: | ----------------------+----------------------------------------------------- Comment (by nolvadex at hotmail.com): nolvadex http ://nolvadex-pills-on.blogspot.com nolvadex [url=http://nolvadex-pills- on.blogspot.com] nolvadex [/url] -- Ticket URL: LinuxBIOS From svn at openbios.org Fri Jan 12 01:15:34 2007 From: svn at openbios.org (LinuxBIOS) Date: Fri, 12 Jan 2007 00:15:34 -0000 Subject: [LinuxBIOS] #6: Add support for 10 cheap, mainstream motherboards In-Reply-To: <060.4056def32ed57b9135e2feadecdf45dc@openbios.org> References: <060.4056def32ed57b9135e2feadecdf45dc@openbios.org> Message-ID: <069.6ce1b938ea8f85805b3866a894cd1177@openbios.org> #6: Add support for 10 cheap, mainstream motherboards ----------------------+----------------------------------------------------- Reporter: uwe | Owner: somebody Type: task | Status: new Priority: major | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: Dependencies: | ----------------------+----------------------------------------------------- Comment (by actos at hotmail.com): actos http://actos-pills- on.blogspot.com actos [url=http://actos-pills-on.blogspot.com] actos [/url] -- Ticket URL: LinuxBIOS From svn at openbios.org Fri Jan 12 01:30:56 2007 From: svn at openbios.org (LinuxBIOS) Date: Fri, 12 Jan 2007 00:30:56 -0000 Subject: [LinuxBIOS] #6: Add support for 10 cheap, mainstream motherboards In-Reply-To: <060.4056def32ed57b9135e2feadecdf45dc@openbios.org> References: <060.4056def32ed57b9135e2feadecdf45dc@openbios.org> Message-ID: <069.4678c4c5d8731a038bedd97072296b47@openbios.org> #6: Add support for 10 cheap, mainstream motherboards ----------------------+----------------------------------------------------- Reporter: uwe | Owner: somebody Type: task | Status: new Priority: major | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: Dependencies: | ----------------------+----------------------------------------------------- Comment (by ionamin at hotmail.com): ionamin http://ionamin- piils-on.blogspot.com ionamin [url=http://ionamin-piils-on.blogspot.com] ionamin [/url] -- Ticket URL: LinuxBIOS From arvinds+ at cs.cmu.edu Fri Jan 12 01:56:45 2007 From: arvinds+ at cs.cmu.edu (Arvind Seshadri) Date: Thu, 11 Jan 2007 19:56:45 -0500 (EST) Subject: [LinuxBIOS] SMM in LinuxBIOS In-Reply-To: <45A572ED.9000302@gmx.net> Message-ID: Hi Carl-Daniel, SEBOS is based on AEGIS, which is a secure bootstrap mechanism. As such, SEBOS can only guarantee the integrity of what programs are loaded into memory. This property is similar to that provided by the TCG trusted boot specification and is called loadtime attestation. Loadtime attestation does not guarantee that a program which is loaded into memory and checked for integrity is what gets executed. The program can be modified by the attacker before being invoked for execution. For example, an attacker can overwrite memory locations in the program via a DMA write. Also, both AEGIS and the TCG specification depend on HW modifications and cannot be used by legacy systems. Pioneer provides the stronger guarantee that the program whose integrity is checked is the one that is invoked for execution. In other words, an attacker cannot modify the program between the time its integrity is checked and the time the program is invoked for execution. Also, where as AEGIS and TCG only measure programs loaded at system boot, Pioneer can measure and launch programs at any point in time. The property provided by Pioneer is, therefore, similar to the late-launch capability of Intel's LT and AMD's SVM, which can be used to design systems with substantially smaller trusted computing bases than AEGIS and TCG. Unlike LT and SVM however, Pioneer is completely software-based and can be used on legacy systems. Cheers, Arvind On Thu, 11 Jan 2007, Carl-Daniel Hailfinger wrote: > Hi Arvind, > > Arvind Seshadri wrote: > > Thanks for the clarification! The way SMI is handled in LinuxBIOS suits my > > purpose very well. I am working on a project called Pioneer, whose goal is > > to prevent any malware present on a computer from tampering with code > > execution (details can be found at > > http://www.cs.cmu.edu/~arvinds/verifiable_code_exec.html). > > It seems you are simply reimplementing SEBOS in a more complicated way. > See http://www.missl.cs.umd.edu/sebos.html for details. > > Regards, > Carl-Daniel > -- > http://www.hailfinger.org/ > > From c-d.hailfinger.devel.2006 at gmx.net Fri Jan 12 02:59:03 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 12 Jan 2007 02:59:03 +0100 Subject: [LinuxBIOS] SMM in LinuxBIOS In-Reply-To: References: Message-ID: <45A6EB67.8090506@gmx.net> Hi Arvind, Arvind Seshadri wrote: > Pioneer provides the stronger guarantee that the program whose integrity > is checked is the one that is invoked for execution. In other words, an > attacker cannot modify the program between the time its integrity is > checked and the time the program is invoked for execution. Also, where as But an attacker can modify the program directly after its execution has started. So Pioneer secures exactly one machine instruction more than SEBOS. I don't think that this is impressive. With current hardware it is impossible (except if you use an IOMMU) to guarantee that a program is not modified during execution. I hope I didn't discuorage you and am still very interested in the results of Pioneer. > AEGIS and TCG only measure programs loaded at system boot, Pioneer can > measure and launch programs at any point in time. The property provided by > Pioneer is, therefore, similar to the late-launch capability of Intel's LT > and AMD's SVM, which can be used to design systems with substantially > smaller trusted computing bases than AEGIS and TCG. Unlike LT and SVM > however, Pioneer is completely software-based and can be used on legacy > systems. Only on legacy systems with LinuxBIOS or on all legacy systems? Regards, Carl-Daniel From svn at openbios.org Fri Jan 12 03:02:22 2007 From: svn at openbios.org (LinuxBIOS) Date: Fri, 12 Jan 2007 02:02:22 -0000 Subject: [LinuxBIOS] #6: Add support for 10 cheap, mainstream motherboards In-Reply-To: <060.4056def32ed57b9135e2feadecdf45dc@openbios.org> References: <060.4056def32ed57b9135e2feadecdf45dc@openbios.org> Message-ID: <069.b3e844e4a2311fdbfeebe1e1b04e2e0d@openbios.org> #6: Add support for 10 cheap, mainstream motherboards ----------------------+----------------------------------------------------- Reporter: uwe | Owner: somebody Type: task | Status: new Priority: major | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: Dependencies: | ----------------------+----------------------------------------------------- Comment (by atenolol at hotmail.com): atenolol http ://atenolol-pills-on.blogspot.com atenolol [url=http://atenolol-pills- on.blogspot.com] atenolol [/url] -- Ticket URL: LinuxBIOS From arvinds+ at cs.cmu.edu Fri Jan 12 03:23:55 2007 From: arvinds+ at cs.cmu.edu (Arvind Seshadri) Date: Thu, 11 Jan 2007 21:23:55 -0500 (EST) Subject: [LinuxBIOS] SMM in LinuxBIOS In-Reply-To: <45A6EB67.8090506@gmx.net> Message-ID: Hi Carl-Daniel, Having an IOMMU is not necessary since our goal is only to prevent DMA write to a region of memory. We have come up with techniques that can prevent DMA writes on legacy systems without an IOMMU. Also, Pioneer is not LinuxBIOS-specific. It can be incorporated into any SMM code. Cheers, Arvind On Fri, 12 Jan 2007, Carl-Daniel Hailfinger wrote: > Hi Arvind, > > Arvind Seshadri wrote: > > Pioneer provides the stronger guarantee that the program whose integrity > > is checked is the one that is invoked for execution. In other words, an > > attacker cannot modify the program between the time its integrity is > > checked and the time the program is invoked for execution. Also, where as > > But an attacker can modify the program directly after its execution has > started. So Pioneer secures exactly one machine instruction more than > SEBOS. I don't think that this is impressive. With current hardware it > is impossible (except if you use an IOMMU) to guarantee that a program > is not modified during execution. > I hope I didn't discuorage you and am still very interested in the > results of Pioneer. > > > AEGIS and TCG only measure programs loaded at system boot, Pioneer can > > measure and launch programs at any point in time. The property provided by > > Pioneer is, therefore, similar to the late-launch capability of Intel's LT > > and AMD's SVM, which can be used to design systems with substantially > > smaller trusted computing bases than AEGIS and TCG. Unlike LT and SVM > > however, Pioneer is completely software-based and can be used on legacy > > systems. > > Only on legacy systems with LinuxBIOS or on all legacy systems? > > Regards, > Carl-Daniel > > From svn at openbios.org Fri Jan 12 03:25:14 2007 From: svn at openbios.org (LinuxBIOS) Date: Fri, 12 Jan 2007 02:25:14 -0000 Subject: [LinuxBIOS] #6: Add support for 10 cheap, mainstream motherboards In-Reply-To: <060.4056def32ed57b9135e2feadecdf45dc@openbios.org> References: <060.4056def32ed57b9135e2feadecdf45dc@openbios.org> Message-ID: <069.e2b3aa5379f76724b32f69be1c0f1d0e@openbios.org> #6: Add support for 10 cheap, mainstream motherboards ----------------------+----------------------------------------------------- Reporter: uwe | Owner: somebody Type: task | Status: new Priority: major | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: Dependencies: | ----------------------+----------------------------------------------------- Comment (by effexor at hotmail.com): effexor http://effexor- pills-on.blogspot.com effexor [url=http://effexor-pills-on.blogspot.com] effexor [/url] -- Ticket URL: LinuxBIOS From c-d.hailfinger.devel.2006 at gmx.net Fri Jan 12 04:18:04 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 12 Jan 2007 04:18:04 +0100 Subject: [LinuxBIOS] SMM in LinuxBIOS In-Reply-To: References: Message-ID: <45A6FDEC.1030005@gmx.net> Hi Arvind, Arvind Seshadri wrote: > Having an IOMMU is not necessary since our goal is only to prevent DMA > write to a region of memory. We have come up with techniques that can > prevent DMA writes on legacy systems without an IOMMU. Also, Pioneer is That sounds interesting. Are you using the GART present in most current systems? > not LinuxBIOS-specific. It can be incorporated into any SMM code. Thanks for clarifying that. Regards, Carl-Daniel -- http://www.hailfinger.org/ From stiwary20 at yahoo.com Fri Jan 12 07:54:02 2007 From: stiwary20 at yahoo.com (sanjay tiwary) Date: Thu, 11 Jan 2007 22:54:02 -0800 (PST) Subject: [LinuxBIOS] LinuxBIOS not working... Message-ID: <20070112065402.4245.qmail@web50109.mail.yahoo.com> Hi Ron/All members of the LinuxBIOS group, I am new to the linuxBIOS technology.And wanetd to use the linuxBIOS stuff.But after creating the rom image and burning the chip, i was not able to see anything on either on display or on serial console.Can any one help me getting out of the problem. I am giving all the details so that you people can make out where am missing? Board Details: The contain chips from Via Northbridge: VT 8606(with AGP VGA Controller S3 Savage- twister) South Bridge: VIA VT82C686A BIOS Chip: 1MB ocessor Processor: PentiumIII or Celeron300MHz, 100 MHz Bus One SO-DIMM socket, 512 MByte max. PC100/ PC133 Two enhanced IDE ports SoundBlaster? compatible AC97 I used the configuration available for VIA/EPIA and Image was successfully created.Initially i tried to use the support avialble for VT8601.But i think, iam not getting the northbridge chip intialised. If anyone have the support avialble for VT8606, then let me know. Just help me out so that i can get something on the serial console.After that debugging will become a little bit easier. Thanks & regards Sanjay ____________________________________________________________________________________ Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index -------------- next part -------------- An HTML attachment was scrubbed... URL: From stepan at coresystems.de Fri Jan 12 11:53:18 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 12 Jan 2007 11:53:18 +0100 Subject: [LinuxBIOS] LinuxBIOS not working... In-Reply-To: <20070112065402.4245.qmail@web50109.mail.yahoo.com> References: <20070112065402.4245.qmail@web50109.mail.yahoo.com> Message-ID: <20070112105318.GC11215@coresystems.de> * sanjay tiwary [070112 07:54]: > Hi Ron/All members of the LinuxBIOS group, > > I am new to the linuxBIOS technology.And wanetd to use the linuxBIOS stuff.But > after creating the rom image and burning the chip, > i was not able to see anything on either on display or on serial console.Can > any one help me getting out of the problem. > I am giving all the details so that you people can make out where am missing? What superio is on the board? -- 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 stiwary20 at yahoo.com Fri Jan 12 14:14:29 2007 From: stiwary20 at yahoo.com (sanjay tiwary) Date: Fri, 12 Jan 2007 05:14:29 -0800 (PST) Subject: [LinuxBIOS] LinuxBIOS not working... Message-ID: <32179.53002.qm@web50101.mail.yahoo.com> Hi We are using VT8231 via vhip which has integrated superio controller. Sanjay ----- Original Message ---- From: Stefan Reinauer To: sanjay tiwary Cc: linuxbios at linuxbios.org Sent: Friday, January 12, 2007 4:23:18 PM Subject: Re: [LinuxBIOS] LinuxBIOS not working... * sanjay tiwary [070112 07:54]: > Hi Ron/All members of the LinuxBIOS group, > > I am new to the linuxBIOS technology.And wanetd to use the linuxBIOS stuff.But > after creating the rom image and burning the chip, > i was not able to see anything on either on display or on serial console.Can > any one help me getting out of the problem. > I am giving all the details so that you people can make out where am missing? What superio is on the board? -- 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 ____________________________________________________________________________________ Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From stiwary20 at yahoo.com Fri Jan 12 14:38:49 2007 From: stiwary20 at yahoo.com (sanjay tiwary) Date: Fri, 12 Jan 2007 05:38:49 -0800 (PST) Subject: [LinuxBIOS] LinuxBIOS not working... Message-ID: <787111.78105.qm@web50107.mail.yahoo.com> I think i should give u the more details: Southbridge Chip: VIA VT82C686 Following controllers/device are integrated with the bridge: Integrated Super IO Controller - Supports 2 serial ports, IR port, parallel port, and floppy disk controller functions - Two UARTs for Complete Serial Ports Programmable character lengths (5,6,7,8) Even, odd, stick or no parity bit generation and detection Programmable baud rate generator High speed baud rate (230Kbps, 460Kbps) support Independent transmit/receiver FIFOs Modem Control Plug and play with 96 base IO address and 12 IRQ options - One dedicated IR port Third serial port dedicated to IR function IR function either through the two complete serial ports or the third dedicated port Infrared-IrDA (HPSIR) and ASK (Amplitude Shift Keyed) IR - Multi-mode parallel port Standard mode, ECP and EPP support Plug and play with 192 base IO address, 12 IRQ and 4 DMA options - Floppy Disk Controller 16 bytes of FIFO Data rates up to 1Mbps Perpendicular recording driver support Two FDDs with drive swap support Plug and play with 48 base IO address, 12 IRQ and 4 DMA options Sanjay ----- Original Message ---- From: Stefan Reinauer To: sanjay tiwary Cc: linuxbios at linuxbios.org Sent: Friday, January 12, 2007 4:23:18 PM Subject: Re: [LinuxBIOS] LinuxBIOS not working... * sanjay tiwary [070112 07:54]: > Hi Ron/All members of the LinuxBIOS group, > > I am new to the linuxBIOS technology.And wanetd to use the linuxBIOS stuff.But > after creating the rom image and burning the chip, > i was not able to see anything on either on display or on serial console.Can > any one help me getting out of the problem. > I am giving all the details so that you people can make out where am missing? What superio is on the board? -- 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 ____________________________________________________________________________________ Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arvinds+ at cs.cmu.edu Fri Jan 12 17:57:51 2007 From: arvinds+ at cs.cmu.edu (Arvind Seshadri) Date: Fri, 12 Jan 2007 11:57:51 -0500 (EST) Subject: [LinuxBIOS] SMM in LinuxBIOS In-Reply-To: <45A6FDEC.1030005@gmx.net> Message-ID: Hi Carl-Daniel, Yep, the GART is one way to go. On the other hand, there are PCI-Express systems that do not have a GART. The whole thing is a bit of a mess, which is why I didn't expand on it. Cheers, Arvind On Fri, 12 Jan 2007, Carl-Daniel Hailfinger wrote: > Hi Arvind, > > Arvind Seshadri wrote: > > Having an IOMMU is not necessary since our goal is only to prevent DMA > > write to a region of memory. We have come up with techniques that can > > prevent DMA writes on legacy systems without an IOMMU. Also, Pioneer is > > That sounds interesting. Are you using the GART present in most current > systems? > > > not LinuxBIOS-specific. It can be incorporated into any SMM code. > > Thanks for clarifying that. > > Regards, > Carl-Daniel > -- > http://www.hailfinger.org/ > > From svn at openbios.org Fri Jan 12 22:06:56 2007 From: svn at openbios.org (LinuxBIOS) Date: Fri, 12 Jan 2007 21:06:56 -0000 Subject: [LinuxBIOS] #6: Add support for 10 cheap, mainstream motherboards In-Reply-To: <060.4056def32ed57b9135e2feadecdf45dc@openbios.org> References: <060.4056def32ed57b9135e2feadecdf45dc@openbios.org> Message-ID: <069.57d0d83c83677cfc358a378911bc3794@openbios.org> #6: Add support for 10 cheap, mainstream motherboards ----------------------+----------------------------------------------------- Reporter: uwe | Owner: somebody Type: task | Status: new Priority: major | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: Dependencies: | ----------------------+----------------------------------------------------- Comment (by clomid at hotmail.com): clomid http://clomid- pills-on.blogspot.com clomid [url=http://clomid-pills-on.blogspot.com] clomid [/url] -- Ticket URL: LinuxBIOS From stuge-linuxbios at cdy.org Fri Jan 12 23:22:39 2007 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 12 Jan 2007 23:22:39 +0100 Subject: [LinuxBIOS] Intel 815 In-Reply-To: <20070112043208.0f90a3bd.anton.borisov@gmail.com> References: <45691A54.8000008@verizon.net> <4571DD9A.7050508@verizon.net> <20061203030116.24152.qmail@cdy.org> <20070112043208.0f90a3bd.anton.borisov@gmail.com> Message-ID: <20070112222239.1542.qmail@cdy.org> On Fri, Jan 12, 2007 at 04:32:08AM +0800, Anton wrote: > > > then, de-sodier those connectors from the existing chip. run wires > > > to the motherboard on those lines, and also to a switch, and then > > > also to the pair of plcc sockets. > > > > I would probably let the switch control one of two AND gates per > > switched signal, the other input being the signal from mobo and > > output going to one socket each. > > Any chances to make it similar for SPI chips? Sure, just a few more signals that have to be switched. //Peter From tylerapohl at gmail.com Sat Jan 13 00:50:00 2007 From: tylerapohl at gmail.com (Tyler Pohl) Date: Fri, 12 Jan 2007 15:50:00 -0800 Subject: [LinuxBIOS] LB Message-ID: <503ab0210701121550mb807f2fjbf5e6f27f7a509a6@mail.gmail.com> Just had to say "LinuxBIOS ROCKS !!!!!!!" WOOT -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladc6 at yahoo.com Sat Jan 13 05:10:28 2007 From: vladc6 at yahoo.com (Vlad C.) Date: Fri, 12 Jan 2007 20:10:28 -0800 (PST) Subject: [LinuxBIOS] New DTX motherboard standard from AMD Message-ID: <489013.64844.qm@web54408.mail.yahoo.com> Hi, AMD has announced a new desktop motherboard standard called DTX that they claim will be a more space and energy efficient than its predecessor, ATX. DTX motherboards will be smaller (about the size of a micro-ATX), but will try to maintain compatibility with existing hardware. More information about them can be found here: http://hardware.slashdot.org/hardware/07/01/12/1940239.shtml It would be great if LinuxBIOS will run on these motherboards from their initial release. One of the stated aims of DTX is to increase upgradeability of smaller (ie. laptop) components, which are at present highly integrated and incompatible with other parts. LinuxBIOS, with its open design, would complement this goal very well by enabling the community to help fix compatibility problems that may arise. In the end, consumers will benefit from having more forward-compatible hardware. Vlad ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com From corey_osgood at verizon.net Sat Jan 13 11:41:41 2007 From: corey_osgood at verizon.net (Amp Man) Date: Sat, 13 Jan 2007 05:41:41 -0500 Subject: [LinuxBIOS] LinuxBIOS not working... In-Reply-To: <787111.78105.qm@web50107.mail.yahoo.com> References: <787111.78105.qm@web50107.mail.yahoo.com> Message-ID: <45A8B765.5050508@verizon.net> I've gotten the vt82c686 working, but at the moment HP still has my laptop, and I don't have a laptop->ide hard drive adapter. Anyways, you'd need to modify all of the pci ids in the 8231 code to match the 686. I also had to remove the usb and nic support to get the code to compile, and there may have been a couple other little changes, I can't remember atm. As far as the northbridge goes, if you're lucky, it's just the same procedure, modify the device ids from the 8601 code. -Corey From stepan at coresystems.de Sat Jan 13 11:51:57 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 13 Jan 2007 11:51:57 +0100 Subject: [LinuxBIOS] LinuxBIOS not working... In-Reply-To: <45A8B765.5050508@verizon.net> References: <787111.78105.qm@web50107.mail.yahoo.com> <45A8B765.5050508@verizon.net> Message-ID: <20070113105157.GA12878@coresystems.de> * Amp Man [070113 11:41]: > I've gotten the vt82c686 working, but at the moment HP still has my > laptop, and I don't have a laptop->ide hard drive adapter. Anyways, > you'd need to modify all of the pci ids in the 8231 code to match the > 686. I also had to remove the usb and nic support to get the code to > compile, and there may have been a couple other little changes, I can't > remember atm. As far as the northbridge goes, if you're lucky, it's just > the same procedure, modify the device ids from the 8601 code. For the vt82c686 it is worth looking at the LinuxBIOS v1 code, it supports that component. Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From stepan at coresystems.de Sat Jan 13 12:50:41 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 13 Jan 2007 12:50:41 +0100 Subject: [LinuxBIOS] epia, rom_cc and locking code In-Reply-To: <4539F406.1080308@hewson-venieri.com> References: <4539F406.1080308@hewson-venieri.com> Message-ID: <20070113115041.GA24453@coresystems.de> * Ben Hewson [061021 12:18]: > Ok first off the issue with ROM_CC and #if - #else - #endif not > compiling properly. > > After some testing I have at least found the problem and it only ever > happens if you put a C++ style > comment on the same line as the #if or #else > Ok now to my problems with the EPIA board. I think in general it is > working ok, but I still have some problems. > From a cold boot and also at other times, it will just hang. I am having > problems tracking down just where it hangs. Does it work since the above problem was fixed? Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From rminnich at gmail.com Sat Jan 13 17:06:50 2007 From: rminnich at gmail.com (ron minnich) Date: Sat, 13 Jan 2007 09:06:50 -0700 Subject: [LinuxBIOS] LinuxBIOS not working... In-Reply-To: <45A8B765.5050508@verizon.net> References: <787111.78105.qm@web50107.mail.yahoo.com> <45A8B765.5050508@verizon.net> Message-ID: <13426df10701130806w1355f5a5sc59af08fcfca2800@mail.gmail.com> On 1/13/07, Amp Man wrote: > I've gotten the vt82c686 working, but at the moment HP still has my > laptop, and I don't have a laptop->ide hard drive adapter. Anyways, > you'd need to modify all of the pci ids in the 8231 code to match the > 686. I also had to remove the usb and nic support to get the code to > compile, and there may have been a couple other little changes, I can't > remember atm. As far as the northbridge goes, if you're lucky, it's just > the same procedure, modify the device ids from the 8601 code. so can we set up southbridge/via/vt82c686 with our code? thanks ron From ben at hewson-venieri.com Sat Jan 13 19:38:00 2007 From: ben at hewson-venieri.com (Ben Hewson) Date: Sat, 13 Jan 2007 18:38:00 +0000 Subject: [LinuxBIOS] epia, rom_cc and locking code In-Reply-To: <20070113115041.GA24453@coresystems.de> References: <4539F406.1080308@hewson-venieri.com> <20070113115041.GA24453@coresystems.de> Message-ID: <45A92708.20709@hewson-venieri.com> Stefan Reinauer wrote: > * Ben Hewson [061021 12:18]: > >> Ok first off the issue with ROM_CC and #if - #else - #endif not >> compiling properly. >> >> After some testing I have at least found the problem and it only ever >> happens if you put a C++ style >> comment on the same line as the #if or #else >> > > >> Ok now to my problems with the EPIA board. I think in general it is >> working ok, but I still have some problems. >> From a cold boot and also at other times, it will just hang. I am having >> problems tracking down just where it hangs. >> > > Does it work since the above problem was fixed? > > Stefan > > Yes rom_cc is fine, but I have a problem where changes to the code base seem to have caused ide problems with Filo(it cant see the ide drive). I haven't spent much time investigating this lately, been busy with other things. Ben From arvinds+ at cs.cmu.edu Sat Jan 13 22:44:51 2007 From: arvinds+ at cs.cmu.edu (Arvind Seshadri) Date: Sat, 13 Jan 2007 16:44:51 -0500 (EST) Subject: [LinuxBIOS] MSI K9SD Master-S2R (MS-9185) Message-ID: Hi, I am looking for a Socket F motherboard that is compatible with LinuxBIOS. The MSI K9SD Master-S2R (MS-9185) seems to be the only one that fits the bill. A couple of questions: 1. Where can I find datasheets for the chipset on this motherboard (Broadcom BCM5785, Broadcom BCM5780)? 2. What is the best place to buy this motherboard? It seems MSI only sells this board in Germany. None of the dealers listed on the MSI Germany webpage seem to carry the board. Thanks, Arvind From tsylla at gmail.com Sat Jan 13 23:25:16 2007 From: tsylla at gmail.com (Tom Sylla) Date: Sat, 13 Jan 2007 17:25:16 -0500 Subject: [LinuxBIOS] MSI K9SD Master-S2R (MS-9185) In-Reply-To: References: Message-ID: <45A95C4C.4040607@gmail.com> Arvind Seshadri wrote: > Hi, > I am looking for a Socket F motherboard that is compatible with LinuxBIOS. > The MSI K9SD Master-S2R (MS-9185) seems to be the only one that fits the > bill. A couple of questions: > 1. Where can I find datasheets for the chipset on this motherboard > (Broadcom BCM5785, Broadcom BCM5780)? As is with many chipsets, you can only get them from the manufacturer, in this case Broadcom. You will have to sign appropriate NDAs, and it will take a *very* long time. They may not deem your need worthy, and you may not get the datasheets at all. (if you were designing a platform, they might give you documentation) Regarding a Socket F platform: at my day job, I made an LB port to Tyan s3992. It booted with ATI graphics, but was pretty unstable for some reason. (some boots would hang in IDE detection, some would hang in with MCEs). I am a hardware minion, not a BIOS minion, so I didn't really spend much time trying to figure out why it wouldn't work well. The diff between the 3992 and broadcom blast (LB supported) were really very small. If someone willing to deal with the gore of LB would like to add support for more Socket F platforms, Tyan s3992 and s3970 would be good candidates. (one is 2x Socket F, HT2000, HT1000, ATI gfx; one is 2x Socket F, HT1000, XGI Z7 gfx) From yinghailu at gmail.com Sun Jan 14 05:30:51 2007 From: yinghailu at gmail.com (yhlu) Date: Sat, 13 Jan 2007 20:30:51 -0800 Subject: [LinuxBIOS] MSI K9SD Master-S2R (MS-9185) In-Reply-To: <45A95C4C.4040607@gmail.com> References: <45A95C4C.4040607@gmail.com> Message-ID: <2ea3fae10701132030l7d445ceag559330fcd12c2105@mail.gmail.com> I will release MCP55 support very soon. We got the approval. YH From dhbarr at gozelle.com Sun Jan 14 07:05:12 2007 From: dhbarr at gozelle.com (David H. Barr) Date: Sun, 14 Jan 2007 00:05:12 -0600 Subject: [LinuxBIOS] MSI K9SD Master-S2R (MS-9185) In-Reply-To: <2ea3fae10701132030l7d445ceag559330fcd12c2105@mail.gmail.com> References: <45A95C4C.4040607@gmail.com> <2ea3fae10701132030l7d445ceag559330fcd12c2105@mail.gmail.com> Message-ID: On 1/13/07, yhlu wrote: > I will release MCP55 support very soon. We got the approval. Great news! Thanks for all your hard work on this, YH. I know all the other desktop people must be as eager as I am. -dhbarr. From vladc6 at yahoo.com Sun Jan 14 15:15:34 2007 From: vladc6 at yahoo.com (Vlad C.) Date: Sun, 14 Jan 2007 06:15:34 -0800 (PST) Subject: [LinuxBIOS] MSI K9SD Master-S2R (MS-9185) In-Reply-To: Message-ID: <385509.92406.qm@web54401.mail.yahoo.com> --- "David H. Barr" wrote: > On 1/13/07, yhlu wrote: > > I will release MCP55 support very soon. We got the approval. > > Great news! Thanks for all your hard work on this, YH. I know all > the other desktop people must be as eager as I am. > > -dhbarr. Indeed, thank you very much YH for helping to make LinuxBIOS on some of the latest desktops a reality. Once the code has been released, I'll work to spread the word among Free/Open Source Software users who I'm sure will create an increased demand for the LinuxBIOS-supported motherboards. Vlad __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From stepan at coresystems.de Sun Jan 14 16:07:28 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 14 Jan 2007 16:07:28 +0100 Subject: [LinuxBIOS] epia, rom_cc and locking code In-Reply-To: <45A92708.20709@hewson-venieri.com> References: <4539F406.1080308@hewson-venieri.com> <20070113115041.GA24453@coresystems.de> <45A92708.20709@hewson-venieri.com> Message-ID: <20070114150728.GB21694@coresystems.de> * Ben Hewson [070113 19:38]: > Stefan Reinauer wrote: > Yes rom_cc is fine, but I have a problem where changes to the code base > seem to have caused ide problems with Filo(it cant see the ide drive). - what IDE drive? - what FILO? (svn rev?) - Did you change the filo config? - Do you have a log file? -- 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 ben at hewson-venieri.com Sun Jan 14 17:14:24 2007 From: ben at hewson-venieri.com (Ben Hewson) Date: Sun, 14 Jan 2007 16:14:24 +0000 Subject: [LinuxBIOS] epia, rom_cc and locking code In-Reply-To: <20070114150728.GB21694@coresystems.de> References: <4539F406.1080308@hewson-venieri.com> <20070113115041.GA24453@coresystems.de> <45A92708.20709@hewson-venieri.com> <20070114150728.GB21694@coresystems.de> Message-ID: <45AA56E0.3000103@hewson-venieri.com> Stefan Reinauer wrote: > * Ben Hewson [070113 19:38]: > >> Stefan Reinauer wrote: >> Yes rom_cc is fine, but I have a problem where changes to the code base >> seem to have caused ide problems with Filo(it cant see the ide drive). >> > > - what IDE drive? > - what FILO? (svn rev?) > - Did you change the filo config? > - Do you have a log file? > > there are some posts on the mailing list I made, but basically my older version of linuxbios using filo boots, but a later version after the rom_cc patch doesn't boot any more. exactly the same hardware and filo image (v 0.5 ). I get the following error from filo using the later version. Detected floating bus No drive detected on IDE channel 0 The older version I have works just fine though. Have attached the log files from both working and non working versions. If you compare the two you will see that the pci enumeration/allocation of resources if different, although it only appears to be so with respect to the ide controller. I have been comparing both sets of files to find any differences. The biggest change I can see is the change to the pci read/write functions, where the 'where' parameter changed from 8 to 16 bits but I dont think that is the problem. Ben -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: linuxbios_bad URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: linuxbios_good URL: From anton.borisov at gmail.com Sun Jan 14 17:09:28 2007 From: anton.borisov at gmail.com (Anton) Date: Mon, 15 Jan 2007 00:09:28 +0800 Subject: [LinuxBIOS] Via epia-m2 difficulties In-Reply-To: <20061109173708.19995.qmail@cdy.org> References: <17cbe10f0611090642v5f8cbd54kc74712ea3d1aa530@mail.gmail.com> <20061109173708.19995.qmail@cdy.org> Message-ID: <20070115000928.1f36b27d.anton.borisov@gmail.com> On Thu, 9 Nov 2006 18:37:08 +0100 Peter Stuge wrote: > 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: I'd rather say the output from awardeco is correct. VideoBIOS has to padded later to 64k boundary. Dumping from live system may be incorrect for videorom bigger than 32k. Contact "Carl-Daniel U. Hailfinger" for details. Thanks. From corey_osgood at verizon.net Sun Jan 14 21:36:20 2007 From: corey_osgood at verizon.net (Corey Osgood) Date: Sun, 14 Jan 2007 15:36:20 -0500 Subject: [LinuxBIOS] LinuxBIOS not working... In-Reply-To: <13426df10701130806w1355f5a5sc59af08fcfca2800@mail.gmail.com> References: <787111.78105.qm@web50107.mail.yahoo.com> <45A8B765.5050508@verizon.net> <13426df10701130806w1355f5a5sc59af08fcfca2800@mail.gmail.com> Message-ID: <45AA9444.6010804@verizon.net> ron minnich wrote: > so can we set up southbridge/via/vt82c686 with our code? > > thanks > > ron > The directory will be southbridge/via/vt82c686a, I'll be adding another one later for vt82c686b. I've found an older backup of what I had done, and worked back up from that, so I should have a patch soon. Which files need GPL headers? -Corey From corey_osgood at verizon.net Sun Jan 14 21:57:28 2007 From: corey_osgood at verizon.net (Corey Osgood) Date: Sun, 14 Jan 2007 15:57:28 -0500 Subject: [LinuxBIOS] Add support for Via vt82c686a Message-ID: <45AA9938.6020804@verizon.net> Okay, I'm hoping that I'm doing this right. This is basically just a hacked up version of the vt8231 to support the vt82c686a. I can't confirm that it works entirely, but it does work far enough to provide serial output. I've added what I hope are the correct GPL headers. Signed off by: Corey Osgood -------------- next part -------------- A non-text attachment was scrubbed... Name: vt82c686a.patch Type: text/x-patch Size: 26181 bytes Desc: not available URL: From steve at flconsult.com Sun Jan 14 22:36:50 2007 From: steve at flconsult.com (Steve Spano) Date: Sun, 14 Jan 2007 16:36:50 -0500 Subject: [LinuxBIOS] geode LX Message-ID: <000001c73824$1a2d4120$0301a8c0@fleballnchain> Hi There we are getting ready to make a custom Geode LX + CS5336 SBC. It looks like there already is support for this in the LinuxBios - is there a quick FAQ/etc on how to setup the toolchain/configure/etc so we can get a build? Thanks Steve Spano, President Finger Lakes Engineering 607-277-1614 www.fl-eng.com steve at flconsult.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From uwe at hermann-uwe.de Mon Jan 15 00:53:36 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Mon, 15 Jan 2007 00:53:36 +0100 Subject: [LinuxBIOS] LinuxBIOS not working... In-Reply-To: <45AA9444.6010804@verizon.net> References: <787111.78105.qm@web50107.mail.yahoo.com> <45A8B765.5050508@verizon.net> <13426df10701130806w1355f5a5sc59af08fcfca2800@mail.gmail.com> <45AA9444.6010804@verizon.net> Message-ID: <20070114235336.GA20305@greenwood> On Sun, Jan 14, 2007 at 03:36:20PM -0500, Corey Osgood wrote: > The directory will be southbridge/via/vt82c686a, I'll be adding another > one later for vt82c686b. I've found an older backup of what I had done, > and worked back up from that, so I should have a patch soon. I'll check my mainboards, I might have an old vt82c686* too, so I can probably help debugging etc. > Which files need GPL headers? That's easy - all of them. 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 c-d.hailfinger.devel.2006 at gmx.net Mon Jan 15 00:53:39 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 15 Jan 2007 00:53:39 +0100 Subject: [LinuxBIOS] Via epia-m2 difficulties In-Reply-To: <20070115000928.1f36b27d.anton.borisov@gmail.com> References: <17cbe10f0611090642v5f8cbd54kc74712ea3d1aa530@mail.gmail.com> <20061109173708.19995.qmail@cdy.org> <20070115000928.1f36b27d.anton.borisov@gmail.com> Message-ID: <45AAC283.3020303@gmx.net> Hi, Anton wrote: > On Thu, 9 Nov 2006 18:37:08 +0100 > Peter Stuge wrote: > >> On Thu, Nov 09, 2006 at 03:42:20PM +0100, Kurt Andr? Selbach wrote: >>> 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: > > I'd rather say the output from awardeco is > correct. VideoBIOS has to padded later to 64k boundary. > Dumping from live system may be incorrect for videorom > bigger than 32k. Contact "Carl-Daniel U. Hailfinger" for > details. RAM below 1 MB often does not have enough room to store the full BIOS. This means parts of the (Video)BIOS may be truncated. I know of a few laptops where the VideoBIOS size is >32k, but only the first 32k of it are kept in memory after execution. That's (with a proper structure) enough for VideoBIOS tasks after bootup (VESA and stuff) but not enough to actually boot the video card. The only way to get the full VideoBIOS are Anton's BIOS extraction tools. The VideoBIOS file is usually padded to 64k with this command: dd conv=notrunc conv=sync bs=65536 if=extractedvideobios of=vbios.rom Hope this helps. Regards, Carl-Daniel -- http://www.hailfinger.org/ From uwe at hermann-uwe.de Mon Jan 15 00:57:39 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Mon, 15 Jan 2007 00:57:39 +0100 Subject: [LinuxBIOS] Add support for Via vt82c686a In-Reply-To: <45AA9938.6020804@verizon.net> References: <45AA9938.6020804@verizon.net> Message-ID: <20070114235739.GB20305@greenwood> Hi, On Sun, Jan 14, 2007 at 03:57:28PM -0500, Corey Osgood wrote: > Okay, I'm hoping that I'm doing this right. This is basically just a > hacked up version of the vt8231 to support the vt82c686a. I can't > confirm that it works entirely, but it does work far enough to provide > serial output. I've added what I hope are the correct GPL headers. > > Signed off by: Corey Osgood Sign-off-by, see http://linuxbios.org/Development_Guidelines#Sign-off_Procedure Most files are missing the GPL header, but every file needs one. You need to check the svn history and add the proper copyright lines, as the original files you based your code on don't have the header either. Let me know if you need help, I can provide patches for this if you want... > Property changes on: src/southbridge/via/vt82c686a/vt82c686a_early_smbus.c > ___________________________________________________________________ > Name: svn:executable > + * Not necessary, these files won't be executed. 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 bingxunshi at gmail.com Mon Jan 15 01:10:10 2007 From: bingxunshi at gmail.com (bxshi) Date: Mon, 15 Jan 2007 08:10:10 +0800 Subject: [LinuxBIOS] MSI K9SD Master-S2R (MS-9185) Message-ID: >I will release MCP55 support very soon. We got the approval. >YH That is really good news. I have a MCP55+socket F board half done , with yinghai's code I think I can finish it very soon. then there may be more choices. ;) bxshi -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey_osgood at verizon.net Mon Jan 15 03:05:10 2007 From: corey_osgood at verizon.net (Corey Osgood) Date: Sun, 14 Jan 2007 21:05:10 -0500 Subject: [LinuxBIOS] Add support for Via vt82c686a In-Reply-To: <20070114235739.GB20305@greenwood> References: <45AA9938.6020804@verizon.net> <20070114235739.GB20305@greenwood> Message-ID: <45AAE156.5030206@verizon.net> An HTML attachment was scrubbed... URL: From corey_osgood at verizon.net Mon Jan 15 03:21:19 2007 From: corey_osgood at verizon.net (Corey Osgood) Date: Sun, 14 Jan 2007 21:21:19 -0500 Subject: [LinuxBIOS] Add support for Via vt82c686a In-Reply-To: <45AAE156.5030206@verizon.net> References: <45AA9938.6020804@verizon.net> <20070114235739.GB20305@greenwood> <45AAE156.5030206@verizon.net> Message-ID: <45AAE51F.9090801@verizon.net> In trac, who are ebiederm and mwrwilkinson? I can't seem to find names to go with handles... -Corey From dhbarr at gozelle.com Mon Jan 15 03:42:42 2007 From: dhbarr at gozelle.com (David H. Barr) Date: Sun, 14 Jan 2007 20:42:42 -0600 Subject: [LinuxBIOS] Add support for Via vt82c686a In-Reply-To: <45AAE51F.9090801@verizon.net> References: <45AA9938.6020804@verizon.net> <20070114235739.GB20305@greenwood> <45AAE156.5030206@verizon.net> <45AAE51F.9090801@verizon.net> Message-ID: On 1/14/07, Corey Osgood wrote: > In trac, who are ebiederm and mwrwilkinson? I can't seem to find names > to go with handles... ebiederm has got to be Eric W. Beiderman. Last I remember he was ebiederman at lnxi dot com. -dhbarr. From rminnich at gmail.com Mon Jan 15 03:50:14 2007 From: rminnich at gmail.com (ron minnich) Date: Sun, 14 Jan 2007 19:50:14 -0700 Subject: [LinuxBIOS] geode LX In-Reply-To: <000001c73824$1a2d4120$0301a8c0@fleballnchain> References: <000001c73824$1a2d4120$0301a8c0@fleballnchain> Message-ID: <13426df10701141850t113ba728s1a854fdfdc4eb926@mail.gmail.com> One LX port has been done, I'm doing another, and you would hence be the 3rd or 4th. You have contacted AMD I assume concerning redistribution rights for the LX VSA? You are going to need to do that. The build depends on what you put on the board. The best thing you could do would be to talk to this mailing list a little so we can help you design the board with linuxbios in mind. Also, do you intend to put linux in flash, for linuxbios to load, or ... in other words, how do you want this thing to boot? There are now several options, so you want to think about how you want it to boot. We've worked with a number of vendors recently on putting linux in the BIOS flash, and having linux load it. They find the debug flexibility very useful. This just started getting to be popular when the 1 MBYTE parts hit the street. thanks ron From steve at flconsult.com Mon Jan 15 04:05:30 2007 From: steve at flconsult.com (Steve Spano) Date: Sun, 14 Jan 2007 22:05:30 -0500 Subject: [LinuxBIOS] geode LX In-Reply-To: <13426df10701141850t113ba728s1a854fdfdc4eb926@mail.gmail.com> Message-ID: <005e01c73852$04e6d960$0301a8c0@fleballnchain> Hi Ron Thanks for the fast reply! Our board design is for a custom product we are developing We will put 1) LX-800 (500Mhz part) 2) CS5536 Companion 3) RealTEK Ethernet (from the reference design) 4) We will use the USB Host port 5) We will take an RS232 port (or use the Parallel Port perhaps) to a secondary Microprocessor to implement some LCD, keypad, and other I/O functions We don't need the Video Support for our product release, we may 'borrow' it for development though. Ideally, we could stream all debug/startup/etc to the RS232 port and use other I/O functions to talk to our custom hardware - but we can deal with that later. In the future, we may use the true video output though. What's the process for doing that? I would like to model our LX design after the most straight forward way to implement the opensource bios. Regarding storage, we will put a NAND flash on the output of the CS5536 to store the linux image, full fillsystem, bios, etc Thanks! Steve Spano FLE -----Original Message----- From: ron minnich [mailto:rminnich at gmail.com] Sent: Sunday, January 14, 2007 9:50 PM To: Steve Spano Cc: linuxbios at linuxbios.org Subject: Re: [LinuxBIOS] geode LX One LX port has been done, I'm doing another, and you would hence be the 3rd or 4th. You have contacted AMD I assume concerning redistribution rights for the LX VSA? You are going to need to do that. The build depends on what you put on the board. The best thing you could do would be to talk to this mailing list a little so we can help you design the board with linuxbios in mind. Also, do you intend to put linux in flash, for linuxbios to load, or ... in other words, how do you want this thing to boot? There are now several options, so you want to think about how you want it to boot. We've worked with a number of vendors recently on putting linux in the BIOS flash, and having linux load it. They find the debug flexibility very useful. This just started getting to be popular when the 1 MBYTE parts hit the street. thanks ron From corey_osgood at verizon.net Mon Jan 15 04:24:45 2007 From: corey_osgood at verizon.net (Corey Osgood) Date: Sun, 14 Jan 2007 22:24:45 -0500 Subject: [LinuxBIOS] Add support for Via vt82c686a In-Reply-To: References: <45AA9938.6020804@verizon.net> <20070114235739.GB20305@greenwood> <45AAE156.5030206@verizon.net> <45AAE51F.9090801@verizon.net> Message-ID: <45AAF3FD.7050503@verizon.net> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vt82c686a.patch Type: text/x-patch Size: 34813 bytes Desc: not available URL: From stuge-linuxbios at cdy.org Mon Jan 15 05:55:12 2007 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Mon, 15 Jan 2007 05:55:12 +0100 Subject: [LinuxBIOS] Add support for Via vt82c686a In-Reply-To: <45AAF3FD.7050503@verizon.net> References: <45AA9938.6020804@verizon.net> <20070114235739.GB20305@greenwood> <45AAE156.5030206@verizon.net> <45AAE51F.9090801@verizon.net> <45AAF3FD.7050503@verizon.net> Message-ID: <20070115045512.21513.qmail@cdy.org> On Sun, Jan 14, 2007 at 10:24:45PM -0500, Corey Osgood wrote: > Thanks! And mwrwilkinson appears to be Mark Wilkinson. I found an old > sourceforge email for him, so I've used that for now, if anyone has an > updated email for him I'll fix it. My archive shows mark.wilkinson at 2pmtech.com on 07 Sep 2006, but I can't say which address he would prefer. > References > > Visible links > 1. mailto:corey_osgood at verizon.net > 2. mailto:corey_osgood at verizon.net Please avoid sending HTML emails to the list. Thanks! :) //Peter From mark.wilkinson at 2pmtech.com Mon Jan 15 10:07:26 2007 From: mark.wilkinson at 2pmtech.com (Mark Wilkinson) Date: Mon, 15 Jan 2007 09:07:26 +0000 Subject: [LinuxBIOS] Add support for Via vt82c686a In-Reply-To: <20070115045512.21513.qmail@cdy.org> References: <45AA9938.6020804@verizon.net> <20070114235739.GB20305@greenwood> <45AAE156.5030206@verizon.net> <45AAE51F.9090801@verizon.net> <45AAF3FD.7050503@verizon.net> <20070115045512.21513.qmail@cdy.org> Message-ID: <45AB444E.4000703@2pmtech.com> Hi Peter, The address I'd prefer is 'mark.wilkinson at 2pmtech.co.uk' - com will work but takes a longer route inside my company's e-mail system :-) I'm not even sure the sourceforge one is still working for me. Regards Mark. Peter Stuge wrote: >On Sun, Jan 14, 2007 at 10:24:45PM -0500, Corey Osgood wrote: > > >> Thanks! And mwrwilkinson appears to be Mark Wilkinson. I found an old >> sourceforge email for him, so I've used that for now, if anyone has an >> updated email for him I'll fix it. >> >> > >My archive shows mark.wilkinson at 2pmtech.com on 07 Sep 2006, but I >can't say which address he would prefer. > > > > >>References >> >> Visible links >> 1. mailto:corey_osgood at verizon.net >> 2. mailto:corey_osgood at verizon.net >> >> > >Please avoid sending HTML emails to the list. Thanks! :) > > >//Peter > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Mon Jan 15 15:58:05 2007 From: rminnich at gmail.com (ron minnich) Date: Mon, 15 Jan 2007 07:58:05 -0700 Subject: [LinuxBIOS] epia, rom_cc and locking code In-Reply-To: <45AA56E0.3000103@hewson-venieri.com> References: <4539F406.1080308@hewson-venieri.com> <20070113115041.GA24453@coresystems.de> <45A92708.20709@hewson-venieri.com> <20070114150728.GB21694@coresystems.de> <45AA56E0.3000103@hewson-venieri.com> Message-ID: <13426df10701150658u4d242f63na4499898cb4527f9@mail.gmail.com> On 1/14/07, Ben Hewson wrote: > there are some posts on the mailing list I made, but basically my older > version of linuxbios using filo boots, but a later version after the > rom_cc patch doesn't boot any more. > > exactly the same hardware and filo image (v 0.5 ). can you get us a source-level diff? ron From segher at kernel.crashing.org Mon Jan 15 16:57:59 2007 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Mon, 15 Jan 2007 16:57:59 +0100 Subject: [LinuxBIOS] Add support for Via vt82c686a In-Reply-To: <45AAE156.5030206@verizon.net> References: <45AA9938.6020804@verizon.net> <20070114235739.GB20305@greenwood> <45AAE156.5030206@verizon.net> Message-ID: <366f3f5e6a46f27ea5e4a1edfac2d58c@kernel.crashing.org> >> Sign-off-by, see >> http://linuxbios.org/Development_Guidelines#Sign-off_Procedure Signed-off-by: even. > As far as the GPL headers go, should everyone who's ever made a change > to that file be included? I'm assuming yes, and working on > straightening it out. Only people who made substantive, non-mechanical changes need to be listed, other changes aren't copyrightable anyway. You can of course list everyone anyway, heh. Segher From uwe at hermann-uwe.de Mon Jan 15 18:50:39 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Mon, 15 Jan 2007 18:50:39 +0100 Subject: [LinuxBIOS] Add support for Via vt82c686a In-Reply-To: <366f3f5e6a46f27ea5e4a1edfac2d58c@kernel.crashing.org> References: <45AA9938.6020804@verizon.net> <20070114235739.GB20305@greenwood> <45AAE156.5030206@verizon.net> <366f3f5e6a46f27ea5e4a1edfac2d58c@kernel.crashing.org> Message-ID: <20070115175038.GA10359@greenwood> Hi, On Mon, Jan 15, 2007 at 04:57:59PM +0100, Segher Boessenkool wrote: > >>Sign-off-by, see > >>http://linuxbios.org/Development_Guidelines#Sign-off_Procedure > > Signed-off-by: even. Yep, typo on my side, sorry. > >As far as the GPL headers go, should everyone who's ever made a change > >to that file be included? I'm assuming yes, and working on > >straightening it out. > > Only people who made substantive, non-mechanical changes need > to be listed, other changes aren't copyrightable anyway. You > can of course list everyone anyway, heh. Yeah, everyone who contributed a non-trivial amount of code, something like 4 or more (non-trivial) lines of code maybe... Merely fixing typos etc. doesn't make you a copyright holder on (part of) the code. Cheers, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From svn at openbios.org Mon Jan 15 19:41:50 2007 From: svn at openbios.org (LinuxBIOS) Date: Mon, 15 Jan 2007 18:41:50 -0000 Subject: [LinuxBIOS] #60: Change 'ram' to 'RAM' in user-visible output In-Reply-To: <060.45dc2426c21ad9b63b9bde7ba6da46fa@openbios.org> References: <060.45dc2426c21ad9b63b9bde7ba6da46fa@openbios.org> Message-ID: <069.1fd4e11e73c27a6978b320dbeadba01a@openbios.org> #60: Change 'ram' to 'RAM' in user-visible output ----------------------------+----------------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: new Priority: minor | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: | Keywords: Dependencies: | Patchstatus: patch needs review ----------------------------+----------------------------------------------- Comment (by stepan): Acked-by: Stefan Reinauer -- Ticket URL: LinuxBIOS From corey_osgood at verizon.net Mon Jan 15 20:17:30 2007 From: corey_osgood at verizon.net (Corey Osgood) Date: Mon, 15 Jan 2007 14:17:30 -0500 Subject: [LinuxBIOS] Add support for Via vt82c686a In-Reply-To: <20070115175038.GA10359@greenwood> References: <45AA9938.6020804@verizon.net> <20070114235739.GB20305@greenwood> <45AAE156.5030206@verizon.net> <366f3f5e6a46f27ea5e4a1edfac2d58c@kernel.crashing.org> <20070115175038.GA10359@greenwood> Message-ID: <45ABD34A.1040609@verizon.net> Okay, looking further into the archives, and into the very /origins/ of these files, in the original freebios cvs (on sourceforge), it appears that there were a lot more people involved than I've included. This patch has everyone whos made any change to the linuxbios svn whatsoever, I don't think any of them are too trivial, but I haven't got the time to go back and check right now. Most of that content has, over time, been rewritten, but some of it's still intact (mainly in the vtX_ide.c). If someone wants to trace all the changes, be my guest, but I haven't got the time right now. I've updated Mark's email, thanks for getting ahold of him. Also, by Ron's definition, I probably don't even qualify as a copyright holder...if anyone has a problem with including myself, let me know and I am completely willing to remove it (or it can be removed by someone else), as I don't think I've written any actual code, just changed a few variables here and there. Signed-off-by: Corey Osgood -------------- next part -------------- A non-text attachment was scrubbed... Name: vt82c686a.patch Type: text/x-patch Size: 34795 bytes Desc: not available URL: From talbotx at comcast.net Tue Jan 16 02:21:13 2007 From: talbotx at comcast.net (Adam Talbot) Date: Mon, 15 Jan 2007 17:21:13 -0800 Subject: [LinuxBIOS] Add support for Via vt82c686a In-Reply-To: <45ABD34A.1040609@verizon.net> References: <45AA9938.6020804@verizon.net> <20070114235739.GB20305@greenwood> <45AAE156.5030206@verizon.net> <366f3f5e6a46f27ea5e4a1edfac2d58c@kernel.crashing.org> <20070115175038.GA10359@greenwood> <45ABD34A.1040609@verizon.net> Message-ID: <45AC2889.1070307@comcast.net> Do we need to update the website to reflect the state of the the via vt82c686a, under the "Supported Chipsets and Devices" -Adam Corey Osgood wrote: > Okay, looking further into the archives, and into the very /origins/ > of these files, in the original freebios cvs (on sourceforge), it > appears that there were a lot more people involved than I've included. > This patch has everyone whos made any change to the linuxbios svn > whatsoever, I don't think any of them are too trivial, but I haven't > got the time to go back and check right now. Most of that content has, > over time, been rewritten, but some of it's still intact (mainly in > the vtX_ide.c). If someone wants to trace all the changes, be my > guest, but I haven't got the time right now. I've updated Mark's > email, thanks for getting ahold of him. Also, by Ron's definition, I > probably don't even qualify as a copyright holder...if anyone has a > problem with including myself, let me know and I am completely willing > to remove it (or it can be removed by someone else), as I don't think > I've written any actual code, just changed a few variables here and > there. > > > Signed-off-by: Corey Osgood > ------------------------------------------------------------------------ > > Index: src/southbridge/via/vt82c686a/vt82c686a_early_smbus.c > =================================================================== > --- src/southbridge/via/vt82c686a/vt82c686a_early_smbus.c (revision 0) > +++ src/southbridge/via/vt82c686a/vt82c686a_early_smbus.c (revision 0) > @@ -0,0 +1,317 @@ > +/* > + * This file is part of the LinuxBIOS project. > + * > + * Copyright (C) 2003 Ron Minnich > + * Copyright (C) 2003 Eric W. Beiderman > + * Copyright (C) 2004 Mark Wilkinson > + * Copyright (C) 2005 Li-Ta Lo > + * Copyright (C) 2007 Corey Osgood > + * > + * 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 SMBUS_IO_BASE 0x5000 > + > +#define SMBHSTSTAT 0x0 > +#define SMBSLVSTAT 0x1 > +#define SMBHSTCTL 0x2 > +#define SMBHSTCMD 0x3 > +#define SMBXMITADD 0x4 > +#define SMBHSTDAT0 0x5 > +#define SMBHSTDAT1 0x6 > +#define SMBBLKDAT 0x7 > +#define SMBSLVCTL 0x8 > +#define SMBTRNSADD 0x9 > +#define SMBSLVDATA 0xa > +#define SMLINK_PIN_CTL 0xe > +#define SMBUS_PIN_CTL 0xf > + > +/* Define register settings */ > +#define HOST_RESET 0xff > +#define DIMM_BASE 0xa0 // 1010000 is base for DIMM in SMBus > +#define READ_CMD 0x01 // 1 in the 0 bit of SMBHSTADD states to READ > + > + > +#define SMBUS_TIMEOUT (100*1000*10) > + > +static void enable_smbus(void) > +{ > + device_t dev; > + unsigned char c; > + /* Power management controller */ > + dev = pci_locate_device(PCI_ID(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4), 0); > + > + if (dev == PCI_DEV_INVALID) { > + die("SMBUS controller not found\r\n"); > + } > + // set IO base address to SMBUS_IO_BASE > + pci_write_config32(dev, 0x90, SMBUS_IO_BASE | 1); > + > + // Enable SMBus > + c = pci_read_config8(dev, 0xd2); > + c |= 5; > + pci_write_config8(dev, 0xd2, c); > + > + /* make it work for I/O ... > + */ > + dev = pci_locate_device(PCI_ID(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4), 0); > + c = pci_read_config8(dev, 4); > + c |= 1; > + pci_write_config8(dev, 4, c); > + print_debug_hex8(c); > + print_debug(" is the comm register\r\n"); > + > + print_debug("SMBus controller enabled\r\n"); > +} > + > + > +static inline void smbus_delay(void) > +{ > + outb(0x80, 0x80); > +} > + > +static int smbus_wait_until_active(void) > +{ > + unsigned long loops; > + loops = SMBUS_TIMEOUT; > + do { > + unsigned char val; > + smbus_delay(); > + val = inb(SMBUS_IO_BASE + SMBHSTSTAT); > + if ((val & 1)) { > + break; > + } > + } while (--loops); > + return loops ? 0 : -4; > +} > + > +static int smbus_wait_until_ready(void) > +{ > + unsigned long loops; > + loops = SMBUS_TIMEOUT; > + do { > + unsigned char val; > + smbus_delay(); > + val = inb(SMBUS_IO_BASE + SMBHSTSTAT); > + if ((val & 1) == 0) { > + break; > + } > + if (loops == (SMBUS_TIMEOUT / 2)) { > + outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), SMBUS_IO_BASE + SMBHSTSTAT); > + } > + } while (--loops); > + return loops ? 0 : -2; > +} > + > +static int smbus_wait_until_done(void) > +{ > + unsigned long loops; > + loops = SMBUS_TIMEOUT; > + do { > + unsigned char val; > + smbus_delay(); > + > + val = inb(SMBUS_IO_BASE + SMBHSTSTAT); > + if ((val & 1) == 0) { > + break; > + } > + } while (--loops); > + return loops ? 0 : -3; > +} > + > +void smbus_reset(void) > +{ > + outb(HOST_RESET, SMBUS_IO_BASE + SMBHSTSTAT); > + outb(HOST_RESET, SMBUS_IO_BASE + SMBHSTSTAT); > + outb(HOST_RESET, SMBUS_IO_BASE + SMBHSTSTAT); > + outb(HOST_RESET, SMBUS_IO_BASE + SMBHSTSTAT); > + > + smbus_wait_until_ready(); > + print_debug("After reset status "); > + print_debug_hex8(inb(SMBUS_IO_BASE + SMBHSTSTAT)); > + print_debug("\r\n"); > +} > + > +static void smbus_print_error(unsigned char host_status_register) > +{ > + > + print_err("smbus_error: "); > + print_err_hex8(host_status_register); > + print_err("\r\n"); > + if (host_status_register & (1 << 4)) { > + print_err("Interrup/SMI# was Failed Bus Transaction\r\n"); > + } > + if (host_status_register & (1 << 3)) { > + print_err("Bus Error\r\n"); > + } > + if (host_status_register & (1 << 2)) { > + print_err("Device Error\r\n"); > + } > + if (host_status_register & (1 << 1)) { > + print_err("Interrupt/SMI# was Successful Completion\r\n"); > + } > + if (host_status_register & (1 << 0)) { > + print_err("Host Busy\r\n"); > + } > +} > + > +/* > + * Copied from intel/i82801dbm early smbus code - suggested by rgm. > + * Modifications/check against i2c-viapro driver code from linux-2.4.22 > + * and VT8231 Reference Docs - mw. > + */ > +static int smbus_read_byte(unsigned device, unsigned address) > +{ > + unsigned char global_control_register; > + unsigned char global_status_register; > + unsigned char byte; > + > + if (smbus_wait_until_ready() < 0) { > + outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), SMBUS_IO_BASE + SMBHSTSTAT); > + if (smbus_wait_until_ready() < 0) { > + return -2; > + } > + } > + > + /* setup transaction */ > + /* disable interrupts */ > + outb(inb(SMBUS_IO_BASE + SMBHSTCTL) & 0xfe, SMBUS_IO_BASE + SMBHSTCTL); > + /* set the device I'm talking too */ > + outb(((device & 0x7f) << 1) | 1, SMBUS_IO_BASE + SMBXMITADD); > + /* set the command/address... */ > + outb(address & 0xFF, SMBUS_IO_BASE + SMBHSTCMD); > + /* set up for a byte data read */ > + outb((inb(SMBUS_IO_BASE + SMBHSTCTL) & 0xe3) | (0x2 << 2), SMBUS_IO_BASE + SMBHSTCTL); > + > + /* clear any lingering errors, so the transaction will run */ > + outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), SMBUS_IO_BASE + SMBHSTSTAT); > + > + /* clear the data byte... */ > + outb(0, SMBUS_IO_BASE + SMBHSTDAT0); > + > + /* start a byte read, with interrupts disabled */ > + outb((inb(SMBUS_IO_BASE + SMBHSTCTL) | 0x40), SMBUS_IO_BASE + SMBHSTCTL); > + /* poll for it to start */ > + if (smbus_wait_until_active() < 0) { > + return -4; > + } > + > + /* poll for transaction completion */ > + if (smbus_wait_until_done() < 0) { > + return -3; > + } > + > + /* Ignore the Host Busy & Command Complete ? */ > + global_status_register = inb(SMBUS_IO_BASE + SMBHSTSTAT) & ~((1 << 1) | (1 << 0)); > + > + /* read results of transaction */ > + byte = inb(SMBUS_IO_BASE + SMBHSTDAT0); > + > + if (global_status_register != 0) { > + return -1; > + } > + return byte; > +} > + > +#if 0 > +/* SMBus routines borrowed from VIA's Trident Driver */ > +/* this works, so I am not going to touch it for now -- rgm */ > +static unsigned char smbus_read_byte(unsigned char devAdr, unsigned char bIndex) > +{ > + unsigned int i; > + unsigned char bData; > + unsigned char sts = 0; > + > + /* clear host status */ > + outb(0xff, SMBUS_IO_BASE); > + > + /* check SMBUS ready */ > + for (i = 0; i < SMBUS_TIMEOUT; i++) > + if ((inb(SMBUS_IO_BASE) & 0x01) == 0) > + break; > + > + /* set host command */ > + outb(bIndex, SMBUS_IO_BASE + 3); > + > + /* set slave address */ > + outb(devAdr | 0x01, SMBUS_IO_BASE + 4); > + > + /* start */ > + outb(0x48, SMBUS_IO_BASE + 2); > + > + /* SMBUS Wait Ready */ > + for (i = 0; i < SMBUS_TIMEOUT; i++) > + if (((sts = inb(SMBUS_IO_BASE)) & 0x01) == 0) > + break; > + if ((sts & ~3) != 0) { > + smbus_print_error(sts); > + return 0; > + } > + bData = inb(SMBUS_IO_BASE + 5); > + > + return bData; > + > +} > +#endif > +/* for reference, here is the fancier version which we will use at some > + * point > + */ > +# if 0 > +int smbus_read_byte(unsigned device, unsigned address, unsigned char *result) > +{ > + unsigned char host_status_register; > + unsigned char byte; > + > + reset(); > + > + smbus_wait_until_ready(); > + > + /* setup transaction */ > + /* disable interrupts */ > + outb(inb(SMBUS_IO_BASE + SMBHSTCTL) & (~1), SMBUS_IO_BASE + SMBHSTCTL); > + /* set the device I'm talking too */ > + outb(((device & 0x7f) << 1) | 1, SMBUS_IO_BASE + SMBXMITADD); > + /* set the command/address... */ > + outb(address & 0xFF, SMBUS_IO_BASE + SMBHSTCMD); > + /* set up for a byte data read */ > + outb((inb(SMBUS_IO_BASE + SMBHSTCTL) & 0xE3) | (0x2 << 2), SMBUS_IO_BASE + SMBHSTCTL); > + > + /* clear any lingering errors, so the transaction will run */ > + outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), SMBUS_IO_BASE + SMBHSTSTAT); > + > + /* clear the data byte... */ > + outb(0, SMBUS_IO_BASE + SMBHSTDAT0); > + > + /* start the command */ > + outb((inb(SMBUS_IO_BASE + SMBHSTCTL) | 0x40), SMBUS_IO_BASE + SMBHSTCTL); > + > + /* poll for transaction completion */ > + smbus_wait_until_done(); > + > + host_status_register = inb(SMBUS_IO_BASE + SMBHSTSTAT); > + > + /* Ignore the In Use Status... */ > + host_status_register &= ~(1 << 6); > + > + /* read results of transaction */ > + byte = inb(SMBUS_IO_BASE + SMBHSTDAT0); > + smbus_print_error(byte); > + > + *result = byte; > + return host_status_register != 0x02; > +} > + > + > +#endif > Index: src/southbridge/via/vt82c686a/Config.lb > =================================================================== > --- src/southbridge/via/vt82c686a/Config.lb (revision 0) > +++ src/southbridge/via/vt82c686a/Config.lb (revision 0) > @@ -0,0 +1,8 @@ > +config chip.h > +driver vt82c686a.o > +driver vt82c686a_lpc.o > +driver vt82c686a_acpi.o > +driver vt82c686a_ide.o > +#driver vt82c686a_nic.o > +#driver vt82c686a_usb.o > + > Index: src/southbridge/via/vt82c686a/vt82c686a_nic.c > =================================================================== > --- src/southbridge/via/vt82c686a/vt82c686a_nic.c (revision 0) > +++ src/southbridge/via/vt82c686a/vt82c686a_nic.c (revision 0) > @@ -0,0 +1,62 @@ > +/* > + * This file is part of the LinuxBIOS project. > + * > + * Copyright (C) 2005 Li-Ta Lo > + * Copyright (C) 2007 Corey Osgood > + * > + * 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 > + > + > +/* > + * Enable the ethernet device and turn off stepping (because it is integrated > + * inside the southbridge) > + * > + * Since my vt82c686 doesn't have ethernet, this will fail. but it will be fun > + * to watch */ > +static void nic_init(struct device *dev) > +{ > + uint8_t byte; > + > + printk_debug("Configuring VIA LAN\n"); > + > + /* We don't need stepping - though the device supports it */ > + byte = pci_read_config8(dev, PCI_COMMAND); > + byte &= ~PCI_COMMAND_WAIT; > + pci_write_config8(dev, PCI_COMMAND, byte); > +} > + > +static struct device_operations nic_ops = { > + .read_resources = pci_dev_read_resources, > + .set_resources = pci_dev_set_resources, > + .enable_resources = pci_dev_enable_resources, > + .init = nic_init, > + .enable = 0, > + .ops_pci = 0, > +}; > + > +/* If anyone ever has a vt82c686a with integrated nic, they'll need to modify > + * this deviceid to make it work */ > +static struct pci_driver northbridge_driver __pci_driver = { > + .ops = &nic_ops, > + .vendor = PCI_VENDOR_ID_VIA, > + .device = PCI_DEVICE_ID_VIA_8233_7, > +}; > Index: src/southbridge/via/vt82c686a/vt82c686a_usb.c > =================================================================== > --- src/southbridge/via/vt82c686a/vt82c686a_usb.c (revision 0) > +++ src/southbridge/via/vt82c686a/vt82c686a_usb.c (revision 0) > @@ -0,0 +1,72 @@ > +/* > + * This file is part of the LinuxBIOS project. > + * > + * Copyright (C) 2005 Li-Ta Lo > + * Copyright (C) 2007 Corey Osgood > + * > + * 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 > + */ > + > +static void usb_on(int enable) > +{ > + unsigned char regval; > + > + /* Base 82c686 controller */ > + device_t dev0 = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, 0); > + /* USB controller 1 */ > + device_t dev2 = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, 0); > + /* USB controller 2 */ > + device_t dev3 = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, dev2); > + > + /* enable USB1 */ > + if(dev2) { > + if (enable) { > + pci_write_config8(dev2, 0x3c, 0x05); > + pci_write_config8(dev2, 0x04, 0x07); > + } else { > + pci_write_config8(dev2, 0x3c, 0x00); > + pci_write_config8(dev2, 0x04, 0x00); > + } > + } > + > + if(dev0) { > + regval = pci_read_config8(dev0, 0x50); > + if (enable) > + regval &= ~(0x10); > + else > + regval |= 0x10; > + pci_write_config8(dev0, 0x50, regval); > + } > + > + /* enable USB2 */ > + if(dev3) { > + if (enable) { > + pci_write_config8(dev3, 0x3c, 0x05); > + pci_write_config8(dev3, 0x04, 0x07); > + } else { > + pci_write_config8(dev3, 0x3c, 0x00); > + pci_write_config8(dev3, 0x04, 0x00); > + } > + } > + > + if(dev0) { > + regval = pci_read_config8(dev0, 0x50); > + if (enable) > + regval &= ~(0x20); > + else > + regval |= 0x20; > + pci_write_config8(dev0, 0x50, regval); > + } > +} > Index: src/southbridge/via/vt82c686a/vt82c686a_early_serial.c > =================================================================== > --- src/southbridge/via/vt82c686a/vt82c686a_early_serial.c (revision 0) > +++ src/southbridge/via/vt82c686a/vt82c686a_early_serial.c (revision 0) > @@ -0,0 +1,97 @@ > +/* > + * This file is part of the LinuxBIOS project. > + * > + * Copyright (C) 2003 Ron Minnich > + * Copyright (C) 2003 Eric W. Beiderman > + * Copyright (C) 2007 Corey Osgood > + * > + * 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 > + */ > + > +/* > + * Enable the serial evices on the VIA > + */ > + > + > +/* The base address is 0x15c, 0x2e, depending on config bytes */ > +#include > +#define SIO_BASE 0x3f0 > +#define SIO_DATA SIO_BASE+1 > + > +static void vt82c686a_writesuper(uint8_t reg, uint8_t val) > +{ > + outb(reg, SIO_BASE); > + outb(val, SIO_DATA); > +} > + > +static void vt82c686a_writesiobyte(uint16_t reg, uint8_t val) > +{ > + outb(val, reg); > +} > + > +static void vt82c686a_writesioword(uint16_t reg, uint16_t val) > +{ > + outw(val, reg); > +} > + > + > +/* regs we use: 85, and the southbridge devfn is defined by the > + mainboard > + */ > + > +static void enable_vt82c686a_serial(void) > +{ > + unsigned long x; > + uint8_t c; > + device_t dev; > + outb(6, 0x80); > + dev = pci_locate_device(PCI_ID(PCI_VENDOR_ID_VIA,PCI_DEVICE_ID_VIA_82C686), 0); > + > + if (dev == PCI_DEV_INVALID) { > + outb(7, 0x80); > + die("Serial controller not found\r\n"); //umm, pointless??? > + } > + > + /* first, you have to enable the superio and superio config. > + put a 6 reg 80 > + */ > + c = pci_read_config8(dev, 0x50); > + c |= 6; > + pci_write_config8(dev, 0x50, c); > + outb(2, 0x80); > + // now go ahead and set up com1. > + // set address > + vt82c686a_writesuper(0xf4, 0xfe); > + // enable serial out > + vt82c686a_writesuper(0xf2, 7); > + // That's it for the sio stuff. > + // movl $SUPERIOCONFIG, %eax > + // movb $9, %dl > + // PCI_WRITE_CONFIG_BYTE > + // set up reg to set baud rate. > + vt82c686a_writesiobyte(0x3fb, 0x80); > + // Set 115 kb > + vt82c686a_writesioword(0x3f8, 1); > + // Set 9.6 kb > + // WRITESIOWORD(0x3f8, 12) > + // now set no parity, one stop, 8 bits > + vt82c686a_writesiobyte(0x3fb, 3); > + // now turn on RTS, DRT > + vt82c686a_writesiobyte(0x3fc, 3); > + // Enable interrupts > + vt82c686a_writesiobyte(0x3f9, 0xf); > + // should be done. Dump a char for fun. > + vt82c686a_writesiobyte(0x3f8, 48); > +} > Index: src/southbridge/via/vt82c686a/vt82c686a_acpi.c > =================================================================== > --- src/southbridge/via/vt82c686a/vt82c686a_acpi.c (revision 0) > +++ src/southbridge/via/vt82c686a/vt82c686a_acpi.c (revision 0) > @@ -0,0 +1,64 @@ > +/* > + * This file is part of the LinuxBIOS project. > + * > + * Copyright (C) 2005 Li-Ta Lo > + * Copyright (C) 2007 Corey Osgood > + * > + * 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 > + > +static void acpi_init(struct device *dev) > +{ > + printk_debug("Configuring VIA ACPI\n"); > + > + // Set ACPI base address to IO 0x4000 > + pci_write_config32(dev, 0x48, 0x4001); > + > + // Enable ACPI access (and setup like award) > + pci_write_config8(dev, 0x41, 0x84); > + > + // Set hardware monitor base address to IO 0x6000 > + pci_write_config32(dev, 0x70, 0x6001); > + > + // Enable hardware monitor (and setup like award) > + pci_write_config8(dev, 0x74, 0x01); > + > + // set IO base address to 0x5000 > + pci_write_config32(dev, 0x90, 0x5001); > + > + // Enable SMBus > + pci_write_config8(dev, 0xd2, 0x01); > +} > + > +static struct device_operations acpi_ops = { > + .read_resources = pci_dev_read_resources, > + .set_resources = pci_dev_set_resources, > + .enable_resources = pci_dev_enable_resources, > + .init = acpi_init, > + .enable = 0, > + .ops_pci = 0, > +}; > + > +static struct pci_driver northbridge_driver __pci_driver = { > + .ops = &acpi_ops, > + .vendor = PCI_VENDOR_ID_VIA, > + .device = PCI_DEVICE_ID_VIA_82C686_4, /* For 686b, this is different (3057)*/ > +}; > Index: src/southbridge/via/vt82c686a/chip.h > =================================================================== > --- src/southbridge/via/vt82c686a/chip.h (revision 0) > +++ src/southbridge/via/vt82c686a/chip.h (revision 0) > @@ -0,0 +1,41 @@ > +/* > + * This file is part of the LinuxBIOS project. > + * > + * Copyright (C) 2003 Ron Minnich > + * Copyright (C) 2003 Eric W. Beiderman > + * Copyright (C) 2004 Mark Wilkinson > + * Copyright (C) 2005 Li-Ta Lo > + * Copyright (C) 2005 Stefan Reinauer > + * Copyright (C) 2007 Corey Osgood > + * > + * 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 _SOUTHBRIDGE_VIA_VT82C686A > +#define _SOUTHBRIDGE_VIA_VT82C686A > + > +extern struct chip_operations southbridge_via_vt82c686a_ops; > + > +struct southbridge_via_vt82c686a_config { > + /* enables of Non-PCI devices */ > + int enable_native_ide; > + int enable_com_ports; > + int enable_keyboard; > + /* currently not parsed but needed by densitron dpx114 */ > + int enable_usb; > + int enable_nvram; > +}; > + > +#endif /* _SOUTHBRIDGE_VIA_VT82C686A */ > Index: src/southbridge/via/vt82c686a/vt82c686a_lpc.c > =================================================================== > --- src/southbridge/via/vt82c686a/vt82c686a_lpc.c (revision 0) > +++ src/southbridge/via/vt82c686a/vt82c686a_lpc.c (revision 0) > @@ -0,0 +1,174 @@ > +/* > + * This file is part of the LinuxBIOS project. > + * > + * Copyright (C) 2005 Li-Ta Lo > + * Copyright (C) 2007 Corey Osgood > + * > + * 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 > + > +#include "chip.h" > + > +/* PIRQ init > + */ > +void pci_assign_irqs(unsigned bus, unsigned slot, const unsigned char pIntAtoD[4]); > +static const unsigned char southbridgeIrqs[4] = { 11, 5, 10, 12 }; > +static const unsigned char enetIrqs[4] = { 11, 5, 10, 12 }; > +static const unsigned char slotIrqs[4] = { 5, 10, 12, 11 }; > + > +/* > + Our IDSEL mappings are as follows > + PCI slot is AD31 (device 15) (00:14.0) > + Southbridge is AD28 (device 12) (00:11.0) > +*/ > +static void pci_routing_fixup(struct device *dev) > +{ > + > + printk_info("%s: dev is %p\n", __FUNCTION__, dev); > + if (dev) { > + /* initialize PCI interupts - these assignments depend > + on the PCB routing of PINTA-D > + > + PINTA = IRQ11 > + PINTB = IRQ5 > + PINTC = IRQ10 > + PINTD = IRQ12 > + */ > + pci_write_config8(dev, 0x55, 0xb0); > + pci_write_config8(dev, 0x56, 0xa5); > + pci_write_config8(dev, 0x57, 0xc0); > + } > + > + // Standard southbridge components > + printk_info("setting southbridge\n"); > + pci_assign_irqs(0, 0x11, southbridgeIrqs); > + > + // Ethernet built into southbridge > + printk_info("setting ethernet\n"); > + pci_assign_irqs(0, 0x12, enetIrqs); > + > + // PCI slot > + printk_info("setting pci slot\n"); > + pci_assign_irqs(0, 0x14, slotIrqs); > + printk_info("%s: DONE\n", __FUNCTION__); > +} > + > +static void vt82c686_init(struct device *dev) > +{ > + unsigned char enables; > + struct southbridge_via_vt82c686a_config *conf = dev->chip_info; > + > + printk_debug("vt82c686a init\n"); > + > + // enable the internal I/O decode > + enables = pci_read_config8(dev, 0x6C); > + enables |= 0x80; > + pci_write_config8(dev, 0x6C, enables); > + > + // Map 4MB of FLASH into the address space > + pci_write_config8(dev, 0x41, 0x7f); > + > + // Set bit 6 of 0x40, because Award does it (IO recovery time) > + // IMPORTANT FIX - EISA 0x4d0 decoding must be on so that PCI > + // interrupts can be properly marked as level triggered. > + enables = pci_read_config8(dev, 0x40); > + pci_write_config8(dev, 0x40, enables); > + > + // Set 0x42 to 0xf0 to match Award bios > + enables = pci_read_config8(dev, 0x42); > + enables |= 0xf0; > + pci_write_config8(dev, 0x42, enables); > + > + // Set bit 3 of 0x4a, to match award (dummy pci request) > + enables = pci_read_config8(dev, 0x4a); > + enables |= 0x08; > + pci_write_config8(dev, 0x4a, enables); > + > + // Set bit 3 of 0x4f to match award (use INIT# as cpu reset) > + enables = pci_read_config8(dev, 0x4f); > + enables |= 0x08; > + pci_write_config8(dev, 0x4f, enables); > + > + // Set 0x58 to 0x03 to match Award > + pci_write_config8(dev, 0x58, 0x03); > + > + // enable the ethernet/RTC > + if (dev) { > + enables = pci_read_config8(dev, 0x51); > + enables |= 0x18; > + pci_write_config8(dev, 0x51, enables); > + } > + > + // enable IDE, since Linux won't do it. > + // First do some more things to devfn (17,0) > + // note: this should already be cleared, according to the book. > + enables = pci_read_config8(dev, 0x50); > + printk_debug("IDE enable in reg. 50 is 0x%x\n", enables); > + enables &= ~8; // need manifest constant here! > + printk_debug("set IDE reg. 50 to 0x%x\n", enables); > + pci_write_config8(dev, 0x50, enables); > + > + // set default interrupt values (IDE) > + enables = pci_read_config8(dev, 0x4c); > + printk_debug("IRQs in reg. 4c are 0x%x\n", enables & 0xf); > + // clear out whatever was there. > + enables &= ~0xf; > + enables |= 4; > + printk_debug("setting reg. 4c to 0x%x\n", enables); > + pci_write_config8(dev, 0x4c, enables); > + > + // set up the serial port interrupts. > + // com2 to 3, com1 to 4 > + pci_write_config8(dev, 0x46, 0x04); > + pci_write_config8(dev, 0x47, 0x03); > + pci_write_config8(dev, 0x6e, 0x98); > + > + /* set up isa bus -- i/o recovery time, rom write enable, extend-ale */ > + pci_write_config8(dev, 0x40, 0x54); > + //ethernet_fixup(); > + > + // Start the rtc > + rtc_init(0); > +} > + > +static void southbridge_init(struct device *dev) > +{ > + vt82c686a_init(dev); > + pci_routing_fixup(dev); > +} > + > +static struct device_operations vt82c686_lpc_ops = { > + .read_resources = pci_dev_read_resources, > + .set_resources = pci_dev_set_resources, > + .enable_resources = pci_dev_enable_resources, > + .init = &southbridge_init, > + .scan_bus = scan_static_bus, > + .enable = 0, > + .ops_pci = 0, > +}; > + > +static struct pci_driver lpc_driver __pci_driver = { > + .ops = &vt82c686a_lpc_ops, > + .vendor = PCI_VENDOR_ID_VIA, > + .device = PCI_DEVICE_ID_VIA_82C686, > +}; > Index: src/southbridge/via/vt82c686a/vt82c686a.c > =================================================================== > --- src/southbridge/via/vt82c686a/vt82c686a.c (revision 0) > +++ src/southbridge/via/vt82c686a/vt82c686a.c (revision 0) > @@ -0,0 +1,97 @@ > +/* > + * This file is part of the LinuxBIOS project. > + * > + * Copyright (C) 2003-2004 Ron Minnich > + * Copyright (C) 2003-2004 Eric W. Beiderman > + * Copyright (C) 2004 Mark Wilkinson > + * Copyright (C) 2005 Li-Ta Lo > + * Copyright (C) 2006 Uwe Hermann > + * Copyright (C) 2007 Corey Osgood > + * > + * 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 > +#include > + > +#include "chip.h" > + > +/* Base 8231 controller */ > +static device_t lpc_dev; > + > +void hard_reset(void) > +{ > + printk_err("NO HARD RESET ON VT82C686A! FIX ME!\n"); > +} > + > +static void keyboard_on(void) > +{ > + unsigned char regval; > + > + if (lpc_dev) { > + regval = pci_read_config8(lpc_dev, 0x51); > + regval |= 0x0f; > + pci_write_config8(lpc_dev, 0x51, regval); > + } > + init_pc_keyboard(0x60, 0x64, 0); > +} > + > +static void com_port_on(void) > +{ > +#if 0 > + // enable com1 and com2. > + enables = pci_read_config8(dev, 0x6e); > + > + /* 0x80 is enable com port b, 0x10 is to make it com2, 0x8 > + * is enable com port a as com1 kevinh/Ispiri - Old code > + * thought 0x01 would make it com1, that was wrong enables = > + * 0x80 | 0x10 | 0x8 ; pci_write_config8(dev, 0x6e, > + * enables); // note: this is also a redo of some port of > + * assembly, but we want everything up. > + */ > + > + /* set com1 to 115 kbaud not clear how to do this yet. > + * forget it; done in assembly. > + */ > +#endif > +} > + > +/* FixME: to be removed ? */ > +static void vt82c686a_enable(struct device *dev) > +{ > + struct southbridge_via_vt82c686a_config *conf = dev->chip_info; > + > + if (!lpc_dev) { > + /* the first time called, enable devices not on PCI bus > + * FIXME: is that device struct there yet? */ > + lpc_dev = dev_find_device(PCI_VENDOR_ID_VIA, > + PCI_DEVICE_ID_VIA_82C686, 0); > + if (conf->enable_keyboard) > + keyboard_on(); > + if (conf->enable_com_ports) > + com_port_on(); > + } > +} > + > +struct chip_operations southbridge_via_vt82c686a_ops = { > + CHIP_NAME("VIA VT82C686A Southbridge") > + .enable_dev = vt82c686a_enable, > +}; > Index: src/southbridge/via/vt82c686a/vt82c686a_ide.c > =================================================================== > --- src/southbridge/via/vt82c686a/vt82c686a_ide.c (revision 0) > +++ src/southbridge/via/vt82c686a/vt82c686a_ide.c (revision 0) > @@ -0,0 +1,129 @@ > +/* > + * This file is part of the LinuxBIOS project. > + * > + * Copyright (C) 2005 Li-Ta Lo > + * Copyright (C) 2006 Ron Minnich > + * Copyright (C) 2007 Corey Osgood > + * > + * 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" > + > +static void ide_init(struct device *dev) > +{ > + struct southbridge_via_vt82c686a_config *conf = (struct southbridge_via_vt82c686a_config *)dev->chip_info; > + unsigned char enables; > + > + if (!conf->enable_native_ide) { > + // Run the IDE controller in 'compatiblity mode - i.e. don't use PCI > + // interrupts. Using PCI ints confuses linux for some reason. > + > + printk_info("%s: enabling compatibility IDE addresses\n", __FUNCTION__); > + enables = pci_read_config8(dev, 0x42); > + printk_debug("enables in reg 0x42 0x%x\n", enables); > + enables &= ~0xc0; // compatability mode > + pci_write_config8(dev, 0x42, enables); > + enables = pci_read_config8(dev, 0x42); > + printk_debug("enables in reg 0x42 read back as 0x%x\n", enables); > + } > + > + enables = pci_read_config8(dev, 0x40); > + printk_debug("enables in reg 0x40 0x%x\n", enables); > + enables |= 3; > + pci_write_config8(dev, 0x40, enables); > + enables = pci_read_config8(dev, 0x40); > + printk_debug("enables in reg 0x40 read back as 0x%x\n", enables); > + > + // Enable prefetch buffers > + enables = pci_read_config8(dev, 0x41); > + enables |= 0xf0; > + pci_write_config8(dev, 0x41, enables); > + > + // Lower thresholds (cause award does it) > + enables = pci_read_config8(dev, 0x43); > + enables &= ~0x0f; > + enables |= 0x05; > + pci_write_config8(dev, 0x43, enables); > + > + // PIO read prefetch counter (cause award does it) > + pci_write_config8(dev, 0x44, 0x18); > + > + // Use memory read multiple > + pci_write_config8(dev, 0x45, 0x1c); > + > + // address decoding. > + // we want "flexible", i.e. 1f0-1f7 etc. or native PCI > + // kevinh at ispiri.com - the standard linux drivers seem ass slow when > + // used in native mode - I've changed back to classic > + enables = pci_read_config8(dev, 0x9); > + printk_debug("enables in reg 0x9 0x%x\n", enables); > + // by the book, set the low-order nibble to 0xa. > + if (conf->enable_native_ide) { > + enables &= ~0xf; > + // cf/cg silicon needs an 'f' here. > + enables |= 0xf; > + } else { > + enables &= ~0x5; > + } > + > + pci_write_config8(dev, 0x9, enables); > + enables = pci_read_config8(dev, 0x9); > + printk_debug("enables in reg 0x9 read back as 0x%x\n", enables); > + > + // standard bios sets master bit. > + enables = pci_read_config8(dev, 0x4); > + printk_debug("command in reg 0x4 0x%x\n", enables); > + enables |= 7; > + > + // No need for stepping - kevinh at ispiri.com > + enables &= ~0x80; > + > + pci_write_config8(dev, 0x4, enables); > + enables = pci_read_config8(dev, 0x4); > + printk_debug("command in reg 0x4 reads back as 0x%x\n", enables); > + > + if (!conf->enable_native_ide) { > + // Use compatability mode - per award bios > + pci_write_config32(dev, 0x10, 0x0); > + pci_write_config32(dev, 0x14, 0x0); > + pci_write_config32(dev, 0x18, 0x0); > + pci_write_config32(dev, 0x1c, 0x0); > + > + // Force interrupts to use compat mode - just like Award bios > + pci_write_config8(dev, 0x3d, 00); > + pci_write_config8(dev, 0x3c, 0xff); > + } > +} > + > +static struct device_operations ide_ops = { > + .read_resources = pci_dev_read_resources, > + .set_resources = pci_dev_set_resources, > + .enable_resources = pci_dev_enable_resources, > + .init = ide_init, > + .enable = 0, > + .ops_pci = 0, > +}; > + > +static struct pci_driver northbridge_driver __pci_driver = { > + .ops = &ide_ops, > + .vendor = PCI_VENDOR_ID_VIA, > + .device = PCI_DEVICE_ID_VIA_82C586_1, > +}; > From uwe at hermann-uwe.de Tue Jan 16 07:18:41 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Tue, 16 Jan 2007 07:18:41 +0100 Subject: [LinuxBIOS] Add support for Via vt82c686a In-Reply-To: <45AC2889.1070307@comcast.net> References: <45AA9938.6020804@verizon.net> <20070114235739.GB20305@greenwood> <45AAE156.5030206@verizon.net> <366f3f5e6a46f27ea5e4a1edfac2d58c@kernel.crashing.org> <20070115175038.GA10359@greenwood> <45ABD34A.1040609@verizon.net> <45AC2889.1070307@comcast.net> Message-ID: <20070116061841.GA28012@greenwood> On Mon, Jan 15, 2007 at 05:21:13PM -0800, Adam Talbot wrote: > Do we need to update the website to reflect the state of the the via > vt82c686a, under the "Supported Chipsets and Devices" No yet, IMHO. We'll do that when the code gets committed. Btw, please don't fully quote such huge patches ;-) Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From svn at openbios.org Tue Jan 16 12:56:36 2007 From: svn at openbios.org (svn at openbios.org) Date: Tue, 16 Jan 2007 11:56:36 -0000 Subject: [LinuxBIOS] r2535 - in trunk/LinuxBIOSv2/src: arch/i386/init cpu/amd/car cpu/x86/car Message-ID: Author: uwe Date: 2007-01-16 12:56:35 +0100 (Tue, 16 Jan 2007) New Revision: 2535 Modified: trunk/LinuxBIOSv2/src/arch/i386/init/crt0.S.lb trunk/LinuxBIOSv2/src/cpu/amd/car/copy_and_run.c trunk/LinuxBIOSv2/src/cpu/amd/car/post_cache_as_ram.c trunk/LinuxBIOSv2/src/cpu/x86/car/copy_and_run.c Log: Change 'ram' to 'RAM' in user-visible output (closes #60). Signed-off-by: Uwe Hermann Acked-by: Stefan Reinauer Modified: trunk/LinuxBIOSv2/src/arch/i386/init/crt0.S.lb =================================================================== --- trunk/LinuxBIOSv2/src/arch/i386/init/crt0.S.lb 2006-12-28 12:00:58 UTC (rev 2534) +++ trunk/LinuxBIOSv2/src/arch/i386/init/crt0.S.lb 2007-01-16 11:56:35 UTC (rev 2535) @@ -215,7 +215,7 @@ #if defined(CONSOLE_DEBUG_TX_STRING) && (ASM_CONSOLE_LOGLEVEL > BIOS_DEBUG) .section ".rom.data" -str_copying_to_ram: .string "Copying LinuxBIOS to ram.\r\n" +str_copying_to_ram: .string "Copying LinuxBIOS to RAM.\r\n" str_pre_main: .string "Jumping to LinuxBIOS.\r\n" .previous Modified: trunk/LinuxBIOSv2/src/cpu/amd/car/copy_and_run.c =================================================================== --- trunk/LinuxBIOSv2/src/cpu/amd/car/copy_and_run.c 2006-12-28 12:00:58 UTC (rev 2534) +++ trunk/LinuxBIOSv2/src/cpu/amd/car/copy_and_run.c 2007-01-16 11:56:35 UTC (rev 2535) @@ -23,7 +23,7 @@ uint8_t *src, *dst; unsigned long ilen, olen; - print_debug("Copying LinuxBIOS to ram.\r\n"); + print_debug("Copying LinuxBIOS to RAM.\r\n"); #if !CONFIG_COMPRESS __asm__ volatile ( Modified: trunk/LinuxBIOSv2/src/cpu/amd/car/post_cache_as_ram.c =================================================================== --- trunk/LinuxBIOSv2/src/cpu/amd/car/post_cache_as_ram.c 2006-12-28 12:00:58 UTC (rev 2534) +++ trunk/LinuxBIOSv2/src/cpu/amd/car/post_cache_as_ram.c 2007-01-16 11:56:35 UTC (rev 2535) @@ -53,7 +53,7 @@ set_init_ram_access(); /* So we can access RAM from [1M, CONFIG_LB_MEM_TOPK) */ // dump_mem(DCACHE_RAM_BASE+DCACHE_RAM_SIZE-0x8000, DCACHE_RAM_BASE+DCACHE_RAM_SIZE-0x7c00); - print_debug("Copying data from cache to ram -- switching to use ram as stack... "); + print_debug("Copying data from cache to RAM -- switching to use RAM as stack... "); /* from here don't store more data in CAR */ #if 0 Modified: trunk/LinuxBIOSv2/src/cpu/x86/car/copy_and_run.c =================================================================== --- trunk/LinuxBIOSv2/src/cpu/x86/car/copy_and_run.c 2006-12-28 12:00:58 UTC (rev 2534) +++ trunk/LinuxBIOSv2/src/cpu/x86/car/copy_and_run.c 2007-01-16 11:56:35 UTC (rev 2535) @@ -15,7 +15,7 @@ unsigned long dst_len; unsigned long ilen, olen; - print_debug("Copying LinuxBIOS to ram.\r\n"); + print_debug("Copying LinuxBIOS to RAM.\r\n"); #if !CONFIG_COMPRESS __asm__ volatile ( From svn at openbios.org Tue Jan 16 13:03:51 2007 From: svn at openbios.org (LinuxBIOS) Date: Tue, 16 Jan 2007 12:03:51 -0000 Subject: [LinuxBIOS] #60: Change 'ram' to 'RAM' in user-visible output In-Reply-To: <060.45dc2426c21ad9b63b9bde7ba6da46fa@openbios.org> References: <060.45dc2426c21ad9b63b9bde7ba6da46fa@openbios.org> Message-ID: <069.670c35f73f2955201197719351e15c47@openbios.org> #60: Change 'ram' to 'RAM' in user-visible output ----------------------------+----------------------------------------------- Reporter: uwe | Owner: uwe Type: enhancement | Status: closed Priority: minor | Milestone: Cosmetic fixes Component: code | Version: v2 Resolution: fixed | Keywords: Dependencies: | Patchstatus: patch has been committed ----------------------------+----------------------------------------------- Changes (by uwe): * patchstatus: patch needs review => patch has been committed -- Ticket URL: LinuxBIOS From ben at hewson-venieri.com Tue Jan 16 19:33:02 2007 From: ben at hewson-venieri.com (Ben Hewson) Date: Tue, 16 Jan 2007 18:33:02 +0000 Subject: [LinuxBIOS] epia, rom_cc and locking code In-Reply-To: <13426df10701150658u4d242f63na4499898cb4527f9@mail.gmail.com> References: <4539F406.1080308@hewson-venieri.com> <20070113115041.GA24453@coresystems.de> <45A92708.20709@hewson-venieri.com> <20070114150728.GB21694@coresystems.de> <45AA56E0.3000103@hewson-venieri.com> <13426df10701150658u4d242f63na4499898cb4527f9@mail.gmail.com> Message-ID: <45AD1A5E.7070909@hewson-venieri.com> ron minnich wrote: > On 1/14/07, Ben Hewson wrote: > > >> there are some posts on the mailing list I made, but basically my older >> version of linuxbios using filo boots, but a later version after the >> rom_cc patch doesn't boot any more. >> >> exactly the same hardware and filo image (v 0.5 ). >> > > can you get us a source-level diff? > > ron > > as I have been putting in some extra debug to see if I could locate the problem, I updated to the latest version. just to check the problem is still there I have tried to build, and it does build ok but it won't load the filo payload. I am guessing this is to do with the new CONFIG_ROM_PAYLOAD_START setting. When I boot I get the following Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3 rom_stream: 0xfffc0000 - 0xfffcffff NO header at 0 NO header at 16 NO header at 32 NO header at 48 : : NO header at 8096 header_offset is -1 Cannot Load ELF Image I assume this is to do with CONFIG_ROM_PAYLOAD_START. Do you have any advice at what I need to set it to ? anyway assuming the problem still exists I have attached the output from diff. As I havent really used diff very much, let me know if you need something more/different. Ben -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff URL: From bxshi at msik.com.cn Wed Jan 17 07:54:08 2007 From: bxshi at msik.com.cn (bxshi at msik.com.cn) Date: Wed, 17 Jan 2007 14:54:08 +0800 Subject: [LinuxBIOS] MSI MS9638 with linuxbios possible?? Message-ID: Hi All , MSI 5000V Master Series(MS-9638) http://www.msi.com.tw/program/products/server/svr/pro_svr_detail.php?UID=633 it is an intel based MB. I wonder if I want to make it with linuxbios support, how much effort should I make? Linuxbios supports ESB6300 now,and I think it is more or less the same as ESB2E.The biggest problem may be the northbridge. Any advice is welcome. Below is some information: CPU: *Dual Dempsey/Woodcrest processor (FSB 667/1066/1333MHz), LGA771 socket *2MB L2 Cache per Core Chipset: *MCH: Intel Blackford-VS *SB: Intel ESB2E, supports SATAII 3Gb/sec, USB2.0. Memory: *Support 4 DDR2 FBDIMMs *2 Way Interleaved DDR2 533/667 registered ECC DIMM *Maximum 16 GB support with DDR2 533/667 Thanks bxshi *****CONFIDENTIAL INFORMATION***** This email is intended only for the use of the person or entity to whom it is addressed and contains information that may be subject to and/or may be restricted from disclosure by contract or applicable law. If you are not the intended recipient of this email, be advised that any disclosure, copy, distribution or use of the contents of this message is strictly prohibited. If you are not the intended recipient of this email, please notify the sender that you have received this in error by replying to this message. Then, please delete it from your system. Thank you. From svn at openbios.org Wed Jan 17 11:57:42 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 17 Jan 2007 10:57:42 -0000 Subject: [LinuxBIOS] r2536 - trunk/LinuxBIOSv2/util/probe_superio Message-ID: Author: stepan Date: 2007-01-17 11:57:42 +0100 (Wed, 17 Jan 2007) New Revision: 2536 Modified: trunk/LinuxBIOSv2/util/probe_superio/Makefile trunk/LinuxBIOSv2/util/probe_superio/probe_superio.c Log: trivial enhancement * add fintek superio support * add license header * add clean target in makefile Signed-off-by: Stefan Reinauer Acked-by: Stefan Reinauer Modified: trunk/LinuxBIOSv2/util/probe_superio/Makefile =================================================================== --- trunk/LinuxBIOSv2/util/probe_superio/Makefile 2007-01-16 11:56:35 UTC (rev 2535) +++ trunk/LinuxBIOSv2/util/probe_superio/Makefile 2007-01-17 10:57:42 UTC (rev 2536) @@ -1,2 +1,6 @@ +CC:=gcc +CFLAGS:=-O2 -Wall probe_superio: probe_superio.c - cc -O2 -o probe_superio probe_superio.c + $(CC) $(CFLAGS) -o $@ $< +clean: + rm probe_superio Modified: trunk/LinuxBIOSv2/util/probe_superio/probe_superio.c =================================================================== --- trunk/LinuxBIOSv2/util/probe_superio/probe_superio.c 2007-01-16 11:56:35 UTC (rev 2535) +++ trunk/LinuxBIOSv2/util/probe_superio/probe_superio.c 2007-01-17 10:57:42 UTC (rev 2536) @@ -1,7 +1,29 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2006 Ronald Minnich + * Copyright (C) 2006 coresystems GmbH + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + #include +#include #include -/* well, they really thought this throught, eh? Family is 8 bits!!!! */ +/* well, they really thought this through, eh? Family is 8 bits!!!! */ char *familyid[] = { [0xf1] = "pc8374 (winbond, was NS)" }; @@ -41,21 +63,97 @@ } void -probe_idregs(unsigned short port){ +dump_fintek(unsigned short port, unsigned int did) +{ + switch(did) { + case 0x0604: + printf ("Fintek F71805\n"); + break; + case 0x4103: + printf ("Fintek F71872\n"); + break; + default: + printf ("Unknown Fintek SuperIO: did=0x%04x\n",did); + return; + } + + printf("Flash write is %s.\n", regval(port, 0x28)&0x80 ? "enabled" : "disabled"); + printf("Flash control is 0x%04x.\n", regval(port, 0x28)); + printf("27=%02x\n", regval(port, 0x27)); + printf("29=%02x\n", regval(port, 0x29)); + printf("2a=%02x\n", regval(port, 0x2a)); + printf("2b=%02x\n", regval(port, 0x2b)); + + /* select UART 1 */ + outb(0x07, port); + outb(0x01, port+1); + printf("UART1 is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); + printf("UART1 base=%02x%02x, irq=%02x, mode=%s\n", + regval(port, 0x60), regval(port, 0x61), regval(port, 0x70)&0x0f, + regval(port, 0xf0)&0x10 ? "RS485":"RS232"); + + /* select UART 2 */ + outb(0x07, port); + outb(0x02, port+1); + printf("UART2 is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); + printf("UART2 base=%02x%02x, irq=%02x, mode=%s\n", + regval(port, 0x60), regval(port, 0x61), regval(port, 0x70)&0x0f, + regval(port, 0xf0)&0x10 ? "RS485":"RS232"); + + /* select Parport */ + outb(0x07, port); + outb(0x03, port+1); + printf("PARPORT is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); + printf("PARPORT base=%02x%02x, irq=%02x\n", + regval(port, 0x60), regval(port, 0x61), regval(port, 0x70)&0x0f); + + /* select hw monitor */ + outb(0x07, port); + outb(0x04, port+1); + printf("HW monitor is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); + printf("HW monitor base=%02x%02x, irq=%02x\n", + regval(port, 0x60), regval(port, 0x61), regval(port, 0x70)&0x0f); + + /* select gpio */ + outb(0x07, port); + outb(0x06, port+1); + printf("GPIO is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); + printf("GPIO 70=%02x, e0=%02x, e1=%02x, e2=%02x, e3=%02x, e4=%02x, e5=%02x\n", + regval(port, 0x70), regval(port, 0xe0), regval(port, 0xe1), regval(port, 0xe2), + regval(port, 0xe3), regval(port, 0xe4), regval(port, 0xe5)); + printf("GPIO e6=%02x, e7=%02x, e8=%02x, e9=%02x, f0=%02x, f1=%02x, f3=%02x, f4=%02x\n", + regval(port, 0xe6), regval(port, 0xe7), regval(port, 0xe8), regval(port, 0xe9), + regval(port, 0xf0), regval(port, 0xf1), regval(port, 0xf3), regval(port, 0xf4)); + printf("GPIO f5=%02x, f6=%02x, f7=%02x, f8=%02x\n", + regval(port, 0xf5), regval(port, 0xf6), regval(port, 0xf7), regval(port, 0xf8)); + + +} + + +void +probe_idregs_simple(unsigned short port){ unsigned char id; - int i; outb(0x20, port); if (inb(port) != 0x20) { - printf("probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", + if (inb(port) == 0xff ) + printf ("No SuperIO chip found at 0x%04x\n", port); + else + printf("probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", port, inb(port), inb(port+1)); return; } id = inb(port+1); - printf("Probe of id returns %02x\n", id); + + printf("SuperIO found at 0x%02x: id = 0x%02x\n", port, id); if (id == 0xff) return; - printf("%s\n", familyid[id]); + if (familyid[id]) + printf("%s\n", familyid[id]); + else + printf("\n"); + switch(id) { case 0xf1: dump_ns8374(port); @@ -66,15 +164,63 @@ } } + void +probe_idregs_fintek(unsigned short port){ + unsigned int vid, did; + + // Enable configuration sequence (Fintek uses this for example) + outb(0x87, port); + outb(0x87, port); + + // + outb(0x20, port); + if (inb(port) != 0x20) { + if (inb(port) == 0xff ) + printf ("No SuperIO chip found at 0x%04x\n", port); + else + printf("probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", + port, inb(port), inb(port+1)); + return; + } + did = inb(port+1); + + outb(0x21, port); + did = did|(inb(port+1)<<8); + + outb(0x23, port); + vid = inb(port+1); + outb(0x24, port); + vid = vid|(inb(port+1)<<8); + + printf("SuperIO found at 0x%02x: vid=0x%04x/did=0x%04x\n", port, vid, did); + + if (vid == 0xff || vid == 0xffff) + return; + + // printf("%s\n", familyid[id]); + switch(vid) { + case 0x3419: + dump_fintek(port, did); + break; + default: + printf("no dump for 0x%04x/0x%04x\n", vid, did); + break; + } + + // disable configuration + outb(0xaa, port); +} + +void probe_superio(unsigned short port) { - probe_idregs(port); + probe_idregs_simple(port); + probe_idregs_fintek(port); } int -main(int argc, char *argv[]){ - unsigned short port; - +main(int argc, char *argv[]) +{ if (iopl(3) < 0) { perror("iopl"); exit(1); @@ -84,4 +230,6 @@ probe_superio(0x2e); /* now try the 4e */ probe_superio(0x4e); + + return 0; } From rminnich at gmail.com Wed Jan 17 15:32:07 2007 From: rminnich at gmail.com (ron minnich) Date: Wed, 17 Jan 2007 07:32:07 -0700 Subject: [LinuxBIOS] MSI MS9638 with linuxbios possible?? In-Reply-To: References: Message-ID: <13426df10701170632jd6776ffi1f1c05862021132e@mail.gmail.com> I think you should get Intel to agree to work with you on this. If they will not agree, however, it may not be a good plan to try to get it working. ron From uwe at hermann-uwe.de Wed Jan 17 21:38:35 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Wed, 17 Jan 2007 21:38:35 +0100 Subject: [LinuxBIOS] r2536 - trunk/LinuxBIOSv2/util/probe_superio Message-ID: <20070117203835.GA2012@greenwood> Hi, On Wed, Jan 17, 2007 at 11:15:31AM +0000, svn at openbios.org wrote: > trivial enhancement > * add license header > * add clean target in makefile These are trivial... > * add fintek superio support ...but this is not IMHO. From looking at the code it's a lot more stuff than just adding some IDs to flashrom or similar. Please post such changes to the list first. > + case 0x0604: > + printf ("Fintek F71805\n"); > + break; > + case 0x4103: > + printf ("Fintek F71872\n"); > + break; Btw, did you get the Fintek chips to properly work? Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From uwe at hermann-uwe.de Wed Jan 17 21:42:34 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Wed, 17 Jan 2007 21:42:34 +0100 Subject: [LinuxBIOS] patch, add support for ST M50FW080 In-Reply-To: <20070110012710.GA22991@coresystems.de> References: <13426df10701091614y506ea96au6c42152156033937@mail.gmail.com> <20070110012710.GA22991@coresystems.de> Message-ID: <20070117204234.GB2012@greenwood> Hi, On Wed, Jan 10, 2007 at 02:27:10AM +0100, Stefan Reinauer wrote: > * ron minnich [070110 01:14]: > > I keep forgetting this procedure. I hope this is ok. > > Add support for ST M50FW080 (1 MBYTE firmware hub). > > Note that it seems to work, but does not program; this is probably due > > to the board we are on, as this part is advertised as FWH compatible. > > Approved-by: Ronald G. Minnich > > Almost: > http://www.linuxbios.org/Development_Guidelines#How_to_contribute Ron, please re-submit with a proper sign-off so we can commit this. Also, you might want to add your explanations above as a code comment so people looking at the code can see it (and don't have to browse the mailing list archive or svn logs). 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 Wed Jan 17 22:10:28 2007 From: rminnich at gmail.com (ron minnich) Date: Wed, 17 Jan 2007 14:10:28 -0700 Subject: [LinuxBIOS] patch, add support for ST M50FW080 In-Reply-To: <20070117204234.GB2012@greenwood> References: <13426df10701091614y506ea96au6c42152156033937@mail.gmail.com> <20070110012710.GA22991@coresystems.de> <20070117204234.GB2012@greenwood> Message-ID: <13426df10701171310i7a800fdauf578a8d6f5fa18af@mail.gmail.com> On 1/17/07, Uwe Hermann wrote: > Hi, > > On Wed, Jan 10, 2007 at 02:27:10AM +0100, Stefan Reinauer wrote: > > * ron minnich [070110 01:14]: > > > I keep forgetting this procedure. I hope this is ok. > > > Add support for ST M50FW080 (1 MBYTE firmware hub). > > > Note that it seems to work, but does not program; this is probably due > > > to the board we are on, as this part is advertised as FWH compatible. > > > Approved-by: Ronald G. Minnich > > > > Almost: > > http://www.linuxbios.org/Development_Guidelines#How_to_contribute > > Ron, please re-submit with a proper sign-off so we can commit this. I'm sorry Uwe, I will get to this, I found other problems with this part that I am stil resolving, and I want to put in a good patch all at once. Thanks ron From kononov195-lbl at yahoo.com Thu Jan 18 00:56:10 2007 From: kononov195-lbl at yahoo.com (Roman Kononov) Date: Wed, 17 Jan 2007 17:56:10 -0600 Subject: [LinuxBIOS] [PATCH] VGA is used before it is initialized Message-ID: <45AEB79A.6040308@yahoo.com> In the original code vga_inited is set, then run_bios() is called, which does printk(), which is allowed using the VGA. The patch puts vga_inited=1 and run_bios() in the right order. Roman ---------------------- Index: src/devices/pci_rom.c =================================================================== --- src/devices/pci_rom.c (revision 2536) +++ src/devices/pci_rom.c (working copy) @@ -69,7 +69,7 @@ #endif #endif -struct rom_header *pci_rom_load(struct device *dev, struct rom_header *rom_header) +struct rom_header *pci_rom_load_and_run(struct device *dev, struct rom_header *rom_header) { struct pci_data * rom_data; unsigned long rom_address; @@ -96,6 +96,7 @@ printk_debug("copying VGA ROM Image from 0x%x to 0x%x, 0x%x bytes\n", rom_header, PCI_VGA_RAM_IMAGE_START, rom_size); memcpy(PCI_VGA_RAM_IMAGE_START, rom_header, rom_size); + run_bios(dev,(unsigned long)PCI_VGA_RAM_IMAGE_START); vga_inited = 1; return (struct rom_header *) (PCI_VGA_RAM_IMAGE_START); #endif @@ -103,6 +104,7 @@ printk_debug("copying non-VGA ROM Image from 0x%x to 0x%x, 0x%x bytes\n", rom_header, pci_ram_image_start, rom_size); memcpy(pci_ram_image_start, rom_header, rom_size); + run_bios(dev,(unsigned long)pci_ram_image_start); pci_ram_image_start += rom_size; return (struct rom_header *) (pci_ram_image_start-rom_size); } Index: src/devices/pci_device.c =================================================================== --- src/devices/pci_device.c (revision 2536) +++ src/devices/pci_device.c (working copy) @@ -634,16 +634,12 @@ void pci_dev_init(struct device *dev) { #if CONFIG_PCI_ROM_RUN == 1 - struct rom_header *rom, *ram; + struct rom_header *rom; rom = pci_rom_probe(dev); if (rom == NULL) return; - ram = pci_rom_load(dev, rom); - if (ram == NULL) - return; - - run_bios(dev, ram); + pci_rom_load_and_run(dev, rom); #endif } Index: src/include/device/pci_rom.h =================================================================== --- src/include/device/pci_rom.h (revision 2536) +++ src/include/device/pci_rom.h (working copy) @@ -34,7 +34,8 @@ }; extern struct rom_header * pci_rom_probe(struct device *dev); -extern struct rom_header *pci_rom_load(struct device *dev, struct rom_header *rom_header); +extern struct rom_header *pci_rom_load_and_run(struct device *dev, struct rom_header *rom_header); +void run_bios(struct device *dev,unsigned long addr); extern void pci_dev_init(struct device *dev); From bingxunshi at gmail.com Thu Jan 18 02:38:04 2007 From: bingxunshi at gmail.com (bxshi) Date: Thu, 18 Jan 2007 09:38:04 +0800 Subject: [LinuxBIOS] r2536 - trunk/LinuxBIOSv2/util/probe_superio Message-ID: >+probe_idregs_fintek(unsigned short port){ >+ unsigned int vid, did; >+ >+ // Enable configuration sequence (Fintek uses this for example) >+ outb(0x87, port); >+ outb(0x87, port); Winbond superios also need to do this way ,so I think change probe_idregs_fintek to another name will be more convient. we need only case 0xxxx for winbond superio. bxshi -------------- next part -------------- An HTML attachment was scrubbed... URL: From svn at openbios.org Thu Jan 18 12:44:20 2007 From: svn at openbios.org (LinuxBIOS) Date: Thu, 18 Jan 2007 11:44:20 -0000 Subject: [LinuxBIOS] #6: Add support for 10 cheap, mainstream motherboards In-Reply-To: <060.4056def32ed57b9135e2feadecdf45dc@openbios.org> References: <060.4056def32ed57b9135e2feadecdf45dc@openbios.org> Message-ID: <069.22155975b58c2f576fd3b106b2927fc6@openbios.org> #6: Add support for 10 cheap, mainstream motherboards ----------------------+----------------------------------------------------- Reporter: uwe | Owner: somebody Type: task | Status: new Priority: major | Milestone: Going mainstream Component: code | Version: v2 Resolution: | Keywords: Dependencies: | ----------------------+----------------------------------------------------- Comment (by anonymous): I'm waiting for it! -- Ticket URL: LinuxBIOS From purpureleaf at gmail.com Thu Jan 18 17:20:17 2007 From: purpureleaf at gmail.com (li pan) Date: Fri, 19 Jan 2007 00:20:17 +0800 Subject: [LinuxBIOS] What to implement "system recovery" features in bios Message-ID: <13a536940701180820v36edf54ayf36d98a95ca92d22@mail.gmail.com> Hi, guys I want to implement system recovery features in bios. The basic idea is: When booting, the user hit some key to enter our program, or else go for the normal boot process. The user can use the bios to back up his os. If the os fails and can't boot, he can fix his os using the backup. And he will be able to use bios to browse his hard disk. Basically like some features found on some HP,IBM's pcs. I have done windows and linux system programming but have never touch BIOS, I think maybe linuxbios can help me. Here is my questions: 1 Can linuxbios do this stuff? I think most likely it is yes:-) 2 This will be installed on some pcs which run linux, windows or other os. So maybe we need the award/ami bios coexist with linuxbios on the same pc. ( We will assemble these pcs, we can choose which type of mainboard to use, so there will be only one type of "old" bios) Is this possible?I mean we want to let award bios to serve normal os, and linuxbios to do the system recovery stuff. Maybe change some part of award bios to let it boot linuxbios once user hit the key. We don't mind if we can simply throw award bios away, but we want to make sure our pcs can run any "normal" os. 3 How much space will all these take? Can we fit them is one bios chip? I don't know how IBM do these, maybe they use another chip to store their system recovery program, this feature can be found on old ibm pcs, but in those days, bios chip was small. 4 Most import, am I on the right track? I am not familiar with low level programming ( not this low), sorry if my idea sounds too crazy. Thanks! From rminnich at gmail.com Thu Jan 18 17:26:53 2007 From: rminnich at gmail.com (ron minnich) Date: Thu, 18 Jan 2007 09:26:53 -0700 Subject: [LinuxBIOS] What to implement "system recovery" features in bios In-Reply-To: <13a536940701180820v36edf54ayf36d98a95ca92d22@mail.gmail.com> References: <13a536940701180820v36edf54ayf36d98a95ca92d22@mail.gmail.com> Message-ID: <13426df10701180826h47a7e82egb5a4dedc5bd26a8e@mail.gmail.com> How big is your BIOS part? Were it me, I would just go for the lazy approach, put Linux in FLASH, and use the Linux suspend/resume/kexec support to implement all this stuff. ron From shaposh at isp.nsc.ru Thu Jan 18 17:33:47 2007 From: shaposh at isp.nsc.ru (Alexander Shaposhnikov) Date: Thu, 18 Jan 2007 22:33:47 +0600 Subject: [LinuxBIOS] Linux Bios for Tyan 5000X/P/V boards Message-ID: <200701182233.48014.shaposh@isp.nsc.ru> Hi, is there any chance we will see support for Tyan 5000X/P/V LGA771 boards? Best Regards, Alexander Shaposhnikov From rminnich at gmail.com Fri Jan 19 08:40:40 2007 From: rminnich at gmail.com (ron minnich) Date: Fri, 19 Jan 2007 00:40:40 -0700 Subject: [LinuxBIOS] Linux Bios for Tyan 5000X/P/V boards In-Reply-To: <200701182233.48014.shaposh@isp.nsc.ru> References: <200701182233.48014.shaposh@isp.nsc.ru> Message-ID: <13426df10701182340l375d5fabiaf4dcee5e2057dd7@mail.gmail.com> On 1/18/07, Alexander Shaposhnikov wrote: > Hi, > is there any chance we will see support for Tyan > 5000X/P/V LGA771 boards? what are those boards? You need to send an lspci and tell us more. ron From shaposh at isp.nsc.ru Fri Jan 19 10:01:26 2007 From: shaposh at isp.nsc.ru (Alexander Shaposhnikov) Date: Fri, 19 Jan 2007 15:01:26 +0600 Subject: [LinuxBIOS] Linux Bios for Tyan 5000X/P/V boards In-Reply-To: <13426df10701182340l375d5fabiaf4dcee5e2057dd7@mail.gmail.com> References: <200701182233.48014.shaposh@isp.nsc.ru> <13426df10701182340l375d5fabiaf4dcee5e2057dd7@mail.gmail.com> Message-ID: <200701191501.26680.shaposh@isp.nsc.ru> Hello ron, 5000-series is a new Intel Xeon DP platform, for the new Core-based Xeons including Quad core Xeon Clovertown. Here is the link: http://www.tyan.com/products/html/xeon.html I have Tyan Tempest i5000XT board with two Clovertowns. Among other things, i would like to have more control over chipset and memory initialization. This can only be done at bootup on these platforms. Best Regards, Alexander Shaposhnikov ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// /sbin/lspci: 00:00.0 Host bridge: Intel Corporation 5000X Chipset Memory Controller Hub (rev 31) 00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 2-3 (rev 31) 00:03.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 3 (rev 31) 00:04.0 PCI bridge: Intel Corporation 5000X Chipset PCI Express x16 Port 4-7 (rev 31) 00:05.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 5 (rev 31) 00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 6 (rev 31) 00:07.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 7 (rev 31) 00:08.0 System peripheral: Intel Corporation 5000 Series Chipset DMA Engine (rev 31) 00:10.0 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev 31) 00:10.1 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev 31) 00:10.2 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev 31) 00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev 31) 00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev 31) 00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev 31) 00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev 31) 00:1b.0 Audio device: Intel Corporation 631xESB/632xESB High Definition Audio Controller (rev 09) 00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 1 (rev 0 9) 00:1d.0 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1 (re v 09) 00:1d.1 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2 (re v 09) 00:1d.2 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #3 (re v 09) 00:1d.3 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #4 (re v 09) 00:1d.7 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller (rev 09) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9) 00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller (rev 09) 00:1f.2 IDE interface: Intel Corporation 631xESB/632xESB/3100 Chipset SATA Storage Controller IDE (rev 09) 00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus Controller (rev 09) 01:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Upstream Port (rev 01) 01:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to PCI-X Bridge (rev 01) 02:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E1 (rev 01) 02:01.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E2 (rev 01) 02:02.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E3 (rev 01) 05:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) ( rev 01) 05:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) ( rev 01) 08:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7300 GT] (rev a1) 0d:04.0 Ethernet controller: VIA Technologies, Inc. VT6105 [Rhine-III] (rev 8b) alex at Clovertown:~> sudo /sbin/lspci 00:00.0 Host bridge: Intel Corporation 5000X Chipset Memory Controller Hub (rev 31) 00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 2-3 (rev 31) 00:03.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 3 (rev 31) 00:04.0 PCI bridge: Intel Corporation 5000X Chipset PCI Express x16 Port 4-7 (rev 31) 00:05.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 5 (rev 31) 00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 6 (rev 31) 00:07.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 7 (rev 31) 00:08.0 System peripheral: Intel Corporation 5000 Series Chipset DMA Engine (rev 31) 00:10.0 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev 31) 00:10.1 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev 31) 00:10.2 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev 31) 00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev 31) 00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev 31) 00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev 31) 00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev 31) 00:1b.0 Audio device: Intel Corporation 631xESB/632xESB High Definition Audio Controller (rev 09) 00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 1 (rev 09) 00:1d.0 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1 (rev 09) 00:1d.1 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2 (rev 09) 00:1d.2 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #3 (rev 09) 00:1d.3 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #4 (rev 09) 00:1d.7 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller (rev 09) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9) 00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller (rev 09) 00:1f.2 IDE interface: Intel Corporation 631xESB/632xESB/3100 Chipset SATA Storage Controller IDE (rev 09) 00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus Controller (rev 09) 01:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Upstream Port (rev 01) 01:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to PCI-X Bridge (rev 01) 02:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E1 (rev 01) 02:01.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E2 (rev 01) 02:02.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E3 (rev 01) 05:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01) 05:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01) 08:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7300 GT] (rev a1) 0d:04.0 Ethernet controller: VIA Technologies, Inc. VT6105 [Rhine-III] (rev 8b) ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// On Friday 19 January 2007 13:40, ron minnich wrote: > On 1/18/07, Alexander Shaposhnikov wrote: > > Hi, > > is there any chance we will see support for Tyan > > 5000X/P/V LGA771 boards? > > what are those boards? You need to send an lspci and tell us more. > ron From yinghai.lu at amd.com Fri Jan 19 18:44:14 2007 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 19 Jan 2007 09:44:14 -0800 Subject: [LinuxBIOS] MCP55 LinuxBIOS with USB debug etc. part 1 Message-ID: <5986589C150B2F49A46483AC44C7BCA49073AD@ssvlexmb2.amd.com> -----Original Message----- From: Lu, Yinghai Sent: Thursday, January 18, 2007 9:06 PM To: 'Ronald G Minnich'; Eric W. Biederman Cc: linuxbios at linuxbios.org Subject: MCP55 LinuxBIOS with USB debug etc. Please check the MCP55 support with usbdebug. MB included: Nvidia l1_2pvv Gigabyte m57sli Supermicro h8dmr Tyan s2912 --- with HTX Signed-off-by: Yinghai Lu -------------- next part -------------- A non-text attachment was scrubbed... Name: fb2_mcp55_full_01172007_1.tar.bz2 Type: application/octet-stream Size: 175115 bytes Desc: fb2_mcp55_full_01172007_1.tar.bz2 URL: From yinghai.lu at amd.com Fri Jan 19 18:44:41 2007 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 19 Jan 2007 09:44:41 -0800 Subject: [LinuxBIOS] MCP55 LinuxBIOS with USB debug etc. -- part 2 Message-ID: <5986589C150B2F49A46483AC44C7BCA49073AE@ssvlexmb2.amd.com> -----Original Message----- From: Lu, Yinghai Sent: Thursday, January 18, 2007 9:06 PM To: 'Ronald G Minnich'; Eric W. Biederman Cc: linuxbios at linuxbios.org Subject: MCP55 LinuxBIOS with USB debug etc. Please check the MCP55 support with usbdebug. MB included: Nvidia l1_2pvv Gigabyte m57sli Supermicro h8dmr Tyan s2912 --- with HTX Signed-off-by: Yinghai Lu -------------- next part -------------- A non-text attachment was scrubbed... Name: fb2_mcp55_full_01172007_2.tar.bz2 Type: application/octet-stream Size: 238341 bytes Desc: fb2_mcp55_full_01172007_2.tar.bz2 URL: From yinghai.lu at amd.com Fri Jan 19 18:45:10 2007 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 19 Jan 2007 09:45:10 -0800 Subject: [LinuxBIOS] MCP55 LinuxBIOS with USB debug etc. -- part 3 Message-ID: <5986589C150B2F49A46483AC44C7BCA49073AF@ssvlexmb2.amd.com> -----Original Message----- From: Lu, Yinghai Sent: Thursday, January 18, 2007 9:06 PM To: 'Ronald G Minnich'; Eric W. Biederman Cc: linuxbios at linuxbios.org Subject: MCP55 LinuxBIOS with USB debug etc. Please check the MCP55 support with usbdebug. MB included: Nvidia l1_2pvv Gigabyte m57sli Supermicro h8dmr Tyan s2912 --- with HTX Signed-off-by: Yinghai Lu -------------- next part -------------- A non-text attachment was scrubbed... Name: fb2_mcp55_full_01172007_3.tar.bz2 Type: application/octet-stream Size: 121200 bytes Desc: fb2_mcp55_full_01172007_3.tar.bz2 URL: From stepan at coresystems.de Fri Jan 19 19:08:10 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 19 Jan 2007 19:08:10 +0100 Subject: [LinuxBIOS] MCP55 LinuxBIOS with USB debug etc. part 1 In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49073AD@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49073AD@ssvlexmb2.amd.com> Message-ID: <20070119180810.GA22038@coresystems.de> * Lu, Yinghai [070119 18:44]: > > > -----Original Message----- > From: Lu, Yinghai > Sent: Thursday, January 18, 2007 9:06 PM > To: 'Ronald G Minnich'; Eric W. Biederman > Cc: linuxbios at linuxbios.org > Subject: MCP55 LinuxBIOS with USB debug etc. > > Please check the MCP55 support with usbdebug. > > MB included: > Nvidia l1_2pvv > Gigabyte m57sli > Supermicro h8dmr > Tyan s2912 --- with HTX > > Signed-off-by: Yinghai Lu Wow! Impressive. Thank you very much for your contribution. Is there any chance you can send this as patches, or just the new files? What's the difference between the archives? -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From yinghai.lu at amd.com Fri Jan 19 19:12:17 2007 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 19 Jan 2007 10:12:17 -0800 Subject: [LinuxBIOS] MCP55 LinuxBIOS with USB debug etc. part 1 Message-ID: <5986589C150B2F49A46483AC44C7BCA49073B0@ssvlexmb2.amd.com> Too much difference. May take several days to produce patch. YH -----Original Message----- From: Stefan Reinauer [mailto:stepan at coresystems.de] Sent: Friday, January 19, 2007 10:08 AM To: Lu, Yinghai Cc: linuxbios at linuxbios.org Subject: Re: [LinuxBIOS] MCP55 LinuxBIOS with USB debug etc. part 1 * Lu, Yinghai [070119 18:44]: > > > -----Original Message----- > From: Lu, Yinghai > Sent: Thursday, January 18, 2007 9:06 PM > To: 'Ronald G Minnich'; Eric W. Biederman > Cc: linuxbios at linuxbios.org > Subject: MCP55 LinuxBIOS with USB debug etc. > > Please check the MCP55 support with usbdebug. > > MB included: > Nvidia l1_2pvv > Gigabyte m57sli > Supermicro h8dmr > Tyan s2912 --- with HTX > > Signed-off-by: Yinghai Lu Wow! Impressive. Thank you very much for your contribution. Is there any chance you can send this as patches, or just the new files? What's the difference between the archives? -- 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 Fri Jan 19 19:28:12 2007 From: a1426z at gawab.com (Al Boldi) Date: Fri, 19 Jan 2007 21:28:12 +0300 Subject: [LinuxBIOS] What to implement "system recovery" features in bios In-Reply-To: <13a536940701180820v36edf54ayf36d98a95ca92d22@mail.gmail.com> References: <13a536940701180820v36edf54ayf36d98a95ca92d22@mail.gmail.com> Message-ID: <200701192128.12537.a1426z@gawab.com> li pan wrote: > Hi, guys > I want to implement system recovery features in bios. > The basic idea is: > When booting, the user hit some key to enter our program, or else go > for the normal boot process. > The user can use the bios to back up his os. If the os fails and can't > boot, he can fix his > os using the backup. And he will be able to use bios to browse his hard > disk. Basically like some features found on some HP,IBM's pcs. > > I have done windows and linux system programming but have never touch > BIOS, I think maybe linuxbios can help me. Here is my questions: > > 1 Can linuxbios do this stuff? I think most likely it is yes:-) Yes. > 2 This will be installed on some pcs which run linux, windows or other > os. So maybe we need the award/ami bios coexist with linuxbios on the > same pc. ( We will assemble these pcs, we can choose which type of > mainboard to use, so there will be only one type of "old" bios) > Is this possible? Yes. > I mean we want to let award bios to serve normal os, > and linuxbios to do the system recovery stuff. Maybe change some part > of award bios to let it boot linuxbios once user hit the key. You basically need a DualBIOS system, that allows you to switch between a main and backup bios. > We don't mind if we can simply throw award bios away, but we want to > make sure our pcs can run any "normal" os. True. > 3 How much space will all these take? Can we fit them is one bios > chip? I don't know how IBM do these, maybe they use another chip to > store their system recovery program, this feature can be found on old > ibm pcs, but in those days, bios chip was small. It depends. I you want to go for the DualBIOS approach, then you need a double size ROM. If you only need a recovery module (i.e. extension ROM) without an additional BIOS, then all you need is FILO (~50kb) plus your UserInterface. > 4 Most import, am I on the right track? I am not familiar with low > level programming ( not this low), sorry if my idea sounds too crazy. It's a great idea. Thanks! -- Al From purpureleaf at gmail.com Sat Jan 20 16:33:12 2007 From: purpureleaf at gmail.com (li pan) Date: Sat, 20 Jan 2007 23:33:12 +0800 Subject: [LinuxBIOS] What to implement "system recovery" features in bios In-Reply-To: <13a536940701200651q6c95340fsd7df8064e6abe9c9@mail.gmail.com> References: <13a536940701200651q6c95340fsd7df8064e6abe9c9@mail.gmail.com> Message-ID: <13a536940701200733r5912d8fbx16878515e7e8071f@mail.gmail.com> Thanks for your suggestions! They are really helpful I still have some more detail questions, --------- 1 Is linuxbios a "real" linux? I mean can a normal linux app run on it? We want the user to use this app to recovery a faild pc, so we need the app in BIOS, not harddisk 2 I am still not sure about the linuxbios/awardbios coexistence stuff. Al mentioned DualBIOS, but as long as I know, that means mainborad holds 2 biso chips, and if one fails, mainboard will use the other. (Correct me if I am wrong, I don't know much about this) But I need the award bios be used in normal case, and if the user hit some key while booting, the computer will switch to linuxbios, which will load the backup/recovery appliaction. I think the IBM app works this way. Thanks for you help! From janek_listy at wp.pl Tue Jan 9 11:30:29 2007 From: janek_listy at wp.pl (Janek Kozicki) Date: Tue, 9 Jan 2007 11:30:29 +0100 Subject: [LinuxBIOS] #36: Make the mailing list archive searchable In-Reply-To: <069.bf138aee7589d292e37df083d194cd67@openbios.org> References: <060.310e1ce9ac350c87801b63e0c3140a12@openbios.org> <069.bf138aee7589d292e37df083d194cd67@openbios.org> Message-ID: <20070109113029.76f3dffc@absurd> LinuxBIOS said: (by the date of Tue, 09 Jan 2007 01:28:30 -0000) WTF with opening post? > #36: Make the mailing list archive searchable I have just two days ago made mailing list of my project hosted on berlios.de searchable using gmane. It turned out to be pretty easy: You need to add LinuxBIOS mailing list to http://gmane.org/ , then send an email to their support with URL to file with full archive of LinuxBIOS list compressed in mbox format. The gmane automatically subscribes to the mailing list, and automatically keeps them two synchronised. And gives you the search capability. In my case the response from gmane support was instant. They got email about mbox archive of my mailing list, and the next day the archive was imported and everything worked. -- Janek Kozicki | From yinghai.lu at amd.com Fri Jan 19 06:05:41 2007 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Thu, 18 Jan 2007 21:05:41 -0800 Subject: [LinuxBIOS] MCP55 LinuxBIOS with USB debug etc. Message-ID: <5986589C150B2F49A46483AC44C7BCA49073AB@ssvlexmb2.amd.com> Please check the MCP55 support with usbdebug. MB included: Nvidia l1_2pvv Gigabyte m57sli Supermicro h8dmr Tyan s2912 --- with HTX Signed-off-by: Yinghai Lu -------------- next part -------------- A non-text attachment was scrubbed... Name: fb2_mcp55_full_01172007.tar.bz2 Type: application/octet-stream Size: 534636 bytes Desc: fb2_mcp55_full_01172007.tar.bz2 URL: From uwe at hermann-uwe.de Sat Jan 20 17:06:16 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 20 Jan 2007 17:06:16 +0100 Subject: [LinuxBIOS] MCP55 LinuxBIOS with USB debug etc. part 1 In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49073B0@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49073B0@ssvlexmb2.amd.com> Message-ID: <20070120160615.GA12416@greenwood> Hi, great work Yinghai! Thanks a lot! Here's the whole blob in patch format (only 'nsf' and 'readme_mcp55.txt' are missing from the patch; I attached them as single files to this mail). Please do _not_ commit this as is. We should split this up in several small, independent patches, then review and test (as far as possible) all of them. The issue tracker will be very useful for this, IHMO we should create an issue for every sub-patch... Also, please note that some of the contents of the patch are old and obsolete (i.e. svn trunk contains newer code, see for example the util/flashrom/* stuff). Most of those parts can be safely ignored (after a careful review of the changes), I guess. 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 -------------- #!/bin/bash MBVENDOR=$1 MBMODEL=$2 LBROOT=/home/yhlu/xx/xx/xx/ echo $MBVENDOR/$MBMODEL date cd "$LBROOT/freebios2/targets" rm -rf "$MBVENDOR/$MBMODEL/$MBMODEL" ./buildtarget "$MBVENDOR/$MBMODEL" &> "$LBROOT/x_b.txt" cd "$MBVENDOR/$MBMODEL/$MBMODEL" #make clean eval make &> "$LBROOT/x_m.txt" if [ $? -eq 0 ]; then echo "ok." else echo "FAILED! Log excerpt:" tail -n 20 "$LBROOT/x_m.txt" exit fi cat ./normal/linuxbios.rom ./fallback/linuxbios.rom ./failover/linuxbios.rom > "$LBROOT/rom/"$MBMODEL"_linuxbios.rom" ls -l "$LBROOT/"$MBMODEL"_linuxbios.rom" date -------------- next part -------------- updates 1. MCP55 support 2. usb2 debug port 3. MB: nvidia l1_2pvv supermicro h8dmr tyan s2912 gigabyte m57sli build: ./nsf nvidia l1_2pvv the LBROOT in nsf need to be changed YH 2007.01.17 -------------- next part -------------- A non-text attachment was scrubbed... Name: monster.patch Type: text/x-diff Size: 601640 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From stiwary20 at yahoo.com Fri Jan 12 07:36:10 2007 From: stiwary20 at yahoo.com (sanjay tiwary) Date: Thu, 11 Jan 2007 22:36:10 -0800 (PST) Subject: [LinuxBIOS] LinuxBIOS not working Message-ID: <318822.14965.qm@web50113.mail.yahoo.com> Hi Ron/All members of the LinuxBIOS group, I am new to the linuxBIOS technology.And wanetd to use the linuxBIOS stuff.But after creating the rom image and burning the chip, i was not able to see anything on either on display or on serial console.Can any one help me getting out of the problem. I am giving all the details so that you people can make out where am missing? Board Details: The contain chips from Via Northbridge: VT 8606(with AGP VGA Controller S3 Savage- twister) South Bridge: VIA VT82C686A BIOS Chip: 1MB ocessor Processor: PentiumIII or Celeron300MHz, 100 MHz Bus One SO-DIMM socket, 512 MByte max. PC100/ PC133 Two enhanced IDE ports SoundBlaster? compatible AC97 I used the configuration available for VIA/EPIA and Image was successfully created.Initially i tried to use the support avialble for VT8601.But i think, iam not getting the northbridge chip intialised. If anyone have the support avialble for VT8606, then let me know. Just help me out so that i can get something on the serial console.After that debugging will become a little bit easier. Thanks & regards Sanjay ____________________________________________________________________________________ Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkotyk at psyndicate.net Fri Jan 19 18:24:45 2007 From: mkotyk at psyndicate.net (Mark Kotyk) Date: Fri, 19 Jan 2007 12:24:45 -0500 Subject: [LinuxBIOS] Bios flashing Message-ID: <45B0FEDD.3040208@psyndicate.net> Here's a couple links I found to be really cool. They propose using cheap and common flash socketed network cards as flash memory programmers. This could be had for a lot cheaper/easier than a BIOS Savior. I feel these links should be added to the Wiki. http://ctflasher.sourceforge.net/ - Linux based software project to flash various types of flash memory using a variety of network cards. http://sandeen.net/fwfix/index.html - The original link I found that proposed the idea, and successfully applied it to update a USB hard drive firmware. I'm planning to do a Car PC project using LinuxBIOS on a EPIA-MII motherboard. I was able to find a cheap 3Com PLCC flash socketed network card at my local computer surplus store this morning. Now I just need to order a few spare memory chips from digikey ($1.79 each), and a PLCC chip extractor for good measure, and I'm ready to rock'n'roll. Cheers From yinghailu at gmail.com Sun Jan 21 04:08:58 2007 From: yinghailu at gmail.com (yhlu) Date: Sat, 20 Jan 2007 19:08:58 -0800 Subject: [LinuxBIOS] MCP55 LinuxBIOS with USB debug etc. part 1 In-Reply-To: <20070120160615.GA12416@greenwood> References: <5986589C150B2F49A46483AC44C7BCA49073B0@ssvlexmb2.amd.com> <20070120160615.GA12416@greenwood> Message-ID: <2ea3fae10701201908v6a78445bx583e658d5221e065@mail.gmail.com> Thanks. Please don't forget On 1/20/07, Uwe Hermann wrote: > Hi, > > great work Yinghai! Thanks a lot! > > Here's the whole blob in patch format (only 'nsf' and > 'readme_mcp55.txt' are missing from the patch; I attached them as single > files to this mail). > > Please do _not_ commit this as is. We should split this up in several > small, independent patches, then review and test (as far as > possible) all of them. The issue tracker will be very useful for this, > IHMO we should create an issue for every sub-patch... > > Also, please note that some of the contents of the patch are old and > obsolete (i.e. svn trunk contains newer code, see for example the > util/flashrom/* stuff). Most of those parts can be safely ignored > (after a careful review of the changes), I guess. > > > HTH, Uwe. > -- > http://www.hermann-uwe.de | http://www.holsham-traders.de > http://www.crazy-hacks.org | http://www.unmaintained-free-software.org > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFFsj33XdVoV3jWIbQRAj6zAJsGxtnusq90B3PICZTHencTqSzskQCghaEh > VlrhTHz62f/ktktm9Y+WJak= > =g+2u > -----END PGP SIGNATURE----- > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > > > From yinghailu at gmail.com Sun Jan 21 04:09:55 2007 From: yinghailu at gmail.com (yhlu) Date: Sat, 20 Jan 2007 19:09:55 -0800 Subject: [LinuxBIOS] MCP55 LinuxBIOS with USB debug etc. part 1 In-Reply-To: <2ea3fae10701201908v6a78445bx583e658d5221e065@mail.gmail.com> References: <5986589C150B2F49A46483AC44C7BCA49073B0@ssvlexmb2.amd.com> <20070120160615.GA12416@greenwood> <2ea3fae10701201908v6a78445bx583e658d5221e065@mail.gmail.com> Message-ID: <2ea3fae10701201909u679a7922o597fbe5e19e14913@mail.gmail.com> Please don't forget mcp55 support in util/flashrom. YH On 1/20/07, yhlu wrote: > Thanks. > > Please don't forget > > On 1/20/07, Uwe Hermann wrote: > > Hi, > > > > great work Yinghai! Thanks a lot! > > > > Here's the whole blob in patch format (only 'nsf' and > > 'readme_mcp55.txt' are missing from the patch; I attached them as single > > files to this mail). > > > > Please do _not_ commit this as is. We should split this up in several > > small, independent patches, then review and test (as far as > > possible) all of them. The issue tracker will be very useful for this, > > IHMO we should create an issue for every sub-patch... > > > > Also, please note that some of the contents of the patch are old and > > obsolete (i.e. svn trunk contains newer code, see for example the > > util/flashrom/* stuff). Most of those parts can be safely ignored > > (after a careful review of the changes), I guess. > > > > > > HTH, Uwe. > > -- > > http://www.hermann-uwe.de | http://www.holsham-traders.de > > http://www.crazy-hacks.org | http://www.unmaintained-free-software.org > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.6 (GNU/Linux) > > > > iD8DBQFFsj33XdVoV3jWIbQRAj6zAJsGxtnusq90B3PICZTHencTqSzskQCghaEh > > VlrhTHz62f/ktktm9Y+WJak= > > =g+2u > > -----END PGP SIGNATURE----- > > > > > > -- > > linuxbios mailing list > > linuxbios at linuxbios.org > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > > > > From uwe at hermann-uwe.de Sun Jan 21 14:10:41 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 21 Jan 2007 14:10:41 +0100 Subject: [LinuxBIOS] [PATCH] flashrom: Support for MCP55 and SST49LFXXXC chips Message-ID: <20070121131041.GA15033@greenwood> Add support for the SST-49LF004C, SST-49LF008C, SST-49LF016C in flashrom. Also add suport for NVIDIA MCP55. Signed-off-by: Yinghai Lu Signed-off-by: Uwe Hermann --- I tried to extract only the relevant changes out of Yinghai's code. Please review (especially check whether I forgot some code) and test whether it works. 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: flashrom_mcp55_sst49lfxxxc.patch Type: text/x-diff Size: 11427 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From stuge-linuxbios at cdy.org Sun Jan 21 18:49:01 2007 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Sun, 21 Jan 2007 18:49:01 +0100 Subject: [LinuxBIOS] [PATCH] flashrom: Support for MCP55 and SST49LFXXXC chips In-Reply-To: <20070121131041.GA15033@greenwood> References: <20070121131041.GA15033@greenwood> Message-ID: <20070121174902.19968.qmail@cdy.org> Add support for the SST-49LF004C, SST-49LF008C, SST-49LF016C in flashrom. Also add suport for NVIDIA MCP55. Signed-off-by: Yinghai Lu Signed-off-by: Uwe Hermann Acked-by: Peter Stuge -------------- next part -------------- Index: util/flashrom/flash.h =================================================================== --- util/flashrom/flash.h (Revision 2536) +++ util/flashrom/flash.h (Arbeitskopie) @@ -56,6 +56,9 @@ #define SST_49LF003A 0x1B /* SST 49LF003A device */ #define SST_49LF004A 0x60 /* SST 49LF004A device */ #define SST_49LF008A 0x5A /* SST 49LF008A device */ +#define SST_49LF004C 0x54 /* SST 49LF004C device */ +#define SST_49LF008C 0x59 /* SST 49LF008C device */ +#define SST_49LF016C 0x5C /* SST 49LF016C device */ #define PMC_ID 0x9D /* PMC Manufacturer ID code */ #define PMC_49FL002 0x6D /* PMC 49FL002 device code */ Index: util/flashrom/flash_enable.c =================================================================== --- util/flashrom/flash_enable.c (Revision 2536) +++ util/flashrom/flash_enable.c (Arbeitskopie) @@ -391,6 +391,46 @@ return 0; } +//By yhlu +static int enable_flash_mcp55(struct pci_dev *dev, char *name) +{ + /* register 4e.b gets or'ed with one */ + unsigned char old, new, byte; + unsigned short word; + + /* if it fails, it fails. There are so many variations of broken mobos + * that it is hard to argue that we should quit at this point. + */ + + //dump_pci_device(dev); + + /* Set the 4MB enable bit bit */ + byte = pci_read_byte(dev, 0x88); + byte |= 0xff; //256K + pci_write_byte(dev, 0x88, byte); + byte = pci_read_byte(dev, 0x8c); + byte |= 0xff; //1M + pci_write_byte(dev, 0x8c, byte); + word = pci_read_word(dev, 0x90); + word |= 0x7fff; //15M + pci_write_word(dev, 0x90, word); + + old = pci_read_byte(dev, 0x6d); + new = old | 0x01; + if (new == old) + return 0; + pci_write_byte(dev, 0x6d, new); + + if (pci_read_byte(dev, 0x6d) != new) { + printf("tried to set 0x%x to 0x%x on %s failed (WARNING ONLY)\n", + 0x6d, new, name); + return -1; + } + + return 0; + +} + typedef struct penable { unsigned short vendor, device; char *name; @@ -432,9 +472,13 @@ {0x10de, 0x0260, "NVidia MCP51", enable_flash_ck804}, {0x10de, 0x0261, "NVidia MCP51", enable_flash_ck804}, + // {0x10de, 0x0261, "NVIDIA C51", enable_flash_ck804}, // YHLU {0x10de, 0x0262, "NVidia MCP51", enable_flash_ck804}, {0x10de, 0x0263, "NVidia MCP51", enable_flash_ck804}, + {0x10de, 0x0364, "NVIDIA MCP55", enable_flash_mcp55}, // LPC + {0x10de, 0x0367, "NVIDIA MCP55", enable_flash_mcp55}, // Pro + {0x1002, 0x4377, "ATI SB400", enable_flash_sb400}, // ATI Technologies Inc IXP SB400 PCI-ISA Bridge (rev 80) }; Index: util/flashrom/sst49lfxxxc.c =================================================================== --- util/flashrom/sst49lfxxxc.c (Revision 0) +++ util/flashrom/sst49lfxxxc.c (Revision 0) @@ -0,0 +1,204 @@ +/* + * 49lfxxxc.c: driver for SST49LFXXXC flash models. + * + * + * Copyright 2000 Silicon Integrated System Corporation + * Copyright 2005 coresystems GmbH + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * 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., 675 Mass Ave, Cambridge, MA 02139, USA. + * + * + * Reference: + * SST49LFxxxC data sheets + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include "flash.h" +#include "jedec.h" +#include "debug.h" + +#define SECTOR_ERASE 0x30 +#define BLOCK_ERASE 0x20 +#define ERASE 0xD0 +#define AUTO_PGRM 0x10 +#define RESET 0xFF +#define READ_ID 0x90 +#define READ_STATUS 0x70 +#define CLEAR_STATUS 0x50 + +#define STATUS_BPS (1 << 1) +#define STATUS_ESS (1 << 6) +#define STATUS_WSMS (1 << 7) + + +static __inline__ int write_lockbits_49lfxxxc(volatile uint8_t *bios, int size, + unsigned char bits) +{ + int i, left = size; + unsigned long address; + + //printf("bios=0x%08lx\n", (unsigned long)bios); + for (i = 0; left > 65536; i++, left -= 65536) { + //printf("lockbits at address=0x%08lx is 0x%01x\n", (unsigned long)0xFFC00000 - size + (i * 65536) + 2, *(bios + (i * 65536) + 2) ); + *(bios + (i * 65536) + 2) = bits; + } + address = i * 65536; + //printf("lockbits at address=0x%08lx is 0x%01x\n", (unsigned long)0xFFc00000 - size + address + 2, *(bios + address + 2) ); + *(bios + address + 2) = bits; + address += 32768; + //printf("lockbits at address=0x%08lx is 0x%01x\n", (unsigned long)0xFFc00000 - size + address + 2, *(bios + address + 2) ); + *(bios + address + 2) = bits; + address += 8192; + //printf("lockbits at address=0x%08lx is 0x%01x\n", (unsigned long)0xFFc00000 - size + address + 2, *(bios + address + 2) ); + *(bios + address + 2) = bits; + address += 8192; + //printf("lockbits at address=0x%08lx is 0x%01x\n", (unsigned long)0xFFc00000 - size + address + 2, *(bios + address + 2) ); + *(bios + address + 2) = bits; + + + return (0); +} + +static __inline__ int erase_sector_49lfxxxc(volatile uint8_t *bios, + unsigned long address) +{ + unsigned char status; + + *bios = SECTOR_ERASE; + *(bios + address) = ERASE; + + do { + status = *bios; + if (status & (STATUS_ESS | STATUS_BPS)) { + printf("sector erase FAILED at address=0x%08lx status=0x%01x\n", (unsigned long)bios + address, status); + *bios = CLEAR_STATUS; + return(-1); + } + } while (!(status & STATUS_WSMS)); + + return (0); +} + +static __inline__ int write_sector_49lfxxxc(volatile uint8_t *bios, + uint8_t *src, + volatile uint8_t *dst, + unsigned int page_size) +{ + int i; + unsigned char status; + + *bios = CLEAR_STATUS; + for (i = 0; i < page_size; i++) { + /* transfer data from source to destination */ + if (*src == 0xFF) { + dst++, src++; + /* If the data is 0xFF, don't program it */ + continue; + } + /*issue AUTO PROGRAM command */ + *bios = AUTO_PGRM; + *dst++ = *src++; + + do { + status = *bios; + if (status & (STATUS_ESS | STATUS_BPS)) { + printf("sector write FAILED at address=0x%08lx status=0x%01x\n", (unsigned long)dst, status); + *bios = CLEAR_STATUS; + return(-1); + } + } while (!(status & STATUS_WSMS)); + } + + return (0); +} + +int probe_49lfxxxc(struct flashchip *flash) +{ + volatile uint8_t *bios = flash->virt_addr; + uint8_t id1, id2; + size_t size = flash->total_size * 1024; + + *bios = RESET; + + *bios = READ_ID; + id1 = *(volatile uint8_t *) bios; + id2 = *(volatile uint8_t *) (bios + 0x01); + + *bios = RESET; + + printf_debug("%s: id1 0x%x, id2 0x%x\n", __FUNCTION__, id1, id2); + if (!(id1 == flash->manufacture_id && id2 == flash->model_id)) + return 0; + + bios = mmap(0, size, PROT_WRITE | PROT_READ, MAP_SHARED, + flash->fd_mem, (off_t) (0xFFFFFFFF - 0x400000 - size + 1)); + if (bios == MAP_FAILED) { + // it's this part but we can't map it ... + perror("Error MMAP /dev/mem"); + exit(1); + } + flash->virt_addr_2 = bios; + return 1; +} + +int erase_49lfxxxc(struct flashchip *flash) +{ + volatile uint8_t *bios = flash->virt_addr; + volatile uint8_t *bios2 = flash->virt_addr_2; + int i; + unsigned int total_size = flash->total_size * 1024; + + write_lockbits_49lfxxxc(bios2, total_size, 0); + for (i = 0; i < total_size; i += flash->page_size) + if (erase_sector_49lfxxxc(bios, i) != 0 ) + return (-1); + + *bios = RESET; + return (0); +} + +int write_49lfxxxc(struct flashchip *flash, uint8_t *buf) +{ + int i; + int total_size = flash->total_size * 1024, page_size = + flash->page_size; + volatile uint8_t *bios = flash->virt_addr; + + + write_lockbits_49lfxxxc(flash->virt_addr_2, total_size, 0); + printf("Programming Page: "); + for (i = 0; i < total_size / page_size; i++) { + /* erase the page before programming */ + erase_sector_49lfxxxc(bios, i * page_size); + + /* write to the sector */ + printf("%04d at address: 0x%08x", i, i * page_size); + write_sector_49lfxxxc(bios, buf + i * page_size, + bios + i * page_size, page_size); + printf("\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b"); + } + printf("\n"); + + *bios = RESET; + return (0); +} Index: util/flashrom/flashchips.c =================================================================== --- util/flashrom/flashchips.c (Revision 2536) +++ util/flashrom/flashchips.c (Arbeitskopie) @@ -31,6 +31,7 @@ #endif #include "am29f040b.h" #include "sst28sf040.h" +#include "sst49lfxxxc.h" #include "w49f002u.h" #include "sst39sf020.h" #include "sst49lf040.h" @@ -82,6 +83,12 @@ probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub, NULL}, {"Pm49FL002", PMC_ID, PMC_49FL002, NULL, 256, 16 * 1024, probe_jedec, erase_chip_jedec, write_49fl004,NULL}, + {"SST49LF004C", SST_ID, SST_49LF004C, NULL, 512, 4 * 1024, + probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc,NULL}, + {"SST49LF008C", SST_ID, SST_49LF008C, NULL, 1024, 4 * 1024 , + probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc, NULL}, + {"SST49LF016C", SST_ID, SST_49LF016C, NULL, 2048, 4 * 1024 , + probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc, NULL}, {"Pm49FL004", PMC_ID, PMC_49FL004, NULL, 512, 64 * 1024, probe_jedec, erase_chip_jedec, write_49fl004,NULL}, {"W29C011", WINBOND_ID, W_29C011, NULL, 128, 128, Index: util/flashrom/sst49lfxxxc.h =================================================================== --- util/flashrom/sst49lfxxxc.h (Revision 0) +++ util/flashrom/sst49lfxxxc.h (Revision 0) @@ -0,0 +1,8 @@ +#ifndef __SST49LFXXXC_H__ +#define __SST49LFXXXC_H__ + +extern int probe_49lfxxxc(struct flashchip *flash); +extern int erase_49lfxxxc(struct flashchip *flash); +extern int write_49lfxxxc(struct flashchip *flash, uint8_t *buf); + +#endif /* !__SST49LFXXXC_H__ */ Index: util/flashrom/Makefile =================================================================== --- util/flashrom/Makefile (Revision 2536) +++ util/flashrom/Makefile (Arbeitskopie) @@ -17,7 +17,8 @@ OBJS = flash_enable.o udelay.o jedec.o sst28sf040.o am29f040b.o mx29f002.o \ sst39sf020.o m29f400bt.o w49f002u.o 82802ab.o msys_doc.o pm49fl004.o \ - sst49lf040.o sst_fwhub.o layout.o lbtable.o flashchips.o flash_rom.o sharplhf00l04.o + sst49lf040.o sst49lfxxxc.o sst_fwhub.o layout.o lbtable.o \ + flashchips.o flash_rom.o sharplhf00l04.o all: pciutils dep $(PROGRAM) Index: util/flashrom/README =================================================================== --- util/flashrom/README (Revision 2536) +++ util/flashrom/README (Arbeitskopie) @@ -114,6 +114,9 @@ SST SST-49LF003A/B SST SST-49LF004A/B SST SST-49LF008A +SST SST-49LF004C +SST SST-49LF008C +SST SST-49LF016C ST ST-M29F400BT ST ST-M29F040B SyncMOS S29C51001T/B @@ -140,6 +143,7 @@ Intel PIIX4/PIIX4E/PIIX4M NVIDIA CK804 NVIDIA MCP51 +NVIDIA MCP55 SiS 630 SiS 5595 VIA VT8231 From geekypenguin at gmail.com Sun Jan 21 20:29:06 2007 From: geekypenguin at gmail.com (Jory A. Pratt) Date: Sun, 21 Jan 2007 13:29:06 -0600 Subject: [LinuxBIOS] Possible type Message-ID: <45B3BF02.9000102@gmail.com> {0x1002, 0x4377, "ATI SB400", enable_flash_sb400}, // ATI Technologies Inc IXP SB400 PCI-ISA Bridge (rev 80) After doing some review trying to get more info so I can work to implement ATI chipset support I believe there is a typo in the code. as shown above. after doing much research I find the smbus is always at 0x1002, 0x4372 while the code is looking at 0x4377 could someone please explain this. Thanks -Jory From geekypenguin at gmail.com Sun Jan 21 21:18:20 2007 From: geekypenguin at gmail.com (Jory A. Pratt) Date: Sun, 21 Jan 2007 14:18:20 -0600 Subject: [LinuxBIOS] ati support Message-ID: <45B3CA8C.7030707@gmail.com> I am gonna undertake the task of writting support for the ati chipset :) If anyone else is interested in helping please contact me directly. To give everyone all the info i have, I have none I will be working from lspci output which included. 00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bridge Subsystem: Hewlett-Packard Company Unknown device 3085 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- Reset- FastB2B- Capabilities: [44] HyperTransport: MSI Mapping Capabilities: [b0] Subsystem: Hewlett-Packard Company Unknown device 3085 00:04.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express Root Port (Slot-) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag+ Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 247 Link: Latency L0s <64ns, L1 <1us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x16 Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Address: fee0100c Data: 4149 Capabilities: [b0] Subsystem: ATI Technologies Inc Unknown device 5950 Capabilities: [b8] HyperTransport: MSI Mapping Capabilities: [100] Advanced Error Reporting 00:13.0 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller (prog-if 10 [OHCI]) Subsystem: ATI Technologies Inc IXP SB400 USB Host Controller 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- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- 00:14.5 Multimedia audio controller: ATI Technologies Inc IXP SB400 AC'97 Audio Controller (rev 01) Subsystem: Hewlett-Packard Company Unknown device 3085 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset+ 16bInt+ PostWrite+ 16-bit legacy interface ports at 0001 03:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: Hewlett-Packard Company Unknown device 3085 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- References: <45B3BF02.9000102@gmail.com> Message-ID: <61ED60EF-1EEC-42FA-891D-9E7EEEFD2AC6@kernel.crashing.org> > {0x1002, 0x4377, "ATI SB400", enable_flash_sb400}, // ATI > Technologies Inc IXP SB400 PCI-ISA Bridge (rev 80) > > After doing some review trying to get more info so I can work to > implement ATI chipset support I believe there is a typo in the > code. as > shown above. > > after doing much research I find the smbus is always at 0x1002, 0x4372 > while the code is looking at 0x4377 could someone please explain this. 1002:4377 is the ISA bridge, as the code comment indeed states. What is confusing you? Segher From stepan at coresystems.de Sun Jan 21 22:48:50 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 21 Jan 2007 22:48:50 +0100 Subject: [LinuxBIOS] Possible type In-Reply-To: <45B3BF02.9000102@gmail.com> References: <45B3BF02.9000102@gmail.com> Message-ID: <20070121214850.GA31947@coresystems.de> * Jory A. Pratt [070121 20:29]: > {0x1002, 0x4377, "ATI SB400", enable_flash_sb400}, // ATI > Technologies Inc IXP SB400 PCI-ISA Bridge (rev 80) > > After doing some review trying to get more info so I can work to > implement ATI chipset support I believe there is a typo in the code. as > shown above. > > after doing much research I find the smbus is always at 0x1002, 0x4372 > while the code is looking at 0x4377 could someone please explain this. Yes. Enabling flash writes requires touching the ISA bridge. You dont need the smbus for that task. What made you assume so? -- 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 corey_osgood at verizon.net Mon Jan 22 07:52:37 2007 From: corey_osgood at verizon.net (Corey Osgood) Date: Mon, 22 Jan 2007 01:52:37 -0500 Subject: [LinuxBIOS] ati support In-Reply-To: <45B3CA8C.7030707@gmail.com> References: <45B3CA8C.7030707@gmail.com> Message-ID: <45B45F35.5050709@verizon.net> Jory A. Pratt wrote: > I am gonna undertake the task of writting support for the ati chipset :) > Good luck! > I have emailed hp about getting the specs they use for writting there > bios, If I hear anything back from them I will be more then happy to > share it .. HP can't help you, at least not as far as the chipset goes. The motherboards in HP's laptops (I assume you have a laptop, seeing as there's a cardbus controller and wifi) are made by an outside company, can't remember the name right at the moment, but it's irrelevant, because they can't help you either. They had to sign an NDA (non-disclosure agreement, if you don't know) with ATI (now AMD) to access the docs that you/we need for this, and you will probably have to do the same, or else screw the docs and try to make something work from lspci -xxx. Oh, and if you do get the docs, you'd have to get their approval before releasing ANYTHING to the public, or else your ass could end up in jail. The final caveat in laptops is the microcontroller, which controls power management, among other things. You probably won't be able to get the docs on that, and I have no idea what you'd have to do to make it work (tbh, I don't even know how you'd find out the make/model on it, aside from ripping apart the laptop). Not to try and put you off or anything, just want you to know what you're getting into. I'd love to see this happen, especially if you could get the microcontroller working, because it's probably the same as mine ;) -Corey From eswierk at arastra.com Mon Jan 22 19:38:37 2007 From: eswierk at arastra.com (Ed Swierk) Date: Mon, 22 Jan 2007 10:38:37 -0800 Subject: [LinuxBIOS] MCP55 LinuxBIOS with USB debug etc. part 1 In-Reply-To: <20070120160615.GA12416@greenwood> References: <5986589C150B2F49A46483AC44C7BCA49073B0@ssvlexmb2.amd.com> <20070120160615.GA12416@greenwood> Message-ID: On 1/20/07, Uwe Hermann wrote: > great work Yinghai! Thanks a lot! Yes, it's great to see some code finally getting released. My own code is still stuck somewhere in nVidia legal limbo, but it's mainly a subset of Yinghai's except for the particular mainboard (DFI LANParty) support. > Please do _not_ commit this as is. We should split this up in several > small, independent patches, then review and test (as far as > possible) all of them. The issue tracker will be very useful for this, > IHMO we should create an issue for every sub-patch... Also there's a lot of overlap between the new code and the existing code in src/southbridge/nvidia/ck804. In some cases the only differences are a few constants. It would be unfortunate if every time nVidia releases a new chipset (MCP65 is just around the corner!) we ended up with another copy of almost the same code. This issue is probably not important enough to block committing the code if it's otherwise okay. Maybe the best thing would be just to open a tracker issue for this, i.e. merging mcp55 and ck804 code into a more generic "nforce" southbridge. I can spend some time on this but can't promise to do it all myself. --Ed From svn at openbios.org Mon Jan 22 21:21:18 2007 From: svn at openbios.org (svn at openbios.org) Date: Mon, 22 Jan 2007 20:21:18 -0000 Subject: [LinuxBIOS] r2537 - trunk/LinuxBIOSv2/util/flashrom Message-ID: Author: uwe Date: 2007-01-22 21:21:17 +0100 (Mon, 22 Jan 2007) New Revision: 2537 Added: trunk/LinuxBIOSv2/util/flashrom/sst49lfxxxc.c trunk/LinuxBIOSv2/util/flashrom/sst49lfxxxc.h Modified: trunk/LinuxBIOSv2/util/flashrom/Makefile trunk/LinuxBIOSv2/util/flashrom/README trunk/LinuxBIOSv2/util/flashrom/flash.h trunk/LinuxBIOSv2/util/flashrom/flash_enable.c trunk/LinuxBIOSv2/util/flashrom/flashchips.c Log: Add support for the SST-49LF004C, SST-49LF008C, SST-49LF016C in flashrom. Also add suport for NVIDIA MCP55. Signed-off-by: Yinghai Lu Signed-off-by: Uwe Hermann Acked-by: Peter Stuge Modified: trunk/LinuxBIOSv2/util/flashrom/Makefile =================================================================== --- trunk/LinuxBIOSv2/util/flashrom/Makefile 2007-01-17 10:57:42 UTC (rev 2536) +++ trunk/LinuxBIOSv2/util/flashrom/Makefile 2007-01-22 20:21:17 UTC (rev 2537) @@ -17,7 +17,8 @@ OBJS = flash_enable.o udelay.o jedec.o sst28sf040.o am29f040b.o mx29f002.o \ sst39sf020.o m29f400bt.o w49f002u.o 82802ab.o msys_doc.o pm49fl004.o \ - sst49lf040.o sst_fwhub.o layout.o lbtable.o flashchips.o flash_rom.o sharplhf00l04.o + sst49lf040.o sst49lfxxxc.o sst_fwhub.o layout.o lbtable.o \ + flashchips.o flash_rom.o sharplhf00l04.o all: pciutils dep $(PROGRAM) Modified: trunk/LinuxBIOSv2/util/flashrom/README =================================================================== --- trunk/LinuxBIOSv2/util/flashrom/README 2007-01-17 10:57:42 UTC (rev 2536) +++ trunk/LinuxBIOSv2/util/flashrom/README 2007-01-22 20:21:17 UTC (rev 2537) @@ -114,6 +114,9 @@ SST SST-49LF003A/B SST SST-49LF004A/B SST SST-49LF008A +SST SST-49LF004C +SST SST-49LF008C +SST SST-49LF016C ST ST-M29F400BT ST ST-M29F040B SyncMOS S29C51001T/B @@ -140,6 +143,7 @@ Intel PIIX4/PIIX4E/PIIX4M NVIDIA CK804 NVIDIA MCP51 +NVIDIA MCP55 SiS 630 SiS 5595 VIA VT8231 Modified: trunk/LinuxBIOSv2/util/flashrom/flash.h =================================================================== --- trunk/LinuxBIOSv2/util/flashrom/flash.h 2007-01-17 10:57:42 UTC (rev 2536) +++ trunk/LinuxBIOSv2/util/flashrom/flash.h 2007-01-22 20:21:17 UTC (rev 2537) @@ -56,6 +56,9 @@ #define SST_49LF003A 0x1B /* SST 49LF003A device */ #define SST_49LF004A 0x60 /* SST 49LF004A device */ #define SST_49LF008A 0x5A /* SST 49LF008A device */ +#define SST_49LF004C 0x54 /* SST 49LF004C device */ +#define SST_49LF008C 0x59 /* SST 49LF008C device */ +#define SST_49LF016C 0x5C /* SST 49LF016C device */ #define PMC_ID 0x9D /* PMC Manufacturer ID code */ #define PMC_49FL002 0x6D /* PMC 49FL002 device code */ Modified: trunk/LinuxBIOSv2/util/flashrom/flash_enable.c =================================================================== --- trunk/LinuxBIOSv2/util/flashrom/flash_enable.c 2007-01-17 10:57:42 UTC (rev 2536) +++ trunk/LinuxBIOSv2/util/flashrom/flash_enable.c 2007-01-22 20:21:17 UTC (rev 2537) @@ -391,6 +391,46 @@ return 0; } +//By yhlu +static int enable_flash_mcp55(struct pci_dev *dev, char *name) +{ + /* register 4e.b gets or'ed with one */ + unsigned char old, new, byte; + unsigned short word; + + /* if it fails, it fails. There are so many variations of broken mobos + * that it is hard to argue that we should quit at this point. + */ + + //dump_pci_device(dev); + + /* Set the 4MB enable bit bit */ + byte = pci_read_byte(dev, 0x88); + byte |= 0xff; //256K + pci_write_byte(dev, 0x88, byte); + byte = pci_read_byte(dev, 0x8c); + byte |= 0xff; //1M + pci_write_byte(dev, 0x8c, byte); + word = pci_read_word(dev, 0x90); + word |= 0x7fff; //15M + pci_write_word(dev, 0x90, word); + + old = pci_read_byte(dev, 0x6d); + new = old | 0x01; + if (new == old) + return 0; + pci_write_byte(dev, 0x6d, new); + + if (pci_read_byte(dev, 0x6d) != new) { + printf("tried to set 0x%x to 0x%x on %s failed (WARNING ONLY)\n", + 0x6d, new, name); + return -1; + } + + return 0; + +} + typedef struct penable { unsigned short vendor, device; char *name; @@ -432,9 +472,13 @@ {0x10de, 0x0260, "NVidia MCP51", enable_flash_ck804}, {0x10de, 0x0261, "NVidia MCP51", enable_flash_ck804}, + // {0x10de, 0x0261, "NVIDIA C51", enable_flash_ck804}, // YHLU {0x10de, 0x0262, "NVidia MCP51", enable_flash_ck804}, {0x10de, 0x0263, "NVidia MCP51", enable_flash_ck804}, + {0x10de, 0x0364, "NVIDIA MCP55", enable_flash_mcp55}, // LPC + {0x10de, 0x0367, "NVIDIA MCP55", enable_flash_mcp55}, // Pro + {0x1002, 0x4377, "ATI SB400", enable_flash_sb400}, // ATI Technologies Inc IXP SB400 PCI-ISA Bridge (rev 80) }; Modified: trunk/LinuxBIOSv2/util/flashrom/flashchips.c =================================================================== --- trunk/LinuxBIOSv2/util/flashrom/flashchips.c 2007-01-17 10:57:42 UTC (rev 2536) +++ trunk/LinuxBIOSv2/util/flashrom/flashchips.c 2007-01-22 20:21:17 UTC (rev 2537) @@ -31,6 +31,7 @@ #endif #include "am29f040b.h" #include "sst28sf040.h" +#include "sst49lfxxxc.h" #include "w49f002u.h" #include "sst39sf020.h" #include "sst49lf040.h" @@ -82,6 +83,12 @@ probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub, NULL}, {"Pm49FL002", PMC_ID, PMC_49FL002, NULL, 256, 16 * 1024, probe_jedec, erase_chip_jedec, write_49fl004,NULL}, + {"SST49LF004C", SST_ID, SST_49LF004C, NULL, 512, 4 * 1024, + probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc,NULL}, + {"SST49LF008C", SST_ID, SST_49LF008C, NULL, 1024, 4 * 1024 , + probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc, NULL}, + {"SST49LF016C", SST_ID, SST_49LF016C, NULL, 2048, 4 * 1024 , + probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc, NULL}, {"Pm49FL004", PMC_ID, PMC_49FL004, NULL, 512, 64 * 1024, probe_jedec, erase_chip_jedec, write_49fl004,NULL}, {"W29C011", WINBOND_ID, W_29C011, NULL, 128, 128, Added: trunk/LinuxBIOSv2/util/flashrom/sst49lfxxxc.c =================================================================== --- trunk/LinuxBIOSv2/util/flashrom/sst49lfxxxc.c (rev 0) +++ trunk/LinuxBIOSv2/util/flashrom/sst49lfxxxc.c 2007-01-22 20:21:17 UTC (rev 2537) @@ -0,0 +1,204 @@ +/* + * 49lfxxxc.c: driver for SST49LFXXXC flash models. + * + * + * Copyright 2000 Silicon Integrated System Corporation + * Copyright 2005 coresystems GmbH + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * 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., 675 Mass Ave, Cambridge, MA 02139, USA. + * + * + * Reference: + * SST49LFxxxC data sheets + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include "flash.h" +#include "jedec.h" +#include "debug.h" + +#define SECTOR_ERASE 0x30 +#define BLOCK_ERASE 0x20 +#define ERASE 0xD0 +#define AUTO_PGRM 0x10 +#define RESET 0xFF +#define READ_ID 0x90 +#define READ_STATUS 0x70 +#define CLEAR_STATUS 0x50 + +#define STATUS_BPS (1 << 1) +#define STATUS_ESS (1 << 6) +#define STATUS_WSMS (1 << 7) + + +static __inline__ int write_lockbits_49lfxxxc(volatile uint8_t *bios, int size, + unsigned char bits) +{ + int i, left = size; + unsigned long address; + + //printf("bios=0x%08lx\n", (unsigned long)bios); + for (i = 0; left > 65536; i++, left -= 65536) { + //printf("lockbits at address=0x%08lx is 0x%01x\n", (unsigned long)0xFFC00000 - size + (i * 65536) + 2, *(bios + (i * 65536) + 2) ); + *(bios + (i * 65536) + 2) = bits; + } + address = i * 65536; + //printf("lockbits at address=0x%08lx is 0x%01x\n", (unsigned long)0xFFc00000 - size + address + 2, *(bios + address + 2) ); + *(bios + address + 2) = bits; + address += 32768; + //printf("lockbits at address=0x%08lx is 0x%01x\n", (unsigned long)0xFFc00000 - size + address + 2, *(bios + address + 2) ); + *(bios + address + 2) = bits; + address += 8192; + //printf("lockbits at address=0x%08lx is 0x%01x\n", (unsigned long)0xFFc00000 - size + address + 2, *(bios + address + 2) ); + *(bios + address + 2) = bits; + address += 8192; + //printf("lockbits at address=0x%08lx is 0x%01x\n", (unsigned long)0xFFc00000 - size + address + 2, *(bios + address + 2) ); + *(bios + address + 2) = bits; + + + return (0); +} + +static __inline__ int erase_sector_49lfxxxc(volatile uint8_t *bios, + unsigned long address) +{ + unsigned char status; + + *bios = SECTOR_ERASE; + *(bios + address) = ERASE; + + do { + status = *bios; + if (status & (STATUS_ESS | STATUS_BPS)) { + printf("sector erase FAILED at address=0x%08lx status=0x%01x\n", (unsigned long)bios + address, status); + *bios = CLEAR_STATUS; + return(-1); + } + } while (!(status & STATUS_WSMS)); + + return (0); +} + +static __inline__ int write_sector_49lfxxxc(volatile uint8_t *bios, + uint8_t *src, + volatile uint8_t *dst, + unsigned int page_size) +{ + int i; + unsigned char status; + + *bios = CLEAR_STATUS; + for (i = 0; i < page_size; i++) { + /* transfer data from source to destination */ + if (*src == 0xFF) { + dst++, src++; + /* If the data is 0xFF, don't program it */ + continue; + } + /*issue AUTO PROGRAM command */ + *bios = AUTO_PGRM; + *dst++ = *src++; + + do { + status = *bios; + if (status & (STATUS_ESS | STATUS_BPS)) { + printf("sector write FAILED at address=0x%08lx status=0x%01x\n", (unsigned long)dst, status); + *bios = CLEAR_STATUS; + return(-1); + } + } while (!(status & STATUS_WSMS)); + } + + return (0); +} + +int probe_49lfxxxc(struct flashchip *flash) +{ + volatile uint8_t *bios = flash->virt_addr; + uint8_t id1, id2; + size_t size = flash->total_size * 1024; + + *bios = RESET; + + *bios = READ_ID; + id1 = *(volatile uint8_t *) bios; + id2 = *(volatile uint8_t *) (bios + 0x01); + + *bios = RESET; + + printf_debug("%s: id1 0x%x, id2 0x%x\n", __FUNCTION__, id1, id2); + if (!(id1 == flash->manufacture_id && id2 == flash->model_id)) + return 0; + + bios = mmap(0, size, PROT_WRITE | PROT_READ, MAP_SHARED, + flash->fd_mem, (off_t) (0xFFFFFFFF - 0x400000 - size + 1)); + if (bios == MAP_FAILED) { + // it's this part but we can't map it ... + perror("Error MMAP /dev/mem"); + exit(1); + } + flash->virt_addr_2 = bios; + return 1; +} + +int erase_49lfxxxc(struct flashchip *flash) +{ + volatile uint8_t *bios = flash->virt_addr; + volatile uint8_t *bios2 = flash->virt_addr_2; + int i; + unsigned int total_size = flash->total_size * 1024; + + write_lockbits_49lfxxxc(bios2, total_size, 0); + for (i = 0; i < total_size; i += flash->page_size) + if (erase_sector_49lfxxxc(bios, i) != 0 ) + return (-1); + + *bios = RESET; + return (0); +} + +int write_49lfxxxc(struct flashchip *flash, uint8_t *buf) +{ + int i; + int total_size = flash->total_size * 1024, page_size = + flash->page_size; + volatile uint8_t *bios = flash->virt_addr; + + + write_lockbits_49lfxxxc(flash->virt_addr_2, total_size, 0); + printf("Programming Page: "); + for (i = 0; i < total_size / page_size; i++) { + /* erase the page before programming */ + erase_sector_49lfxxxc(bios, i * page_size); + + /* write to the sector */ + printf("%04d at address: 0x%08x", i, i * page_size); + write_sector_49lfxxxc(bios, buf + i * page_size, + bios + i * page_size, page_size); + printf("\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b"); + } + printf("\n"); + + *bios = RESET; + return (0); +} Added: trunk/LinuxBIOSv2/util/flashrom/sst49lfxxxc.h =================================================================== --- trunk/LinuxBIOSv2/util/flashrom/sst49lfxxxc.h (rev 0) +++ trunk/LinuxBIOSv2/util/flashrom/sst49lfxxxc.h 2007-01-22 20:21:17 UTC (rev 2537) @@ -0,0 +1,8 @@ +#ifndef __SST49LFXXXC_H__ +#define __SST49LFXXXC_H__ + +extern int probe_49lfxxxc(struct flashchip *flash); +extern int erase_49lfxxxc(struct flashchip *flash); +extern int write_49lfxxxc(struct flashchip *flash, uint8_t *buf); + +#endif /* !__SST49LFXXXC_H__ */ From mack.stout at gmail.com Tue Jan 23 01:38:11 2007 From: mack.stout at gmail.com (mack stout) Date: Mon, 22 Jan 2007 18:38:11 -0600 Subject: [LinuxBIOS] Read / Write to CMOS Message-ID: Hello list, I'm somewhat new to bios programming... but i have a handful of boxes (with Award Bios) that I need to set to pxeboot remotely. I was thinking that I might achieve this by dumping the CMOS (cat /dev/nvram > file) of a box with pxeboot on, and then writing it to a box that has pxeboot turned off. I will actually be surprised if a quick hack like this would actually work, as I imagine its not that simple. But I was hoping that I might get some information about what settings are actually stored in CMOS, if they're changeable, if there's a GPL'd utility to facilitate this process. Does linuxbios support altering bios settings from userspace? Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey_osgood at verizon.net Tue Jan 23 07:08:50 2007 From: corey_osgood at verizon.net (Corey Osgood) Date: Tue, 23 Jan 2007 01:08:50 -0500 Subject: [LinuxBIOS] LinuxBIOSv1 won't build? Message-ID: <45B5A672.8070804@verizon.net> I've got my laptop back, and I'm trying to compile linuxbios for the rcn dc1100s, since it has the same setup as the tyan s2507, but I keep getting compile errors. With gcc 3.3.6: dualp3 dc1100s # make Makefile:501: warning: overriding commands for target `keyboard.o' Makefile:414: warning: ignoring old commands for target `keyboard.o' gcc -x assembler-with-cpp -DASSEMBLY -E ... crt0.S > crt0.s gcc ... -o crt0.o crt0.s crt0.S: Assembler messages: crt0.S:153: Warning: indirect jmp without `*' gcc ... -o linuxbiosmain.o /home/amp/LinuxBIOSv1/src/lib/linuxbiosmain.c /home/amp/LinuxBIOSv1/src/lib/linuxbiosmain.c: In function `linuxbiosmain': /home/amp/LinuxBIOSv1/src/lib/linuxbiosmain.c:66: error: `root' undeclared (first use in this function) /home/amp/LinuxBIOSv1/src/lib/linuxbiosmain.c:66: error: (Each undeclared identifier is reported only once /home/amp/LinuxBIOSv1/src/lib/linuxbiosmain.c:66: error: for each function it appears in.) /home/amp/LinuxBIOSv1/src/lib/linuxbiosmain.c:66: error: syntax error before '/' token I remember that at some point, there was some discussion about v1 not building, but I can't seem to find it. Anyone have a patch to fix this? I hate to go diving into v1 if someone already has a fix. Or heck, if someone's already got a rom built with FILO (I assume you can use filo with v1), that would do even better :-D -Corey From bingxunshi at gmail.com Tue Jan 23 08:03:51 2007 From: bingxunshi at gmail.com (bxshi) Date: Tue, 23 Jan 2007 15:03:51 +0800 Subject: [LinuxBIOS] MCP55 LinuxBIOS with USB debug Message-ID: Dr. Lu, In mcp55_smbus.h static int do_smbus_send_byte(unsigned smbus_io_base, unsigned device, unsigned char val) { ..... outb(0, smbus_io_base + SMBHSTCMD); ..... } I wonder why you write 0 to SMBHSTCMD ? if we are using a smbus_hub , I think we should write the channel number we want to enable to this register. for example , if my memory controller is on channel 2 , we should write outb(2,smbus_io_base+SMBHSTCMD). So could that be changed to outb(val,smbus_io_base + SMBHSTCMD) ? Thanks bxshi -------------- next part -------------- An HTML attachment was scrubbed... URL: From uwe at hermann-uwe.de Tue Jan 23 13:09:44 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Tue, 23 Jan 2007 13:09:44 +0100 Subject: [LinuxBIOS] LinuxBIOSv1 won't build? In-Reply-To: <45B5A672.8070804@verizon.net> References: <45B5A672.8070804@verizon.net> Message-ID: <20070123120944.GA26438@greenwood> Hi, On Tue, Jan 23, 2007 at 01:08:50AM -0500, Corey Osgood wrote: > I remember that at some point, there was some discussion about v1 not > building, but I can't seem to find it. Anyone have a patch to fix this? > I hate to go diving into v1 if someone already has a fix. Or heck, if > someone's already got a rom built with FILO (I assume you can use filo > with v1), that would do even better :-D I don't know about FILO, but here's a patch you can try to get an image. Note that this is an ugly, ugly hack. I just "fixed" stuff as it appeared until the build seemed to work. I didn't get a real LB image as I currently lack a Linux kernel image to test... 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: ugly_hack.patch Type: text/x-diff Size: 1627 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From rafiks at comcast.net Tue Jan 23 15:32:09 2007 From: rafiks at comcast.net (ralph bacolod) Date: Tue, 23 Jan 2007 09:32:09 -0500 Subject: [LinuxBIOS] Netvista 2200 8363 Message-ID: <20070123143209.GA8370@debian.lan> Hi! Just recently bought an IBM Netvista 8363. I got it to boot my LTSP setup via NFS.. It bothers me though that I can't get PXE or even boot a normal Linux kernel in this Thin client.. I notice that it has a socket chip with "ns" plus numbers in it..It looks like this can be replaced.. Did somebody already hacked the bios of this Thin client? Is there someplace where I can find information about trying out linuxbios from scratch .. -- -- Ralph Bacolod,RMT,MT http://rbacolod.blogspot.com From yinghai.lu at amd.com Tue Jan 23 18:04:50 2007 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 23 Jan 2007 09:04:50 -0800 Subject: [LinuxBIOS] MCP55 LinuxBIOS with USB debug Message-ID: <5986589C150B2F49A46483AC44C7BCA49073BF@ssvlexmb2.amd.com> If you have smbus hub, You may need to use smbus_send_byte(hub_address, hub_channel); or smbus_write_byte(hub_address, hub_channel); the code is same as CK804's, and the code is verified with Tyan S4881 and 4885. For PCA9556/PCA9516 static inline void activate_spd_rom(const struct mem_controller *ctrl) { #define SMBUS_HUB 0x18 unsigned device=(ctrl->channel0[0])>>8; smbus_write_byte(SMBUS_HUB, 0x01, device); smbus_write_byte(SMBUS_HUB,0x03, 0); } YH ________________________________ From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of bxshi Sent: Monday, January 22, 2007 11:04 PM To: yinghailu at gmail.com Cc: linuxbios at linuxbios.org Subject: Re: [LinuxBIOS] MCP55 LinuxBIOS with USB debug Dr. Lu, In mcp55_smbus.h static int do_smbus_send_byte(unsigned smbus_io_base, unsigned device, unsigned char val) { ..... outb(0, smbus_io_base + SMBHSTCMD); ..... } I wonder why you write 0 to SMBHSTCMD ? if we are using a smbus_hub , I think we should write the channel number we want to enable to this register. for example , if my memory controller is on channel 2 , we should write outb(2,smbus_io_base+SMBHSTCMD). So could that be changed to outb(val,smbus_io_base + SMBHSTCMD) ? Thanks bxshi -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Tue Jan 23 19:11:10 2007 From: rminnich at gmail.com (ron minnich) Date: Tue, 23 Jan 2007 11:11:10 -0700 Subject: [LinuxBIOS] Read / Write to CMOS In-Reply-To: References: Message-ID: <13426df10701231011r4743c0c2ge07eaa08ee48431f@mail.gmail.com> On 1/22/07, mack stout wrote: > Does linuxbios support altering bios settings from userspace? it's easy to do this. You need the simple tools that read and write cmos. Attached. ron -------------- next part -------------- A non-text attachment was scrubbed... Name: cmos.tgz Type: application/x-gzip Size: 1419 bytes Desc: not available URL: From rminnich at gmail.com Tue Jan 23 19:20:49 2007 From: rminnich at gmail.com (ron minnich) Date: Tue, 23 Jan 2007 11:20:49 -0700 Subject: [LinuxBIOS] help from ubuntu and FC6 experts Message-ID: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> I would like to hear reports of building and running linuxbios on ubuntu and FC6. The background is that ubuntu and, perhaps, fc6, set some options on the gcc pass that make no sense on a bios build. This is a guess. The result is a non-working linuxbios on those machines. It is believed the issue is some sort of stack protection flag that gets set. So, if you have a working linuxbios, and an fc6 or ubuntu handy, I'd like to hear about your success or failure in building and running linuxbios. This has been seen on OLPC, but nowhere else; it may be related to special needs of the OLPC. thanks ron From rminnich at gmail.com Tue Jan 23 20:35:12 2007 From: rminnich at gmail.com (ron minnich) Date: Tue, 23 Jan 2007 12:35:12 -0700 Subject: [LinuxBIOS] LinuxBIOS not working In-Reply-To: <318822.14965.qm@web50113.mail.yahoo.com> References: <318822.14965.qm@web50113.mail.yahoo.com> Message-ID: <13426df10701231135n7d0a1565p15e76f0d2a4c4980@mail.gmail.com> Sanjay, it is good to hear from you, and thanks for your report -- even if it is negative :-) I am not up to date with the 8606 -- maybe someone else is. Do you have a data sheet? You should, in the config file, set DEFAULT_CONSOLE_LOGLEVEL=9 MAXIMUM_CONSOLE_LOGLEVEL=9 and see if you get any output. thanks ron From marcelocoelho at gmail.com Tue Jan 23 20:36:21 2007 From: marcelocoelho at gmail.com (Marcelo Coelho) Date: Tue, 23 Jan 2007 19:36:21 +0000 Subject: [LinuxBIOS] State of cheap motherboard support Message-ID: <20c6f18e0701231136p1549c0bfq78ad235935fa2a77@mail.gmail.com> Hi! I've been following the development to give support to (new) cheap motherboards, specifically the mcp55 based ones. I'm thinking in buying an Asus M2NPV-VM, which uses the Chipset NVIDIA GeForce 6150 + nForce 430. Is this already supported? Thanks for your help! Marcelo From smithbone at gmail.com Tue Jan 23 20:43:57 2007 From: smithbone at gmail.com (Richard Smith) Date: Tue, 23 Jan 2007 14:43:57 -0500 Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> References: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> Message-ID: <45B6657D.2020805@gmail.com> ron minnich wrote: > The background is that ubuntu and, perhaps, fc6, set some options on > the gcc pass that make no sense on a bios build. This is a guess. The > result is a non-working linuxbios on those machines. It is believed > the issue is some sort of stack protection flag that gets set. > So, if you have a working linuxbios, and an fc6 or ubuntu handy, I'd > like to hear about your success or failure in building and running > linuxbios. Ron, I think Linuxbios build will fail on recent Ubuntu dists. When I encounterd the problem the other developers here at OLPC said "oh yeah, it won't build on ubuntu." I have the build working on my kubuntu laptop. Ubuntu enables the gcc stack protector. So when you build you get linuxbios_ram.o: In function `number': vtxprintf.c:(.text+0x271a): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `report_resource_stored': (.text+0x3aca): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `cpu_initialize': (.text+0x875c): undefined reference to `__stack_chk_fail' collect2: ld returned 1 exit status The fix is to add -fno-stack-protector into the CFLAGS. I'm currently doing it manually. What we need to know is how to detect when its active. As for FC6 we would really like to hear from others who are building on FC6 -- Richard A. Smith smithbone at gmail.com From corey_osgood at verizon.net Tue Jan 23 20:53:01 2007 From: corey_osgood at verizon.net (Corey Osgood) Date: Tue, 23 Jan 2007 14:53:01 -0500 Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> References: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> Message-ID: <45B6679D.4000106@verizon.net> ron minnich wrote: > I would like to hear reports of building and running linuxbios on > ubuntu and FC6. > I use ubuntu 6.10 on my desktop, and it always fails to compile somewhere along the line, both with gcc 4.1 and 3.3 from the ubuntu repositories. The box that I usually compile on runs Gentoo 2006.1, which works perfectly. -Corey From yinghai.lu at amd.com Tue Jan 23 20:45:50 2007 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 23 Jan 2007 11:45:50 -0800 Subject: [LinuxBIOS] State of cheap motherboard support Message-ID: <5986589C150B2F49A46483AC44C7BCA49073C1@ssvlexmb2.amd.com> That is C51/MCP51 based. YH -----Original Message----- From: linuxbios-bounces+yinghai.lu=amd.com at linuxbios.org [mailto:linuxbios-bounces+yinghai.lu=amd.com at linuxbios.org] On Behalf Of Marcelo Coelho Sent: Tuesday, January 23, 2007 11:36 AM To: linuxbios at linuxbios.org Subject: [LinuxBIOS] State of cheap motherboard support Hi! I've been following the development to give support to (new) cheap motherboards, specifically the mcp55 based ones. I'm thinking in buying an Asus M2NPV-VM, which uses the Chipset NVIDIA GeForce 6150 + nForce 430. Is this already supported? Thanks for your help! Marcelo -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios From rminnich at gmail.com Tue Jan 23 21:03:08 2007 From: rminnich at gmail.com (ron minnich) Date: Tue, 23 Jan 2007 13:03:08 -0700 Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: <45B6679D.4000106@verizon.net> References: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> <45B6679D.4000106@verizon.net> Message-ID: <13426df10701231203l3e4eabb7m1d51a1c69ab85dcb@mail.gmail.com> On 1/23/07, Corey Osgood wrote: > ron minnich wrote: > > I would like to hear reports of building and running linuxbios on > > ubuntu and FC6. > > > I use ubuntu 6.10 on my desktop, and it always fails to compile > somewhere along the line, both with gcc 4.1 and 3.3 from the ubuntu > repositories. The box that I usually compile on runs Gentoo 2006.1, > which works perfectly. send me the failing output, ok? I assume we don't want the stack protection code in. ron From segher at kernel.crashing.org Tue Jan 23 21:27:28 2007 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Tue, 23 Jan 2007 21:27:28 +0100 Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> References: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> Message-ID: <7006B332-792C-4480-8409-7C11149BEAB5@kernel.crashing.org> > The background is that ubuntu and, perhaps, fc6, set some options on > the gcc pass that make no sense on a bios build. This is a guess. The > result is a non-working linuxbios on those machines. It is believed > the issue is some sort of stack protection flag that gets set. Yeah, at least FC6 does that, and it should be reported as a bug to them (or as a serious misfeature at least) -- by default enabling some options that FSF GCC won't allow you to enable by default (for a good reason) cannot be helpful. Does LinuxBIOS build with -ffreestanding? If you don't, that's a bug for you too -- if you do, and that option does not disable SSP, that's a GCC bug -- either a mainline GCC one, or one in FC6, depending on how they enable it by default. Segher From segher at kernel.crashing.org Tue Jan 23 21:32:22 2007 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Tue, 23 Jan 2007 21:32:22 +0100 Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: <45B6657D.2020805@gmail.com> References: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> <45B6657D.2020805@gmail.com> Message-ID: <570F4056-68DA-4862-B39A-7B7EB0267956@kernel.crashing.org> > The fix is to add -fno-stack-protector into the CFLAGS. I'm currently > doing it manually. What we need to know is how to detect when its > active. You don't have to detect when it's active; you can just always disable it -- well that is, you first have to check if your GCC version supports it at all, it will bail on the command line flag otherwise. If you really want to see what flags are active, compile a (dummy) file to an assembler file using -fverbose-asm, and it will tell you. Segher From smithbone at gmail.com Tue Jan 23 22:11:12 2007 From: smithbone at gmail.com (Richard Smith) Date: Tue, 23 Jan 2007 16:11:12 -0500 Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: <570F4056-68DA-4862-B39A-7B7EB0267956@kernel.crashing.org> References: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> <45B6657D.2020805@gmail.com> <570F4056-68DA-4862-B39A-7B7EB0267956@kernel.crashing.org> Message-ID: <45B679F0.6010809@gmail.com> Segher Boessenkool wrote: > You don't have to detect when it's active; you can just always > disable it -- well that is, you first have to check if your GCC > version supports it at all, it will bail on the command line flag > otherwise. Thats what I meant. You have to know when to use the disable flag. -- Richard A. Smith smithbone at gmail.com From uwe at hermann-uwe.de Tue Jan 23 22:22:28 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Tue, 23 Jan 2007 22:22:28 +0100 Subject: [LinuxBIOS] LinuxBIOS not working In-Reply-To: <13426df10701231135n7d0a1565p15e76f0d2a4c4980@mail.gmail.com> References: <318822.14965.qm@web50113.mail.yahoo.com> <13426df10701231135n7d0a1565p15e76f0d2a4c4980@mail.gmail.com> Message-ID: <20070123212228.GA976@greenwood> Hi, On Tue, Jan 23, 2007 at 12:35:12PM -0700, ron minnich wrote: > Sanjay, it is good to hear from you, and thanks for your report -- > even if it is negative :-) > > I am not up to date with the 8606 -- maybe someone else is. Do you > have a data sheet? As far as I can see, only the VT8601 (not VT8606) is supported in svn(?) Not sure how similar they are. The VIA datasheets aren't usually available publically as far as I know, so you'd have to contact VIA and try to get some datasheet, I guess... 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 smithbone at gmail.com Tue Jan 23 22:56:49 2007 From: smithbone at gmail.com (Richard Smith) Date: Tue, 23 Jan 2007 16:56:49 -0500 Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: <7006B332-792C-4480-8409-7C11149BEAB5@kernel.crashing.org> References: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> <7006B332-792C-4480-8409-7C11149BEAB5@kernel.crashing.org> Message-ID: <45B684A1.1080306@gmail.com> Segher Boessenkool wrote: > Does LinuxBIOS build with -ffreestanding? If you don't, that's > a bug for you too -- if you do, and that option does not disable > SSP, that's a GCC bug -- either a mainline GCC one, or one in > FC6, depending on how they enable it by default. We do not (at least as far as I can tell) and I just tested and -ffreestanding did not help. -- Richard A. Smith smithbone at gmail.com From c-d.hailfinger.devel.2006 at gmx.net Tue Jan 23 23:53:00 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue, 23 Jan 2007 23:53:00 +0100 Subject: [LinuxBIOS] [PATCH] flashrom: Support for MCP55 and SST49LFXXXC chips In-Reply-To: <20070121131041.GA15033@greenwood> References: <20070121131041.GA15033@greenwood> Message-ID: <45B691CC.4090509@gmx.net> Hi Uwe, Uwe Hermann wrote: > Add support for the SST-49LF004C, SST-49LF008C, SST-49LF016C in flashrom. > Also add suport for NVIDIA MCP55. > > I tried to extract only the relevant changes out of Yinghai's code. > Please review (especially check whether I forgot some code) and test > whether it works. > --- util/flashrom/flash_enable.c (Revision 2536) > +++ util/flashrom/flash_enable.c (Arbeitskopie) > @@ -432,9 +472,13 @@ > > {0x10de, 0x0260, "NVidia MCP51", enable_flash_ck804}, > {0x10de, 0x0261, "NVidia MCP51", enable_flash_ck804}, > + // {0x10de, 0x0261, "NVIDIA C51", enable_flash_ck804}, // YHLU > {0x10de, 0x0262, "NVidia MCP51", enable_flash_ck804}, > {0x10de, 0x0263, "NVidia MCP51", enable_flash_ck804}, > Why did you comment out this PCI ID combination? Regards, Carl-Daniel -- http://www.hailfinger.org/ From yinghai.lu at amd.com Wed Jan 24 00:15:09 2007 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 23 Jan 2007 15:15:09 -0800 Subject: [LinuxBIOS] [PATCH] flashrom: Support for MCP55 and SST49LFXXXC chips Message-ID: <5986589C150B2F49A46483AC44C7BCA49073C4@ssvlexmb2.amd.com> > {0x10de, 0x0261, "NVidia MCP51", enable_flash_ck804}, > + // {0x10de, 0x0261, "NVIDIA C51", enable_flash_ck804}, // YHLU Flash is on mcp51 instead of c51. YH -----Original Message----- From: linuxbios-bounces+yinghai.lu=amd.com at linuxbios.org [mailto:linuxbios-bounces+yinghai.lu=amd.com at linuxbios.org] On Behalf Of Carl-Daniel Hailfinger Sent: Tuesday, January 23, 2007 2:53 PM To: Uwe Hermann Cc: linuxbios at linuxbios.org Subject: Re: [LinuxBIOS] [PATCH] flashrom: Support for MCP55 and SST49LFXXXC chips Hi Uwe, Uwe Hermann wrote: > Add support for the SST-49LF004C, SST-49LF008C, SST-49LF016C in flashrom. > Also add suport for NVIDIA MCP55. > > I tried to extract only the relevant changes out of Yinghai's code. > Please review (especially check whether I forgot some code) and test > whether it works. > --- util/flashrom/flash_enable.c (Revision 2536) > +++ util/flashrom/flash_enable.c (Arbeitskopie) > @@ -432,9 +472,13 @@ > > {0x10de, 0x0260, "NVidia MCP51", enable_flash_ck804}, > {0x10de, 0x0261, "NVidia MCP51", enable_flash_ck804}, > + // {0x10de, 0x0261, "NVIDIA C51", enable_flash_ck804}, // YHLU > {0x10de, 0x0262, "NVidia MCP51", enable_flash_ck804}, > {0x10de, 0x0263, "NVidia MCP51", enable_flash_ck804}, > Why did you comment out this PCI ID combination? Regards, Carl-Daniel -- http://www.hailfinger.org/ -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios From mack.stout at gmail.com Wed Jan 24 00:32:55 2007 From: mack.stout at gmail.com (Ben Racher) Date: Tue, 23 Jan 2007 17:32:55 -0600 Subject: [LinuxBIOS] Read / Write to CMOS In-Reply-To: <13426df10701231011r4743c0c2ge07eaa08ee48431f@mail.gmail.com> References: <13426df10701231011r4743c0c2ge07eaa08ee48431f@mail.gmail.com> Message-ID: <45B69B27.1010109@gmail.com> ron minnich wrote: > On 1/22/07, mack stout wrote: > >> Does linuxbios support altering bios settings from userspace? > > it's easy to do this. > > You need the simple tools that read and write cmos. > > Attached. > > ron perfect! just what I had been looking for, and it even works fine with phoenix award bios! I just set the settings that I want to change, dump it, and then write it to clients (with exact same hardware) and the settings are applied. amazing! now i just need to learn what actually happens in these 35 lines of code :-) what library does outb(regno, 0x70); come from? and 0x70 represents the memory where cmos starts at? ben From dhendrix at google.com Wed Jan 24 00:49:11 2007 From: dhendrix at google.com (David Hendricks) Date: Tue, 23 Jan 2007 15:49:11 -0800 Subject: [LinuxBIOS] Read / Write to CMOS In-Reply-To: <45B69B27.1010109@gmail.com> References: <13426df10701231011r4743c0c2ge07eaa08ee48431f@mail.gmail.com> <45B69B27.1010109@gmail.com> Message-ID: The functions come from asm/io.h, 0x70 is the CMOS memory address I/O port, and 0x71 is the CMOS memory data I/O port. It looks like http://www.faqs.org/docs/Linux-mini/IO-Port-Programming.html has some good information on this topic. I know "The Undocumented PC" by Van Gilluwe has a pretty thorough discussion of the CMOS ports as well. On 1/23/07, Ben Racher wrote: > > ron minnich wrote: > > On 1/22/07, mack stout wrote: > > > >> Does linuxbios support altering bios settings from userspace? > > > > it's easy to do this. > > > > You need the simple tools that read and write cmos. > > > > Attached. > > > > ron > perfect! just what I had been looking for, and it even works fine with > phoenix award bios! I just set the settings that I want to change, dump > it, and then write it to clients (with exact same hardware) and the > settings are applied. amazing! > > now i just need to learn what actually happens in these 35 lines of code > :-) what library does > outb(regno, 0x70); come from? and 0x70 represents the memory where cmos > starts at? > > ben > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > -------------- next part -------------- An HTML attachment was scrubbed... URL: From c-d.hailfinger.devel.2006 at gmx.net Wed Jan 24 01:07:15 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 24 Jan 2007 01:07:15 +0100 Subject: [LinuxBIOS] [PATCH] flashrom: Support for MCP55 and SST49LFXXXC chips In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49073C4@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49073C4@ssvlexmb2.amd.com> Message-ID: <45B6A333.1000302@gmx.net> Hello Yinghai, Lu, Yinghai wrote: >> {0x10de, 0x0261, "NVidia MCP51", enable_flash_ck804}, >> + // {0x10de, 0x0261, "NVIDIA C51", enable_flash_ck804}, // YHLU > > Flash is on mcp51 instead of c51. So we can safely delete this line? Regards, Carl-Daniel -- http://www.hailfinger.org/ From segher at kernel.crashing.org Wed Jan 24 01:48:46 2007 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Wed, 24 Jan 2007 01:48:46 +0100 Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: <45B679F0.6010809@gmail.com> References: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> <45B6657D.2020805@gmail.com> <570F4056-68DA-4862-B39A-7B7EB0267956@kernel.crashing.org> <45B679F0.6010809@gmail.com> Message-ID: <1655C02E-F994-4550-9681-666E23F1DA47@kernel.crashing.org> >> You don't have to detect when it's active; you can just always >> disable it -- well that is, you first have to check if your GCC >> version supports it at all, it will bail on the command line flag >> otherwise. > > Thats what I meant. You have to know when to use the disable flag. So you should just try it out somewhere in your build system -- gcc -fno-stack-protector -S -xc - < /dev/null -o /dev/null or something similar, grab the return code -- and that's all you need to do. Maybe FC6 and/or Ubuntu will change their bad bad ways, but there are so many of those systems out in the field already, lots of projects have to protect themselves against this crap now. Sigh. Segher From segher at kernel.crashing.org Wed Jan 24 01:50:36 2007 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Wed, 24 Jan 2007 01:50:36 +0100 Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: <45B684A1.1080306@gmail.com> References: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> <7006B332-792C-4480-8409-7C11149BEAB5@kernel.crashing.org> <45B684A1.1080306@gmail.com> Message-ID: <44A58276-374B-4677-B9F4-BCA37C4D208D@kernel.crashing.org> >> Does LinuxBIOS build with -ffreestanding? If you don't, that's >> a bug for you too -- if you do, and that option does not disable >> SSP, that's a GCC bug -- either a mainline GCC one, or one in >> FC6, depending on how they enable it by default. > > We do not (at least as far as I can tell) Bug! Bug! ;-) > and I just tested and -ffreestanding did not help. I'll go see what the larger GCC community thinks about this -- I'd say it's a bug. Well I'll go check tomorrow :-) Segher From yinghai.lu at amd.com Wed Jan 24 01:54:38 2007 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 23 Jan 2007 16:54:38 -0800 Subject: [LinuxBIOS] [PATCH] flashrom: Support for MCP55 and SST49LFXXXC chips Message-ID: <5986589C150B2F49A46483AC44C7BCA49073C7@ssvlexmb2.amd.com> Yes -----Original Message----- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006 at gmx.net] Sent: Tuesday, January 23, 2007 4:07 PM To: Lu, Yinghai Cc: Uwe Hermann; linuxbios at linuxbios.org Subject: Re: [LinuxBIOS] [PATCH] flashrom: Support for MCP55 and SST49LFXXXC chips Hello Yinghai, Lu, Yinghai wrote: >> {0x10de, 0x0261, "NVidia MCP51", enable_flash_ck804}, >> + // {0x10de, 0x0261, "NVIDIA C51", enable_flash_ck804}, // YHLU > > Flash is on mcp51 instead of c51. So we can safely delete this line? Regards, Carl-Daniel -- http://www.hailfinger.org/ From bingxunshi at gmail.com Wed Jan 24 02:08:21 2007 From: bingxunshi at gmail.com (bxshi) Date: Wed, 24 Jan 2007 09:08:21 +0800 Subject: [LinuxBIOS] MCP55 LinuxBIOS with USB debug In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49073BF@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49073BF@ssvlexmb2.amd.com> Message-ID: You may need to use > > smbus_send_byte(hub_address, hub_channel); > > or > > smbus_write_byte(hub_address, hub_channel); > > > smbus_write_byte may need three parametres, smbus_write_byte(device ,address ,val). for PCA9545 to enable one channel need four steps , 1. outb(hub_address, base_io+02) 2. outb(hub_channel, base_io +03) 3. outb(0x04, base_io + 00) 4. test inb(base_io+01) it is a little different from PCA9556/PCA9557. as I look at the code , use smbus_write_byte may not make pca9545 work . use smbus_send_byte(device,val) , I get the output: No memory for this cpu No memory so I change below outb(val, smbus_io_base + SMBHSTCMD); then everything works fine. so I think smbus_send_byte(device,val) ,device should be the HUB_ADDRESS , and val is the HUB_CHANNEL. is it right? bxshi -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinghai.lu at amd.com Wed Jan 24 02:16:50 2007 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 23 Jan 2007 17:16:50 -0800 Subject: [LinuxBIOS] MCP55 LinuxBIOS with USB debug Message-ID: <5986589C150B2F49A46483AC44C7BCA49073C8@ssvlexmb2.amd.com> Maybe Nvidia fixed the bug in mcp55. AMD8111 is using DAT0... It should use SMBHDTCMD for val with send/receive byte. Serverworks chipset already use CMD. YH ________________________________ From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of bxshi Sent: Tuesday, January 23, 2007 5:08 PM To: Lu, Yinghai Cc: linuxbios at linuxbios.org Subject: Re: [LinuxBIOS] MCP55 LinuxBIOS with USB debug You may need to use smbus_send_byte(hub_address, hub_channel); or smbus_write_byte(hub_address, hub_channel); smbus_write_byte may need three parametres, smbus_write_byte(device ,address ,val). for PCA9545 to enable one channel need four steps , 1. outb(hub_address, base_io+02) 2. outb(hub_channel, base_io +03) 3. outb(0x04, base_io + 00) 4. test inb(base_io+01) it is a little different from PCA9556/PCA9557. as I look at the code , use smbus_write_byte may not make pca9545 work . use smbus_send_byte(device,val) , I get the output: No memory for this cpu No memory so I change below outb(val, smbus_io_base + SMBHSTCMD); then everything works fine. so I think smbus_send_byte(device,val) ,device should be the HUB_ADDRESS , and val is the HUB_CHANNEL. is it right? bxshi -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinghai.lu at amd.com Wed Jan 24 04:46:57 2007 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 23 Jan 2007 19:46:57 -0800 Subject: [LinuxBIOS] more big range for HT_CHAIN_UNITID_BASE and HT_CHAIN_UNITID_BASE Message-ID: <5986589C150B2F49A46483AC44C7BCA49073C9@ssvlexmb2.amd.com> Please check the diff to fb2_mcp55_full_01172007. More range for HT_CHAIN_UNITID_BASE and HT_CHAIN_END_UNITID_BASE. For example: in C51/MCP55 or C51/MCP51 Will allow 1. C51 at 0x10 to 0x14, and MCP at 0 to 4 2. C51 at 1 to 4, and MCP at 7 to 0x0a The reason is c51/mcp51/mcp55 reported unitid is 0x0f (far beyond it needed), and will prevent us from putting them on bus 0. Typical values for c51/mcp55 or c51/mcp51: HT_CHAIN_UNITID_BASE = 0x10 # for C51 HT_CHAIN_END_UNITID_BASE = 0 # for mcp If only have mcp with c51, HT_CHAIN_UNITID_BASE = 0 # for MCP #HT_CHAIN_END_UNITID_BASE = 0 # default value 0x20 Signed-off-by: Yinghai Lu -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Lu, Yinghai Sent: Thursday, January 18, 2007 9:06 PM To: Ronald G Minnich; Eric W. Biederman Cc: linuxbios at linuxbios.org Subject: [LinuxBIOS] MCP55 LinuxBIOS with USB debug etc. Please check the MCP55 support with usbdebug. MB included: Nvidia l1_2pvv Gigabyte m57sli Supermicro h8dmr Tyan s2912 --- with HTX Signed-off-by: Yinghai Lu -------------- next part -------------- A non-text attachment was scrubbed... Name: fb2_01232007.diff Type: application/octet-stream Size: 18722 bytes Desc: fb2_01232007.diff URL: From vladc6 at yahoo.com Wed Jan 24 06:09:51 2007 From: vladc6 at yahoo.com (Vlad C.) Date: Tue, 23 Jan 2007 21:09:51 -0800 (PST) Subject: [LinuxBIOS] State of cheap motherboard support In-Reply-To: <20c6f18e0701231136p1549c0bfq78ad235935fa2a77@mail.gmail.com> Message-ID: <319962.99614.qm@web54403.mail.yahoo.com> --- Marcelo Coelho wrote: > I'm thinking in buying an Asus M2NPV-VM, which uses the Chipset > NVIDIA > GeForce 6150 + nForce 430. I may be mistaken, but I think mcp55 corresponds to the nForce 500 series (590, 570, 550, 520). Given that the nForce 430 motherboard you had in mind is already one generation old, it might not be the most appealing for active development. You can find a non-exhaustive list of other candidate desktop motherboards on the following wiki page: http://linuxbios.org/Desktops Vlad ____________________________________________________________________________________ Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=list&sid=396546091 From tylerapohl at gmail.com Wed Jan 24 07:16:06 2007 From: tylerapohl at gmail.com (Tyler Pohl) Date: Tue, 23 Jan 2007 22:16:06 -0800 Subject: [LinuxBIOS] schematics Message-ID: <503ab0210701232216u5c482ecfw1d0323aa9b92a691@mail.gmail.com> Does VIA give out there schematics for the epia series boards? If so could someone please send them to me. Thank You Tyler Pohl -------------- next part -------------- An HTML attachment was scrubbed... URL: From svn at openbios.org Wed Jan 24 12:09:04 2007 From: svn at openbios.org (svn at openbios.org) Date: Wed, 24 Jan 2007 11:09:04 -0000 Subject: [LinuxBIOS] r2538 - trunk/LinuxBIOSv2/util/flashrom Message-ID: Author: uwe Date: 2007-01-24 12:09:03 +0100 (Wed, 24 Jan 2007) New Revision: 2538 Modified: trunk/LinuxBIOSv2/util/flashrom/flash_enable.c Log: Delete superfluous and incorrect comment (trivial). See also http://www.openbios.org/pipermail/linuxbios/2007-January/018042.html. Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Modified: trunk/LinuxBIOSv2/util/flashrom/flash_enable.c =================================================================== --- trunk/LinuxBIOSv2/util/flashrom/flash_enable.c 2007-01-22 20:21:17 UTC (rev 2537) +++ trunk/LinuxBIOSv2/util/flashrom/flash_enable.c 2007-01-24 11:09:03 UTC (rev 2538) @@ -472,7 +472,6 @@ {0x10de, 0x0260, "NVidia MCP51", enable_flash_ck804}, {0x10de, 0x0261, "NVidia MCP51", enable_flash_ck804}, - // {0x10de, 0x0261, "NVIDIA C51", enable_flash_ck804}, // YHLU {0x10de, 0x0262, "NVidia MCP51", enable_flash_ck804}, {0x10de, 0x0263, "NVidia MCP51", enable_flash_ck804}, From uwe at hermann-uwe.de Wed Jan 24 12:09:42 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Wed, 24 Jan 2007 12:09:42 +0100 Subject: [LinuxBIOS] [PATCH] flashrom: Support for MCP55 and SST49LFXXXC chips In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49073C7@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49073C7@ssvlexmb2.amd.com> Message-ID: <20070124110942.GB27275@greenwood> On Tue, Jan 23, 2007 at 04:54:38PM -0800, Lu, Yinghai wrote: > Yes > > -----Original Message----- > From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006 at gmx.net] > Sent: Tuesday, January 23, 2007 4:07 PM > To: Lu, Yinghai > Cc: Uwe Hermann; linuxbios at linuxbios.org > Subject: Re: [LinuxBIOS] [PATCH] flashrom: Support for MCP55 and > SST49LFXXXC chips > > Hello Yinghai, > > Lu, Yinghai wrote: > >> {0x10de, 0x0261, "NVidia MCP51", enable_flash_ck804}, > >> + // {0x10de, 0x0261, "NVIDIA C51", enable_flash_ck804}, // YHLU > > > > Flash is on mcp51 instead of c51. > > So we can safely delete this line? Fixed, thanks. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From marcelocoelho at gmail.com Wed Jan 24 12:17:52 2007 From: marcelocoelho at gmail.com (Marcelo Coelho) Date: Wed, 24 Jan 2007 11:17:52 +0000 Subject: [LinuxBIOS] State of cheap motherboard support In-Reply-To: <319962.99614.qm@web54403.mail.yahoo.com> References: <20c6f18e0701231136p1549c0bfq78ad235935fa2a77@mail.gmail.com> <319962.99614.qm@web54403.mail.yahoo.com> Message-ID: <20c6f18e0701240317s71162bf9hd18b6666c8c072aa@mail.gmail.com> > I may be mistaken, but I think mcp55 corresponds to the nForce 500 > series (590, 570, 550, 520). Given that the nForce 430 motherboard you > had in mind is already one generation old, it might not be the most > appealing for active development. I think so too. I'm searching for a micro-atx motherboard with onboard graphics. But i haven't found any that had the mcp55. The only ones that I've found were with the nForce 4X0. BTW, it looks like that sometimes LinuxBios also supports Via chipsets. I'm gonna try to search for those also. P.S.: The webpage is really good! Congrats! 2007/1/24, Vlad C. : > --- Marcelo Coelho wrote: > > I'm thinking in buying an Asus M2NPV-VM, which uses the Chipset > > NVIDIA > > GeForce 6150 + nForce 430. > > I may be mistaken, but I think mcp55 corresponds to the nForce 500 > series (590, 570, 550, 520). Given that the nForce 430 motherboard you > had in mind is already one generation old, it might not be the most > appealing for active development. > > You can find a non-exhaustive list of other candidate desktop > motherboards on the following wiki page: > > http://linuxbios.org/Desktops > > Vlad > > > > > ____________________________________________________________________________________ > Need Mail bonding? > Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. > http://answers.yahoo.com/dir/?link=list&sid=396546091 > From segher at kernel.crashing.org Wed Jan 24 15:09:13 2007 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Wed, 24 Jan 2007 15:09:13 +0100 Subject: [LinuxBIOS] schematics In-Reply-To: <503ab0210701232216u5c482ecfw1d0323aa9b92a691@mail.gmail.com> References: <503ab0210701232216u5c482ecfw1d0323aa9b92a691@mail.gmail.com> Message-ID: > Does VIA give out there schematics for the epia series boards? If > so could someone please send them to me. Better ask VIA, not us. Segher From segher at kernel.crashing.org Wed Jan 24 16:08:43 2007 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Wed, 24 Jan 2007 16:08:43 +0100 Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: <44A58276-374B-4677-B9F4-BCA37C4D208D@kernel.crashing.org> References: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> <7006B332-792C-4480-8409-7C11149BEAB5@kernel.crashing.org> <45B684A1.1080306@gmail.com> <44A58276-374B-4677-B9F4-BCA37C4D208D@kernel.crashing.org> Message-ID: >>> Does LinuxBIOS build with -ffreestanding? If you don't, that's >>> a bug for you too -- if you do, and that option does not disable >>> SSP, that's a GCC bug -- either a mainline GCC one, or one in >>> FC6, depending on how they enable it by default. >> >> We do not (at least as far as I can tell) > > Bug! Bug! ;-) > >> and I just tested and -ffreestanding did not help. > > I'll go see what the larger GCC community thinks about this -- > I'd say it's a bug. Well I'll go check tomorrow :-) The outcome is that -ffreestanding shouldn't disable SSP, as it can be useful for freestanding systems too -- they'll just have to provide the necessary library functions themselves. Segher From rminnich at gmail.com Wed Jan 24 16:54:59 2007 From: rminnich at gmail.com (ron minnich) Date: Wed, 24 Jan 2007 08:54:59 -0700 Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: <1655C02E-F994-4550-9681-666E23F1DA47@kernel.crashing.org> References: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> <45B6657D.2020805@gmail.com> <570F4056-68DA-4862-B39A-7B7EB0267956@kernel.crashing.org> <45B679F0.6010809@gmail.com> <1655C02E-F994-4550-9681-666E23F1DA47@kernel.crashing.org> Message-ID: <13426df10701240754i68152ebcs3aaa86624420fe44@mail.gmail.com> On 1/23/07, Segher Boessenkool wrote: > So you should just try it out somewhere in your build system -- > gcc -fno-stack-protector -S -xc - < /dev/null -o /dev/null or > something similar, grab the return code -- and that's all you need > to do. we'd always managed to avoid this kind of ugliness, but I guess we have no choice. What's going to get interesting is when the form that this test takes gets broken by the various distros :-) Some expert person want to try out a fix? If not, I guess I will. ron > From segher at kernel.crashing.org Wed Jan 24 17:10:27 2007 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Wed, 24 Jan 2007 17:10:27 +0100 Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: <13426df10701240754i68152ebcs3aaa86624420fe44@mail.gmail.com> References: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> <45B6657D.2020805@gmail.com> <570F4056-68DA-4862-B39A-7B7EB0267956@kernel.crashing.org> <45B679F0.6010809@gmail.com> <1655C02E-F994-4550-9681-666E23F1DA47@kernel.crashing.org> <13426df10701240754i68152ebcs3aaa86624420fe44@mail.gmail.com> Message-ID: >> So you should just try it out somewhere in your build system -- >> gcc -fno-stack-protector -S -xc - < /dev/null -o /dev/null or >> something similar, grab the return code -- and that's all you need >> to do. > > we'd always managed to avoid this kind of ugliness, but I guess we > have no choice. Indeed. This hurts many more projects btw, not just us. > What's going to get interesting is when the form that this test takes > gets broken by the various distros :-) The test isn't distro-specific; but I'm sure *some* distro (Gentoo? ;-) ) will break it. > Some expert person want to try out a fix? If not, I guess I will. With Kbuild it's really easy (just copy the one-liner from the Linux kernel code); but for v2, you'll need to do a little more work (but you can use the same mechanism, of course -- copy on of the cc-option macros and you're fine). Segher From hamish at prodigi.ch Thu Jan 25 00:56:28 2007 From: hamish at prodigi.ch (Hamish Guthrie) Date: Thu, 25 Jan 2007 00:56:28 +0100 Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: <13426df10701240754i68152ebcs3aaa86624420fe44@mail.gmail.com> References: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> <45B6657D.2020805@gmail.com> <570F4056-68DA-4862-B39A-7B7EB0267956@kernel.crashing.org> <45B679F0.6010809@gmail.com> <1655C02E-F994-4550-9681-666E23F1DA47@kernel.crashing.org> <13426df10701240754i68152ebcs3aaa86624420fe44@mail.gmail.com> Message-ID: <45B7F22C.9000706@prodigi.ch> Hi Guys, I still monitor a lot of what is going on on the LinuxBIOS list. I am now doing a lot of work on ARM and MIPS stuff, in which environments a cross-compilation is required ... well also, in most of my embedded x86 stuff I maintain I now also use a cross-compilation toolchain so that I can use uClibc. Maybe it would be an idea to create a very simple LinuxBIOS toolchain system where from a small SVN download, one can have a clean build environment using a pseudo cross-compile environment with a clean compiler per the 'latest' LinuxBIOS suggestion. I personally use either Buildroot or another really interesting environment called openwrt (which has a really neat build environment aimed at the low-cost broadcom chip-based router environment), but essentially with these environments, one does an SVN checkout which downloads a series of scripts and makefiles, and from that a make creates a completely new toolchain from the specified known sources. The really great thing about this is that one then has a KNOWN toolchain and all compiles are done with this KNOWN toolchain. Removes a whole lot of crap from the entire build environment, and, it generally works on ANY Linux platform - sure, there are some issues on OSX etc, but it does sure make a clean Linux build environment. This may be a resolution to the screwed toolchains supplied in certain distros. I personally stopped using ANY flavour of redhat about 5 years ago when they released 7.1 with totally screwed beta compilers, which just broke everything. Since then I have used SuSE and have mostly never looked back. I have never used any RH or Fedora distro since then, purely because I have no idea what they will incorporate in the next release. At least by using the core code, one has a bit of security in knowing what one is dealing with .... ever tried to tell RH that they introduced a bug in the compiler toolchain??? I think it would probably have fallen on deaf ears. I must also point out that since 7.1, RedHat have insisted on creating their own 'patched' versions of GCC which may work for them, but for generic sources, there are frequently issues. (Especially when cross-compiling). Just my tuppence! Hamish ron minnich wrote: > On 1/23/07, Segher Boessenkool wrote: > >> So you should just try it out somewhere in your build system -- >> gcc -fno-stack-protector -S -xc - < /dev/null -o /dev/null or >> something similar, grab the return code -- and that's all you need >> to do. > > we'd always managed to avoid this kind of ugliness, but I guess we > have no choice. > > What's going to get interesting is when the form that this test takes > gets broken by the various distros :-) > > Some expert person want to try out a fix? If not, I guess I will. > > ron > > From segher at kernel.crashing.org Thu Jan 25 01:39:13 2007 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Thu, 25 Jan 2007 01:39:13 +0100 Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: <45B7F22C.9000706@prodigi.ch> References: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> <45B6657D.2020805@gmail.com> <570F4056-68DA-4862-B39A-7B7EB0267956@kernel.crashing.org> <45B679F0.6010809@gmail.com> <1655C02E-F994-4550-9681-666E23F1DA47@kernel.crashing.org> <13426df10701240754i68152ebcs3aaa86624420fe44@mail.gmail.com> <45B7F22C.9000706@prodigi.ch> Message-ID: <58272BAE-1784-45F4-B4D0-24A71D896AB3@kernel.crashing.org> > Maybe it would be an idea to create a very simple LinuxBIOS > toolchain system where from a small SVN download, one can have a > clean build environment using a pseudo cross-compile environment > with a clean compiler per the 'latest' LinuxBIOS suggestion. Building a cross-compilation toolchain on a fast machine takes about 10 minutes, while building LinuxBIOS should take about 2 seconds. Also, you might *want* to use a "non-default" toolchain. > I personally use either Buildroot or another really interesting > environment called openwrt (which has a really neat build > environment aimed at the low-cost broadcom chip-based router > environment), but essentially with these environments, one does an > SVN checkout which downloads a series of scripts and makefiles, and > from that a make creates a completely new toolchain from the > specified known sources. You might want to check out Dan Kegel's excellent "crosstool". > The really great thing about this is that one then has a KNOWN > toolchain and all compiles are done with this KNOWN toolchain. > Removes a whole lot of crap from the entire build environment, and, > it generally works on ANY Linux platform - sure, there are some > issues on OSX etc, but it does sure make a clean Linux build > environment. I regularly build the Linux kernel on OSX -- all it takes are some fixes to Linux itself, none toolchain related -- and certainly no fixes to the toolchain itself. > This may be a resolution to the screwed toolchains supplied in > certain distros. That much is true, but it's a really heavy-handed solution. An option might be to include a script to build (and install) a toolchain as an optional preparation step for building LB. > I personally stopped using ANY flavour of redhat about 5 years ago > when they released 7.1 with totally screwed beta compilers, which > just broke everything. "2.96". Yeah I still feel the pain. > ever tried to tell RH that they introduced a bug in the compiler > toolchain??? I think it would probably have fallen on deaf ears. You should have tried though. Segher From hamish at prodigi.ch Thu Jan 25 01:59:27 2007 From: hamish at prodigi.ch (Hamish Guthrie) Date: Thu, 25 Jan 2007 01:59:27 +0100 Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: <58272BAE-1784-45F4-B4D0-24A71D896AB3@kernel.crashing.org> References: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> <45B6657D.2020805@gmail.com> <570F4056-68DA-4862-B39A-7B7EB0267956@kernel.crashing.org> <45B679F0.6010809@gmail.com> <1655C02E-F994-4550-9681-666E23F1DA47@kernel.crashing.org> <13426df10701240754i68152ebcs3aaa86624420fe44@mail.gmail.com> <45B7F22C.9000706@prodigi.ch> <58272BAE-1784-45F4-B4D0-24A71D896AB3@kernel.crashing.org> Message-ID: <45B800EF.6010109@prodigi.ch> Segher Boessenkool wrote: > Building a cross-compilation toolchain on a fast machine takes > about 10 minutes, while building LinuxBIOS should take about > 2 seconds. Sure, but it can also take weeks to figure out that your toolchain is actually at fault. > > Also, you might *want* to use a "non-default" toolchain. If you want to use a non-default toolchain, you should be in a position to decide how to deviate from the defaults, in which case, changing the toolchain build options should be really simple if you are at that level of expertise. > > You might want to check out Dan Kegel's excellent "crosstool". Have used that extensively, and found it to be very good under certain circumstances, however, targeting new platforms already catered for by Buildroot and openwrt, it makes no sense since the toolchains are already in place. > > I regularly build the Linux kernel on OSX -- all it takes are some > fixes to Linux itself, none toolchain related -- and certainly no > fixes to the toolchain itself. I am a newbie to OSX, so it is probably just growing pains! Nevertheless, I think OSX is really cool! > >> This may be a resolution to the screwed toolchains supplied in >> certain distros. > > That much is true, but it's a really heavy-handed solution. I think a solution nevertheless for people who are battling with broken toolchains - certainly this should not be a mandatory part of the build, but an option provided for those battling. > > An option might be to include a script to build (and install) > a toolchain as an optional preparation step for building LB. Totally agree. > >> ever tried to tell RH that they introduced a bug in the compiler >> toolchain??? I think it would probably have fallen on deaf ears. > > You should have tried though. I did frequently, and it fell on deaf ears - so much so that one of my corporate clients moved away from RH to SuSE. > > > Segher > > Hamish From segher at kernel.crashing.org Thu Jan 25 02:18:43 2007 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Thu, 25 Jan 2007 02:18:43 +0100 Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: <45B800EF.6010109@prodigi.ch> References: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> <45B6657D.2020805@gmail.com> <570F4056-68DA-4862-B39A-7B7EB0267956@kernel.crashing.org> <45B679F0.6010809@gmail.com> <1655C02E-F994-4550-9681-666E23F1DA47@kernel.crashing.org> <13426df10701240754i68152ebcs3aaa86624420fe44@mail.gmail.com> <45B7F22C.9000706@prodigi.ch> <58272BAE-1784-45F4-B4D0-24A71D896AB3@kernel.crashing.org> <45B800EF.6010109@prodigi.ch> Message-ID: <768C062B-C941-4711-8751-8C0D02468C25@kernel.crashing.org> >> Building a cross-compilation toolchain on a fast machine takes >> about 10 minutes, while building LinuxBIOS should take about >> 2 seconds. > Sure, but it can also take weeks to figure out that your toolchain > is actually at fault That's not my point -- it would be a huge regression (in compile time) to include a toolchain build into the LB default build. >> Also, you might *want* to use a "non-default" toolchain. > If you want to use a non-default toolchain, you should be in a > position to decide how to deviate from the defaults, in which case, > changing the toolchain build options should be really simple if you > are at that level of expertise. No, it's a lot easier to do if you don't have to deal with the mechanics of an automated toolchain build thing at the same time. >> You might want to check out Dan Kegel's excellent "crosstool". > Have used that extensively, and found it to be very good under > certain circumstances, however, targeting new platforms already > catered for by Buildroot and openwrt, it makes no sense since the > toolchains are already in place. Note though that both those systems *use* crosstool under the covers AFAIK. >> I regularly build the Linux kernel on OSX -- all it takes are some >> fixes to Linux itself, none toolchain related -- and certainly no >> fixes to the toolchain itself. > I am a newbie to OSX, so it is probably just growing pains! > Nevertheless, I think OSX is really cool! Heh. Try to build the Linux kernel on it. Hey, I think battle scars are really cool, too! :-) >>> This may be a resolution to the screwed toolchains supplied in >>> certain distros. >> That much is true, but it's a really heavy-handed solution. > I think a solution nevertheless for people who are battling with > broken toolchains - certainly this should not be a mandatory part > of the build, but an option provided for those battling. >> An option might be to include a script to build (and install) >> a toolchain as an optional preparation step for building LB. > Totally agree. The best option probably is to feature something about this really prominently really early in the build instructions. >>> ever tried to tell RH that they introduced a bug in the compiler >>> toolchain??? I think it would probably have fallen on deaf ears. >> You should have tried though. > I did frequently, and it fell on deaf ears - so much so that one of > my corporate clients moved away from RH to SuSE. You tried in their bugzilla? Wow. In the case at hand -- the SSP thing -- I certainly can see why they want to enable this stuff by default ("protecting their not-all-that-knowledgeable customers against stack overrun vulnerabilities"), but IMNSHO it's the wrong way to go about it, and that's without the consideration that SSP doesn't really help at all (except against total morons). Segher From corey_osgood at verizon.net Thu Jan 25 07:14:20 2007 From: corey_osgood at verizon.net (Corey Osgood) Date: Thu, 25 Jan 2007 01:14:20 -0500 Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: <768C062B-C941-4711-8751-8C0D02468C25@kernel.crashing.org> References: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> <45B6657D.2020805@gmail.com> <570F4056-68DA-4862-B39A-7B7EB0267956@kernel.crashing.org> <45B679F0.6010809@gmail.com> <1655C02E-F994-4550-9681-666E23F1DA47@kernel.crashing.org> <13426df10701240754i68152ebcs3aaa86624420fe44@mail.gmail.com> <45B7F22C.9000706@prodigi.ch> <58272BAE-1784-45F4-B4D0-24A71D896AB3@kernel.crashing.org> <45B800EF.6010109@prodigi.ch> <768C062B-C941-4711-8751-8C0D02468C25@kernel.crashing.org> Message-ID: <45B84ABC.9000203@verizon.net> Segher Boessenkool wrote: >>> Building a cross-compilation toolchain on a fast machine takes >>> about 10 minutes, while building LinuxBIOS should take about >>> 2 seconds. >>> > > >> Sure, but it can also take weeks to figure out that your toolchain >> is actually at fault >> Or a 30-second post to the mailing list, or to search the archives. Perhaps we should add this to the wiki as a known issue? I completely agree (and yes, I'm sure I agree this time). The machine I usually build on is a 1ghz P3, and LB takes long enough to build as it is (a couple minutes, usually), I don't really care for it to be any longer, especially if I'm just randomly poking around to see if I get things to work. Could we perhaps parse the output of "gcc -v" before compiling, looking for "ubuntu" or "fedora" (or whatever those fedora guys add onto the version name)? Then offer a warning that the compiler may be broken with respect to linuxbios. BTW, if you still want/need it, here's the error log compiled under Ubuntu 6.10 x64, with ubuntu's gcc 4.1.2: gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T /home/amp/LinuxBIOSv2/src/config/linuxbios_ram.ld linuxbios_ram.o linuxbios_ram.o: In function `number': vtxprintf.c:(.text+0x547e): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `report_resource_stored': (.text+0x66e6): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `init_processor_name': (.text+0x77fe): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `amdk8_set_resources': northbridge.c:(.text+0xa965): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `cpu_initialize': (.text+0x14c3b): undefined reference to `__stack_chk_fail' collect2: ld returned 1 exit status make[1]: *** [linuxbios_ram] Error 1 make[1]: Leaving directory `/home/amp/LinuxBIOSv2/targets/tyan/s2892/s2892/normal' with 3.3.6, also from the repos, it's a bit different: gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T /home/amp/LinuxBIOSv2/src/config/linuxbios_ram.ld linuxbios_ram.o linuxbios_ram.o: In function `idiv_long': (.text+0x11cb7): undefined reference to `__divdi3' linuxbios_ram.o: In function `idiv_long': (.text+0x11ccd): undefined reference to `__moddi3' linuxbios_ram.o: In function `div_long': (.text+0x11e1c): undefined reference to `__udivdi3' linuxbios_ram.o: In function `div_long': (.text+0x11e32): undefined reference to `__umoddi3' collect2: ld returned 1 exit status I don't know if 64 bit could be causing any additional errors, but this seems very similar to what I get on my 32-bit laptop. -Corey From c.jones at f5.com Thu Jan 25 19:10:23 2007 From: c.jones at f5.com (Clay Jones) Date: Thu, 25 Jan 2007 10:10:23 -0800 Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: <45B84ABC.9000203@verizon.net> References: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com><45B6657D.2020805@gmail.com><570F4056-68DA-4862-B39A-7B7EB0267956@kernel.crashing.org><45B679F0.6010809@gmail.com><1655C02E-F994-4550-9681-666E23F1DA47@kernel.crashing.org><13426df10701240754i68152ebcs3aaa86624420fe44@mail.gmail.com><45B7F22C.9000706@prodigi.ch><58272BAE-1784-45F4-B4D0-24A71D896AB3@kernel.crashing.org><45B800EF.6010109@prodigi.ch><768C062B-C941-4711-8751-8C0D02468C25@kernel.crashing.org> <45B84ABC.9000203@verizon.net> Message-ID: <4E497EE4DD5F9347B242A83387F27DC801167AE7@exchsix.olympus.f5net.com> The toolchain would only build once, not every time linuxbios is rebuilt. -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Corey Osgood Sent: Wednesday, January 24, 2007 10:14 PM To: Segher Boessenkool Cc: Hamish Guthrie; ron minnich; LinuxBIOS Subject: Re: [LinuxBIOS] help from ubuntu and FC6 experts Segher Boessenkool wrote: >>> Building a cross-compilation toolchain on a fast machine takes >>> about 10 minutes, while building LinuxBIOS should take about >>> 2 seconds. >>> > > >> Sure, but it can also take weeks to figure out that your toolchain >> is actually at fault >> Or a 30-second post to the mailing list, or to search the archives. Perhaps we should add this to the wiki as a known issue? I completely agree (and yes, I'm sure I agree this time). The machine I usually build on is a 1ghz P3, and LB takes long enough to build as it is (a couple minutes, usually), I don't really care for it to be any longer, especially if I'm just randomly poking around to see if I get things to work. Could we perhaps parse the output of "gcc -v" before compiling, looking for "ubuntu" or "fedora" (or whatever those fedora guys add onto the version name)? Then offer a warning that the compiler may be broken with respect to linuxbios. BTW, if you still want/need it, here's the error log compiled under Ubuntu 6.10 x64, with ubuntu's gcc 4.1.2: gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T /home/amp/LinuxBIOSv2/src/config/linuxbios_ram.ld linuxbios_ram.o linuxbios_ram.o: In function `number': vtxprintf.c:(.text+0x547e): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `report_resource_stored': (.text+0x66e6): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `init_processor_name': (.text+0x77fe): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `amdk8_set_resources': northbridge.c:(.text+0xa965): undefined reference to `__stack_chk_fail' linuxbios_ram.o: In function `cpu_initialize': (.text+0x14c3b): undefined reference to `__stack_chk_fail' collect2: ld returned 1 exit status make[1]: *** [linuxbios_ram] Error 1 make[1]: Leaving directory `/home/amp/LinuxBIOSv2/targets/tyan/s2892/s2892/normal' with 3.3.6, also from the repos, it's a bit different: gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T /home/amp/LinuxBIOSv2/src/config/linuxbios_ram.ld linuxbios_ram.o linuxbios_ram.o: In function `idiv_long': (.text+0x11cb7): undefined reference to `__divdi3' linuxbios_ram.o: In function `idiv_long': (.text+0x11ccd): undefined reference to `__moddi3' linuxbios_ram.o: In function `div_long': (.text+0x11e1c): undefined reference to `__udivdi3' linuxbios_ram.o: In function `div_long': (.text+0x11e32): undefined reference to `__umoddi3' collect2: ld returned 1 exit status I don't know if 64 bit could be causing any additional errors, but this seems very similar to what I get on my 32-bit laptop. -Corey -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios From rminnich at gmail.com Thu Jan 25 19:23:14 2007 From: rminnich at gmail.com (ron minnich) Date: Thu, 25 Jan 2007 11:23:14 -0700 Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: <45B84ABC.9000203@verizon.net> References: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> <570F4056-68DA-4862-B39A-7B7EB0267956@kernel.crashing.org> <45B679F0.6010809@gmail.com> <1655C02E-F994-4550-9681-666E23F1DA47@kernel.crashing.org> <13426df10701240754i68152ebcs3aaa86624420fe44@mail.gmail.com> <45B7F22C.9000706@prodigi.ch> <58272BAE-1784-45F4-B4D0-24A71D896AB3@kernel.crashing.org> <45B800EF.6010109@prodigi.ch> <768C062B-C941-4711-8751-8C0D02468C25@kernel.crashing.org> <45B84ABC.9000203@verizon.net> Message-ID: <13426df10701251023k5780e1deue4cbb528fd905e24@mail.gmail.com> bear in mind that many people, given a linuxbios that would not build on system x.y.z, assumed the problem was linuxbios -- even when it was not. In fact, it has rarely been linuxbios, but has in fact been a particular distro or toolchain. How do you answer the following: "I can build a kernel on this distro just fine, why can't I build linuxbios"? I think it would be nice if somebody could show us the -fturn-off-this-switch approach and how to put it into the linuxbios build process, and detect that on whatever gcc we're using the turn-off-this-switch does not exist, but can be automagically worked around. But I would also be extremely grateful to anyone who can show us how to set up linuxbios with the 'use this toolchain' as an option. I think, given the number of distros and the strange ways they are breaking our build process, we have to have this option available to users. thanks ron From russ at ashlandhome.net Thu Jan 25 19:32:41 2007 From: russ at ashlandhome.net (Russ Whitaker) Date: Thu, 25 Jan 2007 10:32:41 -0800 (PST) Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: <45B84ABC.9000203@verizon.net> References: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> <45B6657D.2020805@gmail.com> <570F4056-68DA-4862-B39A-7B7EB0267956@kernel.crashing.org> <45B679F0.6010809@gmail.com> <1655C02E-F994-4550-9681-666E23F1DA47@kernel.crashing.org> <13426df10701240754i68152ebcs3aaa86624420fe44@mail.gmail.com> <45B7F22C.9000706@prodigi.ch> <58272BAE-1784-45F4-B4D0-24A71D896AB3@kernel.crashing.org> <45B800EF.6010109@prodigi.ch> <768C062B-C941-4711-8751-8C0D02468C25@kernel.crashing.org> <45B84ABC.9000203@verizon.net> Message-ID: On Thu, 25 Jan 2007, Corey Osgood wrote: [..] > > BTW, if you still want/need it, here's the error log compiled under > Ubuntu 6.10 x64, with ubuntu's gcc 4.1.2: > According to the gcc home page gcc-4.1.2 will be released any day now. Russ From segher at kernel.crashing.org Thu Jan 25 20:01:24 2007 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Thu, 25 Jan 2007 20:01:24 +0100 Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: <45B84ABC.9000203@verizon.net> References: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> <45B6657D.2020805@gmail.com> <570F4056-68DA-4862-B39A-7B7EB0267956@kernel.crashing.org> <45B679F0.6010809@gmail.com> <1655C02E-F994-4550-9681-666E23F1DA47@kernel.crashing.org> <13426df10701240754i68152ebcs3aaa86624420fe44@mail.gmail.com> <45B7F22C.9000706@prodigi.ch> <58272BAE-1784-45F4-B4D0-24A71D896AB3@kernel.crashing.org> <45B800EF.6010109@prodigi.ch> <768C062B-C941-4711-8751-8C0D02468C25@kernel.crashing.org> <45B84ABC.9000203@verizon.net> Message-ID: > Could we perhaps parse the output of "gcc -v" before compiling, > looking for "ubuntu" or "fedora" (or whatever those fedora guys add > onto the version name)? Then offer a warning that the compiler may > be broken with respect to linuxbios. It's just as easy to add the -fno-stack-protector flag if the compiler supports it. > gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T /home/ > amp/LinuxBIOSv2/src/config/linuxbios_ram.ld linuxbios_ram.o > linuxbios_ram.o: In function `number': > vtxprintf.c:(.text+0x547e): undefined reference to `__stack_chk_fail' > linuxbios_ram.o: In function `report_resource_stored': > (.text+0x66e6): undefined reference to `__stack_chk_fail' > linuxbios_ram.o: In function `init_processor_name': > (.text+0x77fe): undefined reference to `__stack_chk_fail' > linuxbios_ram.o: In function `amdk8_set_resources': > northbridge.c:(.text+0xa965): undefined reference to > `__stack_chk_fail' > linuxbios_ram.o: In function `cpu_initialize': > (.text+0x14c3b): undefined reference to `__stack_chk_fail' > collect2: ld returned 1 exit status > make[1]: *** [linuxbios_ram] Error 1 > make[1]: Leaving directory `/home/amp/LinuxBIOSv2/targets/tyan/ > s2892/s2892/normal' That's the failure at hand yes. > with 3.3.6, also from the repos, it's a bit different: > gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T /home/ > amp/LinuxBIOSv2/src/config/linuxbios_ram.ld linuxbios_ram.o > linuxbios_ram.o: In function `idiv_long': > (.text+0x11cb7): undefined reference to `__divdi3' > linuxbios_ram.o: In function `idiv_long': > (.text+0x11ccd): undefined reference to `__moddi3' > linuxbios_ram.o: In function `div_long': > (.text+0x11e1c): undefined reference to `__udivdi3' > linuxbios_ram.o: In function `div_long': > (.text+0x11e32): undefined reference to `__umoddi3' > collect2: ld returned 1 exit status That's different, [i]div_long is asking for a 64-bit division, which isn't a native instruction but implemented by the GCC support lib (libgcc), and you're explicitly building without it. Segher From corey_osgood at verizon.net Thu Jan 25 21:40:07 2007 From: corey_osgood at verizon.net (Corey Osgood) Date: Thu, 25 Jan 2007 15:40:07 -0500 Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: References: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> <45B6657D.2020805@gmail.com> <570F4056-68DA-4862-B39A-7B7EB0267956@kernel.crashing.org> <45B679F0.6010809@gmail.com> <1655C02E-F994-4550-9681-666E23F1DA47@kernel.crashing.org> <13426df10701240754i68152ebcs3aaa86624420fe44@mail.gmail.com> <45B7F22C.9000706@prodigi.ch> <58272BAE-1784-45F4-B4D0-24A71D896AB3@kernel.crashing.org> <45B800EF.6010109@prodigi.ch> <768C062B-C941-4711-8751-8C0D02468C25@kernel.crashing.org> <45B84ABC.9000203@verizon.net> Message-ID: <45B915A7.2010906@verizon.net> Russ Whitaker wrote: > On Thu, 25 Jan 2007, Corey Osgood wrote: > [..] > >> BTW, if you still want/need it, here's the error log compiled under >> Ubuntu 6.10 x64, with ubuntu's gcc 4.1.2: >> >> > According to the gcc home page gcc-4.1.2 will be released any day now. > > Russ It's a prerelease, but I guess officially it would still be 4.1.1: $ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release x86_64-linux-gnu Thread model: posix gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) > Segher Boessenkool wrote: >>> gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T >>> /home/amp/LinuxBIOSv2/src/config/linuxbios_ram.ld linuxbios_ram.o >>> linuxbios_ram.o: In function `idiv_long': >>> (.text+0x11cb7): undefined reference to `__divdi3' >>> linuxbios_ram.o: In function `idiv_long': >>> (.text+0x11ccd): undefined reference to `__moddi3' >>> linuxbios_ram.o: In function `div_long': >>> (.text+0x11e1c): undefined reference to `__udivdi3' >>> linuxbios_ram.o: In function `div_long': >>> (.text+0x11e32): undefined reference to `__umoddi3' >>> collect2: ld returned 1 exit status >> with 3.3.6, also from the repos, it's a bit different: >> >> That's different, [i]div_long is asking for a 64-bit division, >> which isn't a native instruction but implemented by the GCC >> support lib (libgcc), and you're explicitly building without >> it. I've done nothing different than with any other build, except change the symlinks in /usr/bin to point to gcc-3.3, etc (ubuntu doesn't have any gcc-config style setup for easy changing of gcc versions). It could be I just missed something, but I didn't pass any extra options to make. -Corey P.S. Sorry for the gross mis-quote in my previous post From uwe at hermann-uwe.de Thu Jan 25 23:13:50 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 25 Jan 2007 23:13:50 +0100 Subject: [LinuxBIOS] [PATCH] Support for Winbond W83627EHG Super I/O Message-ID: <20070125221350.GA16656@greenwood> Add support for the Winbond W83627EHG Super I/O. Signed-off-by: Yinghai Lu Signed-off-by: Uwe Hermann --- This is from Yinghai's huge patch. I added missing license headers (Yinghai please complain if any of them is incorrect!), fixed some coding style issues and added a few comments. The code is untested by me (didn't even test whether it builds)! Anybody wants to test this? Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: w83627ehg.patch Type: text/x-diff Size: 13641 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From yinghai.lu at amd.com Thu Jan 25 23:25:46 2007 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Thu, 25 Jan 2007 14:25:46 -0800 Subject: [LinuxBIOS] [PATCH] Support for Winbond W83627EHG Super I/O Message-ID: <5986589C150B2F49A46483AC44C7BCA49073E6@ssvlexmb2.amd.com> Thanks. -----Original Message----- From: linuxbios-bounces+yinghai.lu=amd.com at linuxbios.org [mailto:linuxbios-bounces+yinghai.lu=amd.com at linuxbios.org] On Behalf Of Uwe Hermann Sent: Thursday, January 25, 2007 2:14 PM To: linuxbios at linuxbios.org Subject: [LinuxBIOS] [PATCH] Support for Winbond W83627EHG Super I/O Add support for the Winbond W83627EHG Super I/O. Signed-off-by: Yinghai Lu Signed-off-by: Uwe Hermann --- This is from Yinghai's huge patch. I added missing license headers (Yinghai please complain if any of them is incorrect!), fixed some coding style issues and added a few comments. The code is untested by me (didn't even test whether it builds)! Anybody wants to test this? Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org From uwe at hermann-uwe.de Thu Jan 25 23:35:54 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 25 Jan 2007 23:35:54 +0100 Subject: [LinuxBIOS] Netvista 2200 8363 In-Reply-To: <20070123143209.GA8370@debian.lan> References: <20070123143209.GA8370@debian.lan> Message-ID: <20070125223554.GA18795@greenwood> Hi, this topic came up before, please check http://www.openbios.org/pipermail/linuxbios/2004-August/008654.html On Tue, Jan 23, 2007 at 09:32:09AM -0500, ralph bacolod wrote: > I notice that it has a socket chip with "ns" plus numbers in it..It > looks like this can be replaced.. Looking at http://jeanchristophe.duber.free.fr/netvista_8363/netvista8363-firmware.jpg suggests that it's soldered on, so you cannot easily replace it. Apparently there are two BIOSes on this thing? Not sure. A bigger image: http://www.bluetrait.com/images/folders/ibm-thin-client-8363/source/IMG_0811.JPG Can you post the 'lspci' and 'lspci -n' output here? 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 uwe at hermann-uwe.de Thu Jan 25 23:38:38 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 25 Jan 2007 23:38:38 +0100 Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: References: <570F4056-68DA-4862-B39A-7B7EB0267956@kernel.crashing.org> <45B679F0.6010809@gmail.com> <1655C02E-F994-4550-9681-666E23F1DA47@kernel.crashing.org> <13426df10701240754i68152ebcs3aaa86624420fe44@mail.gmail.com> <45B7F22C.9000706@prodigi.ch> <58272BAE-1784-45F4-B4D0-24A71D896AB3@kernel.crashing.org> <45B800EF.6010109@prodigi.ch> <768C062B-C941-4711-8751-8C0D02468C25@kernel.crashing.org> <45B84ABC.9000203@verizon.net> Message-ID: <20070125223838.GB18795@greenwood> Hi, On Thu, Jan 25, 2007 at 08:01:24PM +0100, Segher Boessenkool wrote: > > Could we perhaps parse the output of "gcc -v" before compiling, > > looking for "ubuntu" or "fedora" (or whatever those fedora guys add > > onto the version name)? Then offer a warning that the compiler may > > be broken with respect to linuxbios. > > It's just as easy to add the -fno-stack-protector flag if the > compiler supports it. Yes. Checking for "Fedora" or "Ubuntu" is the wrong approach. We should check whether the compiler actually supports feature xyz, not whether we're on a certain platform. 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 Jan 25 23:42:22 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 25 Jan 2007 23:42:22 +0100 Subject: [LinuxBIOS] ati support In-Reply-To: <45B45F35.5050709@verizon.net> References: <45B3CA8C.7030707@gmail.com> <45B45F35.5050709@verizon.net> Message-ID: <20070125224222.GC18795@greenwood> Hi, On Mon, Jan 22, 2007 at 01:52:37AM -0500, Corey Osgood wrote: > Jory A. Pratt wrote: > > I am gonna undertake the task of writting support for the ati chipset :) Great to hear! Please keep us updated if you manage to get some documentation from ATI, or some working code from guesswork or reverse engineering or whatever... Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From svn at openbios.org Thu Jan 25 23:45:56 2007 From: svn at openbios.org (LinuxBIOS) Date: Thu, 25 Jan 2007 22:45:56 -0000 Subject: [LinuxBIOS] #73: Merge NVIDIA MCP55 and CK804 code? Message-ID: <060.cda2dd58f4f4518c6b45b30484c4f48c@openbios.org> #73: Merge NVIDIA MCP55 and CK804 code? ---------------------------------+------------------------------------------ Reporter: uwe | Owner: somebody Type: task | Status: new Priority: major | Milestone: Component: code | Version: v2 Keywords: | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ We should consider merging the NVIDIA MCP55 and CK804 code at some point as it's pretty similar. See also http://www.openbios.org/pipermail/linuxbios/2007-January/018014.html -- Ticket URL: LinuxBIOS From uwe at hermann-uwe.de Thu Jan 25 23:46:44 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 25 Jan 2007 23:46:44 +0100 Subject: [LinuxBIOS] MCP55 LinuxBIOS with USB debug etc. part 1 In-Reply-To: References: <5986589C150B2F49A46483AC44C7BCA49073B0@ssvlexmb2.amd.com> <20070120160615.GA12416@greenwood> Message-ID: <20070125224643.GD18795@greenwood> Hi, On Mon, Jan 22, 2007 at 10:38:37AM -0800, Ed Swierk wrote: > This issue is probably not important enough to block committing the > code if it's otherwise okay. Maybe the best thing would be just to > open a tracker issue for this, [...] Done: http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/73 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 Jan 25 23:54:09 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 25 Jan 2007 23:54:09 +0100 Subject: [LinuxBIOS] What to implement "system recovery" features in bios In-Reply-To: <13a536940701200733r5912d8fbx16878515e7e8071f@mail.gmail.com> References: <13a536940701200651q6c95340fsd7df8064e6abe9c9@mail.gmail.com> <13a536940701200733r5912d8fbx16878515e7e8071f@mail.gmail.com> Message-ID: <20070125225409.GE18795@greenwood> Hi, On Sat, Jan 20, 2007 at 11:33:12PM +0800, li pan wrote: > Thanks for your suggestions! They are really helpful > I still have some more detail questions, > --------- > 1 Is linuxbios a "real" linux? > I mean can a normal linux app run on it? > We want the user to use this app to recovery a faild pc, so we need > the app in BIOS, not harddisk Depends. LinuxBIOS is (despite the name) not the same as Linux. It's some tiny initialization code, which then "boots" a payload, which can be almost anything, e.g. a Linux real kernel or FILO or whatever. See http://linuxbios.org/. It _is_ possible to run small (special) applications purely from the BIOS (no harddrive) I guess, as long as it doesn't need any resources which are not in the BIOS or not accessible at the time the BIOS runs... FILO is one "application" which does just that. > 2 I am still not sure about the linuxbios/awardbios coexistence stuff. > Al mentioned DualBIOS, but as long as I know, that means mainborad > holds 2 biso chips, and if one fails, mainboard will use the other. (Correct me > if I am wrong, I don't know much about this) > But I need the award bios be used in normal case, and if the user hit some key > while booting, the computer will switch to linuxbios, which will load > the backup/recovery appliaction. I think the IBM app works this way. Not sure you can do that, you'd have to modify the AWARD BIOS to react on the keypress and then jump into LinuxBIOS, right? You don't have the AWARD BIOS source code, so... You can just physically swap the BIOS chip (if it's socketed) or build a solution so that the mainboard holds two BIOS chips and you can switch between them physically (a small switch or so) while the computer is turned off. I'm just guessing though, I've never done something like this... Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From tylerapohl at gmail.com Fri Jan 26 01:23:12 2007 From: tylerapohl at gmail.com (Tyler Pohl) Date: Thu, 25 Jan 2007 16:23:12 -0800 Subject: [LinuxBIOS] help from ubuntu and FC6 experts Message-ID: <503ab0210701251623t508ef395v39af2a85bb95dc8a@mail.gmail.com> I have a stand alone development machine that runs LFS (linux from scratch) It is by far the best way to go when developing code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Fri Jan 26 04:03:40 2007 From: rminnich at gmail.com (ron minnich) Date: Thu, 25 Jan 2007 20:03:40 -0700 Subject: [LinuxBIOS] MCP55 LinuxBIOS with USB debug etc. part 1 In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49073AD@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49073AD@ssvlexmb2.amd.com> Message-ID: <13426df10701251903jfe34775uc44da312be28b8e2@mail.gmail.com> On 1/19/07, Lu, Yinghai wrote: > > > -----Original Message----- > From: Lu, Yinghai > Sent: Thursday, January 18, 2007 9:06 PM > To: 'Ronald G Minnich'; Eric W. Biederman > Cc: linuxbios at linuxbios.org > Subject: MCP55 LinuxBIOS with USB debug etc. > > Please check the MCP55 support with usbdebug. > > MB included: > Nvidia l1_2pvv > Gigabyte m57sli > Supermicro h8dmr > Tyan s2912 --- with HTX > > Signed-off-by: Yinghai Lu OK, this is a big patch which I guess we're digesting in pieces. I note that Uwe has got a good start. Can anyone tell me where we are with this? thanks ron From yinghai.lu at amd.com Fri Jan 26 04:08:16 2007 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Thu, 25 Jan 2007 19:08:16 -0800 Subject: [LinuxBIOS] MCP55 LinuxBIOS with USB debug etc. part 1 Message-ID: <5986589C150B2F49A46483AC44C7BCA49073E7@ssvlexmb2.amd.com> Uwe put the 1. flashrom changes with mcp55 support 2. superio winbond 83627ehg Left: 1. src/southbridge/nvidia/mcp55 -- all 2. src/superio/it*. 3. other usbdebug in console, lib.... 4. early_ht.c, incoherent_ht.c, northbridge.c in amdk8 5. hyperstransport.c in src/devices. 6. src/mainboard, targets YH -----Original Message----- From: ron minnich [mailto:rminnich at gmail.com] Sent: Thursday, January 25, 2007 7:04 PM To: Lu, Yinghai Cc: linuxbios at linuxbios.org Subject: Re: [LinuxBIOS] MCP55 LinuxBIOS with USB debug etc. part 1 On 1/19/07, Lu, Yinghai wrote: > > > -----Original Message----- > From: Lu, Yinghai > Sent: Thursday, January 18, 2007 9:06 PM > To: 'Ronald G Minnich'; Eric W. Biederman > Cc: linuxbios at linuxbios.org > Subject: MCP55 LinuxBIOS with USB debug etc. > > Please check the MCP55 support with usbdebug. > > MB included: > Nvidia l1_2pvv > Gigabyte m57sli > Supermicro h8dmr > Tyan s2912 --- with HTX > > Signed-off-by: Yinghai Lu OK, this is a big patch which I guess we're digesting in pieces. I note that Uwe has got a good start. Can anyone tell me where we are with this? thanks ron From rminnich at gmail.com Fri Jan 26 18:42:43 2007 From: rminnich at gmail.com (ron minnich) Date: Fri, 26 Jan 2007 10:42:43 -0700 Subject: [LinuxBIOS] patch. yhlu new targes and some msm800sev mods from me Message-ID: <13426df10701260942y33afa65cw30edfeae2485d688@mail.gmail.com> I am doing this in pieces as yh lu has provided us with lots and lots of source :-) ron -------------- next part -------------- A non-text attachment was scrubbed... Name: yhlupatch1 Type: application/octet-stream Size: 30891 bytes Desc: not available URL: From acassis at gmail.com Fri Jan 26 19:45:34 2007 From: acassis at gmail.com (Alan Carvalho de Assis) Date: Fri, 26 Jan 2007 18:45:34 +0000 Subject: [LinuxBIOS] sst49lf160c support (patch) Message-ID: <37367b3a0701261045u40a476aav64ddc5ee8196d242@mail.gmail.com> Hi guys, I using SST49LF160C on Tyan S2850, and all is running fine. Then I sending a small patch to add support to it. I do a funny test, wrote my legacy BIOS (512KB) on SST49LF160C (2MB): dd if=/dev/zero of=head bs=1 count=1572864 cat bios.bin >> head ./flashrom -w head wow, it works :-) Cheers, -- ------------------------------------------------------------ | Alan Carvalho de Assis | ------------------------------------------------------------ -- N?o importa o que os outros ir?o pensar, A cura para a infelicidade ? a felicidade -------------- next part -------------- A non-text attachment was scrubbed... Name: sst49lf160c.patch Type: text/x-patch Size: 1351 bytes Desc: not available URL: From c-d.hailfinger.devel.2006 at gmx.net Fri Jan 26 23:28:05 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 26 Jan 2007 23:28:05 +0100 Subject: [LinuxBIOS] patch. yhlu new targes and some msm800sev mods from me In-Reply-To: <13426df10701260942y33afa65cw30edfeae2485d688@mail.gmail.com> References: <13426df10701260942y33afa65cw30edfeae2485d688@mail.gmail.com> Message-ID: <45BA8075.7020202@gmx.net> Hi Ron, ron minnich wrote: > I am doing this in pieces as yh lu has provided us with lots and lots > of source :-) Could you separate the two changes? One patch for msm800sev (first), one for yhlu's stuff (second)? Just to keep unrelated changes separate and to ensure that the tree will pass abuild at least after the first patch. I would add yhlu's new targets *after* adding his mcp55 support because that way we will never break abuild for the whole tree. Regards, Carl-Daniel -- http://www.hailfinger.org/ From rminnich at gmail.com Sat Jan 27 00:00:38 2007 From: rminnich at gmail.com (ron minnich) Date: Fri, 26 Jan 2007 16:00:38 -0700 Subject: [LinuxBIOS] patch. yhlu new targes and some msm800sev mods from me In-Reply-To: <45BA8075.7020202@gmx.net> References: <13426df10701260942y33afa65cw30edfeae2485d688@mail.gmail.com> <45BA8075.7020202@gmx.net> Message-ID: <13426df10701261500v3113da0t5226ca5e0898dae6@mail.gmail.com> On 1/26/07, Carl-Daniel Hailfinger wrote: > I would add yhlu's new targets *after* adding his mcp55 support because > that way we will never break abuild for the whole tree. you're right, I just got overwhelmed by it all. mcp55 patch attached. ron -------------- next part -------------- A non-text attachment was scrubbed... Name: mcp55diff Type: application/octet-stream Size: 79225 bytes Desc: not available URL: From uwe at hermann-uwe.de Sat Jan 27 02:38:32 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 27 Jan 2007 02:38:32 +0100 Subject: [LinuxBIOS] sst49lf160c support (patch) In-Reply-To: <37367b3a0701261045u40a476aav64ddc5ee8196d242@mail.gmail.com> References: <37367b3a0701261045u40a476aav64ddc5ee8196d242@mail.gmail.com> Message-ID: <20070127013832.GA16781@greenwood> Hi, On Fri, Jan 26, 2007 at 06:45:34PM +0000, Alan Carvalho de Assis wrote: > I using SST49LF160C on Tyan S2850, and all is running fine. > > Then I sending a small patch to add support to it. Please add a proper sign-off to your patch/mail, see http://linuxbios.org/Development_Guidelines#Sign-off_Procedure Also, please update the flashrom README with the new chip. Otherwise the patch looks fine. Cheers, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From c-d.hailfinger.devel.2006 at gmx.net Sat Jan 27 03:25:25 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 27 Jan 2007 03:25:25 +0100 Subject: [LinuxBIOS] [PATCH] cleaned up MCP55 chipset code Message-ID: <45BAB815.1080700@gmx.net> Hi Ron, the attached patch is a rework of the patch you posted earlier. Basically, I cleaned up the mixed tab/spaces indentation and tried to make the layout more consistent. Regards, Carl-Daniel -- http://www.hailfinger.org/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: linuxbios_mcp55.diff URL: From pquinton at softhome.net Sat Jan 27 10:31:00 2007 From: pquinton at softhome.net (Phil Quinton) Date: Sat, 27 Jan 2007 09:31:00 -0000 (GMT) Subject: [LinuxBIOS] Gigabyte GA-6BXD Dual PIII (i440BX) Message-ID: <52885.87.194.114.251.1169890260.squirrel@pro.SoftHome.net> Hi, I'm a newbie to this list, so forgive me if this has already been covered. Can someone confirm if LB v1 or v2 will work with the above board? I'd be interested in helping test and debug if that would help? Thanks in advance. Phil. -- If it's real... I'm not interested! From acassis at gmail.com Sat Jan 27 12:01:22 2007 From: acassis at gmail.com (Alan Carvalho de Assis) Date: Sat, 27 Jan 2007 11:01:22 +0000 Subject: [LinuxBIOS] sst49lf160c support (patch) In-Reply-To: <20070127013832.GA16781@greenwood> References: <37367b3a0701261045u40a476aav64ddc5ee8196d242@mail.gmail.com> <20070127013832.GA16781@greenwood> Message-ID: <37367b3a0701270301q39c8a01bj63473937fe4e1484@mail.gmail.com> Hi Uwe, 2007/1/27, Uwe Hermann : > > Please add a proper sign-off to your patch/mail, see > http://linuxbios.org/Development_Guidelines#Sign-off_Procedure > Ok, I solved it now. > Also, please update the flashrom README with the new chip. > Updated. > Otherwise the patch looks fine. > Thank you. Signed-off-by: Alan Carvalho de Assis Best regards, -- ------------------------------------------------------------ | Alan Carvalho de Assis | ------------------------------------------------------------ -- N?o importa o que os outros ir?o pensar, A cura para a infelicidade ? a felicidade -------------- next part -------------- A non-text attachment was scrubbed... Name: sst49lf160c.patch Type: text/x-patch Size: 1733 bytes Desc: not available URL: From svn at openbios.org Sat Jan 27 14:39:06 2007 From: svn at openbios.org (svn at openbios.org) Date: Sat, 27 Jan 2007 13:39:06 -0000 Subject: [LinuxBIOS] r2539 - trunk/LinuxBIOSv2/util/flashrom Message-ID: Author: uwe Date: 2007-01-27 14:39:06 +0100 (Sat, 27 Jan 2007) New Revision: 2539 Modified: trunk/LinuxBIOSv2/util/flashrom/README trunk/LinuxBIOSv2/util/flashrom/flash.h trunk/LinuxBIOSv2/util/flashrom/flashchips.c Log: Add support for the SST 49LF160C. Signed-off-by: Alan Carvalho de Assis Acked-by: Uwe Hermann Modified: trunk/LinuxBIOSv2/util/flashrom/README =================================================================== --- trunk/LinuxBIOSv2/util/flashrom/README 2007-01-24 11:09:03 UTC (rev 2538) +++ trunk/LinuxBIOSv2/util/flashrom/README 2007-01-27 13:39:06 UTC (rev 2539) @@ -110,6 +110,7 @@ SST SST-49LF040 SST SST-49LF020A SST SST-49LF080A +SST SST-49LF160C SST SST-49LF002A/B SST SST-49LF003A/B SST SST-49LF004A/B Modified: trunk/LinuxBIOSv2/util/flashrom/flash.h =================================================================== --- trunk/LinuxBIOSv2/util/flashrom/flash.h 2007-01-24 11:09:03 UTC (rev 2538) +++ trunk/LinuxBIOSv2/util/flashrom/flash.h 2007-01-27 13:39:06 UTC (rev 2539) @@ -59,6 +59,7 @@ #define SST_49LF004C 0x54 /* SST 49LF004C device */ #define SST_49LF008C 0x59 /* SST 49LF008C device */ #define SST_49LF016C 0x5C /* SST 49LF016C device */ +#define SST_49LF160C 0x4C /* SST 49LF160C device */ #define PMC_ID 0x9D /* PMC Manufacturer ID code */ #define PMC_49FL002 0x6D /* PMC 49FL002 device code */ Modified: trunk/LinuxBIOSv2/util/flashrom/flashchips.c =================================================================== --- trunk/LinuxBIOSv2/util/flashrom/flashchips.c 2007-01-24 11:09:03 UTC (rev 2538) +++ trunk/LinuxBIOSv2/util/flashrom/flashchips.c 2007-01-27 13:39:06 UTC (rev 2539) @@ -89,6 +89,8 @@ probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc, NULL}, {"SST49LF016C", SST_ID, SST_49LF016C, NULL, 2048, 4 * 1024 , probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc, NULL}, + {"SST49LF160C", SST_ID, SST_49LF160C, NULL, 2048, 4 * 1024 , + probe_49lfxxxc, erase_49lfxxxc, write_49lfxxxc, NULL}, {"Pm49FL004", PMC_ID, PMC_49FL004, NULL, 512, 64 * 1024, probe_jedec, erase_chip_jedec, write_49fl004,NULL}, {"W29C011", WINBOND_ID, W_29C011, NULL, 128, 128, From uwe at hermann-uwe.de Sat Jan 27 15:00:10 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 27 Jan 2007 15:00:10 +0100 Subject: [LinuxBIOS] sst49lf160c support (patch) In-Reply-To: <37367b3a0701270301q39c8a01bj63473937fe4e1484@mail.gmail.com> References: <37367b3a0701261045u40a476aav64ddc5ee8196d242@mail.gmail.com> <20070127013832.GA16781@greenwood> <37367b3a0701270301q39c8a01bj63473937fe4e1484@mail.gmail.com> Message-ID: <20070127140010.GA6231@greenwood> > Signed-off-by: Alan Carvalho de Assis Committed, thanks. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From uwe at hermann-uwe.de Sat Jan 27 15:03:22 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 27 Jan 2007 15:03:22 +0100 Subject: [LinuxBIOS] [PATCH] cleaned up MCP55 chipset code In-Reply-To: <45BAB815.1080700@gmx.net> References: <45BAB815.1080700@gmx.net> Message-ID: <20070127140322.GB6231@greenwood> Hi, yet another update: I added license headers to all files. Yinghai, please complain if any of them is incorrect. 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: mcp55_with_licenses.patch Type: text/x-diff Size: 98481 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From anitha.boyapati at gmail.com Sat Jan 27 20:19:09 2007 From: anitha.boyapati at gmail.com (anitha boyapati) Date: Sun, 28 Jan 2007 00:49:09 +0530 Subject: [LinuxBIOS] build target - error Message-ID: Hi, I heard about linuxbios a couple of days back.I checked out sources and here I am building it. I follow documentation given in linuxbios/documentation.As a starting point I am trying demo example.[Mine is not amd though] [ cd targets ] [sh buildtarget amd/solo] [cd amd/solo/solo] [ make] The build isnot successfull.I get the error as : ------------------------------------------------------------------------------------------- ././auto.inc:84655: Error: junk at end of line, first unrecognized character is `"' ././auto.inc:87289: Error: junk at end of line, first unrecognized character is `"' ././auto.inc:87293: Error: junk at end of line, first unrecognized character is `"' crt0.S:217: Error: junk at end of line, first unrecognized character is `"' crt0.S:220: Error: unknown pseudo-op: `.previous' make[1]: *** [crt0.o] Error 1 make[1]: Leaving directory `/cygdrive/e/bios/LinuxBIOSv2/targets/amd/solo/solo/n ormal' make: *** [normal/linuxbios.rom] Error 1 ---------------------------------------------------------------------------------------------- Can somebody help me out? I work with cygwin -NT 5.1.gcc version is 3.4.4. Thnks in advance. -- anithaboyapati -------------- next part -------------- An HTML attachment was scrubbed... URL: From smithbone at gmail.com Sat Jan 27 22:58:39 2007 From: smithbone at gmail.com (Richard Smith) Date: Sat, 27 Jan 2007 16:58:39 -0500 Subject: [LinuxBIOS] build target - error In-Reply-To: References: Message-ID: <45BBCB0F.2050700@gmail.com> anitha boyapati wrote: > > Can somebody help me out? I work with cygwin -NT 5.1.gcc version is 3.4.4. > Thnks in advance. > There isn't any support for building under cygwin so you are sort of on your own. I suspect that buildtarget didn't generate a proper config file or makefile. Do you have access to a linux machine where you can do a build and then compare the 2 directories? Also look at the output from buildtarget. Did it give any errors? -- Richard A. Smith smithbone at gmail.com From yinghailu at gmail.com Sun Jan 28 03:51:37 2007 From: yinghailu at gmail.com (yhlu) Date: Sat, 27 Jan 2007 18:51:37 -0800 Subject: [LinuxBIOS] [PATCH] cleaned up MCP55 chipset code In-Reply-To: <20070127140322.GB6231@greenwood> References: <45BAB815.1080700@gmx.net> <20070127140322.GB6231@greenwood> Message-ID: <2ea3fae10701271851m1eba0059l775670012849a91b@mail.gmail.com> Good, Please apply at first. we may produce patch regarding with smbus for send/receive byte ( using CMD byte instead of DAT0) thanks YH On 1/27/07, Uwe Hermann wrote: > Hi, > > yet another update: I added license headers to all files. > Yinghai, please complain if any of them is incorrect. > > > Uwe. > -- > http://www.hermann-uwe.de | http://www.holsham-traders.de > http://www.crazy-hacks.org | http://www.unmaintained-free-software.org > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFFu1uqXdVoV3jWIbQRAkvMAJ0cax8BVuxziweAC5Zjm75GeiSQ9QCdF5Vw > I8ofDT2unFhOAdhEnCGEWQA= > =jOp2 > -----END PGP SIGNATURE----- > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > > > From anitha.boyapati at gmail.com Sun Jan 28 06:17:24 2007 From: anitha.boyapati at gmail.com (anitha boyapati) Date: Sun, 28 Jan 2007 10:47:24 +0530 Subject: [LinuxBIOS] build target - error In-Reply-To: <45BBCB0F.2050700@gmail.com> References: <45BBCB0F.2050700@gmail.com> Message-ID: Hi, I started compiling on ubuntu this time.(GCC-4.0.3). I seemed to be having problems with payloads Here is the err list when i tried to 'make' the demo example from docs.: ---------------------------------------------------------------------------------------------------- cp linuxbios_ram.nrv2b linuxbios_ram.rom gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o nm -n linuxbios | sort > linuxbios.map objcopy --gap-fill 0xff -O binary linuxbios linuxbios.strip make[1]: *** No rule to make target `../../../payloads/tg3--ide_disk.zelf', needed by `payload'. Stop. make[1]: Leaving directory `/media/hda6/bios/LinuxBIOSv2/targets/amd/solo/solo/normal' make: *** [normal/linuxbios.rom] Error 1 --------------------------------------------------------------------------------------------------------------------------- So whats this? I have checked out twice just incase I missed some files.Anyhelp is appreciated. On 1/28/07, Richard Smith wrote: > > anitha boyapati wrote: > > > > > Can somebody help me out? I work with cygwin -NT 5.1.gcc version is > 3.4.4. > > Thnks in advance. > > > > There isn't any support for building under cygwin so you are sort of on > your own. I suspect that buildtarget didn't generate a proper config > file or makefile. Do you have access to a linux machine where you can > do a build and then compare the 2 directories? > > Also look at the output from buildtarget. Did it give any errors? > -- > Richard A. Smith > smithbone at gmail.com > > -- anithaboyapati -------------- next part -------------- An HTML attachment was scrubbed... URL: From uwe at hermann-uwe.de Sun Jan 28 11:05:17 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 28 Jan 2007 11:05:17 +0100 Subject: [LinuxBIOS] build target - error In-Reply-To: References: <45BBCB0F.2050700@gmail.com> Message-ID: <20070128100517.GA16527@greenwood> Hi, On Sun, Jan 28, 2007 at 10:47:24AM +0530, anitha boyapati wrote: > cp linuxbios_ram.nrv2b linuxbios_ram.rom > gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o > nm -n linuxbios | sort > linuxbios.map > objcopy --gap-fill 0xff -O binary linuxbios linuxbios.strip > make[1]: *** No rule to make target `../../../payloads/tg3--ide_disk.zelf', > needed by `payload'. Stop. > make[1]: Leaving directory > `/media/hda6/bios/LinuxBIOSv2/targets/amd/solo/solo/normal' > make: *** [normal/linuxbios.rom] Error 1 You need to change the 'payload' lines in targets/amd/solo/Config.lb to point to the payload file you want to use. The file "../../../payloads/tg3--ide_disk.zelf" doesn't exist on your system, right? Change that to /home/foo/whatever.elf, where that file is a payload image (e.g. FILO), see http://linuxbios.org/Payloads. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From uwe at hermann-uwe.de Sun Jan 28 11:09:01 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 28 Jan 2007 11:09:01 +0100 Subject: [LinuxBIOS] [PATCH] cleaned up MCP55 chipset code In-Reply-To: <2ea3fae10701271851m1eba0059l775670012849a91b@mail.gmail.com> References: <45BAB815.1080700@gmx.net> <20070127140322.GB6231@greenwood> <2ea3fae10701271851m1eba0059l775670012849a91b@mail.gmail.com> Message-ID: <20070128100901.GB16527@greenwood> Hi, On Sat, Jan 27, 2007 at 06:51:37PM -0800, yhlu wrote: > Good, Please apply at first. we may produce patch regarding with smbus > for send/receive byte > ( using CMD byte instead of DAT0) OK, great! Please post an Acked-by line, or, alternatively, commit this yourself with all these sign-off lines in the commit message: Signed-off-by: Yinghai Lu Signed-off-by: Ronald G. Minnich Signed-off-by: Carl-Daniel Hailfinger Signed-off-by: Uwe Hermann Acked-by: Yinghai Lu Cheers, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From segher at kernel.crashing.org Sun Jan 28 12:05:52 2007 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 28 Jan 2007 12:05:52 +0100 Subject: [LinuxBIOS] build target - error In-Reply-To: References: Message-ID: <4A9101FE-2EC2-4735-97D7-59AC44B135E0@kernel.crashing.org> > ././auto.inc:84655: Error: junk at end of line, first unrecognized > character is > `"' > ././auto.inc:87289: Error: junk at end of line, first unrecognized > character is > `"' > ././auto.inc:87293: Error: junk at end of line, first unrecognized > character is > `"' > crt0.S:217: Error: junk at end of line, first unrecognized > character is `"' > crt0.S:220: Error: unknown pseudo-op: `.previous' Your assembler doesn't understand ELF-style asm dialect. Try using as cross-compiler to Linux (or, just use Linux itself). Segher From stefan.reinauer at coresystems.de Sun Jan 28 12:22:02 2007 From: stefan.reinauer at coresystems.de (Stefan Reinauer) Date: Sun, 28 Jan 2007 12:22:02 +0100 Subject: [LinuxBIOS] build target - error In-Reply-To: <4A9101FE-2EC2-4735-97D7-59AC44B135E0@kernel.crashing.org> References: <4A9101FE-2EC2-4735-97D7-59AC44B135E0@kernel.crashing.org> Message-ID: <45BC875A.4060708@coresystems.de> Segher Boessenkool wrote: >> ././auto.inc:84655: Error: junk at end of line, first unrecognized >> character is >> `"' >> ././auto.inc:87289: Error: junk at end of line, first unrecognized >> character is >> `"' >> ././auto.inc:87293: Error: junk at end of line, first unrecognized >> character is >> `"' >> crt0.S:217: Error: junk at end of line, first unrecognized >> character is `"' >> crt0.S:220: Error: unknown pseudo-op: `.previous' > > Your assembler doesn't understand ELF-style asm dialect. It looks like some \n vs \r\n problem. There's invisible junk at the end of every single line. Probably requires a patch to romcc or an extra "dos2unix" run. Stefan From segher at kernel.crashing.org Sun Jan 28 12:54:56 2007 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 28 Jan 2007 12:54:56 +0100 Subject: [LinuxBIOS] build target - error In-Reply-To: <45BC875A.4060708@coresystems.de> References: <4A9101FE-2EC2-4735-97D7-59AC44B135E0@kernel.crashing.org> <45BC875A.4060708@coresystems.de> Message-ID: <7D234391-043B-4773-BB69-A9CB15AE126C@kernel.crashing.org> >>> ././auto.inc:84655: Error: junk at end of line, first unrecognized >>> character is >>> `"' >>> ././auto.inc:87289: Error: junk at end of line, first unrecognized >>> character is >>> `"' >>> ././auto.inc:87293: Error: junk at end of line, first unrecognized >>> character is >>> `"' >>> crt0.S:217: Error: junk at end of line, first unrecognized >>> character is `"' >>> crt0.S:220: Error: unknown pseudo-op: `.previous' >> >> Your assembler doesn't understand ELF-style asm dialect. > > > It looks like some \n vs \r\n problem. There's invisible junk at > the end > of every single line. It complains about a double quote, not about the empty string. It also doesn't know ".previous", at which point it is time to give up ;-) > Probably requires a patch to romcc or an extra "dos2unix" run. Nah, LinuxBIOS' assembler code assumes GAS+ELF so you better use that and not some other assembler ;-) You could add code to LB so that it explains what's wrong if no suitable assembler is selected. Segher From uwe at hermann-uwe.de Sun Jan 28 19:27:32 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 28 Jan 2007 19:27:32 +0100 Subject: [LinuxBIOS] Gigabyte GA-6BXD Dual PIII (i440BX) In-Reply-To: <52885.87.194.114.251.1169890260.squirrel@pro.SoftHome.net> References: <52885.87.194.114.251.1169890260.squirrel@pro.SoftHome.net> Message-ID: <20070128182732.GA12582@greenwood> Hi, On Sat, Jan 27, 2007 at 09:31:00AM -0000, Phil Quinton wrote: > I'm a newbie to this list, so forgive me if this has already been covered. > > Can someone confirm if LB v1 or v2 will work with the above board? > > I'd be interested in helping test and debug if that would help? v2: not yet, 440BX is not yet ported, but it's on out todo list. v1: there's some code for GA-6BXC, which sounds like it's similar to your board, but I don't know what the status of the code is... 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 acassis at gmail.com Sun Jan 28 20:54:24 2007 From: acassis at gmail.com (Alan Carvalho de Assis) Date: Sun, 28 Jan 2007 19:54:24 +0000 Subject: [LinuxBIOS] VGA Console does not start if ROM_SIZE > 512 Message-ID: <37367b3a0701281154j5aaa0094kd8b715c019534996@mail.gmail.com> Hi guys, I am testing LinuxBIOS on 2MB flash in tyan s2850. If I compile Linux to 512KB (-36KB from VGA ROM) and complete the head of ROM file with 0's to get 2MB everything work fine, LinuxBIOS starts and I can see the GRUB menu on VGA monitor. This is the working option: option ROM_SIZE = 512*1024-36*1024 If I change it to 1MB or 2MB it don't work: option ROM_SIZE = 2048*1024-36*1024 -- ------------------------------------------------------------ | Alan Carvalho de Assis | ------------------------------------------------------------ -- N?o importa o que os outros ir?o pensar, A cura para a infelicidade ? a felicidade From acassis at gmail.com Sun Jan 28 21:02:47 2007 From: acassis at gmail.com (Alan Carvalho de Assis) Date: Sun, 28 Jan 2007 20:02:47 +0000 Subject: [LinuxBIOS] VGA Console does not start if ROM_SIZE > 512 Message-ID: <37367b3a0701281202n724e669bw72bba305951e8835@mail.gmail.com> Hi guys, I am testing LinuxBIOS on 2MB flash in tyan s2850. If I compile LinuxBIOS to 512KB (-36KB from VGA ROM) and complete the head of ROM file with 0's to get 2MB everything work fine, LinuxBIOS starts and I can see the GRUB menu on VGA monitor. This is the working option: option ROM_SIZE = 512*1024-36*1024 If I change it to 1MB or 2MB VGA console don't work: option ROM_SIZE = 2048*1024-36*1024 But serial console and everything (except VGA) still working. I searched for something related to it on source code, but don't found anything about it. How to fix this problem? Cheers, -- ------------------------------------------------------------ | Alan Carvalho de Assis | ------------------------------------------------------------ -- N?o importa o que os outros ir?o pensar, A cura para a infelicidade ? a felicidade From stepan at coresystems.de Sun Jan 28 21:11:44 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 28 Jan 2007 21:11:44 +0100 Subject: [LinuxBIOS] VGA Console does not start if ROM_SIZE > 512 In-Reply-To: <37367b3a0701281202n724e669bw72bba305951e8835@mail.gmail.com> References: <37367b3a0701281202n724e669bw72bba305951e8835@mail.gmail.com> Message-ID: <20070128201144.GA5108@coresystems.de> * Alan Carvalho de Assis [070128 21:02]: > This is the working option: > option ROM_SIZE = 512*1024-36*1024 > > If I change it to 1MB or 2MB VGA console don't work: > option ROM_SIZE = 2048*1024-36*1024 If you change the ROM_SIZE you also need to change the start of the vga bios: register "rom_address" = "0xfff80000" should be register "rom_address" = "0xffe00000" for a 2MB image -- 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 roger at eskimo.com Mon Jan 29 05:16:50 2007 From: roger at eskimo.com (roger) Date: Sun, 28 Jan 2007 20:16:50 -0800 Subject: [LinuxBIOS] Filo boot from CD-Rom syntax Message-ID: <1170044210.3386.15.camel@localhost2.localdomain> Can somebody please update the Filo README file (and/or the Linuxbios Filo documentation) to including the following concerning CD-ROM device file syntax? ie. CD-ROM device is to be specified as "hdc1" and not "hdc"! Following is the relevant Filo documentation clippings: According to: http://te.to/~ts1/filo/CHANGES "* Support for mounting boot disk image of El Torito bootable CD-ROM. ("hdc1" means the boot disk image of the CD-ROM at hdc.)" However, I only see a very vague reference for the syntax of specifying a CD-ROM drives within Filo's README: "Notation of DEVICE for IDE disk and CD-ROM is same as in Linux (eg. hda1 means the first partition of master device on primary IDE channel)." (With the above Filo README information, the user is going to think "/dev/hdb" or "hdb" instead, FILO wants to see "hdb1"!) -- Roger http://www.eskimo.com/~roger/index.html Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61 Sun Jan 28 20:16:23 PST 2007 From rminnich at gmail.com Mon Jan 29 05:26:09 2007 From: rminnich at gmail.com (ron minnich) Date: Sun, 28 Jan 2007 21:26:09 -0700 Subject: [LinuxBIOS] Filo boot from CD-Rom syntax In-Reply-To: <1170044210.3386.15.camel@localhost2.localdomain> References: <1170044210.3386.15.camel@localhost2.localdomain> Message-ID: <13426df10701282026m31236561jf2c4405b5c43374f@mail.gmail.com> On 1/28/07, roger wrote: > Can somebody please update the Filo README file (and/or the Linuxbios > Filo documentation) to including the following concerning CD-ROM device > file syntax? You probably know more than most of us about this -- I hate to be pushy, but could you write the correct things in there and send me a patch? That way we can be reasonably sure it is right :-) Thanks for the heads up, and thanks in advance for your correction! ron From roger at eskimo.com Mon Jan 29 05:40:17 2007 From: roger at eskimo.com (roger) Date: Sun, 28 Jan 2007 20:40:17 -0800 Subject: [LinuxBIOS] Filo problems booting El Torito (LiveCD) CD-ROMS? Message-ID: <1170045617.3386.34.camel@localhost2.localdomain> Could it be I'm just having problems using Linuxbios & Filo under Qemu emulation instead of actually booting from a flash device? Anyways, here's my debug info: I'm successfully using Qemu to load Linuxbios with a filo payload specifying "hdc1" as my CD-ROM device within the Filo Config file. /dev/hdc = DVD-ROM with DVD+R LiveCD /dev/hdd = CD-ROM with CD-R LiveCD Using an actual CD-ROM (DVD-ROM) device with the Qemu "-cdrom /dev/hdc" option : $ /home/roger/tmp/qemu/bin/qemu -L ~ -nographic -cdrom /dev/hdc -boot d boot: hdc1 malloc_diag: alloc: 208 bytes (5 blocks), free: 16168 bytes (1 blocks) malloc_diag: alloc: 224 bytes (6 blocks), free: 16152 bytes (1 blocks) file_open: dev=hdc1, path= find_ide_controller: found PCI IDE controller 8086:7010 prog_if=0x80 find_ide_controller: secodary channel: compatibility mode find_ide_controller: cmd_base=0x170 ctrl_base=0x374 ide_software_reset: Waiting for ide1 to become ready for reset... ok init_drive: Testing for hdc init_drive: Probing for hdc print_status: IDE: status=0x41, err=0x4 init_drive: Testing for hdc init_drive: Probing for hdc hdc: ATAPI: QEMU CD-ROM init_drive: Testing for hdd init_drive: Probing for hdd print_status: IDE: status=0x0, err=0x1 init_drive: Testing for hdd init_drive: Probing for hdd print_status: IDE: status=0x0, err=0x1 atapi_detect_medium: block_len=2048 atapi_detect_medium: sectors=520415 1016MB medium detected open_pc_partition: pc partition magic number not found open_eltorito_image: El-Torito boot catalog at sector 53 open_eltorito_image: id='' Disc doesn't use boot disk emulation devopen: can't open partition 1 malloc_diag: alloc: 208 bytes (5 blocks), free: 16168 bytes (1 blocks) malloc_diag: alloc: 192 bytes (4 blocks), free: 16184 bytes (1 blocks) boot: hdc1 Using a Loop ISO Filesystem specified as a "-cdrom" option for Qemu: $ /home/roger/tmp/qemu/bin/qemu -L ~ -nographic -cdrom /home/roger/gentoo/install cd/install-x86-minimal-2006.1.iso boot: hdc1 malloc_diag: alloc: 208 bytes (5 blocks), free: 16168 bytes (1 blocks) malloc_diag: alloc: 224 bytes (6 blocks), free: 16152 bytes (1 blocks) file_open: dev=hdc1, path= find_ide_controller: found PCI IDE controller 8086:7010 prog_if=0x80 find_ide_controller: secodary channel: compatibility mode find_ide_controller: cmd_base=0x170 ctrl_base=0x374 ide_software_reset: Waiting for ide1 to become ready for reset... ok init_drive: Testing for hdc init_drive: Probing for hdc print_status: IDE: status=0x41, err=0x4 init_drive: Testing for hdc init_drive: Probing for hdc hdc: ATAPI: QEMU CD-ROM init_drive: Testing for hdd init_drive: Probing for hdd print_status: IDE: status=0x0, err=0x1 init_drive: Testing for hdd init_drive: Probing for hdd print_status: IDE: status=0x0, err=0x1 atapi_detect_medium: block_len=2048 atapi_detect_medium: sectors=27737 54MB medium detected open_pc_partition: pc partition magic number not found open_eltorito_image: El-Torito boot catalog at sector 34 open_eltorito_image: id='' Disc doesn't use boot disk emulation devopen: can't open partition 1 malloc_diag: alloc: 208 bytes (5 blocks), free: 16168 bytes (1 blocks) malloc_diag: alloc: 192 bytes (4 blocks), free: 16184 bytes (1 blocks) boot: hdc1 -- Roger http://www.eskimo.com/~roger/index.html Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61 Sun Jan 28 20:40:16 PST 2007 From roger at eskimo.com Mon Jan 29 06:49:15 2007 From: roger at eskimo.com (roger) Date: Sun, 28 Jan 2007 21:49:15 -0800 Subject: [LinuxBIOS] Filo boot from CD-Rom syntax In-Reply-To: <13426df10701282026m31236561jf2c4405b5c43374f@mail.gmail.com> References: <1170044210.3386.15.camel@localhost2.localdomain> <13426df10701282026m31236561jf2c4405b5c43374f@mail.gmail.com> Message-ID: <1170049755.3386.72.camel@localhost2.localdomain> On Sun, 2007-01-28 at 21:26 -0700, ron minnich wrote: > On 1/28/07, roger wrote: > > Can somebody please update the Filo README file (and/or the Linuxbios > > Filo documentation) to including the following concerning CD-ROM device > > file syntax? > > You probably know more than most of us about this -- I hate to be > pushy, but could you write the correct things in there and send me a > patch? That way we can be reasonably sure it is right :-) > > Thanks for the heads up, and thanks in advance for your correction! > > ron I'm supplying two patches -- preferably patching the FILO README directly on the openbios.org cvs branch. The FILO Readme @: http://openbios.org/viewvc/trunk/filo-0.5/?root=FILO /trunk/filo-0.5/README (I also just posted this to the openbios mailing list but I got an "out of the office until Jan 29 notice.) As an alternative & probably less desirable as the Filo README should have this correction, the Linuxbios FILO page: http://www.linuxbios.org/index.php/FILO -- Roger http://www.eskimo.com/~roger/index.html Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61 Sun Jan 28 21:04:51 PST 2007 -------------- next part -------------- A non-text attachment was scrubbed... Name: FILO.patch Type: text/x-patch Size: 735 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: README.patch Type: text/x-patch Size: 530 bytes Desc: not available URL: From bingxunshi at gmail.com Mon Jan 29 07:14:38 2007 From: bingxunshi at gmail.com (bxshi) Date: Mon, 29 Jan 2007 14:14:38 +0800 Subject: [LinuxBIOS] Filo boot from CD-Rom syntax In-Reply-To: <1170044210.3386.15.camel@localhost2.localdomain> References: <1170044210.3386.15.camel@localhost2.localdomain> Message-ID: >ie. CD-ROM device is to be specified as "hdc1" and not "hdc"! I installed one IDE HDD and one IDE CD-ROM and use filo in etherboot . Filo recognize the IDE hdd as hda, and the Cd-rom as hdb. in Config file I specify: AUTOBOOT_FILE = "hdb:/isolinux/vmlinuz initrd=/isolinux/initrd.img expert nofb acpi=off devfs=nomount #ramdisk_size=65536 console=ttyS0,115200" it installs OS well . it seems we don't need to specify CDROM to hdb1 .hdb works well. bxshi -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger at eskimo.com Mon Jan 29 08:04:01 2007 From: roger at eskimo.com (roger) Date: Sun, 28 Jan 2007 23:04:01 -0800 Subject: [LinuxBIOS] Filo boot from CD-Rom syntax In-Reply-To: References: <1170044210.3386.15.camel@localhost2.localdomain> Message-ID: <1170054241.6667.7.camel@localhost2.localdomain> On Mon, 2007-01-29 at 14:14 +0800, bxshi wrote: > > >ie. CD-ROM device is to be specified as "hdc1" and not "hdc"! > > I installed one IDE HDD and one IDE CD-ROM and use filo in etherboot . > Filo recognize the IDE hdd as hda, and the Cd-rom as hdb. > in Config file I specify: > AUTOBOOT_FILE = "hdb:/isolinux/vmlinuz initrd=/isolinux/initrd.img > expert nofb acpi=off devfs=nomount #ramdisk_size=65536 > console=ttyS0,115200" > > it installs OS well . it seems we don't need to specify CDROM to > hdb1 .hdb works well. I'm working for the "boot:" prompt of file-0.5 & it does require the specific designation of "hdc1" (or other device file with a numeral 1 as the suffix) to be probed properly from the "boot:" prompt. As well as, the filo-0.5/Config file). However, you are right, If you'll notice in my Filo output, Filo is automagically probing both my cdrom drives with only one CD-ROM drive being designated. :-) I'm planning on playing with some of my Atmel and DOC2000(MD2802) flash devices in a couple of days after I solder an extension wires w/ wirewraps from my motherboard 32 Pin DIP/TSOP socket. So, I'll follow-up on this once I'm able to flash w/o issues of yanking PCI cards out of my motherboards to provide space for a ziff socket. >From your notes, I'm speculating too Filo is probably working ok and it might just be having issues under the Qemu emulator. -- Roger http://www.eskimo.com/~roger/index.html Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61 Sun Jan 28 22:56:38 PST 2007 From stefan.reinauer at coresystems.de Mon Jan 29 12:23:59 2007 From: stefan.reinauer at coresystems.de (Stefan Reinauer) Date: Mon, 29 Jan 2007 12:23:59 +0100 Subject: [LinuxBIOS] Filo boot from CD-Rom syntax In-Reply-To: <1170049755.3386.72.camel@localhost2.localdomain> References: <1170044210.3386.15.camel@localhost2.localdomain> <13426df10701282026m31236561jf2c4405b5c43374f@mail.gmail.com> <1170049755.3386.72.camel@localhost2.localdomain> Message-ID: <45BDD94F.3060200@coresystems.de> roger wrote: > I'm supplying two patches -- preferably patching the FILO README > directly on the openbios.org cvs branch. Thanks. Applied. Stefan From uwe at hermann-uwe.de Mon Jan 29 12:24:49 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Mon, 29 Jan 2007 12:24:49 +0100 Subject: [LinuxBIOS] Filo boot from CD-Rom syntax In-Reply-To: <1170049755.3386.72.camel@localhost2.localdomain> References: <1170044210.3386.15.camel@localhost2.localdomain> <13426df10701282026m31236561jf2c4405b5c43374f@mail.gmail.com> <1170049755.3386.72.camel@localhost2.localdomain> Message-ID: <20070129112449.GA17514@greenwood> Hi, On Sun, Jan 28, 2007 at 09:49:15PM -0800, roger wrote: > On Sun, 2007-01-28 at 21:26 -0700, ron minnich wrote: > > On 1/28/07, roger wrote: > > > Can somebody please update the Filo README file (and/or the Linuxbios > > > Filo documentation) to including the following concerning CD-ROM device > > > file syntax? > > > > You probably know more than most of us about this -- I hate to be > > pushy, but could you write the correct things in there and send me a > > patch? That way we can be reasonably sure it is right :-) > > > > Thanks for the heads up, and thanks in advance for your correction! > > > > ron > > I'm supplying two patches -- preferably patching the FILO README > directly on the openbios.org cvs branch. > > The FILO Readme @: > http://openbios.org/viewvc/trunk/filo-0.5/?root=FILO > /trunk/filo-0.5/README > (I also just posted this to the openbios mailing list but I got an "out > of the office until Jan 29 notice.) Please create your patches with 'svn diff' after modifying a checkout of the code. Also, you need to add a sign-off or we won't be able to commit your patches: http://linuxbios.org/Development_Guidelines#Sign-off_Procedure Cheers, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From stefan.reinauer at coresystems.de Mon Jan 29 14:37:52 2007 From: stefan.reinauer at coresystems.de (Stefan Reinauer) Date: Mon, 29 Jan 2007 14:37:52 +0100 Subject: [LinuxBIOS] more big range for HT_CHAIN_UNITID_BASE and HT_CHAIN_UNITID_BASE In-Reply-To: <5986589C150B2F49A46483AC44C7BCA49073C9@ssvlexmb2.amd.com> References: <5986589C150B2F49A46483AC44C7BCA49073C9@ssvlexmb2.amd.com> Message-ID: <45BDF8B0.2040304@coresystems.de> Lu, Yinghai wrote: > More range for HT_CHAIN_UNITID_BASE and HT_CHAIN_END_UNITID_BASE. > For example: in C51/MCP55 or C51/MCP51 > Will allow > 1. C51 at 0x10 to 0x14, and MCP at 0 to 4 > 2. C51 at 1 to 4, and MCP at 7 to 0x0a What? Why? How? > The reason is c51/mcp51/mcp55 reported unitid is 0x0f (far beyond it > needed), and will prevent us from putting them on bus 0. Is this a chipset bug? > Typical values for c51/mcp55 or c51/mcp51: > HT_CHAIN_UNITID_BASE = 0x10 # for C51 > HT_CHAIN_END_UNITID_BASE = 0 # for mcp > > If only have mcp with c51, > HT_CHAIN_UNITID_BASE = 0 # for MCP > #HT_CHAIN_END_UNITID_BASE = 0 # default value 0x20 Can we get this properly documented in the code somewhere? The HT_CHAIN_ stuff is not exactly easy to understand. From acassis at gmail.com Mon Jan 29 16:58:58 2007 From: acassis at gmail.com (Alan Carvalho de Assis) Date: Mon, 29 Jan 2007 15:58:58 +0000 Subject: [LinuxBIOS] VGA Console does not start if ROM_SIZE > 512 In-Reply-To: <20070128201144.GA5108@coresystems.de> References: <37367b3a0701281202n724e669bw72bba305951e8835@mail.gmail.com> <20070128201144.GA5108@coresystems.de> Message-ID: <37367b3a0701290758w1bdf00e6v98ceb4e0f053aa1@mail.gmail.com> Hi Stefan, 2007/1/28, Stefan Reinauer : > If you change the ROM_SIZE you also need to change the start of > the vga bios: > > register "rom_address" = "0xfff80000" > > should be > > register "rom_address" = "0xffe00000" > > for a 2MB image > -- thank you very much. It works perfectly now. Cheers, Alan From roger at eskimo.com Mon Jan 29 20:22:29 2007 From: roger at eskimo.com (roger) Date: Mon, 29 Jan 2007 11:22:29 -0800 Subject: [LinuxBIOS] Filo boot from CD-Rom syntax In-Reply-To: <20070129112449.GA17514@greenwood> References: <1170044210.3386.15.camel@localhost2.localdomain> <13426df10701282026m31236561jf2c4405b5c43374f@mail.gmail.com> <1170049755.3386.72.camel@localhost2.localdomain> <20070129112449.GA17514@greenwood> Message-ID: <1170098549.19607.3.camel@localhost2.localdomain> On Mon, 2007-01-29 at 12:24 +0100, Uwe Hermann wrote: > > > > I'm supplying two patches -- preferably patching the FILO README > > directly on the openbios.org cvs branch. > > > > The FILO Readme @: > > http://openbios.org/viewvc/trunk/filo-0.5/?root=FILO > > /trunk/filo-0.5/README > > (I also just posted this to the openbios mailing list but I got an "out > > of the office until Jan 29 notice.) > > Please create your patches with 'svn diff' after modifying a checkout of > the code. Also, you need to add a sign-off or we won't be able to commit > your patches: > http://linuxbios.org/Development_Guidelines#Sign-off_Procedure > > > Cheers, Uwe. Got it. -- Roger http://www.eskimo.com/~roger/index.html Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61 Mon Jan 29 11:19:07 PST 2007 From michalwan at hotmail.com Tue Jan 30 02:45:41 2007 From: michalwan at hotmail.com (michal wan) Date: Tue, 30 Jan 2007 09:45:41 +0800 Subject: [LinuxBIOS] linuxbios debug full log Message-ID: configure environment in filo-0.4.2 SUPPORT_PCI = 1 PCI_BRUTE_SCAN = 1 DEBUG_ALL = 1 in LinuxBIOSV2510 use targets/artecgroup/dbe61 the problem is "find_ide_controller: PCI IDE #0 not found" the full log is in the attached file any advice would be appreciated! _________________________________________________________________ ???? MSN Explorer: http://explorer.msn.com/lccn -------------- next part -------------- A non-text attachment was scrubbed... Name: linuxbios-debug-log.bz2 Type: application/x-bzip2 Size: 4131 bytes Desc: not available URL: From indrek.kruusa at artecdesign.ee Tue Jan 30 09:02:47 2007 From: indrek.kruusa at artecdesign.ee (Indrek Kruusa) Date: Tue, 30 Jan 2007 10:02:47 +0200 Subject: [LinuxBIOS] linuxbios debug full log In-Reply-To: References: Message-ID: <200701301002.47955.indrek.kruusa@artecdesign.ee> ?hel kenal p?eval (teisip?ev 30 jaanuar 2007 3:45 am) kirjutas michal wan: > configure environment > > in filo-0.4.2 > SUPPORT_PCI = 1 > PCI_BRUTE_SCAN = 1 > DEBUG_ALL = 1 > > in LinuxBIOSV2510 > use targets/artecgroup/dbe61 > > the problem is "find_ide_controller: PCI IDE #0 not found" Originally the dbe61 target doesn't have IDE enabled. Additionally to properly configured resources you must have VSA2 binary (you can get it from AMD). VSA2 software is part of the Geode LX platform. For example without VSA2 you can't get PCI properly working (there isn't PCI headers for devices). You need it for IDE too. cheers, Indrek From russ at ashlandhome.net Tue Jan 30 09:40:26 2007 From: russ at ashlandhome.net (Russ Whitaker) Date: Tue, 30 Jan 2007 00:40:26 -0800 (PST) Subject: [LinuxBIOS] Filo boot from CD-Rom syntax In-Reply-To: <1170044210.3386.15.camel@localhost2.localdomain> References: <1170044210.3386.15.camel@localhost2.localdomain> Message-ID: On Sun, 28 Jan 2007, roger wrote: > Can somebody please update the Filo README file (and/or the Linuxbios > Filo documentation) to including the following concerning CD-ROM device > file syntax? > > ie. CD-ROM device is to be specified as "hdc1" and not "hdc"! > > > Following is the relevant Filo documentation clippings: > > According to: http://te.to/~ts1/filo/CHANGES > "* Support for mounting boot disk image of El Torito bootable CD-ROM. > ("hdc1" means the boot disk image of the CD-ROM at hdc.)" > > > However, I only see a very vague reference for the syntax of specifying a > CD-ROM drives within Filo's README: > > "Notation of DEVICE for IDE disk and > CD-ROM is same as in Linux (eg. hda1 means the first partition of > master device on primary IDE channel)." > > (With the above Filo README information, the user is going to think > "/dev/hdb" or "hdb" instead, FILO wants to see "hdb1"!) > Personally I think that is a "bug" in FILO. "hdx" refers to the entire device "x" "hdx1" refers to the first primary partition of "x" "hdx2" refers to the second primary partition of "x" And since you can't partition a CD-ROM ( or DVD for that mater ) "hdb" should be correct. reference: "man fdisk", etc. russ From ts1 at tsn.or.jp Tue Jan 30 11:32:43 2007 From: ts1 at tsn.or.jp (Takeshi Sone) Date: Tue, 30 Jan 2007 19:32:43 +0900 Subject: [LinuxBIOS] Filo boot from CD-Rom syntax In-Reply-To: References: <1170044210.3386.15.camel@localhost2.localdomain> Message-ID: <20070130103243.GA22462@tsn.or.jp> On Tue, Jan 30, 2007 at 12:40:26AM -0800, Russ Whitaker wrote: > On Sun, 28 Jan 2007, roger wrote: > >Can somebody please update the Filo README file (and/or the Linuxbios > >Filo documentation) to including the following concerning CD-ROM device > >file syntax? > > > >ie. CD-ROM device is to be specified as "hdc1" and not "hdc"! > Personally I think that is a "bug" in FILO. No, this is not a bug. > "hdx" refers to the entire device "x" > "hdx1" refers to the first primary partition of "x" > "hdx2" refers to the second primary partition of "x" "hdb" refers to the entire CD-ROM. "hdb1" refers to the "boot disk image" in the CD-ROM. "Boot disk image" is something like 1.44MB floppy disk image, as specified in El Torito. However, recent distributions don't use the disk image. They use the entire CD-ROM instead, thanks to isolinux. So you can use "hdb" to boot them. Sorry for the confusion. My English was (is) bad, so the README should be re-written anyway to clarify things. -- Takeshi From gregmartin at alcatel-lucent.com Tue Jan 30 18:27:58 2007 From: gregmartin at alcatel-lucent.com (Martin, Greg A (Greg)) Date: Tue, 30 Jan 2007 11:27:58 -0600 Subject: [LinuxBIOS] CoreDuo Support Message-ID: Hi, I am new to the list. I am attempting to port LinuxBios to a CoreDuo Processor coupled with an Intel 3100 system controller. I seem to be having some problem with the memory and cache coherency, but as I am relatively new to x86 (ppc is my background) I am unsure if I am getting the cpu initialized properly. I started with one on the e7520 based systems and seem to have the memory functioning, but memory tests fail with what looks like cache line pushouts of erroneous data. Does this make sense to anybody? Greg From roger at eskimo.com Tue Jan 30 22:52:33 2007 From: roger at eskimo.com (roger) Date: Tue, 30 Jan 2007 13:52:33 -0800 Subject: [LinuxBIOS] Filo boot from CD-Rom syntax In-Reply-To: <20070130103243.GA22462@tsn.or.jp> References: <1170044210.3386.15.camel@localhost2.localdomain> <20070130103243.GA22462@tsn.or.jp> Message-ID: <1170193953.12198.64.camel@localhost2.localdomain> On Tue, 2007-01-30 at 19:32 +0900, Takeshi Sone wrote: > No, this is not a bug. > > > "hdx" refers to the entire device "x" > > "hdx1" refers to the first primary partition of "x" > > "hdx2" refers to the second primary partition of "x" > > "hdb" refers to the entire CD-ROM. > "hdb1" refers to the "boot disk image" in the CD-ROM. > > "Boot disk image" is something like 1.44MB floppy disk image, as > specified in El Torito. > > However, recent distributions don't use the disk image. They use > the entire CD-ROM instead, thanks to isolinux. > So you can use "hdb" to boot them. > > Sorry for the confusion. > My English was (is) bad, so the README should be re-written anyway > to clarify things. What you just wrote, sounds excellent to me. (Is it more proper to post Filo related material to the openbios.org mailing list. If so, I have done so.) -- Roger http://www.eskimo.com/~roger/index.html Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61 Tue Jan 30 13:48:33 PST 2007 From russ at ashlandhome.net Wed Jan 31 00:10:22 2007 From: russ at ashlandhome.net (Russ Whitaker) Date: Tue, 30 Jan 2007 15:10:22 -0800 (PST) Subject: [LinuxBIOS] Filo boot from CD-Rom syntax In-Reply-To: <20070130103243.GA22462@tsn.or.jp> References: <1170044210.3386.15.camel@localhost2.localdomain> <20070130103243.GA22462@tsn.or.jp> Message-ID: On Tue, 30 Jan 2007, Takeshi Sone wrote: > On Tue, Jan 30, 2007 at 12:40:26AM -0800, Russ Whitaker wrote: >> On Sun, 28 Jan 2007, roger wrote: >>> Can somebody please update the Filo README file (and/or the Linuxbios >>> Filo documentation) to including the following concerning CD-ROM device >>> file syntax? >>> >>> ie. CD-ROM device is to be specified as "hdc1" and not "hdc"! > >> Personally I think that is a "bug" in FILO. > > No, this is not a bug. > >> "hdx" refers to the entire device "x" >> "hdx1" refers to the first primary partition of "x" >> "hdx2" refers to the second primary partition of "x" > > "hdb" refers to the entire CD-ROM. > "hdb1" refers to the "boot disk image" in the CD-ROM. > > "Boot disk image" is something like 1.44MB floppy disk image, as > specified in El Torito. The "1" is misleading. It is not a partition. Perhaps it should have been named "hdbi" or the like. The El Torito spec says: "... int 41 is not valid on a CD-ROM." (int 41 reads/writes the partition table) Bios int 13 (low-level disc i/o) is used to fetch a "mode" from the CD: No Emulation Mode Drive A: 1.2 Drive A: 1.44 Drive A: 2.88 Drive C: hard drive reference: http://www.phoenix.com/NR/rdonlyres/98D3219C-9CC9-4DF5-B496-A286D893E36A/0/specscdrom.pdf (Interesting read, and it's not very long - 19 pages and a blank page) Russ From rminnich at gmail.com Wed Jan 31 07:29:39 2007 From: rminnich at gmail.com (ron minnich) Date: Tue, 30 Jan 2007 23:29:39 -0700 Subject: [LinuxBIOS] 16 Mb group buy Message-ID: <13426df10701302229we622b03r52fa84c6ce8b910c@mail.gmail.com> some time ago I offered to do a group buy of the 16 Mbit parts. I'm still willing to do that if we can pick the right part and get the people together. So, again, what's the part, and how many do we all need? 16 Mbit part -- this is pretty exciting, it will allow us to have a pretty full-featured kernel+busybox in there. thanks ron From michalwan at hotmail.com Wed Jan 31 03:19:26 2007 From: michalwan at hotmail.com (michal wan) Date: Wed, 31 Jan 2007 10:19:26 +0800 Subject: [LinuxBIOS] linuxbios debug full log Message-ID: Press for default boot, or for boot prompt... 5^H ^H4^H ^H3^H ^H2^H ^H1^H ^Htimed out boot: hda1:/boot/vmlinuz-2.6.15-1.2054_FC5 root=/dev/hda1 console=tty0 console=ttyS0,115200 malloc_diag: alloc: 376 bytes (5 blocks), free: 16000 bytes (1 blocks) malloc_diag: alloc: 392 bytes (6 blocks), free: 15984 bytes (1 blocks) file_open: dev=hda1, path=/boot/vmlinuz-2.6.15-1.2054_FC5 find_ide_controller: found PCI IDE controller 1022:209a prog_if=0x80 find_ide_controller: primary channel: compatibility mode find_ide_controller: cmd_base=0x1f0 ctrl_base=0x3f4 ide_software_reset: Waiting for ide0 to become ready for reset... ok IDE time out No drive detected on IDE channel 0 devopen: failed to open ide malloc_diag: alloc: 376 bytes (5 blocks), free: 16000 bytes (1 blocks) malloc_diag: alloc: 280 bytes (4 blocks), free: 16096 bytes (1 blocks) boot: hda1:/boot/vmlinuz-2.6.15-1.2054_FC5 root=/dev/hda1 console=tty0 console=ttyS0,115200 _________________________________________________________________ ?????????????? MSN Messenger: http://messenger.msn.com/cn -------------- next part -------------- A non-text attachment was scrubbed... Name: linuxbios-debug-log.bz2 Type: application/x-bzip2 Size: 4131 bytes Desc: not available URL: From stefan.reinauer at coresystems.de Wed Jan 31 09:37:18 2007 From: stefan.reinauer at coresystems.de (Stefan Reinauer) Date: Wed, 31 Jan 2007 09:37:18 +0100 Subject: [LinuxBIOS] 16 Mb group buy In-Reply-To: <13426df10701302229we622b03r52fa84c6ce8b910c@mail.gmail.com> References: <13426df10701302229we622b03r52fa84c6ce8b910c@mail.gmail.com> Message-ID: <45C0553E.2050202@coresystems.de> ron minnich wrote: > some time ago I offered to do a group buy of the 16 Mbit parts. I'm > still willing to do that if we can pick the right part and get the > people together. So, again, what's the part, and how many do we all > need? > > 16 Mbit part -- this is pretty exciting, it will allow us to have a > pretty full-featured kernel+busybox in there. I take a couple. * How many do we need to get them delivered? * How many are still missing to that amount? From talbotx at comcast.net Wed Jan 31 09:45:14 2007 From: talbotx at comcast.net (Adam Talbot) Date: Wed, 31 Jan 2007 00:45:14 -0800 Subject: [LinuxBIOS] 16 Mb group buy In-Reply-To: <45C0553E.2050202@coresystems.de> References: <13426df10701302229we622b03r52fa84c6ce8b910c@mail.gmail.com> <45C0553E.2050202@coresystems.de> Message-ID: <45C0571A.9010404@comcast.net> What part are we looking at? Cost per part? Do you take paypal? -Adam Stefan Reinauer wrote: > ron minnich wrote: > >> some time ago I offered to do a group buy of the 16 Mbit parts. I'm >> still willing to do that if we can pick the right part and get the >> people together. So, again, what's the part, and how many do we all >> need? >> >> 16 Mbit part -- this is pretty exciting, it will allow us to have a >> pretty full-featured kernel+busybox in there. >> > > > I take a couple. > > * How many do we need to get them delivered? > * How many are still missing to that amount? > > > > From stefan.reinauer at coresystems.de Wed Jan 31 13:16:09 2007 From: stefan.reinauer at coresystems.de (Stefan Reinauer) Date: Wed, 31 Jan 2007 13:16:09 +0100 Subject: [LinuxBIOS] CoreDuo Support In-Reply-To: References: Message-ID: <45C08889.5090409@coresystems.de> Hi Greg, Martin, Greg A (Greg) wrote: > Hi, I am new to the list. I am attempting to port LinuxBios to a CoreDuo Processor > coupled with an Intel 3100 system controller. I seem to be having some problem with > the memory and cache coherency, but as I am relatively new to x86 (ppc is my background) > I am unsure if I am getting the cpu initialized properly. I started with one on the e7520 > based systems and seem to have the memory functioning, but memory tests fail with what > looks like cache line pushouts of erroneous data. Does this make sense to anybody? The biggest difference between the 7520 and the 3100 is that the 3100 uses DDR2 memory. This requires a more complex initialization sequence. I suggest the following information: ftp://download.intel.com/design/intarch/datashts/31345802.pdf ftp://download.intel.com/design/intarch/specupdt/31345901.pdf Especially chapters 10.1.2.2 and 12 might be interesting. Given the difference to the e75xx is not too fundamental, you might be lucky with this information, but chances are good that you need the Core Duo BIOS Writer's Guide, which Intel is giving out under an NDA. Best regards, Stefan From stuge-linuxbios at cdy.org Wed Jan 31 17:16:06 2007 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Wed, 31 Jan 2007 17:16:06 +0100 Subject: [LinuxBIOS] 16 Mb group buy In-Reply-To: <45C0553E.2050202@coresystems.de> References: <13426df10701302229we622b03r52fa84c6ce8b910c@mail.gmail.com> <45C0553E.2050202@coresystems.de> Message-ID: <20070131161607.25603.qmail@cdy.org> On Wed, Jan 31, 2007 at 09:37:18AM +0100, Stefan Reinauer wrote: > * How many do we need to get them delivered? I've bought as little as 30 parts (one tube) from a local SST distributor in the past. > * How many are still missing to that amount? The only problem with buying that few parts is that shipping becomes pretty expensive per part. :\ //Peter From c-d.hailfinger.devel.2006 at gmx.net Wed Jan 31 17:28:27 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 31 Jan 2007 17:28:27 +0100 Subject: [LinuxBIOS] 16 Mb group buy In-Reply-To: <45C0571A.9010404@comcast.net> References: <13426df10701302229we622b03r52fa84c6ce8b910c@mail.gmail.com> <45C0553E.2050202@coresystems.de> <45C0571A.9010404@comcast.net> Message-ID: <45C0C3AB.7060603@gmx.net> Adam Talbot wrote: > What part are we looking at? Avnet has the SST49LF016C-33-4C-NHE for $3.0140 in multiples of 30 parts. https://emwcs.avnet.com/webapp/wcs/stores/servlet/SupplierPartView?qasFilter=FALSE&manufacturerPartNumOperator=LEFT_LIKE&manufacturerPartNum=sst49lf016c&catalogId=500201&storeId=500201&productId=2337280&langId=-1 Please make sure you're ordering the PLCC32 variety (this chip is also offered in TSOP32 and Avnet has the part description wrong). I'll probably take 3-5 of them depending on the cost of shipping. Regards, Carl-Daniel -- http://www.hailfinger.org/ From dhbarr at gozelle.com Wed Jan 31 17:48:30 2007 From: dhbarr at gozelle.com (David H. Barr) Date: Wed, 31 Jan 2007 10:48:30 -0600 Subject: [LinuxBIOS] 16 Mb group buy In-Reply-To: <45C0C3AB.7060603@gmx.net> References: <13426df10701302229we622b03r52fa84c6ce8b910c@mail.gmail.com> <45C0553E.2050202@coresystems.de> <45C0571A.9010404@comcast.net> <45C0C3AB.7060603@gmx.net> Message-ID: On 1/31/07, Carl-Daniel Hailfinger wrote: > Adam Talbot wrote: > > What part are we looking at? > > Avnet has the SST49LF016C-33-4C-NHE for $3.0140 in multiples of 30 parts. > I'll probably take 3-5 of them depending on the cost of shipping. I would be interested in a similar number. -dhbarr. From uwe at hermann-uwe.de Wed Jan 31 19:00:34 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Wed, 31 Jan 2007 19:00:34 +0100 Subject: [LinuxBIOS] [PATCH] cleaned up MCP55 chipset code In-Reply-To: <20070128100901.GB16527@greenwood> References: <45BAB815.1080700@gmx.net> <20070127140322.GB6231@greenwood> <2ea3fae10701271851m1eba0059l775670012849a91b@mail.gmail.com> <20070128100901.GB16527@greenwood> Message-ID: <20070131180034.GA19669@greenwood> Hi, On Sun, Jan 28, 2007 at 11:09:01AM +0100, Uwe Hermann wrote: > On Sat, Jan 27, 2007 at 06:51:37PM -0800, yhlu wrote: > > Good, Please apply at first. we may produce patch regarding with smbus > > for send/receive byte > > ( using CMD byte instead of DAT0) > > OK, great! Please post an Acked-by line, or, alternatively, commit this > yourself with all these sign-off lines in the commit message: > > Signed-off-by: Yinghai Lu > Signed-off-by: Ronald G. Minnich > Signed-off-by: Carl-Daniel Hailfinger > Signed-off-by: Uwe Hermann > Acked-by: Yinghai Lu Ping? Can anybody point out problems with the patch or ACK it? I believe it's ready to be committed now. 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 stefan.reinauer at coresystems.de Wed Jan 31 19:09:27 2007 From: stefan.reinauer at coresystems.de (Stefan Reinauer) Date: Wed, 31 Jan 2007 19:09:27 +0100 Subject: [LinuxBIOS] [PATCH] cleaned up MCP55 chipset code In-Reply-To: <20070131180034.GA19669@greenwood> References: <45BAB815.1080700@gmx.net> <20070127140322.GB6231@greenwood> <2ea3fae10701271851m1eba0059l775670012849a91b@mail.gmail.com> <20070128100901.GB16527@greenwood> <20070131180034.GA19669@greenwood> Message-ID: <45C0DB57.6030906@coresystems.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Uwe Hermann wrote: > Hi, > > On Sun, Jan 28, 2007 at 11:09:01AM +0100, Uwe Hermann wrote: >> On Sat, Jan 27, 2007 at 06:51:37PM -0800, yhlu wrote: >>> Good, Please apply at first. we may produce patch regarding with smbus >>> for send/receive byte >>> ( using CMD byte instead of DAT0) >> OK, great! Please post an Acked-by line, or, alternatively, commit this >> yourself with all these sign-off lines in the commit message: >> >> Signed-off-by: Yinghai Lu >> Signed-off-by: Ronald G. Minnich >> Signed-off-by: Carl-Daniel Hailfinger >> Signed-off-by: Uwe Hermann >> Acked-by: Yinghai Lu > > Ping? Can anybody point out problems with the patch or ACK it? I believe > it's ready to be committed now. I have no hardware to try it, but since it is a requirement for the actual board support code, and we will find issues when that is checked in, I say Acked-by: Stefan Reinauer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFwNtXwDe7QTE00RERAg1fAJsFJt+OsSvhTf8j+2lXZ5XFyKVvMwCfZNdA OFGI35mOedEErlV14QsDhww= =y3cC -----END PGP SIGNATURE----- From kononov195-lbl at yahoo.com Wed Jan 31 19:09:47 2007 From: kononov195-lbl at yahoo.com (Roman Kononov) Date: Wed, 31 Jan 2007 12:09:47 -0600 Subject: [LinuxBIOS] help from ubuntu and FC6 experts In-Reply-To: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> References: <13426df10701231020u2723984apb9b1996a2b7cdc65@mail.gmail.com> Message-ID: <45C0DB6B.5010003@yahoo.com> On 01/23/2007 12:20 PM, ron minnich wrote: > I would like to hear reports of building and running linuxbios on > ubuntu and FC6. I've just built working linuxbios. A lot of warnings; no errors. ~>uname -a Linux xd1000 2.6.18-1.2869.fc6 #1 SMP Wed Dec 20 14:51:34 EST 2006 x86_64 x86_64 x86_64 GNU/Linux ~>gcc --version gcc (GCC) 4.1.1 20070105 (Red Hat 4.1.1-51) Roman From eswierk at arastra.com Wed Jan 31 19:15:47 2007 From: eswierk at arastra.com (Ed Swierk) Date: Wed, 31 Jan 2007 10:15:47 -0800 Subject: [LinuxBIOS] [PATCH] cleaned up MCP55 chipset code In-Reply-To: <20070131180034.GA19669@greenwood> References: <45BAB815.1080700@gmx.net> <20070127140322.GB6231@greenwood> <2ea3fae10701271851m1eba0059l775670012849a91b@mail.gmail.com> <20070128100901.GB16527@greenwood> <20070131180034.GA19669@greenwood> Message-ID: On 1/31/07, Uwe Hermann wrote: > Ping? Can anybody point out problems with the patch or ACK it? I believe > it's ready to be committed now. I'll give it a try today. --Ed From kononov195-lbl at yahoo.com Wed Jan 31 19:26:58 2007 From: kononov195-lbl at yahoo.com (Roman Kononov) Date: Wed, 31 Jan 2007 12:26:58 -0600 Subject: [LinuxBIOS] [PATCH] VGA is used before it is initialized In-Reply-To: <45AEB79A.6040308@yahoo.com> References: <45AEB79A.6040308@yahoo.com> Message-ID: <45C0DF72.3040800@yahoo.com> On 01/17/2007 05:56 PM, Roman Kononov wrote: > In the original code vga_inited is set, then run_bios() is > called, which does printk(), which is allowed using the VGA. > > The patch puts vga_inited=1 and run_bios() in the right order. For me, this bug resulted in linuxbios hanged. When console log level is BIOS_INFO and above, linuxbios accesses the video memory of uninitialized VGA hardware, which is bad. Roman From stefan.reinauer at coresystems.de Wed Jan 31 19:48:42 2007 From: stefan.reinauer at coresystems.de (Stefan Reinauer) Date: Wed, 31 Jan 2007 19:48:42 +0100 Subject: [LinuxBIOS] [PATCH] VGA is used before it is initialized In-Reply-To: <45C0DF72.3040800@yahoo.com> References: <45AEB79A.6040308@yahoo.com> <45C0DF72.3040800@yahoo.com> Message-ID: <45C0E48A.4060603@coresystems.de> Roman Kononov wrote: > On 01/17/2007 05:56 PM, Roman Kononov wrote: >> In the original code vga_inited is set, then run_bios() is >> called, which does printk(), which is allowed using the VGA. >> >> The patch puts vga_inited=1 and run_bios() in the right order. > > For me, this bug resulted in linuxbios hanged. > > When console log level is BIOS_INFO and above, linuxbios accesses > the video memory of uninitialized VGA hardware, which is bad. > Can you try the attached patch? It's a little less intrusive -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: vgainit.diff URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature URL: From kononov195-lbl at yahoo.com Wed Jan 31 20:20:51 2007 From: kononov195-lbl at yahoo.com (Roman Kononov) Date: Wed, 31 Jan 2007 13:20:51 -0600 Subject: [LinuxBIOS] [PATCH] VGA is used before it is initialized In-Reply-To: <45C0E48A.4060603@coresystems.de> References: <45AEB79A.6040308@yahoo.com> <45C0DF72.3040800@yahoo.com> <45C0E48A.4060603@coresystems.de> Message-ID: <45C0EC13.9030402@yahoo.com> On 01/31/2007 12:48 PM, Stefan Reinauer wrote: > Can you try the attached patch? It's a little less intrusive It will not compile when CONFIG_CONSOLE_VGA=0. Are you comfortable with more #ifdefs? From kononov195-lbl at yahoo.com Wed Jan 31 20:36:38 2007 From: kononov195-lbl at yahoo.com (Roman Kononov) Date: Wed, 31 Jan 2007 13:36:38 -0600 Subject: [LinuxBIOS] [PATCH] VGA is used before it is initialized In-Reply-To: <45C0E48A.4060603@coresystems.de> References: <45AEB79A.6040308@yahoo.com> <45C0DF72.3040800@yahoo.com> <45C0E48A.4060603@coresystems.de> Message-ID: <45C0EFC6.3050007@yahoo.com> Related question: If I say CONFIG_PCI_ROM_RUN=1 and CONFIG_CONSOLE_VGA=0, why does it skip VGA initialization? The rational here is that I may need a lot of debugging output, but I do not want it to be directed to the VGA, because it is almost useless on the VGA and the users are scared. In the same time I need the VGA to be initialized so that payloads can use it. I would make it so that the VGA is initialized if either flag is set. Anything else is initialized only on CONFIG_PCI_ROM_RUN. From stefan.reinauer at coresystems.de Wed Jan 31 20:50:04 2007 From: stefan.reinauer at coresystems.de (Stefan Reinauer) Date: Wed, 31 Jan 2007 20:50:04 +0100 Subject: [LinuxBIOS] [PATCH] VGA is used before it is initialized In-Reply-To: <45C0EC13.9030402@yahoo.com> References: <45AEB79A.6040308@yahoo.com> <45C0DF72.3040800@yahoo.com> <45C0E48A.4060603@coresystems.de> <45C0EC13.9030402@yahoo.com> Message-ID: <45C0F2EC.1010504@coresystems.de> Roman Kononov wrote: > On 01/31/2007 12:48 PM, Stefan Reinauer wrote: >> Can you try the attached patch? It's a little less intrusive > > It will not compile when CONFIG_CONSOLE_VGA=0. > Are you comfortable with more #ifdefs? eh. of course, sorry. It was just a quick hack I have to admit. From stefan.reinauer at coresystems.de Wed Jan 31 20:52:17 2007 From: stefan.reinauer at coresystems.de (Stefan Reinauer) Date: Wed, 31 Jan 2007 20:52:17 +0100 Subject: [LinuxBIOS] [PATCH] VGA is used before it is initialized In-Reply-To: <45C0EFC6.3050007@yahoo.com> References: <45AEB79A.6040308@yahoo.com> <45C0DF72.3040800@yahoo.com> <45C0E48A.4060603@coresystems.de> <45C0EFC6.3050007@yahoo.com> Message-ID: <45C0F371.7000602@coresystems.de> Roman Kononov wrote: > Related question: > > If I say CONFIG_PCI_ROM_RUN=1 and CONFIG_CONSOLE_VGA=0, > why does it skip VGA initialization? > > The rational here is that I may need a lot of debugging > output, but I do not want it to be directed to the VGA, > because it is almost useless on the VGA and the users are > scared. In the same time I need the VGA to be initialized > so that payloads can use it. > > I would make it so that the VGA is initialized if either > flag is set. Anything else is initialized only on > CONFIG_PCI_ROM_RUN. This sounds reasonable. Is it enough to not set vga_inited if CONFIG_CONSOLE_VGA=0 ? From kononov195-lbl at yahoo.com Wed Jan 31 21:10:49 2007 From: kononov195-lbl at yahoo.com (Roman Kononov) Date: Wed, 31 Jan 2007 14:10:49 -0600 Subject: [LinuxBIOS] [PATCH] VGA is used before it is initialized In-Reply-To: <45C0F371.7000602@coresystems.de> References: <45AEB79A.6040308@yahoo.com> <45C0DF72.3040800@yahoo.com> <45C0E48A.4060603@coresystems.de> <45C0EFC6.3050007@yahoo.com> <45C0F371.7000602@coresystems.de> Message-ID: <45C0F7C9.3080603@yahoo.com> On 01/31/2007 01:52 PM, Stefan Reinauer wrote: > Is it enough to not set vga_inited if > CONFIG_CONSOLE_VGA=0 ? Yes, it is. If CONFIG_CONSOLE_VGA=0, vga_inited is undefined, else vga_inited is defined and should be set. From kononov195-lbl at yahoo.com Wed Jan 31 21:49:36 2007 From: kononov195-lbl at yahoo.com (Roman Kononov) Date: Wed, 31 Jan 2007 14:49:36 -0600 Subject: [LinuxBIOS] [PATCH] e820 table correction Message-ID: <45C100E0.60800@yahoo.com> Hello, I have this situation: Linuxbios boots an Opteron motherboard with 1GB memory. Linuxbios directly loads a recent linux kernel. The memory layout is like this: BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000000e18 (reserved) BIOS-e820: 0000000000000e18 - 00000000000a0000 (usable) BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable) BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved) BIOS-e820: 00000000000f0400 - 0000000040000000 (usable) The f0000-f0400 region contains IRQ and ACPI tables. At some point the kernel builds a resource table containing all physical address ranges and type of hardware the addresses are mapped to. The table is accessible via /proc/iomem: # cat /proc/iomem 00000000-00000e17 : reserved 00000e18-0009ffff : System RAM 000a0000-000bffff : Video RAM area 000c0000-000cbfff : Video ROM 000f0000-000fffff : System ROM e0000000-efffffff : PCI Bus #03 e0000000-efffffff : 0000:03:00.0 f0000000-f3ffffff : GART f4000000-f60fffff : PCI Bus #03 f4000000-f4ffffff : 0000:03:00.0 f5000000-f5ffffff : 0000:03:00.0 f6000000-f601ffff : 0000:03:00.0 f6100000-f6100fff : 0000:00:01.0 f6101000-f6101fff : 0000:00:02.0 f6101000-f6101fff : ohci_hcd f6102000-f6102fff : 0000:00:04.0 f6103000-f6103fff : 0000:00:07.0 f6103000-f6103fff : sata_nv f6104000-f6104fff : 0000:00:08.0 f6104000-f6104fff : sata_nv f6105000-f6105fff : 0000:00:0a.0 f6106000-f61060ff : 0000:00:02.1 f6200000-f620ffff : 0000:40:01.0 As you can see, the 00000000000f0400-0000000040000000 region is not listed. It is not listed because the kernel unconditionally adds "000f0000-000fffff : System ROM" first (look for "request_resource(&iomem_resource, &system_rom_resource)"), and then the attempt to add f0400-40000000 range fails because of overlapping. The kernel does not care that the range is not listed there. Kexec does. It uses the /proc/iomem file to instruct the kexec system call how to place the segments of a new kernel in the physical memory. Kexec fails to start a new kernel because it cannot locate enough physical memory. This must be fixed either in linux or linuxbios. Assuming that linuxbios is to be fixed, I cooked a patch which provides this memory layout: BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000000e18 (reserved) BIOS-e820: 0000000000000e18 - 00000000000a0000 (usable) BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 0000000040000000 (usable) The /proc/iomem contains: # cat /proc/iomem 00000000-00000e17 : reserved 00000e18-0009ffff : System RAM 000a0000-000bffff : Video RAM area 000c0000-000cbfff : Video ROM 000f0000-000fffff : System ROM 00100000-3fffffff : System RAM 00100000-00203c61 : Kernel code 00203c62-00248c3f : Kernel data e0000000-efffffff : PCI Bus #03 e0000000-efffffff : 0000:03:00.0 f0000000-f3ffffff : GART f4000000-f60fffff : PCI Bus #03 f4000000-f4ffffff : 0000:03:00.0 f5000000-f5ffffff : 0000:03:00.0 f6000000-f601ffff : 0000:03:00.0 f6100000-f6100fff : 0000:00:01.0 f6101000-f6101fff : 0000:00:02.0 f6101000-f6101fff : ohci_hcd f6102000-f6102fff : 0000:00:04.0 f6103000-f6103fff : 0000:00:07.0 f6103000-f6103fff : sata_nv f6104000-f6104fff : 0000:00:08.0 f6104000-f6104fff : sata_nv f6105000-f6105fff : 0000:00:0a.0 f6106000-f61060ff : 0000:00:02.1 f6200000-f620ffff : 0000:40:01.0 Kexec is happier with the patch. Regards, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: lb_table.patch Type: text/x-patch Size: 775 bytes Desc: not available URL: From kononov195-lbl at yahoo.com Wed Jan 31 22:02:21 2007 From: kononov195-lbl at yahoo.com (Roman Kononov) Date: Wed, 31 Jan 2007 15:02:21 -0600 Subject: [LinuxBIOS] [PATCH] amdk8_sysconf.h type corrected Message-ID: <45C103DD.60604@yahoo.com> Hello, This fixes a small typo. Regards, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: amdk8_sysconf.patch Type: text/x-patch Size: 439 bytes Desc: not available URL: From stuge-linuxbios at cdy.org Wed Jan 31 22:19:05 2007 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Wed, 31 Jan 2007 22:19:05 +0100 Subject: [LinuxBIOS] [PATCH] amdk8_sysconf.h type corrected In-Reply-To: <45C103DD.60604@yahoo.com> References: <45C103DD.60604@yahoo.com> Message-ID: <20070131211906.17840.qmail@cdy.org> Hi Roman, On Wed, Jan 31, 2007 at 03:02:21PM -0600, Roman Kononov wrote: > This fixes a small typo. Thanks for the patches! Please have a look at http://linuxbios.org/Development_Guidelines and specifically the "How to contribute" section, so your patches can make it into svn faster. //Peter From adam.kaufman at pinnacle.com Wed Jan 31 22:26:10 2007 From: adam.kaufman at pinnacle.com (Kaufman, Adam) Date: Wed, 31 Jan 2007 16:26:10 -0500 Subject: [LinuxBIOS] LinuxBIOS Solaris Dev Message-ID: Hey guys. My company has been looking at using LinuxBIOS for some of our products. Since a fair amount of our customers are using Solaris, we are interested in getting involved with that effort. I've seen a few references to porting the flashrom utility to Solaris, which would be a good priority for us. I poked around the LB source a bit, and it seems like it will be some work to get that running in Solaris. I wondered if you guys have researched this effort at all, and if so, what ideas you had for implementation. Thanks, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Wed Jan 31 22:44:05 2007 From: rminnich at gmail.com (ron minnich) Date: Wed, 31 Jan 2007 14:44:05 -0700 Subject: [LinuxBIOS] LinuxBIOS Solaris Dev In-Reply-To: References: Message-ID: <13426df10701311344r7263318fn70ad85fa157c804f@mail.gmail.com> I don't see a solaris port as a huge problem. flashrom just uses mmap and solaris has that. If you want to try a make and see what happens, I'd like to hear how it goes. ron From uwe at hermann-uwe.de Wed Jan 31 23:19:41 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Wed, 31 Jan 2007 23:19:41 +0100 Subject: [LinuxBIOS] LinuxBIOS Solaris Dev In-Reply-To: <13426df10701311344r7263318fn70ad85fa157c804f@mail.gmail.com> References: <13426df10701311344r7263318fn70ad85fa157c804f@mail.gmail.com> Message-ID: <20070131221941.GA5178@greenwood> On Wed, Jan 31, 2007 at 02:44:05PM -0700, ron minnich wrote: > I don't see a solaris port as a huge problem. flashrom just uses mmap > and solaris has that. > > If you want to try a make and see what happens, I'd like to hear how it goes. Just a short note: if you build flashrom without having the whole LinuxBIOS source tree around, you'll need to copy the file src/include/boot/linuxbios_tables.h into the flashrom source directory and apply the attached patch to make it use the file. Btw, should we apply this in svn anyways? flashrom cannot be used indepently 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: 30_lbtable.patch Type: text/x-diff Size: 379 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From kononov195-lbl at yahoo.com Wed Jan 31 23:25:27 2007 From: kononov195-lbl at yahoo.com (Roman Kononov) Date: Wed, 31 Jan 2007 16:25:27 -0600 Subject: [LinuxBIOS] [PATCH] amdk8_sysconf.h type corrected In-Reply-To: <20070131211906.17840.qmail@cdy.org> References: <45C103DD.60604@yahoo.com> <20070131211906.17840.qmail@cdy.org> Message-ID: <45C11757.9020401@yahoo.com> This fixes a small typo. Signed-off-by: Roman Kononov --- On 01/31/2007 03:19 PM, Peter Stuge wrote: > Please have a look at http://linuxbios.org/Development_Guidelines Thank you -------------- next part -------------- A non-text attachment was scrubbed... Name: amdk8_sysconf.patch Type: text/x-patch Size: 346 bytes Desc: not available URL: From kononov195-lbl at yahoo.com Wed Jan 31 23:36:58 2007 From: kononov195-lbl at yahoo.com (Roman Kononov) Date: Wed, 31 Jan 2007 16:36:58 -0600 Subject: [LinuxBIOS] [PATCH] e820 table correction Message-ID: <45C11A0A.6020704@yahoo.com> Hello, I have this situation: Linuxbios boots an Opteron motherboard with 1GB memory. Linuxbios directly loads a recent linux kernel. The memory layout is like this: BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000000e18 (reserved) BIOS-e820: 0000000000000e18 - 00000000000a0000 (usable) BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable) BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved) BIOS-e820: 00000000000f0400 - 0000000040000000 (usable) The f0000-f0400 region contains IRQ and ACPI tables. At some point the kernel builds a resource table containing all physical address ranges and type of hardware the addresses are mapped to. The table is accessible via /proc/iomem: # cat /proc/iomem 00000000-00000e17 : reserved 00000e18-0009ffff : System RAM 000a0000-000bffff : Video RAM area 000c0000-000cbfff : Video ROM 000f0000-000fffff : System ROM e0000000-efffffff : PCI Bus #03 e0000000-efffffff : 0000:03:00.0 f0000000-f3ffffff : GART f4000000-f60fffff : PCI Bus #03 f4000000-f4ffffff : 0000:03:00.0 f5000000-f5ffffff : 0000:03:00.0 f6000000-f601ffff : 0000:03:00.0 f6100000-f6100fff : 0000:00:01.0 f6101000-f6101fff : 0000:00:02.0 f6101000-f6101fff : ohci_hcd f6102000-f6102fff : 0000:00:04.0 f6103000-f6103fff : 0000:00:07.0 f6103000-f6103fff : sata_nv f6104000-f6104fff : 0000:00:08.0 f6104000-f6104fff : sata_nv f6105000-f6105fff : 0000:00:0a.0 f6106000-f61060ff : 0000:00:02.1 f6200000-f620ffff : 0000:40:01.0 As you can see, the 00000000000f0400-0000000040000000 region is not listed. It is not listed because the kernel unconditionally adds "000f0000-000fffff : System ROM" first (look for "request_resource(&iomem_resource, &system_rom_resource)"), and then the attempt to add f0400-40000000 range fails because of overlapping. The kernel does not care that the range is not listed there. Kexec does. It uses the /proc/iomem file to instruct the kexec system call how to place the segments of a new kernel in the physical memory. Kexec fails to start a new kernel because it cannot locate enough physical memory. This must be fixed either in linux or linuxbios. Assuming that linuxbios is to be fixed, I cooked a patch which provides this memory layout: BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000000e18 (reserved) BIOS-e820: 0000000000000e18 - 00000000000a0000 (usable) BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 0000000040000000 (usable) The /proc/iomem contains: # cat /proc/iomem 00000000-00000e17 : reserved 00000e18-0009ffff : System RAM 000a0000-000bffff : Video RAM area 000c0000-000cbfff : Video ROM 000f0000-000fffff : System ROM 00100000-3fffffff : System RAM 00100000-00203c61 : Kernel code 00203c62-00248c3f : Kernel data e0000000-efffffff : PCI Bus #03 e0000000-efffffff : 0000:03:00.0 f0000000-f3ffffff : GART f4000000-f60fffff : PCI Bus #03 f4000000-f4ffffff : 0000:03:00.0 f5000000-f5ffffff : 0000:03:00.0 f6000000-f601ffff : 0000:03:00.0 f6100000-f6100fff : 0000:00:01.0 f6101000-f6101fff : 0000:00:02.0 f6101000-f6101fff : ohci_hcd f6102000-f6102fff : 0000:00:04.0 f6103000-f6103fff : 0000:00:07.0 f6103000-f6103fff : sata_nv f6104000-f6104fff : 0000:00:08.0 f6104000-f6104fff : sata_nv f6105000-f6105fff : 0000:00:0a.0 f6106000-f61060ff : 0000:00:02.1 f6200000-f620ffff : 0000:40:01.0 Kexec is happier with the patch. Regards, Signed-off-by: Roman Kononov --- -------------- next part -------------- A non-text attachment was scrubbed... Name: lb_table.patch Type: text/x-patch Size: 681 bytes Desc: not available URL: From rminnich at gmail.com Wed Jan 31 23:42:47 2007 From: rminnich at gmail.com (ron minnich) Date: Wed, 31 Jan 2007 15:42:47 -0700 Subject: [LinuxBIOS] [PATCH] amdk8_sysconf.h type corrected In-Reply-To: <20070131211906.17840.qmail@cdy.org> References: <45C103DD.60604@yahoo.com> <20070131211906.17840.qmail@cdy.org> Message-ID: <13426df10701311442u46af36f1n23bc9884419e5c3a@mail.gmail.com> On 1/31/07, Peter Stuge wrote: > Please have a look at http://linuxbios.org/Development_Guidelines > and specifically the "How to contribute" section, so your patches > can make it into svn faster. apropos this comment. Could someone add a little clarification about what happens once an Acked-by: is added? I would assume that if someone with commit rights adds an acked-by:, they take responsibility for the commit. But that is not spelled out. Thanks ron From kononov195-lbl at yahoo.com Wed Jan 31 23:45:56 2007 From: kononov195-lbl at yahoo.com (Roman Kononov) Date: Wed, 31 Jan 2007 16:45:56 -0600 Subject: [LinuxBIOS] [PATCH] romstream off-by-1 Message-ID: <45C11C24.2050502@yahoo.com> This eliminates an illegal and annoying warning. 'rom' is the current read pointer. 'rom_end' points to last valid byte of the stream. Regards, Signed-off-by: Roman Kononov --- -------------- next part -------------- A non-text attachment was scrubbed... Name: romstream.patch Type: text/x-patch Size: 456 bytes Desc: not available URL: